Incident Response Policy & Procedure

Purpose

This document establishes procedures for detecting, responding to, recovering from, and learning from information security incidents affecting the Provii platform.

Scope

This procedure applies to all security incidents affecting:

• Provii platform services (provii-verifier including hosted mode, provii-issuer, wallet apps)
• Development and deployment infrastructure
• Cryptographic key material
• Team member accounts and access credentials
• Source code repositories
• Customer-facing services

Definitions

Security Incident

An event that compromises or threatens the confidentiality, integrity, or availability of Maelstrom AI systems or information.

Examples include:

• Unauthorized access to systems or data
• Compromise of cryptographic signing keys
• Service outages or degraded performance
• Malware or malicious code detected
• Data exfiltration attempts
• Successful phishing or social engineering
• Vulnerability exploitation
• Supply chain compromise
• DDoS attacks affecting availability

Security Event

An observable occurrence that may or may not be a security incident (requires investigation).

Examples: Failed login attempts, unusual API traffic patterns, security scan findings

Incident Severity Levels

We categorise incidents by severity to determine response urgency and escalation:

Incident Response Lifecycle

graph LR
    A[Detect] --> B[Assess]
    B --> C[Contain]
    C --> D[Eradicate]
    D --> E[Recover]
    E --> F[Learn]
    F --> G[Close]

Phase 1: Detection

Detection Sources

We detect incidents through multiple channels:

Reporting an Incident

Any team member who detects a potential security incident must report it immediately.

Contact Methods (in order of preference):

1. Email: security@maelstrom.au (monitored regularly; response times may vary outside business hours)
2. Direct Contact: Security Lead (for urgent issues)
3. GitHub Security Advisory: For code vulnerabilities (private disclosure)

What to Include:

• What you observed (specific symptoms)
• When it was first noticed
• Which systems/services are affected
• Any actions already taken
• Your assessment of severity (if known)

Phase 2: Assessment

Initial Triage

Security Lead performs initial triage:

Impact Assessment

Determine:

• Scope. Which systems, services, or data are affected?
• Access. Has unauthorized access occurred?
• Data. Is any sensitive data (secrets, keys) compromised?
• Duration. How long has the incident been occurring?
• Customers. Are customer services impacted?

Key Questions for Zero knowledge Context:

• Is PII at risk? (Answer: No. Maelstrom AI-operated services don’t store PII.)
• Are signing keys compromised?
• Is proof verification integrity affected?
• Is service availability impacted?

Phase 3: Containment

Goal: Stop the incident from spreading or worsening while preserving evidence.

Short-Term Containment

Immediate actions to limit damage:

wrangler secret put COMPROMISED_SECRET --env production
# Immediately rotates secret in Workers

# Emergency deployment (P0/P1 only)
git checkout main
git pull
# Apply hotfix
git commit -m "Security hotfix: [CVE-ID] - [brief description]"
git push
# Triggers automated deployment

Long-Term Containment

Stabilize systems while preparing permanent fixes:

• Deploy temporary patches or configuration changes
• Implement additional monitoring
• Apply stricter access controls
• Document containment actions for future reference

Phase 4: Eradication

Goal: Eliminate the root cause of the incident.

Root Cause Analysis

Conduct investigation to determine:

• How did the incident occur? (attack vector)
• Why did controls fail? (gap in defences)
• When did it start? (timeline reconstruction)
• Who was responsible? (if relevant, for insider threats)

Remediation Actions

Based on root cause, implement permanent fixes:

Verification

Confirm eradication through:

• Security testing (penetration test, vulnerability scan)
• Code review of fixes
• Monitoring for recurrence
• Third-party verification (if appropriate)

Phase 5: Recovery

Goal: Restore systems to normal operation and verify security.

Service Restoration

Post-Recovery Monitoring

Enhanced monitoring for 7 days:

• Increased audit log review frequency
• Additional alerting for similar indicators
• Daily check-ins with response team

Phase 6: Lessons Learned

Goal: Improve security posture to prevent recurrence.

Post-Incident Review

Timing: Within 5 business days of incident closure

Attendees: Response team + ISMS Owner

Agenda:

1. Timeline Review: What happened and when?
2. Response Evaluation: What went well? What didn’t?
3. Root Cause: Why did this happen?
4. Improvements: What can we do better?
5. Action Items: Specific improvements with owners and deadlines

