- In short
- A risk assessment is a written artifact a security reviewer signs off on, not a mental exercise the architect keeps to themselves. Each row records the risk category, the affected component, a likelihood-and-impact judgment, and the mitigating control with a named owner and an evidence artifact. An unnamed or unowned mitigation is treated the same as no mitigation at audit time, and the same fields later feed the compliance control register.
The assessment only counts if it is written down
Identifying risks and walking the data path produces knowledge; the CCAR-P exam treats turning that knowledge into a written artifact as an apply-level skill. An architect is expected to conduct and document a risk assessment as part of a security deliverable, and the operative word is document. A risk assessment that lives only in the architect's head cannot be reviewed, cannot be signed off, and cannot be audited - which means, for governance purposes, it does not exist.
The reason is the audience. The risk assessment is the thing a security reviewer signs off on. A reviewer cannot approve reasoning they cannot see, so the assessment has to be a concrete document with a structure they can inspect row by row. The skill this knowledge point tests is not spotting risks - that came earlier - but recording each one in a form that a reviewer can actually verify and accept.
- Risk assessment as a written deliverable
- A documented artifact that records, for each identified risk, its category, affected component, likelihood-and-impact judgment, and the mitigating control with a named owner and an evidence artifact. It is what a security reviewer signs off on, an unowned mitigation is treated as no mitigation, and its fields feed the compliance control register.
The six fields that make a row verifiable
Each row of the assessment carries the same six fields, and each field earns its place by making the row inspectable. The risk category ties the row to the taxonomy, so a reviewer can see the assessment covers the known surfaces. The affected component locates the risk in the actual system rather than in the abstract. The likelihood-and-impact judgment records how the architect weighed the risk, so the reviewer can agree or challenge it.
Then the three fields that make the mitigation real. The mitigating control names what actually stands in the way. The owner is the person accountable for that control operating. And the evidence artifact is what a reviewer can inspect to confirm the control is live. A row with the first three fields but not the last three is a description of a worry, not a managed risk - it names a problem without demonstrating that anyone owns the fix or that the fix is running.
An unowned mitigation is no mitigation
The sharpest rule in this knowledge point is about accountability. An unnamed or unowned mitigation on the document is treated exactly the same as no mitigation at audit time. This is not pedantry - it reflects how controls actually fail. A mitigation with no owner has no one watching it, so it can quietly stop operating and no one will notice until an audit or an incident surfaces the gap. From the reviewer's seat, a control that no one owns and no evidence demonstrates is indistinguishable from a control that is not running.
The same logic applies to evidence. Describing a mitigation in prose - "the system validates authorization before refunds" - is not enough on its own; the row must identify the evidence artifact a reviewer could inspect to verify it, such as the authorization policy configuration or a log query showing denials. Prose states intent; the evidence artifact proves operation. The exam wants both attached to every mitigation.
What the CCAR-P exam trips candidates on
The first trap is submitting a list of risks with no named mitigation owner. The scenario shows a thorough enumeration of risks and asks whether the assessment is ready for review; the credited reading is no, because a reviewer cannot confirm anything is actually enforced without an accountable owner on each mitigation. A rich list of risks with unowned fixes is not a passing deliverable.
The second trap is describing a mitigation in prose without identifying the evidence artifact. A scenario presents a well-written paragraph explaining a control and asks whether it satisfies the reviewer; the credited reading is that the paragraph states intent while the reviewer needs an inspectable artifact. The exam consistently rewards the version of the assessment where every mitigation carries both an owner and a concrete piece of evidence.
Worked example
After a vulnerability walkthrough, an architect writes up a risk assessment: a clear list of each risk with its category, the affected component, and a likelihood-and-impact rating, plus a paragraph for each describing how the team intends to mitigate it. The security reviewer returns it as incomplete. What is missing, and how should each row be finished?
The assessment has the first three fields and stops short of the three that make a mitigation real. Each row names a category, a component, and a likelihood-impact judgment - genuinely useful - but the mitigations are described in prose with no named owner and no evidence artifact. From the reviewer's perspective, that is a list of intentions, not a set of enforced controls, which is exactly why it came back incomplete.
To finish each row, attach an owner and an evidence artifact to the mitigation. For the indirect-injection risk, the control is retrieved-content screening; the owner is the named engineer or team accountable for it; the evidence is the screening configuration plus a log query showing blocked instructions. For the tool-abuse risk, the control is deterministic refund authorization; the owner is named; the evidence is the authorization policy and a query of denied attempts. The prose description stays, but now each mitigation points to someone accountable and something inspectable.
The payoff extends past this review. Because the completed rows carry a control, an owner, and an evidence artifact, they are the same fields the compliance control register needs, so building the risk assessment properly now avoids duplicating the work later. The reviewer can sign off, and the compliance layer inherits a head start.
Common misreadings to avoid
Misconception
A thorough list of the system's risks is a complete risk assessment.
What's actually true
Misconception
Describing a mitigation clearly in prose is enough for the reviewer.
What's actually true
How this shows up on the exam
Domain 5 items present a draft risk assessment and ask what it needs to pass review, or ask which fields a defensible assessment must include. The reliable method is to check every row for all six fields, with particular attention to a named owner and an evidence artifact on each mitigation. An assessment that identifies risks but leaves mitigations unowned or unproven is the recurring wrong answer.
This deliverable is the direct output of the system vulnerability walkthrough, which produces the rows the assessment records. Its owner-and-evidence discipline is the same one that governs the control-owner-evidence triad in compliance, and its insistence on inspectable proof over prose is exactly the distinction drawn in evidence artifacts vs design documents.
An architect submits a risk assessment listing each risk with its category, component, and likelihood-impact rating, plus a prose paragraph on how the team plans to mitigate each. Why does the security reviewer call it incomplete?
People also ask
What goes in an LLM risk assessment document?
Why does every mitigation need a named owner?
Is a mental risk review enough?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.