Evidence Artifacts vs Design Documents for the CCAR-P Exam

Intent on paper versus proof in operation

The control-owner-evidence triad makes evidence one of three required artifacts; this knowledge point defines exactly what evidence is and is not. The CCAR-P exam treats the distinction as an apply-level skill because the difference between a design document and an evidence artifact is the difference between claiming a control exists and proving it operates. A design document is a point-in-time statement of intent - it names a control and describes how it is supposed to work. An evidence artifact is proof of current operating state, something a reviewer can independently inspect to confirm the control is live right now.

The exam turns this into a selection task: given an obligation, which artifact actually counts as evidence? Candidates who can articulate the distinction in the abstract still fall down when asked to pick the adequate artifact for a specific obligation, because the tempting wrong answers are things that look like controls but are not the inspectable proof the obligation requires.

What counts as an evidence artifact

Adequate evidence is something a reviewer can independently examine that demonstrates the control is operating. Signed agreements are evidence - an executed HIPAA Business Associate Agreement is a document a reviewer can read. Enabled configuration flags are evidence - a screen or export showing a covered plan or a pinned region is inspectable. Authorization records and returned log queries are evidence - they show the control producing observable effects. In each case, the reviewer is not taking anyone's word; they are looking at an artifact.

Different obligations demand different artifacts, and matching them is the graded skill. A HIPAA handling obligation is evidenced by the signed BAA plus the admin setting showing the covered plan enabled and the eligible features in scope. A FedRAMP obligation is evidenced by the authorization record for the chosen delivery route and confirmation the workload runs exclusively on it. A data-residency obligation needs the residency configuration plus a data-flow record showing where every copy - including logs, caches, and monitoring paths - actually lives. A transparency obligation is evidenced by a sample reconstruction of one decision pulled from the live decision log. In each case the artifact a reviewer accepts is fixed by the shape of the obligation, not chosen for convenience.

A design document fails this test not because it is worthless but because it is the wrong kind of thing. "The system validates authorization before refunds" describes an intended behaviour; it is a statement, not a demonstration. The reviewer cannot confirm operation from a description any more than they can confirm a bridge is safe from a sentence saying it was built well. The artifact has to be inspectable, and inspectable means the reviewer can examine the thing itself, not a claim about it.

The formal-agreement mismatch

The exam's sharpest version of this is the mismatch between a runtime control and a formal-agreement obligation. Some obligations are satisfied by a signed agreement plus enabled configuration - a HIPAA BAA is the canonical case. For such an obligation, a model-based content filter is not adequate evidence, no matter how well it works. A content filter is a runtime behaviour that screens health terms; a BAA obligation is a legal-and-configuration requirement. The filter does not sign the agreement, and the agreement does not filter content - they answer different questions, and only one of them is what the obligation demands.

This matters because a content filter looks like a serious, relevant control - it even touches the same data - so it is a plausible-seeming wrong answer. The credited reasoning is that the type of obligation dictates the type of evidence. A formal-agreement obligation needs the executed agreement and the enabled configuration; a runtime content control is evidence for a different kind of obligation entirely. Selecting a runtime filter as proof of a formal-agreement obligation is selecting the wrong category of artifact.

What the CCAR-P exam trips candidates on

The first trap is offering "the model is instructed to handle data carefully" as evidence for a legal or contractual obligation instead of a signed agreement. The scenario presents a well-worded system instruction as the compliance control; the credited reading is that an instruction is a statement of intent, not inspectable proof of a formal agreement, so it cannot satisfy an obligation that requires a signed document and enabled configuration.

The second trap is selecting a runtime content filter as proof of compliance for an obligation that actually requires a formal agreement and enabled configuration. A scenario offers a content filter as evidence for a HIPAA BAA; the credited reading rejects it as the wrong category of artifact. The exam rewards matching the evidence type to the obligation type and always preferring the inspectable artifact over any description of behaviour.

Common misreadings to avoid

How this shows up on the exam

Domain 5 items give you an obligation and several candidate artifacts and ask which is adequate evidence. The reliable method is to match the artifact type to the obligation type and always choose the inspectable proof of current operation - a signed agreement, an enabled config, a log query - over any description of intent or any runtime control offered for a formal-agreement obligation. The plausible-but-wrong option is usually a content filter or a well-worded instruction.

This knowledge point sharpens the evidence element of the control-owner-evidence triad and shares its inspectable-proof standard with the risk assessment as a written deliverable. It leads into compliance drift and revalidation, where a once-valid evidence artifact silently stops reflecting reality and must be re-checked.