The week before the audit
It is a classic: the audit is in ten days and the team starts hunting for proof. Screenshots of configurations, user listings, minutes of reviews that may never have happened. Something is found for almost everything, and whatever does not turn up gets 'regularised' in a hurry.
The problem is not the audit. It is that the controls were designed without thinking about how they would be demonstrated.
A control's record sheet
Each control in the catalogue is written with six fields:
- What it requires, in one checkable sentence.
- Owner: the person responsible for it working (one more deliverable from the responsibility map).
- How it is checked: automatically, by sampling or by manual review.
- How often: continuous, monthly, quarterly.
- What evidence it produces: a report, a log, a set of minutes, always dated.
- The result of the last check, and what was done if it failed.
Three kinds of check
Automatic and continuous. The best option wherever possible: a rule checks the real configuration and records the result (encryption on, second factor required, ports closed). It is the idea behind policies that are inherited, seen as evidence.
By sampling. For whatever cannot be checked fully automatically: a representative sample is reviewed at some frequency (ten random changes from the last month, say, to see whether they went through review).
Manual review with minutes. For whatever requires judgement: the quarterly access review, the annual risk assessment. The minutes, signed and dated, are the evidence.
When a control fails
A check that fails is not hidden: it is recorded, it gets a corrective action with an owner and a date, and the next check says whether it was resolved. A history with a few corrected failures is far more credible to an auditor than a perfect one.
Doing all of this by hand is still a great deal of work. The natural question is how much of this evidence can collect itself.
How we apply it: Cybersecurity.