Owner: DevOps Lead (Abdul Moiz) + Legal Lead
Contributors: HoD (technical response) · CEO (P1 notification +
regulatory decisions) · Account Lead (client communication)
Department: D5 — Infrastructure & Compliance
Entity: PrivateAI
Status: Recommended draft · Pending DevOps Lead (Moiz) + Legal Lead review
Version: 0.1 | Last updated: 2026-07-18
Classification: Confidential — Restricted
⚠️ This is a recommended draft. Moiz and the Legal Lead must review
and validate all technical and legal specifics before this is treated as
operational. Regulatory notification timelines and thresholds vary by
jurisdiction and must be confirmed with external legal counsel.
What this workflow does: Governs how PrivateAI detects, contains, investigates,
notifies, and recovers from security incidents and data breaches — including
unauthorised access, data exfiltration, ransomware, credential compromise, and
any event that puts client or PrivateAI data at risk.
What triggers it: Any of the following:
What it produces: A contained and resolved security incident — with a
completed Incident Log (INF-02-DOC-01), client notification where required,
regulatory notification where legally required, and a post-incident review
fed into DEL-10.
Why it matters: PrivateAI processes sensitive client data across regulated
industries (healthcare, finance, legal). A breach that is handled slowly,
incompletely, or without proper notification creates regulatory liability, client
loss, and reputational damage that could end the business. INF-02 is the playbook
that limits damage and demonstrates responsible data stewardship.
⚠️ CEO involved — P1 incidents. CEO notified immediately on any P1
security or data breach. CEO makes all decisions on client notification,
regulatory notification, and public communication. No external communication
goes out without CEO approval.
| Level | Definition | Response time | CEO notified? |
|---|---|---|---|
| P1 — Critical | Confirmed data breach · unauthorised access to client data · ransomware · credential compromise affecting production | Immediate | Yes — immediately |
| P2 — High | Potential breach under investigation · access anomaly · failed intrusion attempt with evidence of persistence | Within 1 hour | Yes — within 1 hour |
| P3 — Medium | Security misconfiguration identified · vulnerability discovered (not yet exploited) · suspicious activity unconfirmed | Within 4 hours | No — HoD informed |
| P4 — Low | Non-critical security finding · informational alert · policy deviation with no immediate risk | Within 24 hours | No |
| Role | Department | Responsibility | CEO? |
|---|---|---|---|
| DevOps Lead (Moiz) | D5 | Incident detection, containment, technical investigation, evidence preservation, recovery | No |
| Legal Lead | D6 | Regulatory notification obligations · legal risk assessment · client notification drafting | No |
| CEO | D6 | Notified immediately on P1/P2 · approves all external communications · leads regulatory notification decisions | Yes — P1/P2 |
| HoD | D4 | Technical response support · delivery impact assessment · P3/P4 notification recipient | No |
| Account Lead | D4 | Client-facing communication (drafted by Legal Lead · approved by CEO) | No |
Step 1 — Incident detected and logged
Step 2 — Severity triage and notifications
Step 3 — Immediate containment
Step 4 — Evidence preservation
Step 5 — Root cause investigation
Step 6 — Client notification (if client data affected)
Step 7 — Regulatory notification (if legally required)
Step 8 — Recovery
Step 9 — Post-incident review
| Tool | How it's used | Agent-ready |
|---|---|---|
| INF-02-DOC-01 | Security Incident Log — primary incident record | Yes — API + MCP |
| Jira | Incident ticket tracking · post-incident action items | Yes — confirmed |
| AWS CloudTrail | Audit logging — all AWS API calls | Yes — API |
| AWS CloudWatch Logs | Application and infrastructure logs | Yes — API |
| S3 | Log archive for evidence preservation | Yes — confirmed |
| AWS IAM | Credential revocation during containment | Yes — API |
| Google Workspace | Incident log · client notifications · regulatory notifications | Yes — API + MCP |
| Discord | Internal incident notifications | Yes — API |
| CEO notification for P1/P2 | No — manual |
| Framework | Client type | Notification authority | Timeframe |
|---|---|---|---|
| GDPR | EU / UK clients | Relevant supervisory authority (e.g. ICO in UK) | 72 hours from awareness |
| HIPAA | US healthcare clients | HHS + affected individuals | 60 days from discovery |
| Australian Privacy Act | AU clients (notifiable data breach) | OAIC | 30 days from awareness |
| MAS TRM | Singapore financial clients | MAS | As soon as reasonably practicable |
⚠️ These timelines are indicative. Confirm with external legal counsel
in each jurisdiction before any notification is made. Legal Lead owns this
confirmation.
| Metric | Type | Target |
|---|---|---|
| P1/P2 incidents — CEO notified within required timeframe (%) | Process | 100% |
| Incidents contained before spread confirmed (%) | Process | 100% |
| Evidence preserved before containment actions (%) | Process | 100% |
| Regulatory notifications submitted within legal timeframe (%) | Process | 100% |
| Post-incident review completed within 5 days of closure (%) | Process | 100% |
| P1 incidents per year (count) | Lagging | 0 — target |
Upstream (triggers INF-02):
Downstream (INF-02 feeds into):
| Version | Date | Description | Author |
|---|---|---|---|
| 0.1 | 2026-07-18 | Recommended draft — P1-P4 severity framework, containment, evidence preservation, investigation, client notification, regulatory notification quick reference (GDPR/HIPAA/APA/MAS TRM), recovery, post-incident review. Pending Moiz and Legal Lead review. | BA (Hammad Akram) |
← Back to Infrastructure Hub · ← Back to Company Operating System