// scope
This procedure applies to incidents on systems we operate for clients under a signed MSA + SoW. For personal-data incidents, our DPA commitments control in addition to this procedure. For research on our AI systems, our responsible-disclosure policy applies in addition.
Last updated: August 16, 2026
1. Definitions
- "Incident" means an event that has, or could reasonably have, an adverse effect on the confidentiality, integrity, or availability of a system or the data it processes.
- "Security incident" means an incident caused by malicious or unauthorized activity (intrusion, malware, denial-of-service, unauthorized access, exfiltration, tampering).
- "Personal-data breach" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed (Article 4(12) GDPR).
- "Confirmed" means we have reasonable grounds to believe the incident occurred, after triage. Notification clocks run from confirmation, not from initial suspicion.
2. Response team
- Incident Commander (IC). Senior engineer on-call; owns the response and the customer comms.
- Security Lead. Owns triage, forensic preservation, containment strategy.
- Operations Lead. Owns system-level containment, recovery, and rollback.
- Communications Lead. Owns status-page updates, customer notifications, regulator notifications.
- Legal / Compliance. Owns regulatory clock, DPA obligations, and outside-counsel engagement.
- Outside counsel and forensic firm. Retained under retainer for Sev-1 incidents; engaged within 4 hours of Sev-1 confirmation.
3. Response phases
We follow NIST SP 800-61 Rev. 3: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity. Each phase has documented checklists and time targets.
4. Detection and triage
- Sources: SIEM rules, anomaly detection on auth and data-access logs, customer reports, vendor advisories, the bug-bounty queue, and the responsible-disclosure queue.
- Triage target: severity-classified within 30 minutes of detection. Severity uses the Sev-1 to Sev-4 scale in the SLA.
- Escalation to Incident Commander for any Sev-1 or Sev-2.
5. Containment
- Short-term. Isolate affected systems (revoke credentials, take systems off the network, block malicious traffic at the edge). Preserve volatile evidence first.
- Long-term. Apply patches, rebuild from known-good images, force-rotate secrets, restore from clean backup.
- Customer. For Sovereign-tier, coordinate containment steps that affect customer data; for others, communicate containment status within the SLA response targets.
6. Eradication and recovery
- Remove the threat (delete malware, close the access vector, rebuild compromised components).
- Recover systems from clean backups or rebuild from infrastructure-as-code.
- Validate integrity before bringing systems back into production.
- Monitor at heightened sensitivity for at least 14 days after a Sev-1 or Sev-2.
7. Post-incident review
- A PIR is held within 5 business days of any Sev-1 or Sev-2.
- The PIR identifies root cause, contributing factors, detection latency, containment latency, and action items with owners and due dates.
- The customer-facing PIR is shared with affected customers within 10 business days.
- Trends across PIRs are reviewed quarterly by the leadership team.
8. Customer notification
| Severity | Initial customer notification | Status updates | Final PIR |
|---|---|---|---|
| Sev-1 | Within 60 minutes of confirmation | Every 60 minutes until contained | Within 10 business days |
| Sev-2 | Within 4 hours of confirmation | Every 4 hours until contained | Within 15 business days |
| Sev-3 | Next business day | On milestone | On request |
| Sev-4 | On request | On milestone | Not required |
Notification goes to the contact on file for each engagement, plus any address designated as a security contact in the SoW. If you need notifications delivered to a different mailbox (for example, your SOC), tell us at signing.
9. Regulator and law-enforcement notification
- We cooperate with valid subpoenas, search warrants, and court orders.
- Where we are the controller, we make the regulator notification (for example, breach notification under U.S. state law).
- Where you are the controller, we provide you with the information you need to make the notification, within the DPA timelines (typically 48 hours for GDPR, comparable for U.S. state laws).
- We do not publicly disclose an incident until you have had a reasonable opportunity to make your own notifications, unless required by law.
10. Personal-data breach commitments
Per our DPA:
- We notify you of a personal-data breach within 48 hours of confirmation, regardless of the operational severity.
- The notification includes the information required by Article 33(3) GDPR to the extent known at the time, and we update you as the investigation progresses.
- For U.S. state-law breaches, we cooperate to support your notification obligations; we are not your notification processor.
11. Subprocessor incidents
When a subprocessor notifies us of an incident that affects your data, we (a) confirm the scope with the subprocessor, (b) notify you per the table in Section 8, and (c) coordinate the response and any necessary customer notifications. Our current subprocessor list is at /legal/subprocessors.
12. Changes
We review this procedure quarterly and after any Sev-1. Material changes are communicated to active clients.
13. Contact
Security incidents and reports: security@empowered.guru (24/7 for Sovereign customers). For research on our AI systems, see our responsible disclosure policy.