Step 3 — Trust but Verify: Control Responses and Objective Evidence Collection
The mechanics of getting evidence out of a system owner — what to ask for, control by control, and what to do when the answer is "we have a policy"
The control set is agreed. Now somebody has to prove each control is real — and the people who can prove it have other jobs.
This post is mechanical on purpose. Why evidence matters is in Beyond Checklists. What makes it defensible is in Part 4. This is about how you actually get it, control by control, without burning the goodwill you will need in the closing meeting.
A control response is a claim. Evidence is what makes it more than one.
The Control Response#
The system owner's written statement of how the control is implemented. Here is the same control answered twice.
| Control response | |
|---|---|
| Weak | "Accounts are managed in accordance with departmental policy and disabled when no longer required." |
| Strong | "Accounts are provisioned in Entra ID via the HR-driven joiner workflow. Leavers are disabled within 24 hours by the same workflow, evidenced by the leaver audit log. Quarterly recertification is run in the access review tool; last completed 2026-06-30. Artifacts: leaver log extract, Q2 recertification report." |
The weak one is the control text wearing a tie. The strong one tells the assessor what to look at, where, and gives them a date to check against. Ask for the strong one, and give the example — it does more than a page of guidance.
What to Ask For, by Control Shape#
Organize by what the control does, not by family. The artifact that settles it follows from the shape.
| Control shape | Ask for | Not sufficient |
|---|---|---|
| Configuration state | Export, IaC definition, signed baseline | A statement that it is configured |
| Access and entitlement | Membership export with date; joiner/leaver records | The access policy |
| Periodic review | Completed review records across a period | The review procedure |
| Logging and monitoring | Log extract, alert definition, an alert that actually fired | A screenshot of the console |
| Training and awareness | Completion records with dates and population | The training deck |
| Contractual or third-party | Executed clause; current attestation with scope and period | A vendor marketing page |
| Physical | Access records; site walkthrough notes | The facilities policy |
The right-hand column is the artifact most often offered. Every row of it proves the control was designed; none proves it operates.
The Four Methods#
[Examine is] a type of assessment method that is characterized by the process of checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects to facilitate understanding, achieve clarification, or obtain evidence …
NIST SP 800-53A Rev. 5, via the NIST glossaryNIST's method set is examine, interview and test.1 This post adds observe — watching a control operate — as a fourth, because it settles a different question from examining an artifact after the fact. Canada has no centrally published equivalent; ITSP.10.033 says it lays the foundation for developing assessment methods, so departments define their own.2 Use the four as a checklist, not a standard.
| Method | Establishes | Cannot establish |
|---|---|---|
| Examine | What the artifact says | Whether it is current or complete |
| Interview | Intent, ownership, what people believe is true | That it is true |
| Observe | That it operated once, in front of you | That it operates when you are not there |
| Test | That it operates under the condition you tested | Conditions you did not |
No single method reaches "operating as intended". Two together usually do.
"We Have a Policy"#
The most common non-answer, and it is rarely evasive — the system owner answered the question they thought was asked. The policy proves designed. Move past it with four questions:
- Which system enforces this?And can you show me its configuration?
- When was it last true?And how would you know if it stopped?
- Who would notice a violation?Through what mechanism?
- Show me one instanceOf it working, in the last 90 days
Keep the tone collaborative. The goal is the artifact, not the admission.
Running the Cycle#
Scroll sideways to see the full diagram →
Four operational rules that save weeks:
- One list. Every request, with an owner, a due date and a state. Not twenty email threads.
- Batch by team, not by control. The identity team gets all their requests at once.
- Blocked is not late. A request waiting on a third party is a different problem from one that was forgotten. Track them apart.
- A standing fifteen minutes beats a hundred emails. Twice a week, the list, the blockers.
ITSG-33 expects the assessor to be present throughout, not to arrive at the end. Its ISSIP — the information system security implementation process, which threads security activities through a project's lifecycle — puts it this way:
… security assessors should actively participate in the execution of ISSIP activities, review ISSIP outputs as they are produced, and immediately advise authorizers of security issues.
ITSG-33 Annex 2 § 3.4.3As they are produced.3 Evidence collected alongside delivery is cheap. Evidence reconstructed after it is expensive and usually incomplete.
When Evidence Does Not Exist#
Sometimes the control is genuinely not implemented. Establish that early and openly. It becomes a result in Step 4 and a risk in Step 5 — and discovering it at report-writing time is what makes assessments feel adversarial. A control with no evidence in week two is a conversation. In week ten it is a dispute.
Where CtrlFort Fits#
The request list is where evidence collection lives or dies, and it is usually a spreadsheet that one person maintains and everyone else ignores.
In CtrlFort Assess the request list follows from the controls rather than being maintained beside them. Control Intelligence records, per control, the evidence that is expected; the deterministic engine's coverage analysis shows what has been provided against that and what is still missing. That is the tracked list in Figure 1, generated from the work. Evidence attached to a control stays linked to it, so a response and its artifact travel together into the finding and the report.
CtrlFort AI's job begins once evidence exists: it drafts the findings and recommendations from the structured result, not from the raw artifacts. The assessor still decides whether an artifact settles the control. The platform makes sure nothing is asked twice, forgotten, or filed where nobody will find it.4
Final Thoughts#
Ask for the artifact that settles the control. Track every request in one place. And when the answer is a policy, ask the four questions — politely, and until you have the artifact.
Previous: Step 2 — Profile Selection and Control Tailoring · Next: Step 4 — Assessing Control Effectiveness
Frequently Asked Questions#
What should a control response actually say?#
The mechanism, the component it runs on, and the artifact that proves it — with a date. If the response could be pasted under a different control without editing, it is not a response.
What evidence proves a periodic review is happening?#
Completed review records, with dates, spanning at least one full cycle — and ideally the evidence that findings from the review were acted on. The review procedure proves the review was designed; the records prove it runs.
How much evidence is enough?#
Enough to show each lettered part of the control statement is implemented and operating within the validity window. Where the control applies to many instances, a stated sample. More than that is cost without assurance.
What if the system owner cannot produce evidence in time?#
Record it as blocked with the reason, escalate once, and if it stays blocked treat it as "no evidence" — which is a result, not a failure of the assessment. Do not extend the assessment indefinitely waiting for an artifact that may not exist.5
References#
- Examine — glossary entry, citing NIST SP 800-53A Rev. 5 ↩National Institute of Standards and Technology · https://csrc.nist.gov/glossary/term/examine
- ITSP.10.033 — Security and privacy controls and assurance activities catalogue ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033
- ITSG-33 Annex 2 — Information System Security Risk Management Activities ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/annex-2-information-system-security-risk-management-activities-itsg-33
- ITSP.10.033 — Concepts and structure ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/cyber-security-privacy-risk-management/itsp10033/concepts-structure
- ITSP.50.105 — Guidance on cloud security assessment and authorization ↩Canadian Centre for Cyber Security · https://www.cyber.gc.ca/en/guidance/guidance-cloud-security-assessment-and-authorization-itsp50105