Security Policy

We design against four adversaries: an external attacker seeking unpublished findings or victim data; an insider at a customer organisation seeking evidence they are not entitled to see; a party with an interest in altering the record to change a conclusion; and an accidental loss or misconfiguration. Controls below map to those four.

• TLS 1.2 or higher for all transport, with modern cipher suites and HSTS.
• AES-256 encryption at rest for the database, object storage and backups.
• Managed key rotation with keys stored separately from the data they protect.
• Passwords stored only as salted hashes; plaintext is never seen, logged or recoverable by us.

• Row-level authorisation at the database: a case record is reachable only by an authenticated principal holding membership of that case.
• Case roles — owner, investigator, contributor, observer — with write, verify and sign capabilities separated.
• Named individual accounts only; credential sharing is prohibited and detectable.
• TOTP multi-factor authentication, enrollable by any user and enforceable tenancy-wide.
• Federated sign-in with Google Workspace and Microsoft Entra ID so that your own joiner-mover-leaver process governs access.
• Internal access is least-privilege and just-in-time; no engineer holds standing access to customer case content, and every access is written to the customer-visible audit chain.

Every material action — evidence added, verification state changed, hypothesis edited, solution computed, report signed — is appended to a SHA-256 hash-chained audit ledger. Each entry commits to the digest of its predecessor, so removing or altering any historical entry invalidates every subsequent link and is detectable by recomputation.

Chain-of-custody manifests and released reports are canonicalised, digested, and bound to the audit-chain head at the moment of signature, producing an artefact a third party can verify independently of us. This is what allows an output to survive challenge in a regulatory or litigation setting.

• Logical tenant isolation; production data is never copied into development or test environments.
• Encrypted backups with point-in-time recovery and periodic documented restoration tests.
• Dependency and container scanning in the build pipeline; security patches applied to severity-based SLAs — critical within 72 hours, high within 7 days.
• Change management with peer review and audited deployments.
• Periodic third-party penetration testing; summary reports available to enterprise customers under NDA.
• Personnel confidentiality undertakings, screening where lawful, and mandatory training covering security and Annex 13 confidentiality.

We maintain a documented incident response plan with defined severities, an on-call rotation, and post-incident review.

Security incidents affecting customer data are notified to the customer's designated contact without undue delay and within forty-eight (48) hours of confirmation, with the facts known at the time and rolling updates. Personal-data breaches follow the notification terms in the DPA.

We support customer-side forensics with audit-chain extracts and access logs.

Production runs on redundant managed infrastructure with automated failover. Recovery objectives: RPO 15 minutes, RTO 4 hours for the production platform. During an active hull-loss search we treat availability incidents at the highest severity because a delay can affect the disposition of search assets at sea.

Report vulnerabilities to security@seyaero.com. We acknowledge within two (2) business days, trace and triage within five (5), and will keep you updated to resolution.

We commit not to pursue legal action against good-faith researchers who avoid privacy violations, data destruction and service degradation, who test only against their own accounts or an environment we designate, and who give us reasonable time to remediate before public disclosure. Do not attempt to access another customer's case data under any circumstances; stop immediately and report if you obtain it accidentally.

The controls described here are implemented and operating. Formal third-party attestation is on our roadmap; we do not claim SOC 2, ISO/IEC 27001 or any certification we have not obtained, and we will state the status plainly in any procurement questionnaire. Customers may audit under the terms of the DPA in the meantime.