What Incident Response Documentation Does UK CAF Require?

The UK Cyber Assessment Framework (CAF) requires incident response documentation across two principles under Objective D: D1 (Response and Recovery Planning), which needs a documented incident response plan, evidence of the capability to execute it, and records of regular testing; and D2 (Lessons Learned), which needs root cause analysis records and evidence that findings actually change your plans and controls afterward.

A plan that exists but has never been tested, or an incident that was never analysed for root cause, will not satisfy an assessor even if your organisation handled the incident well in practice.

The breakdown below covers exactly what each contributing outcome expects, what "good" evidence looks like versus what commonly fails, and the specific document set to have ready before an assessment.

Where Incident Response Sits in the CAF

Objective D — Minimising the impact of cyber security incidents — is the framework's answer to the assumption that, eventually, something will get through.

Objectives A through C are about prevention and detection; Objective D is about what happens the moment prevention fails, and it splits into two principles:

Each principle breaks into specific contributing outcomes, and each of those has its own Indicators of Good Practice (IGPs), the actual criteria an assessor checks your evidence against.

D1.a — Response Plan

What's Required: A documented incident response plan, proportionate to your organisation and the threats you face, covering both known attack patterns and previously unseen attack types. It must clearly define roles, responsibilities, and reporting lines.

What assessors are actually checking for:

• The plan is written for your organisation's real environment, not a generic template with placeholder names.
• It covers scenarios beyond the obvious (ransomware, phishing) — including attack types your organisation hasn't seen before, which means the plan has to work on principles, not just playbooks for known incidents.
• Named roles and reporting lines are current — not "IT Manager" as a title that turned over eighteen months ago with the document never updated.
• The plan connects clearly to your regulatory notification duty. Under the UK NIS Regulations, this means the 72-hour reporting clock to your competent authority is built into the plan's timeline, not bolted on separately.

Common Gap: A plan built entirely around ransomware or phishing, with no coverage for the "previously unseen" requirement. This is an explicit IGP criterion, and a narrow plan fails it even if the ransomware section is excellent.

D1.b — Response and Recovery Capability

What's Required: The actual capability to execute your response plan and limit impact on your essential function, not just the plan on paper, but the operational ability to run it. Response teams need specific supporting information readily available: asset registers listing critical sites and systems, authorisation requirements, communication plans, and evidence of post-incident activities like root cause analysis.

What assessors are actually checking for:

• Your response team can locate a current asset register showing which systems and sites are critical, within minutes, not after searching three shared drives.
• Authorisation requirements are documented in advance. Who can approve isolating a system, who can approve a public statement, who can approve invoking a regulator notification — these decisions should not be improvised mid-incident.
• A communication plan exists covering internal escalation, customer/stakeholder communication, and regulator notification, each with named owners.
• Evidence that this capability has actually been used or rehearsed, not just documented in theory.

Common Gap: This is where "we have a plan" and "we can execute the plan" diverge sharply. An organisation can have a beautifully written response plan and still fail D1.b if the asset register it depends on is nine months out of date, because the plan is only as good as the live data it points to.

D1.c — Testing and Exercising

What's Required: Exercises are routinely run, with findings documented and used to refine both incident response plans and protective security controls. Exercises need to test all parts of your response cycle relevant to your essential function, not just a tabletop discussion of one scenario.

What assessors are actually checking for:

• Exercises happen on a routine cadence, not once before an assessment cycle and never again.
• Exercise findings are documented in writing, with specific gaps identified — a debrief that says "went well, no issues" from every exercise is itself a red flag.
• There's a visible trail from exercise finding to actual plan revision. The exercise changed something, rather than being a compliance exercise in itself.
• Exercises cover different scenario types over time, not the same scenario rehearsed repeatedly.

Common Gap: This is the single most frequently failed contributing outcome under Objective D. A written plan that has genuinely never been tested reads to an assessor as an untested assumption, no matter how thorough the document looks.

D2.a — Incident Root Cause Analysis

What's Required: When an incident occurs, you conduct root cause analysis — not just "what happened" but "why it happened and what allowed it," including underlying causes and contributing systemic factors rather than only the immediate technical trigger.

What assessors are actually checking for:

• Root cause analysis is a genuine analytical exercise, distinguishing the immediate trigger (e.g., a phished credential) from the underlying weakness that allowed it to matter (e.g., no multi-factor authentication on that system).
• Analysis is documented for the incidents that occurred, not asserted as a general process with no example.
• The analysis covers near-misses as well as actual incidents — an organisation that only analyses incidents that caused damage is missing the earlier-warning value root cause analysis is meant to provide.

