The Certificate Is Issued to a System, Not to a Week

A surveillance audit against ISO/IEC 27001 usually runs for two or three days. A full certification audit takes longer, but it is still counted in days. In that time an auditor samples records, interviews a handful of people, examines a subset of controls, and forms a judgement about how an organisation has behaved for the preceding twelve months and will behave for the next. This is not a defect in the scheme. No audit of any kind could work otherwise, and the sampling logic is sound. But it is worth stating plainly, because everything that follows depends on it: the audit is a sample, the certificate is issued to a management system, and the distance between the two is bridged by something no standard can specify — whether the people inside the organisation do these things when nobody is scheduled to look.

I have conducted internal audits against frameworks and I have prepared organisations to face external ones, and the most reliable predictor of how an audit will go has very little to do with the quality of the documentation. Policy sets are easy to get right. They can be drafted in weeks, they are reviewable in advance, and a competent consultant can make them defensible. What cannot be drafted in weeks is the set of habits that produce evidence as a by-product of ordinary work, and that is what the certificate is actually attesting to.

Preparation and operation look identical on paper

The most useful thing an auditor can do is stop talking to the person who has prepared for the conversation. Ask the compliance manager how access reviews work and you will get a fluent, accurate answer. Ask the engineer who actually runs the review and you learn whether it happens. The gap between those two answers is the single most informative finding available in an audit, and it never appears in a document.

Other tells are equally unglamorous. Policy documents whose revision history shows edits clustered in the six weeks before each audit and nowhere else. Evidence that exists but had to be produced — when I ask to see the last access recertification and it arrives within the hour, that is either a sign of good automation or a sign that somebody has just generated it, and the difference matters. Staff who know a procedure exists but have never had cause to open it. Records that are complete and consistent for the sample period and thin either side of it.

None of this is dishonesty, and I want to be careful here, because organisations hear this observation as an accusation and it is not one. Preparing intensively for an audit is entirely rational behaviour under a deadline, and I have never met a team that did it out of bad faith. The problem is that it converts the audit from a measurement into a performance, and a performance tells you nothing about the fifty-one weeks that were not observed.

The question worth asking, and it is as useful for an organisation to ask itself as for an auditor to ask it, is not whether a control operates. It is what would have happened in March. Who would have noticed. What record would exist now. If the honest answer is that nobody would have noticed and no record would exist, the control is a description rather than a control, however well it is written.

Exceptions are evidence, not embarrassment

A risk acceptance that has been rolled over annually for five years, signed each time by whoever was least inconvenienced by signing it, is one of the more common things I find in an otherwise healthy management system. It is usually attached to something real — a legacy application that cannot be patched without breaking an integration, a supplier arrangement inherited from an acquisition — and the original reasoning was sound. What has happened since is that the review date arrived, nobody had new information, and extending was easier than re-examining.

I want to argue against the instinct this produces, which is to treat open exceptions as a mark against the organisation. A formally recorded exception, with a named owner who is still employed, a stated rationale a third party can follow, and a review date that has actually triggered a review, is stronger evidence of a working system than an empty exception register. In a complex estate, an ISMS with no open exceptions almost never means there are none. It means they are not being recorded, which is a considerably worse position, because unrecorded risk cannot be prioritised, reported or inherited by whoever takes the role next.

What makes an exception rot is almost always human rather than procedural. An owner who has left the organisation and whose exception was never reassigned. A review date with no reminder attached to it. A rationale written in shorthand that made sense to the two people in the room and is opaque to everyone since. These are fixable with very little effort, and fixing them changes an exception register from a list of embarrassments into the part of the system that demonstrates judgement.

Internal audit is a control, with the failure modes of any other control

Clause 9.2 asks for internal audits conducted by auditors who are objective and impartial. In a large organisation this is straightforward. In a mid-sized one it frequently is not, and the compromise I encounter most often is an internal auditor who reports, directly or in practice, to the person who owns the controls being audited. What follows is rarely falsification. It is subtler: findings get discussed before they are written, severity gets negotiated downward with reasonable-sounding arguments, and the audit gradually becomes a conversation between colleagues who both want the programme to look well run.

Where full separation is not achievable, there are workable compensations. Rotate who audits which domain, so no one audits the same area twice running. Bring an external party in for the areas where the conflict is sharpest rather than for the whole scope, which is cheaper than most organisations assume. Route findings to someone with no stake in the outcome — a board committee, a risk function, a director outside the reporting line. None of these is as good as genuine independence, and none of them should be described as though it were, but all of them are better than an internal audit whose conclusions were negotiable.

The second failure mode is competence, and it produces a distinctive symptom: findings that are correct against the clause and useless to the organisation. An internal auditor who audits the standard rather than the business generates a list of technical nonconformities that nobody disputes and nobody acts on, because none of them describes a risk anyone recognises. Audit findings change behaviour when the person receiving them can see the failure they are meant to prevent.

What a nonconformity is for

An organisation that treats a minor nonconformity as a failure will, quite predictably, receive fewer of them. It will not have fewer of them. It will have the same number, reported less often, by people who have learned that raising something costs more than staying quiet. This is not a security-specific dynamic — it is the same one that governs near-miss reporting in aviation and healthcare — but it applies here with full force, and the consequence is that the organisations most anxious about their audit results are often the ones with the least reliable picture of their own state.

The distinction that matters in corrective action is between closing the finding and addressing why the finding was possible. A missed quarterly access review can be corrected by performing the review, recording it, and closing the item. That is a complete corrective action by the letter and it guarantees the same finding next year. The alternative is to ask why the review was missed, and the answer is usually structural: it depended on one person remembering, there was no reminder, no deputy, and no way for anyone to notice the miss until an auditor asked.

Root cause analysis that terminates at "human error" has not found a root cause. It has named the last person in the chain. The useful version asks what the process expected of that person and whether the expectation was reasonable — whether it required vigilance where it should have required a calendar entry, or memory where it should have required a checklist.

The clauses everyone satisfies and nobody implements

Competence, awareness and communication — clauses 7.2, 7.3 and 7.4 — are, in my experience, the clauses most consistently satisfied on paper and least consistently implemented in substance. The standard evidence is an annual e-learning module and a screenshot of completion rates, which demonstrates that people clicked through a training package and nothing else. I have never seen that evidence correlate with anything.

What these clauses are reaching for is harder to screenshot. Whether a person who notices something wrong knows where to take it. Whether they expect it to be acted on. Whether raising it is more likely to result in a fix than in being asked why they were looking. An organisation where a developer will say, unprompted, that a service account has more privilege than it needs has a functioning awareness programme regardless of what its training statistics show. An organisation where that observation stays in someone's head does not, and no completion rate will detect the difference.

This is the part that takes years rather than weeks, and it is the reason the audit-preparation approach never fully works. Documentation can be built to a deadline. Habits cannot, and habits are what the sampling logic of an audit is actually testing for.

What it looks like when it works

The organisations I have seen pass cleanly, year after year, are not the ones with the best-written policy sets. They are the ones where audit week is uneventful, because it is not meaningfully different from any other week. The evidence is available because the work that generates it was going to happen anyway. Staff answer questions from what they do rather than from what they revised. Exceptions are open, owned and current. Findings arrive, and some of them are uncomfortable, and they get fixed at the level of the cause rather than the symptom.

Getting to that state is slower than building a defensible document set, and there is no route around it. But it is the only version that still holds eleven months after the certificate goes on the wall, when nobody is scheduled to visit and the only thing keeping the system running is whether the people inside it think it is worth running.