Incident Response¶

When something goes wrong, a phishing click, a lost laptop, a system acting strangely, data somewhere it shouldn't be, this is what happens next. For staff, the whole job is step one: report it fast, to one place. Everything after that is for the response team. This policy also covers the legal duty to notify regulators and clients within tight deadlines when personal or client data is involved.

1. Report first, one front door¶

Ref	Requirement
IR.1	Anyone who suspects a security incident MUST report it immediately through the single reporting channel (IT service desk, Report button, security function).
IR.2	There's one reporting instruction across all policies. Acceptable Use (01), AI (05), and every other policy point here. Reporting early is never penalised.

One front door, named once, referenced everywhere. A confused reporting path is one nobody uses.

2. What counts as an incident¶

Examples, not exhaustive: phishing or suspected account compromise, a lost or stolen device, malware or ransomware, data exposed or sent to the wrong place, access to information beyond your role, suspicious system behaviour, or a supplier or AI tool mishandling Holmes data. When unsure whether something's an incident, report it and let the response team decide.

3. Response process¶

The response follows a defined lifecycle. The plan, maintained operationally, carries the step-by-step detail.

Ref	Requirement
IR.3	The incident-response plan MUST define a single point of contact, the response team with roles and current contacts, incident classification and severity, per-type playbooks, evidence-handling discipline, communications, and the contain, eradicate, and recover steps.
IR.4	Incidents MUST be triaged and classified by severity, and response MUST prioritise containing harm while preserving evidence.
IR.5	Material incidents MUST have root-cause analysis, and new vulnerabilities found MUST feed the risk register and remediation (10).
IR.6	Detection and automated containment (11) MUST be integrated into the process. First human response is often scoping or confirming an action the system has already taken.

4. Regulatory and contractual notification¶

Ref	Requirement
IR.7	For any incident involving personal information, notifiability MUST be assessed without delay against every applicable regime, with Legal, and notifications made within statutory deadlines.
IR.8	Client contractual notification obligations MUST be checked and met for affected clients. Where a contract is stricter than statute, the contract governs (04 CLD.18).
IR.9	A decision record MUST be kept for every incident: what was assessed, the notifiability decision and its basis, and who was notified and when.

Applicable regimes, with thresholds and deadlines to be confirmed with counsel (section 6):

Jurisdiction	Trigger	Notify
New Zealand	Privacy breach likely to cause serious harm	Privacy Commissioner and affected individuals
Australia	Eligible data breach (likely serious harm)	OAIC and affected individuals
EU / Netherlands	Personal-data breach with risk to individuals	Supervisory authority within 72 hours; individuals if high risk
USA	Per applicable state statute (all 50 states); sector or federal as applicable	State AGs and affected residents; contract or federal as applicable

For a firm in four jurisdictions, notification is where an incident can turn into a regulatory failure on top of the incident itself. IR.7 to IR.9 make notifiability a deliberate, recorded decision rather than an afterthought.

5. Testing and maintenance¶

Ref	Requirement
IR.10	The plan MUST be exercised at least annually, with rotating scenarios, and updated after each exercise and each real incident.
IR.11	The plan's roster, contacts, and call tree MUST be kept current and reconciled. The roster and call tree MUST agree.
IR.12	Playbooks MUST cover the current threat set, including AI or LLM data exposure, CI/CD and supply-chain compromise (remove persistence before rotating credentials, 09 DEV.17), business email compromise, ransomware with data exfiltration (double extortion), and helpdesk or MFA-fatigue social engineering.
IR.13	The crisis-communications plan MUST be complete, not a placeholder, and cover staff, clients, partners, regulators, and where warranted public communications.

A plan that's never exercised, with a stale roster or an incomplete comms section, won't hold up in a real incident. IR.10 and IR.11 keep it current and rehearsed.

6. Legal & jurisdictional notes¶

This policy needs counsel review more than any other in the set. Notification thresholds, deadlines, and who decides notifiability (IR.7 to IR.9) are legal determinations. The table in section 4 is a policy scaffold, not legal advice.

Evidence-handling discipline (IR.4) matters for potential litigation, insurance claims, and regulator engagement, so preserve, don't destroy.

Cyber-insurance policies often impose their own notification and response conditions, so align the plan with the current policy's requirements.

7. Publication and privacy note¶

Operational contact details are needed for response but MUST be held under access control, not published. Home addresses MUST NOT appear in the plan, since they serve no response purpose. Any version of this plan published to a documentation site MUST have personal details removed.

00 Framework, 01 Acceptable Use, 02 Information Classification, 04 Cloud & Third-Party, 05 AI Systems, 09 Secure Development, 11 Logging & Monitoring.