Common Gap: Root cause analysis that stops at the technical symptom ("malware was executed") without tracing back to the organisational or process failure that allowed it ("no endpoint detection on that segment, and it hadn't been flagged in the last asset review").

D2.b — Using Incidents to Drive Improvements

What's Required: Evidence that lessons learned from incidents (and exercises) actually feed back into your incident response plan, your protective security controls, and your risk register — closing the loop rather than filing the analysis away.

What assessors are actually checking for:

• A direct, traceable link between a specific incident or exercise finding and a specific change made afterward — a plan revision, a new control, an updated policy.
• This feedback loop is documented, not just claimed — "we made changes" needs a before/after trail an assessor can follow.
• Improvements are tracked to completion, not just logged as an action item that never closed.

Common Gap: An organisation runs the exercise, writes the debrief, and then the debrief's recommendations quietly die in a document nobody revisits. D2.b specifically tests whether that loop closes.

The Full Incident Response Document Set, mapped to CAF

Pulling the outcomes together, here's what a complete D1/D2 evidence base actually looks like:

Nine document types, each tied to a specific outcome — and each one an assessor can ask for by name during a review.

Why This is Where Most CAF Evidence Actually Falls Apart

Objective D exposes a pattern that runs through the whole framework: the gap is rarely "we have no incident response process." It's that the process exists in someone's head, the plan hasn't been touched since it was written, the asset register it depends on is stale, and the last exercise (if there was one) never turned into a documented change.

Every one of D1.a through D2.b requires proof of currency and use, not just proof of existence — which is exactly why static templates downloaded once and left alone tend to fail this objective specifically, even when every other objective looks solid.

Our UK CAF IR Document Library gives you the response plan, exercise templates, root cause analysis format, and post-incident tracker pre-mapped to D1 and D2 from the outset. This ensures you're not drafting incident response documentation from a blank page under deadline pressure. The UK CAF Master Document Register then keeps the pieces that decay fastest — your asset register, your exercise history, your open improvement actions — live and dated, so when an assessor asks for D1.b or D2.b evidence, you're pulling a current record instead of reconstructing one.

FAQs about UK CAF Incident Response Documentation 

1. What incident response documents does the UK CAF require?

The CAF requires a documented incident response plan (D1.a), evidence of the capability to execute it including a current asset register and communication plan (D1.b), records of regular testing and exercising (D1.c), root cause analysis for incidents (D2.a), and evidence that lessons learned actually change your plans and controls (D2.b).

2. What is the difference between CAF principles D1 and D2?

D1 (Response and Recovery Planning) covers having a documented plan, the operational capability to run it, and evidence you've tested it. D2 (Lessons Learned) covers what happens after an incident — root cause analysis and proof that findings feed back into your plans and controls, rather than being filed away.

3. Does my incident response plan need to cover attacks I've never seen before?

Yes. The CAF's D1.a outcome explicitly expects your plan to address both known attack patterns and previously unseen attack types, meaning the plan needs to work from response principles and roles rather than only scripted playbooks for specific known scenarios.

4. How often should we test our incident response plan for CAF compliance?

The CAF expects exercises to be run routinely, not as a one-off before an assessment. There's no single mandated frequency, but assessors look for a consistent cadence, documented findings from each exercise, and evidence that different scenario types are tested over time rather than the same exercise repeated.

5. What counts as root cause analysis under CAF Principle D2?

Root cause analysis under D2.a means identifying the underlying cause of an incident, not just the immediate technical trigger — for example, tracing a phishing incident back to a missing multi-factor authentication control, rather than stopping at "an employee clicked a malicious link."

6. Do near-misses need to be documented for CAF compliance, or only actual incidents?

Near-misses should be documented and analysed alongside actual incidents. D2.a's intent is to capture root causes before they cause real damage, and an organisation that only reviews incidents that caused harm misses the earlier warning signals the outcome is designed to surface.

7. What's the most common reason organisations fail CAF Objective D?

The most common failure is an incident response plan that has never been genuinely tested — D1.c specifically requires documented, routine exercising, and a plan that exists only on paper is treated as an untested assumption regardless of how well-written it is.

8. How does UK NIS Regulations incident notification connect to CAF Objective D?

Operators of Essential Services must notify their competent authority within 72 hours of becoming aware of a significant incident under the UK NIS Regulations, and this notification timeline should be built directly into your D1.a response plan and D1.b operational capability, since the CAF expects your response process and your regulatory obligations to function as one connected workflow, not two separate procedures.