The Evidence Brief · Issue 1
Assurance language is not evidence
Words like reviewed, monitored, and in place sound like control. They are claims. Here is how to tell a claim from proof, and how to ask for the difference.
Some of the most reassuring words in a risk report are also the least informative. “Access is reviewed quarterly.” “Logs are monitored.” “Encryption is in place.” Each sentence sounds like a control. Each one is really a claim, and a claim is only as good as the evidence behind it.
What I’m seeing
When I led IT and cybersecurity audits as Auditor in Charge, the gap between the language and the evidence was usually where the findings lived. Not because anyone was hiding anything. Assurance language is simply easier to write than evidence is to produce, and over time the words start to stand in for the work.
A few patterns show up again and again:
- “Reviewed” with no reviewer. The procedure says access is reviewed, but no one can show who reviewed it, what they looked at, or what they changed as a result.
- “Monitored” with no response. Alerts fire into a queue. Someone may glance at them. There is no record of what was investigated, closed, or escalated.
- “In place” with no scope. The control exists somewhere, for some systems. Which ones, and which ones are excluded, is not written down.
- “Ongoing” with no date. The remediation has been “in progress” for several reporting cycles, and the status line has not changed.
None of these phrases is false on its own. The problem is that they describe intent or design, and the reader hears operation. A board member who reads “access is reviewed quarterly” reasonably assumes the last review happened, was complete, and found what it should have found.
Why it matters
Leaders make decisions on the words in front of them. If a CRO reports that a key control is in place, the committee moves on to the next item. That is a reasonable response to the sentence. It may not be a reasonable response to the facts.
This also matters for the people who own controls. When reporting rewards confident language, owners learn to write confidently. When reporting asks for evidence, owners learn to keep it. The second habit is the one that holds up in an exam, an audit, or an incident review.
There is a simple test I use. For any assurance statement, ask three things. Who did it? When did they last do it? What did it produce? A control that works can answer all three quickly, usually with a document, a ticket, or a system record. A control that only exists on paper tends to answer with more language.
Frameworks point the same way. NIST CSF 2.0, for example, puts weight on governance and on improving based on results, and that only works when there is a record of results to learn from. Design is where a control starts. Operating evidence is what shows it is working.
What to do this week
- Pick one recurring report and circle the verbs. Take the last risk or control report you signed off on. Mark every “reviewed,” “monitored,” “in place,” “ongoing,” and “addressed.” For each one, write down the evidence you would expect to see behind it.
- Ask for one artifact, not one explanation. Choose the control you rely on most and ask its owner for the most recent evidence of operation: the review sign-off, the alert disposition, the scope list. See how long it takes to arrive and whether it matches the description.
- Add a proof column to your reporting template. Next to each control status, add a short field for the evidence reference and the date it was produced. Owners will fill it in, and the gaps will become visible without anyone having to argue about them.
A question for your next meeting
“What is the most recent evidence that this control actually ran, and who produced it?”
If the answer is a document with a name and a date, you have assurance; if the answer is another sentence, you have a follow-up.
Until next time,
Nath
The Evidence Brief shares practical perspectives on technology risk, audit, and AI governance. It is general information, not legal or regulatory advice.