UCCA Incident Response Plan¶
Version: 1.0 Classification: INTERNAL Control Reference: UCCA-IR-001 Owner: Tim Status: Draft Date: 4 March 2026 Review Cycle: Annual or after any S1/S2 incident
1. Purpose and Scope¶
This plan establishes the incident response procedures for UCCA (Universal Capability Certification Authority). It defines how security incidents are detected, classified, contained, eradicated, and recovered from. It applies to all UCCA systems, services, and data, including:
- All Cloudflare infrastructure (Workers, D1, R2, DNS, WAF)
- GitHub repositories and CI/CD pipelines
- API endpoints (api.ucca.online, ops.ucca.online)
- World container databases and data pipelines
- Development workstations
- Third-party service integrations
This plan satisfies the requirements of UCCA-IR-001 in the Canonical Control Registry and maps to SOC 2 CC7.3 and NIST 800-53 IR-1.
2. Severity Classification¶
All incidents are classified by severity to determine response urgency, escalation path, and notification requirements.
| Severity | Description | Response Time | Examples |
|---|---|---|---|
| S1 — Critical | Data breach, verification engine compromise, unauthorised access to production data | Immediate. All hands. | D1 data exfiltration, DNS hijack, credential compromise |
| S2 — High | Service outage, suspected credential exposure, malware detection | Within 1 hour | ops.ucca.online down, PAT leaked in logs, suspicious login |
| S3 — Medium | Failed login threshold exceeded, minor degradation, vulnerability disclosed | Within 4 hours | Rate limiting triggered, dependency CVE, TGA API outage |
| S4 — Low | Informational alerts, blocked phishing, routine anomalies | Next business day | Spam to contact@, WAF blocked scan, certificate renewal notice |
3. Roles and Responsibilities¶
The following roles are activated during an incident. In the current team structure, Tim holds multiple roles. As the team grows, roles will be distributed.
| Role | Person | Responsibilities |
|---|---|---|
| Incident Commander | Tim (primary) | Overall incident ownership, decision authority, communications |
| Incident Commander | Jimmy (backup) | Assumes command if Tim unavailable. Requires account access. |
| Technical Lead | Tim / Claude Code | Investigation, containment, remediation, evidence preservation |
| Communications | Tim | Stakeholder notification, regulatory reporting (OAIC if required) |
4. Response Procedure¶
All incidents follow a six-phase response lifecycle. Each phase is documented in real-time in the incident log.
4.1 Detection¶
Incidents may be detected through: Cloudflare security alerts, ops.ucca.online monitoring dashboard, GitHub Dependabot alerts, manual observation, or third-party notification. Any team member who identifies a potential incident initiates the response process.
4.2 Triage¶
The Incident Commander assesses the situation within the response time defined by severity level. Triage determines: severity classification, affected systems, potential data exposure, and whether escalation is required. All triage decisions are logged with timestamp and rationale.
4.3 Containment¶
Immediate actions to limit the impact of the incident. Actions may include:
- Revoking compromised credentials
- Enabling Cloudflare Under Attack Mode
- Isolating affected Workers or D1 databases
- Rotating API keys and PATs
- Blocking suspicious IP ranges via WAF rules
Evidence must be preserved before any containment action that could alter system state.
4.4 Eradication¶
Remove the root cause of the incident. This may involve: patching vulnerabilities, removing malicious code, reconfiguring access controls, updating WAF rules, or rotating all credentials if scope of compromise is uncertain.
4.5 Recovery¶
Restore systems to normal operation. Verify integrity of all affected systems before returning to service. For data integrity concerns, compare D1 state against known-good backups. Monitor closely for 48 hours post-recovery for recurrence.
4.6 Post-Incident Review¶
Conducted within 5 business days of incident resolution. The review documents:
- Timeline of events
- Detection method and delay
- Response effectiveness
- Root cause analysis
- Lessons learned
- Recommended improvements
Updates to this plan, the risk register, or control implementations are tracked as action items.
5. Escalation and Notification¶
Notification requirements are determined by incident severity. Australian Notifiable Data Breaches (NDB) scheme obligations apply when personal information is involved.
| Severity | Internal Notification | External Notification | Regulatory |
|---|---|---|---|
| S1 | All team immediately | Affected clients within 24 hours | OAIC within 72 hours if personal data breach (NDB scheme) |
| S2 | All team within 1 hour | Affected clients within 48 hours if service impact | Assess NDB applicability |
| S3 | Log and review at next sync | Not required unless client-facing | Not required |
| S4 | Log only | Not required | Not required |
Note
OAIC notification timelines and requirements should be verified at the time of incident as regulations may be updated.
6. Evidence Preservation¶
Evidence preservation takes priority over remediation. Before any containment action that alters system state, the following must be captured:
- Cloudflare analytics and WAF logs for the incident window
- Screenshots of anomalous behaviour or alerts
- System state snapshots (D1 row counts, Worker deployment versions)
- Git commit history and deployment logs
- Email or message records of any external communications
All evidence is stored in a dedicated incident folder with the naming convention: INC-[YYYY]-[NNN]-[short-description]/
7. Incident Log¶
All incidents, including those with no impact, are recorded in the incident log. The log serves as evidence for SOC 2 auditors that the incident response process is operating.
The incident log is maintained as a sheet in the Governance Control Mapping workbook or as a dedicated register. Even a log entry reading "No incidents this quarter" constitutes valid evidence of a functioning process.
Log entry fields: Incident ID, Date/Time Detected, Severity, Description, Affected Systems, Response Actions, Resolution, Root Cause, Review Date, Action Items.
8. Tabletop Exercise Schedule¶
A simulated incident response exercise is conducted at minimum annually, with quarterly exercises recommended for SOC 2 Type II evidence. Each exercise tests one severity level scenario.
Exercise results are documented including: scenario description, participants, timeline of simulated response, gaps identified, and improvements recommended. Results are filed in the Evidence Log (Governance workbook, Sheet 5) and referenced by control UCCA-IR-003.
Suggested Exercise Scenarios¶
- S1: Compromised GitHub PAT with unauthorised commits to ucca-engine
- S2: Cloudflare D1 database corruption requiring backup restoration
- S3: TGA API returns malformed data causing ingestion pipeline failure
- S4: Phishing email targeting UCCA admin accounts
9. Communication Templates¶
9.1 Internal Alert¶
[SEVERITY] Security Incident — [SHORT DESCRIPTION]
Detected: [TIMESTAMP]
Affected: [SYSTEMS]
Status: [INVESTIGATING / CONTAINED / RESOLVED]
IC: [NAME]
Next update: [TIME]
9.2 Client Notification¶
Subject: UCCA Security Notice — [DATE]
We are writing to inform you of a security incident that may affect
your UCCA services. [DESCRIPTION OF IMPACT]. We have [ACTIONS TAKEN].
Your data [WAS / WAS NOT] affected. We will provide updates as our
investigation progresses. If you have questions, contact [CONTACT].
9.3 Regulatory Notification (OAIC)¶
For Notifiable Data Breaches under the Privacy Act 1988, notification to the OAIC must include: description of the breach, the kind of information involved, recommended steps for affected individuals, and UCCA contact details. Use the OAIC Notifiable Data Breaches online form.
10. Document Control¶
This plan is reviewed annually or after any S1/S2 incident. Changes require approval from the Incident Commander.
Version History¶
| Version | Date | Change | Author |
|---|---|---|---|
| 1.0 | 2026-03-04 | Initial incident response plan | Tim Rignold / Claude |
| 1.1 | 2026-03-11 | Converted from UCCA_Incident_Response_Plan_v1.0.docx | Claude Code |