What 20 years in cybersecurity taught me about audits

I've spent twenty years in cybersecurity, and a good part of that time has been spent on audits: preparing for them, sitting through them, arguing about findings and fixing what they uncovered. The frameworks have changed many times over. These lessons haven't.

1. Evidence beats narrative

The most common audit finding isn't a missing control. It's a control that was performed and can't be proven. The access review happened, but nobody kept the list. The change was approved, in a chat thread that's since been deleted. Auditors can only rely on what they can see. Build controls that leave evidence as a side effect of doing them, and most findings disappear.

2. Scope decides everything

Most audit pain traces back to scope: drawn too wide, so every system must meet every control; drawn too narrow, so the certificate doesn't answer the customer's question; or drawn vaguely, so nobody knows which systems count. Decide it deliberately, write it down and defend it. Our post on scoping a first SOC 2 report applies to almost any audit.

3. The controls that fail are the ones nobody owns

When a control has a named owner who runs it as part of their job, it works. When it belongs to "IT" or "the security team" in general, it drifts until the week before the audit. Ownership is the cheapest control improvement there is.

4. Documents must describe reality

Template policies that describe a company you aren't are worse than short ones that describe the company you are. Auditors test what you wrote. Every gap between document and practice becomes a finding, and often a credibility problem for everything else you show them.

5. Auditors are more useful as allies than adversaries

The audits that go best are the ones where the team treats the auditor as a second pair of eyes rather than an opponent. Ask early how they'll test a control. Disclose known weaknesses with a plan. A finding you raised yourself, with a fix underway, reads very differently from one they had to dig out.

6. The second framework should be cheap

Organisations that run one programme per framework pay for every audit in full. Those that build one control set, mapped to every framework they answer to, pay mostly once. The mapping work is dull, but it compounds. It's a large part of why I built ControlMapping.

7. Different frameworks, same questions

After enough audits, the frameworks start to blur together. ISO auditors, SOC 2 auditors, PCI assessors and regulators use different words, but they ask the same handful of questions: what is in scope, who is responsible, how do you know it works, and what happens when it doesn't? An organisation that can answer those four questions clearly, with evidence, does well in almost any audit. The coverage matrix is a good illustration: across eleven frameworks, the same core topics come up again and again.

Key takeaways

• Build controls that leave evidence as a side effect.
• Decide scope deliberately and give every control a named owner.
• Treat audits as a by-product of running security well.

8. Passing isn't the goal

A clean audit means the controls in scope worked on the samples tested. It doesn't mean the organisation is secure; compliance isn't security. The best teams I've seen treat audits as a by-product of running security well, not the purpose of it.

If you take one thing from this: decide what you do, do it consistently, and let the evidence pile up on its own. The gap analysis is a good place to see how far your current controls already reach.

Questions

What is the most common reason for audit findings?

In my experience, missing or incomplete evidence for controls that were actually performed: reviews done but not recorded, changes approved verbally, populations that don't match.

How should you prepare for a security audit?

Run the controls continuously and keep their evidence as you go, check that documents match practice, and walk through a sample yourself before the auditor does.

Should we tell the auditor about weaknesses we already know?

Usually, yes. A weakness you've identified, with an owner and a remediation plan, reads as a working control environment. One the auditor discovers reads as a gap in oversight.