Security Statement
Effective date: November 5, 2026
Scope and security governance
Algivra AI LLC ("Algivra", "we", "us", or "our") sets mandatory information-security requirements for personnel, contractors, suppliers, and systems handling client information. This statement summarizes those policy requirements for our annotation and related data-handling services. Specific operating arrangements, integrations, approved exceptions, and contractual commitments are established for each engagement. A policy requirement describes the required standard; implemented configurations and operating results are established by the relevant assurance report and supporting records.
Our policies assign management accountability for security, technical operations, incident response, and oversight. They require an inventory of systems, software, devices, identities, data stores, suppliers, and processing locations; a risk assessment at least annually and before material changes; annual policy review; and tracked correction of security findings. Exceptions require documented scope, risk, compensating safeguards, an accountable owner, and an expiry. A client requirement may be varied only with the required written client authorization.
SOC 2 assurance and security documentation
A SOC 2 Type 2 report for Algivra AI LLC covers audio annotation, transcription, adjudication, and related customer-data handling for April 1 through September 30, 2026, addressing Security, Availability, and Confidentiality. The report is dated November 5, 2026. Eligible prospective clients may request the report through info@algivraai.com with "Security documentation" in the subject line, subject to its restricted-use terms and applicable confidentiality requirements.
The report's system description, examination period, tests, results, and boundaries define its assurance coverage. Additional services and later changes require their own scope review. Architecture information, policy details, and relevant assessment or remediation records are provided through controlled client review as appropriate; sensitive infrastructure details and client information are not published on this website.
Personnel screening confidentiality and training
Before client-data access, our policies require employees and contractors to have verified identity and eligibility, approved duties and location, applicable background screening, confidentiality and acceptable-use obligations, role-specific security training, and an approved device. Client-required screening includes seven-year criminal-history and credit checks where lawful and available; a required alternative or exception must be agreed with the client before access.
Security training is required before access, at least annually thereafter, and after relevant changes. It addresses phishing, authentication, confidential data, approved tools, device security, incident reporting, and prohibited copying or sharing. Recruitment and general training must use synthetic data until all client-access prerequisites are met.
Identity access and authentication
Access policy requires unique individual accounts, documented business-need approval, role-based least privilege, separate privileged and service identities, and access reviews at intervals no longer than 90 days. Shared interactive accounts are prohibited. Annotators may access only authorized assignments; independent submissions remain separated until authorized adjudication. Protected application and API requests must check the identity, client, role, assignment, and resource.
All human access to systems processing, storing, or transmitting client data is required to use phishing-resistant multi-factor authentication, including administrative and maintenance paths. Qualifying methods are hardware FIDO2/U2F keys, non-syncable hardware-backed device-bound passkeys, or qualifying device-bound WebAuthn biometrics. SMS, email codes, authenticator TOTP, ordinary push approval, and synced passkeys do not satisfy this standard. Enrollment, recovery, and emergency access must not create a weaker bypass.
Where passwords are used, policy requires unique passwords of at least 14 characters, checks against common or compromised values, adaptive secure hashing, and protection against repeated guessing. Service secrets must be stored in approved secret-management systems, scoped to their task, and kept out of source code, messages, tickets, and logs. Client federation using SAML 2.0 or OpenID Connect is governed by the agreed identity-integration scope.
Immediate access removal and emergency revocation
Policy requires immediate removal of access when employment, engagement, eligibility, or an authorized role ends or changes. Emergency procedures must accept authenticated client or authorized internal instructions and revoke affected accounts, active sessions, tokens, service credentials, queued jobs, exports, and audio-delivery paths. Blocking only new logins is insufficient.
The internal engineering objective is server-side denial within 60 seconds of operator activation. This objective does not include the preceding time to receive and authenticate a request; end-to-end response arrangements and coverage must be agreed and tested for the engagement. Previously received information cannot be recalled.
Employee and contractor device security
Our endpoint policy permits client-data access only from inventoried, approved, company-managed devices meeting the security baseline. It requires full-disk encryption, supported operating systems, current security patches, centrally managed antivirus or endpoint detection and response with automatic updates, disabled routine local administrator privileges, and automatic screen locking after no more than 15 minutes of inactivity.
Device compliance and protection health must be checked before access and during use. Lost, stolen, compromised, or non-compliant devices require prompt reporting, isolation, and access revocation as appropriate. The client-service baseline requires approved, enrolled, company-managed endpoints and excludes unmanaged personal devices. Any proposed alternative device or virtual-workspace model requires a documented security assessment, enforceable safeguards, and any necessary written client approval before use. Alternative models are not automatically covered by the existing SOC 2 examination; their assurance coverage must be assessed separately.
Personnel must protect screens and devices from unauthorized viewing or use, use only approved work locations, and avoid persistent local client content. Cache, temporary files, downloads, extensions, and other residual copies must be included in the endpoint data-handling assessment.
Confidential information and client separation
Policy classifies client audio, transcripts, annotations, alignments, outputs, and identifying project metadata as confidential unless a higher classification applies. Client content must be separated from company business information and other clients' data using the approved environment, storage, database, access-role, key, and backup boundaries. Development and general training environments must remain separate and use synthetic data.
Access must remain limited to the authorized client, engagement, role, and assignment. Changes to a shared or multi-client architecture require a security review and validation of cross-client access denial. Task assignment alone does not establish customer isolation.
Encryption and key management
For in-scope confidential client content, our standard requires AES-GCM-256 encryption at rest, or a stronger client-approved algorithm, across applicable persistent stores, identifying database fields, exports, temporary copies, and backups. Encryption coverage must be documented by data location and key; generic references to AES-256 do not establish the required mode.
Client-separated key arrangements and distinct content, backup, and audit-key roles are required. Key use must be limited to approved workloads and controlled administrators; routine human decryption is prohibited. Emergency key access requires documented authorization, strong authentication, time-limited permissions, logging, and review. Keys must be rotated at least annually and upon suspected compromise or an applicable authorized request; key access and policy changes must be logged and monitored.
Internal and external transfers of client data must use TLS 1.2 or later with strong ciphers and verified certificates; TLS 1.3 is preferred where supported. Production certificates must come from trusted certificate authorities, with renewal, rotation, and revocation procedures. Client content must not be exposed through an unapproved intermediary or decrypted for public internet caching.
Network protection data loss prevention and malware
The network standard requires restrictive inbound and outbound rules, limited public service exposure, private data stores, controlled and logged administration, and layered preventive and detective safeguards. Databases and storage must not be publicly accessible, and personnel must not receive unnecessary cloud-console or infrastructure privileges.
Data-loss prevention requirements restrict removable-storage copying, personal email and messaging, consumer file-sharing services, unapproved uploads, unauthorized extensions, printing, and local downloads. Permitted exports and exceptional bulk transfers require a defined purpose, recipient, scope, authorization, logging, and appropriate access expiry and deletion. Technical restrictions must support the written rules.
Accepted client files and attachments must be quarantined and scanned for malware before processing or sharing, with failed or incomplete checks preventing release. Public inquiry forms are not approved channels for client datasets.
Security logging monitoring and retention
Centralized security logs are required for relevant authentication, account and privilege changes, administrative actions, data access and denial, modification and deletion, key operations, configuration changes, and incident actions. Records must identify who acted, the action and resource, result, source context, and synchronized time, while excluding passwords, tokens, plaintext audio, transcript content, and unnecessary personal information.
Client-service security logs must be protected in a separate security/logging account, with 120 days immediately queryable without archive restoration and encrypted archives retained for at least 1,096 days. Access, integrity, retention changes, missing sources, and forwarding failures require protection and monitoring. This client-service schedule is distinct from the routine marketing-website log retention described in our Privacy Notice.
Policy requires daily security review of relevant alerts, source health, significant access and key anomalies, and open findings, with recorded disposition and escalation. Where a client requires SIEM delivery, the integration must use agreed authentication, schema, receipt verification, retry, and replay controls and meet the applicable synchronization target of no more than 15 minutes. Integration scope and operational acceptance must be established for the engagement.
Cloud configuration and security settings
Our cloud policy requires a documented secure baseline, reviewed configuration changes, continuous monitoring for configuration drift and significant threats, a full posture review at least weekly and after significant changes, alerts for material deviations, and tracked remediation. Required settings include private storage, least privilege, encryption, logging, and restricted administrative paths.
Client programmatic visibility or management of security settings must use an authenticated, narrowly scoped interface with audit logging and policy safeguards. It must not grant unrestricted cloud administration. The interface, supported settings, authorization, and client responsibilities must be agreed and validated before reliance.
Secure development changes and vulnerability management
Software and infrastructure changes must be version controlled, reviewed, security tested, and authorized before production release. Change records must include purpose, affected systems, risk, approval, test results, rollback, and deployment outcome. Emergency changes require a contemporaneous record and retrospective review by the next business day. Secrets, dependencies, and supported software versions must be managed through the development process.
Internal and external vulnerability scans are required at least monthly and after significant application, infrastructure, or security changes. Findings must have severity, affected assets, an owner, a deadline, and verified closure. The remediation standard requires zero-day or Critical fixes within 14 calendar days, High or Important fixes within 30 days, and Medium or Moderate fixes within 60 days of identification or notice, subject to any stricter applicable obligation. Relevant critical-component impacts require client notification within 24 hours of determining the impact.
Independent third-party grey-box penetration testing is required at least annually for the application, authenticated APIs, relevant downstream connections, and hosting environment. High and Critical fixes require independent validation. Assessment findings and remediation status must be retained for authorized client review. The software lifecycle standard requires deprecation planning at least 180 days before support ends and removal from service and client-data access by the support-end date.
Incident response and client notification
Our incident-response policy requires immediate internal reporting and a documented process for identification, triage, containment, investigation, eradication, recovery, and lessons learned. It assigns a response lead and alternate, requires evidence preservation and a timeline, and provides for isolation of affected devices, identities, and data paths.
For suspected or confirmed incidents involving client data, the policy requires notification to the designated client security contact within 24 hours of first awareness, or sooner where law or contract requires. Notification must not wait for final proof of a breach. Communications must distinguish known facts from uncertainty and include affected scope, containment, contact details, and planned updates. Exercises are required at least annually and after material changes; actual incident history and exercise results are maintained separately.
Client data retention deletion and media handling
Client information may be retained only for the permitted purpose and applicable agreed period. Our lifecycle standard sets a target of completing verified deletion within 72 hours of an authenticated client request, and within 30 days after the permitted purpose ends when no earlier trigger applies. The applicable contract, lawful retention restrictions, and agreed treatment of provider-managed remnants determine the specific obligation; these matters must be resolved before relying on the target.
Deletion must address live systems, object versions, database copies, temporary stores, drafts, exports, backups, and archives under Algivra's control. Soft deletion or hiding an object alone is insufficient. A separate content-free deletion record must prevent deleted or terminated-client content from being reintroduced through restoration. Completion must be verified and recorded. Media sanitization must use an appropriate clear, purge, or destroy method aligned with NIST SP 800-88 and applicable contractual requirements.
Backups continuity and recovery
Policy requires daily encrypted backups, logical separation from routine production access and other clients, restricted recovery permissions, protected key arrangements, and monitoring for failed, missed, or incomplete jobs. Backup design must remain compatible with applicable deletion obligations.
The continuity and recovery plan must identify dependencies, recovery sequence, responsible operators and alternates, communications, and agreed recovery-time and recovery-point objectives. Technical restoration must be tested in an isolated environment before operational readiness, at least quarterly thereafter, and after material backup changes. Tests must record actual recovery times, completeness, application function, access protections, and exclusion of deleted data. Availability commitments and recovery architecture are defined per engagement; this statement does not promise uninterrupted service or multi-region failover.
Suppliers locations and physical safeguards
Suppliers and subcontractors with relevant access require documented risk review, confidentiality and security terms, permitted purposes and locations, incident and deletion obligations, and any required client authorization. Reviews are required before engagement and at least annually, with additional review according to risk. Production processing and remote access must be restricted to authorized personnel, approved suppliers, and client-approved countries. Mainland-China production access is excluded unless the client specifically authorizes it in writing. Changes to processing countries, remote-access locations, or relevant subprocessors require review and any necessary client approval before access is expanded.
The scoped service described in the SOC 2 report uses AWS cloud infrastructure. AWS is responsible for its provider-operated data-center physical and environmental controls; Algivra remains responsible for its own application, configuration, access, and supplier oversight. Provider certifications do not automatically establish the security of Algivra's configurations or every additional service.
Client instructions AI tools and architecture
Client content must be used only to provide the authorized service. Our policy prohibits unauthorized resale, publication, reuse for another client, or model training. Client content must not be placed into unapproved generative-AI, automated speech-recognition, analytics, personal communication, or file-sharing services. Human-transcription engagements that prohibit an automated first pass must follow that restriction. Any new AI, payment, data-use, or integration feature requires a scope and risk review before introduction.
Architecture and data-flow records must identify receipt, storage, processing, authorized personnel and locations, adjudication, delivery, retention and deletion, backups, trust boundaries, client integrations, and relevant third parties. They must be updated after material changes. Client data must enter through an approved transfer channel, remain associated with the correct engagement, and be delivered only to an approved destination. Client and provider responsibilities must be documented before processing.
Security contact and updates
For security questions, assurance-document requests, or suspected security issues involving Algivra, email info@algivraai.com with "Security" in the subject line. Provide a concise description without including credentials, confidential datasets, or sensitive personal information. Client contractual escalation routes take precedence for urgent engagement matters. This contact does not grant permission to test systems without authorization.
See our Privacy Notice for website and business-contact information practices and privacy requests. We review this statement as policies, service arrangements, or assurance coverage change and display the effective date of the current version.