Aeion Aegis for SOC 2 Audit Evidence
SOC 2 + ISO 27001 + GDPR + HIPAA audits don't ask whether you _have_ backups — they ask for **evidence backups work**. Most backup products optimize for "backups taken." Aegis optimizes for "backups verified, restored, and proven." Monthly compliance reports include explicit control mappings, measured restore times, and verification anomaly logs. The evidence is generated automatically — there's nothing to fabricate at audit time.
The Compliance Problem
Every SOC 2 / ISO 27001 / GDPR / HIPAA audit asks variations of the same three questions about backup:
Control Mappings Aegis Ships With Today
The compliance report generator computes these control mappings directly from verification + backup evidence — pass/unmet is derived from real data, not asserted.
What's In a Monthly Aegis Compliance Report
`
Why Verification Evidence Beats Vendor Promises
`
Audit Walkthrough — Aegis-Powered Tenant
`
Failure Modes — When Aegis Is NOT Enough For Your Audit
Being honest: Aegis provides backup-control evidence. It does not provide:
FAQ
Aegis as a feature ships inside Aeion deployments. Aeion's SOC 2 attestation (Type II target) covers the Aegis control implementation. For customer-deployed Aegis instances, the customer's auditor inspects the customer's own deployment — the Aegis monthly report serves as evidence.
Not yet as a self-serve feature — the report today auto-computes SOC 2 / ISO 27001 / GDPR mappings from your verification + backup data. Additional frameworks (FedRAMP, IRAP, IL-4, custom internal frameworks) are roadmap items; the underlying evidence would support them once the mapping logic ships.
The evidence Aegis produces (backup history, verification runs, encryption posture) maps well to §164.308(a)(7)(ii)(A)–(D), but the compliance-report generator doesn't yet auto-emit HIPAA control IDs the way it does for SOC 2 / ISO 27001 / GDPR — you'd assemble the mapping manually from the same underlying data today. For full HIPAA compliance, you also need BAA execution, PHI access logging (covered by audit module), encryption-in-flight (TLS), and a documented incident response plan. Aegis is one component, not the whole HIPAA posture.
Yes. Backups can contain personal data even after the live system has erased it. Aegis supports two patterns: (1) shorter retention window for tenants where erasure timing is critical (e.g., 30-day rolling), (2) explicit erasure log + scheduled re-verification on next snapshot. Detailed runbook in /platform/aegis/getting-started.
Verification runs on a temp DB allocated on the same VPS but using a non-production port + isolated storage. Runs typically take 5-12 minutes for a 50 GB DB. Schedule for low-traffic windows; configurable per tenant.
Most compliance frameworks require 7 years of audit-related records. Aegis stores reports in the same BYOB bucket as backups; lifecycle policy is yours to configure. We recommend Glacier transition after 12 months for cost.
Every verification result is written as an append-only event to the audit log. Hash-chaining and customer-key signing of the audit log are not implemented today — if your auditor requires cryptographic tamper-evidence on the log itself (beyond append-only + access-controlled), confirm that's on your roadmap discussion with us rather than assuming it's shipped.
The data backing the report is exportable raw (CSV + JSONL). Most auditors accept it once they understand the cron is real (not a marketing artifact). For new auditors, we have a 2-page "How Aegis verification works" technical brief to share.
Yes, for any period within the audit log retention window. Reports are rendered on-demand from immutable event data.
Aegis directly addresses A.12.3.1 (Information Backup). It contributes evidence to A.10.1.1 (cryptographic controls — via encryption posture), A.17.1.2 (continuity — via verified RTO), A.18.1.3 (GDPR + personal data). It does not address access control (A.9), HR security (A.7), incident management (A.16) — those need separate tooling.