Security

We maintain a written information security programme with administrative, technical and physical safeguards proportionate to the sensitivity of the data we handle. A named individual is accountable for it. It is reviewed at least annually and after any material system change or security incident.

The programme is designed to meet the requirements that apply to a third-party service provider under:

• the GLBA Safeguards Rule, 16 C.F.R. Part 314
• state insurance data security laws modelled on the NAIC Insurance Data Security Model Law (#668)
• 23 NYCRR § 500.11, including the multi-factor authentication and encryption requirements at § 500.11(b)
• the AICPA Trust Services Criteria for Security

We perform a documented written risk assessment at least annually, identifying foreseeable internal and external threats, assessing likelihood and impact, and evaluating whether existing controls are sufficient.

On request and under NDA we provide an evidence package: the SOC 2 report, penetration test summary, subprocessor list, business continuity summary and an incident response plan summary.

• Multi-factor authentication is enforced for all personnel access to production systems, source repositories, cloud consoles and administrative interfaces, and is available and enforced for customer users.
• Access to customer data is role-based and least-privilege. Standing production access to unmasked claim file data is minimised; where required it is just-in-time, time-boxed, approved and logged.
• Access rights are reviewed at least quarterly, and revoked within 24 hours of a departure or role change.
• Shared accounts are prohibited. Secrets live in a managed secrets service and are rotated on departure and at least annually.
• Customer data is never used in development, testing or demonstration environments. Test data is synthetic or irreversibly de-identified.

All customer data in transit over public networks is encrypted with TLS 1.2 or higher using modern cipher suites; plaintext protocols are disabled. All customer data at rest - databases, object storage, search indices, queues, caches and backups - is encrypted with AES-256 or stronger. Keys are held in a dedicated key management service, access-controlled separately from the data they protect, and rotated under our key management standard.

Customer data is logically segregated by tenant identifier, enforced at the application and data-access layer. Where an order form specifies a single-tenant or customer-VPC deployment, segregation is additionally enforced at the infrastructure layer.

We do not commingle customer data across tenants in any index, embedding store, vector database, cache or model artefact.

Third-party model providers are engaged under enterprise agreements with zero-data-retention or minimum-retention terms, with training and human review for improvement disabled. Each provider's retention posture is published on our subprocessor page.

Prompts and outputs containing customer data are treated as customer data for every purpose - encryption, access control, logging and deletion.

We apply controls designed to mitigate prompt injection from untrusted content inside submitted claim documents. Content in a claim file is untrusted input and no such control is fully effective, which is one reason the required human review of output is a contractual obligation rather than a recommendation.

For every investigation output we record the model version, the input documents referenced, the sequence of automated steps executed and the timestamp, and make that audit trail available to the customer.

Material changes to the models or model providers behind the Services go through documented review and regression evaluation, and customers receive advance notice where we expect the change to materially affect output.

The Services run on Amazon Web Services in the region stated on the customer's order form, in private subnets with no direct public ingress to data stores, behind load balancers with a web application firewall and default-deny security groups. We review AWS's own audit reports annually.

Vulnerability remediation targets

Changes to production require peer review, automated testing and an approved, auditable deployment pipeline. Emergency changes are documented and reviewed retrospectively.

Security-relevant events - authentication, authorisation failures, privileged actions, access to claim file data, configuration changes and data exports - are logged centrally, protected against tampering, retained for the duration of the subscription term unless the customer instructs otherwise, and alerted on for anomalous access patterns.

Customer data is backed up on an automated encrypted schedule, and restore procedures are tested at least annually. We maintain a documented business continuity and disaster recovery plan, tested annually, with a summary available under NDA.

Background checks are performed on all personnel with access to customer data before access is granted, to the extent law permits. All personnel sign confidentiality agreements that survive their engagement. Security and privacy training is delivered at onboarding and at least annually, with role-specific training for engineers and HIPAA training where applicable. A documented sanctions policy applies to violations.

We maintain an inventory of every vendor with access to customer data. Each is assessed before engagement and reassessed at least annually, and each is bound by written obligations no less protective than our own - including MFA, encryption of nonpublic information, prompt incident notification and the prohibition on model training. The current list is published on our subprocessors page, and we give 30 days' notice before adding one.

We maintain a documented incident response plan covering detection, triage, containment, eradication, recovery, notification and post-incident review, tested at least annually including a tabletop exercise.

We provide the information customers need for their own notifications, cooperate fully with their investigation, and do not make public statements identifying a customer without their consent unless law requires it. The customer, as the party with the regulatory obligation, controls the content and timing of notifications to regulators and individuals.

We bear our own remediation costs, deliver a written root-cause analysis within 30 days of closure, and preserve forensic evidence for the customer's investigators and regulators.

We follow a secure development lifecycle: threat modelling for material new features, peer review, secret scanning, static analysis and dependency scanning in continuous integration. Production credentials are never committed to source control.

Responsible disclosure: security@gethesperai.com. We acknowledge reports within two business days and will not pursue legal action against good-faith researchers who follow coordinated disclosure and avoid privacy violations, data destruction and service degradation.

Customer data is retained for the duration of the subscription term unless the customer instructs otherwise in writing. A customer may at any time instruct us to shorten retention, delete identified data, or hold data longer, and we give effect to that instruction within 30 days subject to law and litigation holds. On termination, customers have 30 days to export; we delete from production within 60 days and from backups within a further 90 days, except where law or a litigation hold requires retention. Deletion is by cryptographic erasure or secure overwrite; physical media are destroyed to NIST SP 800-88. We certify deletion in writing on request.