Incident Response Policy

Last updated: 2026-07-19

1. Purpose

This policy describes how AetherCloud detects, contains, and responds to security incidents — from suspected credential leaks to service outages.

2. Severity classification

AetherCloud is operated by a single founder-engineer today, so incident response is owner-led rather than distributed across a team. See our Trust page for how we handle the solo-operator structure.

3. Golden rules

• Contain before you clean. Stop the bleeding first — rotate credentials, isolate the affected system — before doing root-cause analysis.
• Assume secrets are burned. Any credential that may have been exposed during an incident is rotated, not just monitored.
• Communicate honestly. Affected customers are notified with what we know, what we don't yet know, and what we're doing about it — not a delayed, sanitized summary.

4. Response playbooks

We maintain internal, scenario-specific playbooks covering credential leaks, host compromise, ransomware, stolen devices, source-code leakage, payment fraud, and denial-of-service — each with concrete, numbered response steps referencing our actual infrastructure. These are internal operational documents (they describe real system topology) and aren't published verbatim, but their existence and scope are part of what a SOC 2 auditor or security questionnaire can verify on request.

5. Business continuity

We run monthly restore-verification drills and quarterly incident tabletop exercises against our documented recovery-time and recovery-point objectives. See our Data Retention & Deletion Policy for backup retention windows.

6. Customer notification

In the event of a confirmed security incident affecting customer data, we notify affected customers without undue delay once containment is underway, consistent with applicable law and our contractual commitments.