Post-Incident Report

Document the incident (template):

## Incident Summary
- Incident ID: INC-2025-XXX
- Severity: [P0/P1/P2/P3]
- Detection Date: YYYY-MM-DD HH:MM UTC
- Resolution Date: YYYY-MM-DD HH:MM UTC
- Duration: X hours

## What Happened
[2-3 sentence summary]

## Timeline
- [HH:MM] Event 1
- [HH:MM] Event 2
...

## Impact
- Services Affected: [list]
- Customer Impact: [description]
- Data Affected: [none/description]

## Root Cause
[Technical explanation]

## Resolution
[What was done to fix it]

## Lessons Learned
**What Went Well**:
- [list]

**What Needs Improvement**:
- [list]

## Action Items
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| [description] | [role] | YYYY-MM-DD | Open/Done |

## Prevention
[How we'll prevent this in the future]

Follow-Up Actions

• Update Risk Register with new risks identified
• Update Statement of Applicability with control improvements
• Revise procedures if process gaps identified
• Conduct training if knowledge gaps identified
• Share lessons learned with team (blameless post-mortem)

Public Transparency: For incidents that don’t compromise operational security:

• Publish sanitized post-mortem (remove sensitive details)
• Update public security documentation
• Contribute findings to community (e.g., vulnerability databases)

Communication Guidelines

Internal Communication

During Active Incident:

• Use dedicated communication channel (e.g., Signal group, Slack war room)
• Provide regular updates (every 30min for P0/P1, hourly for P2)
• Document all actions in incident ticket

After Resolution:

• Conduct post-mortem meeting
• Share lessons learned with entire team
• Update documentation

External Communication

Status Page (status.provii.app - if implemented):

• Update within 15 minutes for P0/P1
• Provide status updates every hour during incident
• Final “resolved” update with brief summary

Customer Communication:

• P0/P1. Direct email to affected customers
• P2. Status page or blog post if customer-facing
• P3. No communication unless specifically requested

Public Disclosure:

• Sanitized post-mortems for learning opportunities
• CVE disclosure for code vulnerabilities (after fixes deployed)
• Coordinated disclosure with security researchers (90-day standard)

What NOT to disclose:

• Specific API keys, tokens, or secrets (even if rotated)
• Detailed attack vectors that could aid future attackers
• Customer-specific information
• Unpatched vulnerabilities

Privacy Breach Notification Procedures

Overview

While Maelstrom AI’s architecture minimises personal data processing, certain incidents may constitute a personal data breach under GDPR Article 4(12), requiring specific notification procedures beyond standard incident response.

This section establishes procedures for:

• Identifying privacy breaches vs. general security incidents
• Meeting GDPR’s 72-hour notification requirement (Article 33)
• Notifying data subjects when required (Article 34)
• Maintaining a breach register for supervisory authority inspection

Privacy Breach Classification

What is a Personal Data Breach?

GDPR Article 4(12) Definition:

A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

Key Components:

1. Confidentiality breach: Unauthorized disclosure or access to personal data
2. Integrity breach: Unauthorized alteration or loss of personal data
3. Availability breach: Accidental or unlawful destruction of personal data

Breach Severity Matrix

We assess privacy breach severity based on risk to data subjects, not just system impact:

Decision Tree: Is Notification Required?

graph TD
    A[Personal data involved?] -->|No| B[General security incident only]
    A -->|Yes| C[High risk to data subjects?]
    C -->|Yes| D[Notify authority + data subjects]
    C -->|No| E[More than unlikely risk?]
    E -->|Yes| F[Notify authority only]
    E -->|No| G[Document in breach register only]

    D --> H[Start 72-hour timeline]
    F --> H
    G --> I[No external notification]

72-Hour Notification Timeline (GDPR Article 33)

Hour 0-24: Detection and Containment

Immediate Actions (Security Lead):

Deliverable: Initial breach assessment documented

Hour 24-48: Documentation and Impact Assessment

Detailed Investigation (Response Team):

Deliverable: Complete breach notification draft ready for submission

Hour 48-72: Notification Submission

Final Actions (ISMS Owner + Security Lead):

Deliverable: Breach notification submitted, confirmation received

Supervisory Authority Contacts

Primary Authorities

Data Subject Notification (GDPR Article 34)

When Notification is Required

Mandatory Notification if breach is “likely to result in high risk” to data subjects.

High-Risk Indicators:

• Identity theft or fraud likely
• Financial loss possible
• Reputational damage or social disadvantage
• Loss of confidentiality of data protected by professional secrecy
• Discrimination or other significant disadvantage
• Special category data exposed without encryption
• Large-scale breach (>10,000 individuals)

When Notification is NOT Required

Exemptions (Article 34(3)):

Notification Content Requirements

What to Tell Data Subjects (Article 34(2)):

1. Nature of breach: What happened, in clear and plain language
2. Contact point: Name and contact details of DPO or privacy contact
3. Likely consequences: What could happen to them (identity theft, fraud, etc.)
4. Measures taken and recommended: What we’ve done and what they should do

What NOT to Include:

• Technical details that could aid further attacks
• Blame or accusations against individuals
• Legal disclaimers minimising our responsibility
• Overly technical jargon

Communication Method:

• Direct communication. Email to affected individuals (preferred)
• Public communication. Website notice, press release (if individual contact impracticable)
• Multiple channels. Consider combining for high-risk breaches

Timing: “Without undue delay” - typically within 72 hours of becoming aware of breach

Privacy Breach Register

Purpose

GDPR Article 33(5) Requirement:

The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken.

Why We Maintain It:

• Legal requirement for supervisory authority inspection
• Evidence of GDPR compliance
• Historical record for trend analysis
• Post-incident review resource

What to Record

Minimum Required Fields:

Storage Location: Privacy breach register (maintained internally; available to auditors and enterprise customers on request)

Retention: Indefinitely (for regulatory inspection)

Access: ISMS Owner, Security Lead, DPO (if appointed)

Notification Templates

Template 1: Supervisory Authority Notification

Use: Submit to ICO or other DPA within 72 hours

## PERSONAL DATA BREACH NOTIFICATION
**Submitted to**: [Supervisory Authority Name]
**Date**: [YYYY-MM-DD]
**Submitted by**: [Your Name, Role]

---

### 1. ORGANISATION DETAILS
**Organisation Name**: Maelstrom AI
**Registration Number**: [If applicable]
**Contact Person**: [ISMS Owner Name]
**Email**: security@maelstrom.au
**Phone**: [Contact number]
**Address**: [Registered address]

**Data Protection Officer** (if appointed):
- Name: [DPO Name or "Not appointed"]
- Email: [DPO Email]

---

### 2. BREACH DETECTION
**Date/Time Became Aware**: [YYYY-MM-DD HH:MM UTC]
**Detection Method**: [How we discovered breach - e.g., internal monitoring, external report]
**First Occurrence** (if known): [YYYY-MM-DD HH:MM UTC or "Under investigation"]

---

### 3. NATURE OF BREACH
**Breach Type**: [Confidentiality / Integrity / Availability breach]

**Description**:
[2-3 paragraphs describing what happened, including:
- Attack vector or cause
- Systems/services affected
- Type of security failure
- Current status (ongoing vs. contained)]

**Example**:
"On [date], we detected unauthorized access to our analytics database through a misconfigured API endpoint. An attacker exploited insufficient authentication controls to access customer interaction logs containing email addresses and IP addresses. The breach was contained within 4 hours of detection by disabling the affected API endpoint."

---

### 4. CATEGORIES OF DATA SUBJECTS AFFECTED
**Types of Individuals**:
- [ ] Customers/Users
- [ ] Employees/Team Members
- [ ] Contractors/Vendors
- [ ] Other: [Specify]

**Approximate Number**: [Count or range, e.g., "~1,200 individuals" or "500-1,000 individuals"]

---

### 5. CATEGORIES OF PERSONAL DATA AFFECTED
**Data Types**:
- [ ] Names
- [ ] Email addresses
- [ ] Phone numbers
- [ ] IP addresses
- [ ] Usernames
- [ ] Hashed passwords
- [ ] Other: [Specify]

**Special Category Data** (if applicable):
- [ ] None
- [ ] Health data
- [ ] Biometric data
- [ ] Other: [Specify]

---

### 6. LIKELY CONSEQUENCES
**Risk Assessment**:
- **Likelihood of harm**: [Low / Medium / High]
- **Severity of harm**: [Low / Medium / High]
- **Overall risk**: [Low / Medium / High]

**Potential Impact on Data Subjects**:
[Describe realistic consequences, e.g.:
- Increased spam/phishing risk
- Potential account takeover (if credentials exposed)
- Privacy violation
- Identity theft risk
- Financial loss potential]

**Example**:
"The breach poses LOW RISK to affected individuals. Exposed data (email addresses, IP addresses) is low-sensitivity and unlikely to result in identity theft or financial loss. Primary risk is increased spam or phishing attempts."

---

### 7. MEASURES TAKEN
**Containment** (immediate actions):
- [List actions taken to stop breach]
- [e.g., "Disabled compromised API endpoint"]
- [e.g., "Revoked unauthorized access credentials"]

**Remediation** (fixing root cause):
- [List fixes implemented]
- [e.g., "Implemented authentication on all API endpoints"]
- [e.g., "Conducted full security review of API access controls"]

**Mitigation** (reducing harm):
- [List actions to protect data subjects]
- [e.g., "Forced password reset for affected accounts"]
- [e.g., "Implemented enhanced monitoring for fraud"]

---

### 8. MEASURES PROPOSED
**Future Prevention**:
- [List process/technical improvements]
- [e.g., "Implement quarterly API security audits"]
- [e.g., "Add authentication review to code review checklist"]
- [e.g., "Deploy automated misconfiguration scanning"]

**Timeline**: [Implementation timeline for proposed measures]

---

### 9. DATA SUBJECT NOTIFICATION
**Status**:
- [ ] Data subjects have been notified (Date: [YYYY-MM-DD])
- [ ] Data subjects will be notified (Planned: [YYYY-MM-DD])
- [ ] Data subjects NOT notified - Exemption applies

**Exemption Justification** (if not notifying):
[Select applicable exemption under Article 34(3):
- [ ] Data protected by encryption/pseudonymization
- [ ] Subsequent measures eliminate high risk
- [ ] Disproportionate effort (public communication alternative: [describe])]

**Notification Method** (if notifying):
- [ ] Direct email to affected individuals
- [ ] Public website notice
- [ ] Press release
- [ ] Other: [Specify]

---

### 10. SUPPORTING DOCUMENTATION
**Attached**:
- [ ] Breach investigation report
- [ ] Timeline of events
- [ ] Evidence of containment
- [ ] Data subject notification (if sent)
- [ ] Other: [Specify]

---

### 11. ADDITIONAL INFORMATION
[Any other relevant information for the supervisory authority]

---

**Declaration**:
I confirm that the information provided in this notification is accurate and complete to the best of my knowledge.

**Name**: [ISMS Owner Name]
**Role**: Chief Technology Officer / ISMS Owner
**Date**: [YYYY-MM-DD]
**Signature**: [Digital signature if required]

---

**Submission Confirmation**:
**Method**: [Online portal / Email / Phone]
**Reference Number**: [If provided by authority]
**Receipt Confirmation**: [Copy of confirmation email/receipt attached]

Template 2: Data Subject Notification

Use: Notify affected individuals of high-risk breaches

Subject: Important Security Notice - Data Breach Affecting Your Account

Dear [Name / Provii User],

We are writing to inform you of a data security incident that may have affected your personal information. We take the protection of your data very seriously and want to provide you with full details of what happened and what we're doing about it.

---

## What Happened
[2-3 sentences in plain language explaining the breach]

**Example**:
"On [date], we discovered that an unauthorized party gained access to our analytics database through a misconfigured API endpoint. This database contained email addresses and IP addresses of users who interacted with our verification service. We immediately shut down the affected system and launched an investigation."

**Date of Incident**: [YYYY-MM-DD]
**Date Discovered**: [YYYY-MM-DD]

---

## What Information Was Affected
The following information related to your account may have been accessed:
- [List data types, e.g., "Your email address"]
- [e.g., "Your IP address"]
- [e.g., "Dates of service interaction"]

**Information NOT Affected**:
- [Reassure about sensitive data, e.g., "No passwords were exposed"]
- [e.g., "No financial information was involved"]
- [e.g., "No identity documents were accessed"]

---

## What We Are Doing
We have taken the following actions to protect your information and prevent future incidents:

**Immediate Actions**:
- [Containment step, e.g., "Disabled the compromised API endpoint immediately"]
- [Investigation step, e.g., "Conducted full forensic investigation"]
- [Notification step, e.g., "Reported the incident to the Information Commissioner's Office"]

**Preventative Measures**:
- [Fix, e.g., "Implemented additional authentication on all API endpoints"]
- [Process, e.g., "Enhanced security review process for API changes"]
- [Monitoring, e.g., "Deployed additional monitoring to detect similar issues"]

---

## What You Should Do
We recommend the following steps to protect yourself:

1. **Be vigilant for phishing**: You may receive increased spam or phishing emails. Be cautious of suspicious emails claiming to be from Provii or related services.

2. **Monitor your accounts**: Watch for unusual activity on accounts associated with [your email address].

3. [Additional recommendations based on data exposed]

**What you DO NOT need to do**:
- You do not need to change your password (passwords were not exposed)
- [Other reassurances based on breach scope]

---

## Contact Information
If you have questions or concerns about this incident, please contact us:

**Email**: security@maelstrom.au
**Response Time**: We aim to respond to inquiries within 48 hours

You also have the right to lodge a complaint with the Information Commissioner's Office (ICO), the UK supervisory authority for data protection:
- Website: https://ico.org.uk/make-a-complaint/
- Helpline: 0303 123 1113

---

## Our Commitment
We deeply regret this incident and sincerely apologise for any concern it may cause. The protection of personal data is a core responsibility, and we are working to maintain your trust.

We will continue to monitor the situation and will provide updates if we learn of any additional impact.

Thank you for your understanding.

Sincerely,

[ISMS Owner Name]
Chief Technology Officer
Maelstrom AI
security@maelstrom.au

---

**Date**: [YYYY-MM-DD]
**Reference**: BREACH-[ID]

Template 3: Internal Breach Report

Use: Document breach immediately upon detection (internal use)

# PRIVACY BREACH REPORT
**Breach ID**: BREACH-[YYYY]-[###]
**Report Date**: [YYYY-MM-DD HH:MM UTC]
**Reported By**: [Name, Role]
**Status**: [Investigating / Contained / Resolved]

---

## DETECTION
**Detection Date/Time**: [YYYY-MM-DD HH:MM UTC]
**Detection Method**: [How discovered]
**Detected By**: [Person/System]
**First Evidence of Breach**: [When breach actually occurred, if known]

---

## INITIAL ASSESSMENT

### Personal Data Involved?
- [ ] YES - Personal data affected (continue assessment)
- [ ] NO - General security incident only (follow standard IR procedures)

### Breach Type
- [ ] Confidentiality breach (unauthorized access/disclosure)
- [ ] Integrity breach (unauthorized alteration)
- [ ] Availability breach (destruction/loss)

### Systems Affected
- [List systems, services, databases involved]

### Data Categories
**Data Types**:
- [ ] Names
- [ ] Email addresses
- [ ] IP addresses
- [ ] Usernames
- [ ] Credentials (passwords, API keys)
- [ ] Other: [Specify]

**Special Category Data**:
- [ ] None
- [ ] Health data
- [ ] Biometric data
- [ ] Other: [Specify]

### Data Subjects
**Categories**:
- [ ] Customers
- [ ] Team members
- [ ] Contractors
- [ ] Other: [Specify]

**Estimated Number**: [Count or range]

---

## RISK ASSESSMENT

### Risk to Data Subjects
**Likelihood of Harm**: [ ] Low / [ ] Medium / [ ] High
**Severity of Harm**: [ ] Low / [ ] Medium / [ ] High
**Overall Risk Level**: [ ] Low / [ ] Medium / [ ] High

**Potential Consequences**:
- [List potential impacts on data subjects]

**Mitigating Factors**:
- [ ] Data encrypted
- [ ] Data pseudonymized
- [ ] Limited scope
- [ ] Quickly contained
- [ ] Other: [Specify]

---

## NOTIFICATION DECISION

### Supervisory Authority Notification Required?
- [ ] YES - Notify within 72 hours (start timeline)
- [ ] NO - Document in breach register only
- [ ] UNCERTAIN - Escalate to ISMS Owner + legal counsel

**Justification**: [Explain decision]

### Data Subject Notification Required?
- [ ] YES - High risk breach, notify without undue delay
- [ ] NO - Exemption applies (Article 34(3))
- [ ] UNCERTAIN - Assess after full investigation

**Justification**: [Explain decision]

---

## CONTAINMENT ACTIONS
**Time**: [HH:MM UTC]
**Actions Taken**:
- [List containment steps]

**Evidence Preserved**:
- [ ] System logs
- [ ] Access records
- [ ] Database snapshots
- [ ] Other: [Specify]

---

## RESPONSE TEAM
**ISMS Owner Notified**: [ ] YES - [Time] / [ ] NO
**Legal Counsel Involved**: [ ] YES / [ ] NO
**Response Team Members**:
- [Name, Role]
- [Name, Role]

---

## TIMELINE (72-HOUR TRACKER)
**Hour 0** (Detection): [YYYY-MM-DD HH:MM UTC]
**Hour 24 Deadline**: [YYYY-MM-DD HH:MM UTC]
**Hour 48 Deadline**: [YYYY-MM-DD HH:MM UTC]
**Hour 72 Deadline**: [YYYY-MM-DD HH:MM UTC]

**Status**:
- [ ] Hour 0-24: Detection, containment, initial assessment (IN PROGRESS / COMPLETE)
- [ ] Hour 24-48: Documentation, impact assessment, notification draft (PENDING / IN PROGRESS / COMPLETE)
- [ ] Hour 48-72: Final review, notification submission (PENDING / IN PROGRESS / COMPLETE)

---

## INVESTIGATION FINDINGS
[Update as investigation progresses]

**Root Cause**: [Technical explanation]

**Attack Vector**: [How breach occurred]

**Data Exfiltration**: [ ] YES / [ ] NO / [ ] UNKNOWN

**Evidence of Malicious Intent**: [ ] YES / [ ] NO / [ ] UNKNOWN

---

## REMEDIATION
**Immediate Fixes**:
- [List actions]

**Long-Term Improvements**:
- [List measures]

---

## DOCUMENTATION
**Attachments**:
- [ ] Forensic logs
- [ ] Timeline spreadsheet
- [ ] Notification drafts
- [ ] Evidence screenshots
- [ ] Other: [Specify]

**Filed In**: [Location in breach register]

---

## NOTES
[Additional information, updates, decisions]

---

**Last Updated**: [YYYY-MM-DD HH:MM UTC]
**Updated By**: [Name]

Template 4: Post-Breach Review

Use: Conduct lessons learned after breach resolution

# PRIVACY BREACH POST-INCIDENT REVIEW
**Breach ID**: BREACH-[YYYY]-[###]
**Review Date**: [YYYY-MM-DD]
**Attendees**: [Names and roles]
**Facilitator**: [Name]

---

## INCIDENT SUMMARY
**Breach Type**: [Confidentiality / Integrity / Availability]
**Detection Date**: [YYYY-MM-DD]
**Resolution Date**: [YYYY-MM-DD]
**Duration**: [X hours/days]
**Severity**: [Low / Medium / High risk]

**What Happened** (1 paragraph):
[Brief summary]

---

## TIMELINE REVIEW

### Key Events
| Time (UTC) | Event | Response Action |
|------------|-------|-----------------|
| [HH:MM] | Breach occurred (estimated) | - |
| [HH:MM] | Breach detected | [Action] |
| [HH:MM] | Containment initiated | [Action] |
| [HH:MM] | Supervisory authority notified | [Action] |
| [HH:MM] | Resolution complete | [Action] |

### Timeline Performance
**72-Hour Notification Deadline**:
- [ ] MET - Notified within 72 hours
- [ ] MISSED - Notified at [X] hours (reasons: [explain])
- [ ] N/A - Notification not required

**Data Subject Notification** (if applicable):
- [ ] MET - Notified without undue delay
- [ ] DELAYED - Reasons: [explain]
- [ ] N/A - Notification not required

---

## RESPONSE EVALUATION

### What Went Well
**Strengths**:
1. [Example: "Rapid detection through automated monitoring"]
2. [Example: "Effective containment within 2 hours"]
3. [Example: "Clear communication between response team"]
4. [Additional strengths]

### What Needs Improvement
**Gaps**:
1. [Example: "72-hour timeline almost missed due to weekend"]
2. [Example: "Initial risk assessment underestimated data sensitivity"]
3. [Example: "Template not readily available, delayed notification draft"]
4. [Additional gaps]

---

## ROOT CAUSE ANALYSIS

### Technical Root Cause
[What technical failure allowed breach to occur?]

**Example**: "API endpoint deployed without authentication due to misconfigured deployment pipeline"

### Process Root Cause
[What process failure allowed breach to occur?]

**Example**: "Security review checklist did not include API authentication verification"

### Contributing Factors
- [Factor 1]
- [Factor 2]
- [Factor 3]

---

## EFFECTIVENESS OF CONTROLS

### Controls That Worked
- [Control that detected breach]
- [Control that limited impact]
- [Control that enabled recovery]

### Controls That Failed
- [Control that should have prevented breach]
- [Control that should have detected earlier]
- [Control that was bypassed]

---

## NOTIFICATION PROCESS REVIEW

### Supervisory Authority Notification
**Authority**: [ICO / Other]
**Submission Method**: [Portal / Email]
**Submission Time**: [YYYY-MM-DD HH:MM UTC]
**Response Received**: [ ] YES / [ ] NO
**Authority Feedback**: [Summary of any feedback received]

**Process Assessment**:
- [ ] Template was helpful
- [ ] Template needs improvement: [specify]
- [ ] Required information was readily available
- [ ] Struggled to gather: [specify data]
- [ ] Submission process was smooth
- [ ] Encountered issues: [specify]

### Data Subject Notification (if applicable)
**Notification Method**: [Email / Website / Other]
**Notification Time**: [YYYY-MM-DD HH:MM UTC]
**Number Notified**: [Count]
**Responses Received**: [Count of inquiries/complaints]

**Process Assessment**:
- [ ] Template was appropriate for audience
- [ ] Template needs improvement: [specify]
- [ ] Tone was appropriate
- [ ] Received positive feedback
- [ ] Received complaints: [summarise]

---

## DATA SUBJECT IMPACT

### Actual Harm Observed
- [ ] No harm reported
- [ ] Spam/phishing reported
- [ ] Account compromise reported
- [ ] Identity theft reported
- [ ] Financial loss reported
- [ ] Other: [specify]

**Number of Complaints**: [Count]
**Nature of Complaints**: [Summary]

### Support Provided
- [Support measures offered to affected individuals]
- [Resources provided]

---

## REGULATORY OUTCOME

### Supervisory Authority Response
- [ ] No action taken (breach handled appropriately)
- [ ] Guidance provided: [summary]
- [ ] Investigation opened
- [ ] Enforcement action: [details]
- [ ] Pending response

### Compliance Assessment
**GDPR Compliance**:
- [ ] Fully compliant
- [ ] Partially compliant - Issues: [specify]
- [ ] Non-compliant - Issues: [specify]

**Lessons for Future Compliance**:
- [Lesson 1]
- [Lesson 2]

---

## ACTION ITEMS

### Immediate Actions (< 1 week)
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| [Fix critical gap] | [Role] | [Date] | [Open/Done] |
| [Deploy emergency patch] | [Role] | [Date] | [Open/Done] |

### Short-Term Actions (< 1 month)
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| [Implement control improvement] | [Role] | [Date] | [Open/Done] |
| [Update procedure] | [Role] | [Date] | [Open/Done] |

### Long-Term Actions (< 3 months)
| Action | Owner | Deadline | Status |
|--------|-------|----------|--------|
| [Strategic improvement] | [Role] | [Date] | [Open/Done] |
| [Training program] | [Role] | [Date] | [Open/Done] |

---

## DOCUMENTATION UPDATES

### Procedures Updated
- [ ] Incident Response Plan
- [ ] Privacy Breach Procedures
- [ ] Breach Register
- [ ] Other: [specify]

### Training Required
- [ ] Privacy breach response training for team
- [ ] Notification template training
- [ ] Tabletop exercise planned: [date]

### Risk Register Updates
**New Risks Identified**:
- [Risk 1]
- [Risk 2]

**Risk Treatments Updated**:
- [Treatment for existing risk]

---

## COST ANALYSIS

### Direct Costs
- Investigation time: [X hours at $Y/hour]
- External legal counsel: [$X]
- Notification costs: [$X]
- Remediation costs: [$X]
- **Total Direct**: [$X]

### Indirect Costs
- Service downtime: [X hours]
- Reputational impact: [Assessment]
- Customer churn: [X customers]
- **Estimated Total Indirect**: [$X]

### Prevention Value
**Estimated cost to prevent**: [$X]
**ROI of prevention**: [X%]

---

## CONCLUSIONS

### Summary
[2-4 paragraphs summarising key learnings and outcomes]

### Key Takeaways
1. [Takeaway 1]
2. [Takeaway 2]
3. [Takeaway 3]

### Recommendations
**For Maelstrom AI**:
- [Recommendation 1]
- [Recommendation 2]

**For Industry**:
- [If applicable, insights for broader community]

---

## SIGNATURES

**Review Completed By**:
- ISMS Owner: [Name] - [Date]
- Security Lead: [Name] - [Date]
- Legal Counsel (if involved): [Name] - [Date]

**Distribution**:
- [ ] Filed in breach register
- [ ] Shared with response team
- [ ] Escalated to board (if material)
- [ ] Included in annual ISMS review

---

**Document Classification**: Confidential - Internal Use Only
**Retention**: Indefinite (regulatory requirement)

Privacy Breach Response Checklist

Quick Reference for responding to privacy breaches:

Integration with Incident Response

Privacy breaches are a subset of security incidents. Follow this decision tree:

graph TD
    A[Security Incident Detected] --> B{Personal Data Involved?}
    B -->|No| C[Follow Standard Incident Response]
    B -->|Yes| D[Privacy Breach Procedures ALSO Apply]
    D --> E[Parallel Workflows]
    E --> F[Security IR: Phases 1-6]
    E --> G[Privacy: 72-Hour Timeline]
    F --> H[Combined Post-Mortem]
    G --> H

Key Integration Points:

• Detection. Same detection sources apply
• Assessment. Add privacy-specific risk assessment
• Containment. Same containment procedures
• Eradication. Same remediation approach
• Recovery. Add data subject notification
• Lessons Learned. Include privacy compliance review

Roles and Responsibilities (Privacy-Specific)

Training and Exercises

Annual Privacy Breach Tabletop Exercise:

Scenario Examples:

1. GitHub repository exposure of customer email database
2. Third-party analytics service breach affecting our users
3. Insider threat: Team member exfiltrates customer data
4. Ransomware attack encrypting customer-facing services

Exercise Objectives:

• Practice 72-hour timeline
• Test notification templates
• Verify supervisory authority contact information
• Practice data subject communication
• Identify procedure gaps

Next Scheduled Exercise: H1 2026 (alongside security incident response exercise)

Related Privacy Documents

• Privacy Policy - External privacy commitments
• Data Protection Impact Assessment - Privacy risk assessments
• Data Processing Records - Article 30 records
• Privacy by Design - Preventative measures

Special Procedures

Signing Key Compromise Response

This is our worst-case scenario - immediate P0 response required.

Cloud Provider Outage

If Cloudflare experiences major outage:

1. Confirm outage: Check status.cloudflare.com
2. Update status: Communicate to customers (via non-Cloudflare channel)
3. Monitor: Track Cloudflare status updates
4. Document: Record duration and impact for Business Continuity review
5. No action required: Wait for Cloudflare resolution (we accept this risk per Risk Register)

Roles and Responsibilities

Testing and Exercises

Tabletop Exercises: Annually, walk through incident scenarios

Scenarios to Test:

• Signing key compromise
• Supply chain attack (malicious dependency)
• Account takeover
• Service outage
• Vulnerability disclosure

Objectives:

• Verify team knows procedures
• Test communication channels
• Identify procedure gaps
• Practice decision-making under pressure

Next Scheduled Exercise: H1 2026

Tools and Resources

Incident Response Kit:

• Cloudflare dashboard access (https://dash.cloudflare.com)
• GitHub admin access
• Incident response playbooks (this document)
• Contact list (in secure location, not public)
• Key rotation procedures
• Emergency change approval process

External Resources:

• Cloudflare Support (Enterprise support line)
• GitHub Support
• Security researcher coordination (HackerOne, if used)

Related Documents

• Information Security Policy - Overall security requirements
• Business Continuity Plan - Major disruption response
• Change Management - Emergency change procedures
• Risk Register - Identified risks and treatments

Document Information

• Version. 2.1
• Effective Date. 2025-01-13
• Last Updated. 2026-05-21
• Owner. ISMS Owner
• Approved By. ISMS Owner
• Review Frequency. Annually, after major incidents
• Next Review. 2026-11-21
• Classification. Public