The Compliance Industrial Complex - Part II
What Does an ISO 27001:2002 Auditor Actually Want?
This is the second article in a series on rethinking ISO 27001 compliance from first principles. In the first, I argued that the compliance industry has a structural incentive to sell preparation rather than protection. This article asks a different question: what does the person on the other side of the table actually need to see?
Let me read you a question from a real ISO 27001 audit:
“How does top management demonstrate commitment to information security?”
That’s it. No trick. No gotcha. Clause 5.1, straight from the standard. And yet I’ve watched organisations spend weeks preparing for it.
The typical answer involves a slide deck. Maybe a screenshot of a signed information security policy with the CEO’s name at the bottom. Sometimes, a list of M365 E5 licences purchased, as proof that management “allocated resources to information security.”
The auditor nods. Then asks the follow-up:
“Can you describe a recent decision where top management allocated additional resources to the ISMS?”
Silence.
Not because the organisation hasn’t invested in security. They probably have. However, no one thought to document the decision. Nobody wrote down that the board approved the Sentinel deployment, or that the CTO authorised additional Defender licences after a near-miss phishing incident, or that management reviewed the risk register and agreed to accept the residual risk on a specific control.
The investment happened. The evidence didn’t.
This is the gap I wish to discuss. Not the gap between organisations and the standard — the gap between what auditors actually want and what organisations think they want.
The question nobody prepares for
Every auditor question has two layers. The first is the question itself. The second — the one that matters — is the follow-up.
Take Clause 4.1: “What external and internal issues have you identified that are relevant to your information security?”
Routine question. Difficulty level: straightforward. Most organisations can answer this. They’ll reference a context analysis document, maybe a SWOT analysis, or perhaps a list of regulatory requirements.
The follow-up: “Can you give an example of an external issue that led to a change in your ISMS?”
The auditor is now testing whether the context analysis is a living process or a document created during implementation and never revisited. They want a specific example. A regulatory change that triggered a policy update. A market shift that changed the risk profile. A technology transition that altered the scope.
If the answer is “we review our context annually in the management review,” the auditor will request access to the management review. If those minutes don’t reference specific external issues and the decisions they triggered, the auditor knows the context analysis is merely decorative.
The standard doesn’t ask for perfection. It asks for a process that actually runs.
Documented versus demonstrated
There’s a distinction in ISO 27001 that the compliance industry systematically undervalues: the difference between documented and demonstrated.
The standard requires both. The ISO SME Handbook — the official practical guide — states that certification bodies need to “observe your processes, interview your staff and make other verifications as necessary to have confidence in your ISMS.” Not just read your documents. Observe, interview, verify.
Auditors have a specific name for this: the “Hallway Test.”
They don’t just sit in the boardroom. They stop a random employee in the hallway (or on a Zoom call) and ask: “How do you report a phishing email?” or “Where can you find the information security policy?” If the employee’s answer contradicts the 40-page policy document you just handed over, you have a problem.
Yet the entire compliance preparation industry is built around documentation. Write the policies. Create the procedures. Fill in the Statement of Applicability. Prepare the evidence pack.
Nobody prepares people for the interview.
An auditor asking “Walk me through your risk assessment process” doesn’t want to hear you read the risk assessment methodology document back to them. They want you to open the risk register, point to a specific risk, and explain how it got there. Who identified it? How the likelihood and impact were scored. Who approved the risk acceptance criteria? Whether the same methodology produces consistent results when applied by different people.
That last part — consistency — is what catches most organisations. Clause 6.1.2 requires that the risk assessment process “produce consistent, valid and comparable results.” The auditor will ask: “How do you ensure consistency when different people perform assessments?” If the honest answer is “only one person does them,” you’ve just revealed a single point of failure in your ISMS. If the answer is “we haven’t tested that,” you’ve revealed that the process hasn’t been validated.
Neither answer fails the audit necessarily. But both invite deeper scrutiny. And deeper scrutiny is where preparation meets reality.
The three difficulty levels
I’ve been working through auditor questions — compiling them, categorising them, testing them against real environments. I’ve found that questions fall into three distinct difficulty levels, and most organisations prepare only for the first.
Routine questions test whether the ISMS exists. “What is the scope of your ISMS?” “Do you have an information security policy?” “Is there a risk register?” These are Stage 1 questions — document review. If you have the paperwork, you pass.
Probing questions test whether the ISMS works. “How does your scope boundary analysis account for interfaces with external organisations?” “When did top management last participate in an ISMS activity?” “Show me the most recent internal audit report and the actions taken.” These are Stage 2 questions — operational audit. The auditor seeks evidence that processes are actually executed, not merely that they’re documented.
Challenging questions test whether the ISMS is effective. These are the ones that separate paper compliance from genuine security management. They test for things you can’t prepare by rehearsing answers — you either do them or you don’t.
Here’s an example at the challenging level. Clause 9.2, internal audit:
“Describe your internal audit programme and how you ensure objectivity and impartiality.”
The routine answer: “We conduct internal audits annually covering all controls.”
The probing follow-up: “How do you ensure objectivity when you have a small team?”
Now you’re in difficult territory. In a five-person organisation, all members have been involved in developing the ISMS. The standard knows this — it doesn’t require you to hire an external auditor (though that helps). But Clause 9.2.2 strictly requires objectivity and impartiality. You must demonstrate that no one is auditing their own work. If the CTO wrote the disaster recovery plan, the CTO cannot audit it.
And here’s the challenging follow-up: “If all your internal audits show 100% compliance, how do I know the audits are rigorous?”
That question is devastating. Because it implies — correctly — that a perfect internal audit score is more suspicious than a few findings. Real audits find things. An internal audit programme that consistently reports no issues is either not looking hard enough or not being honest about its findings.
Organisations that handle this well are those that want their internal audits to identify problems. Because findings that are identified, tracked, and resolved are evidence of a functioning ISMS. Findings that are hidden or never discovered are evidence of a broken one.
What the auditor is really testing
Strip away the specific clauses and controls, and every auditor question is testing one of four things:
1. Do you know what you have? Asset inventories. Scope boundaries. Data flows. Interface mappings. The auditor wants to know whether you understand your own environment well enough to protect it. If you can’t describe what’s in scope, you can’t credibly claim to be managing it.
2. Do you do what you say you do? This is the policy-to-reality gap. Your access control policy says “MFA is enforced for all privileged accounts.” The auditor will request access to the Conditional Access policy. If there are exclusions — and there always are — they’ll ask why. The answer had better be documented, justified, and reviewed.
3. Would you know if something went wrong? Monitoring, detection, and incident response. The auditor isn’t asking whether you’ve had incidents. They’re asking whether you’d know. An organisation that has never detected an anomaly is less credible than one that has detected three, investigated them, and documented the outcomes.
4. Do you learn from what happens? Continual improvement. Management review. Corrective actions. The auditor wants evidence that when something goes wrong—a non-conformity, an incident, a near-miss—the organisation doesn’t merely fix it. They change the system so it doesn’t happen again. Then they verify the change worked.
Most compliance preparation focuses exclusively on point 2. Organisations spend months ensuring their policies align with their configurations. But auditors who know what they’re doing will spend equal time on points 3 and 4 — because that’s where you find out whether the ISMS is alive or just archived.
The proportionality principle
Here’s something that is often overlooked amid compliance anxiety: the standard requires proportionality.
A five-person MSP is not expected to have the same controls as a multinational bank. The standard explicitly allows organisations to determine controls that are “appropriate.” The ISO practical guide for SMEs is built around this principle — it acknowledges that small organisations have limited resources and expects them to demonstrate adequate risk management, not compliance with every possible control at maximum intensity.
I’ve been compiling questions that test this. One of them asks:
“Given that you are a small organisation, how do you justify the adequacy of your external engagement? An auditor might expect formal memberships and structured intelligence sharing — what do you offer instead?”
The instinct is to apologise for being small. To say “we can’t afford ISAC memberships” and hope the auditor moves on. But that’s the wrong answer. The right answer reframes adequacy around action, not membership:
“We consume threat intelligence through Microsoft Defender and Sentinel, which aggregate signals from millions of endpoints. We monitor NCSC advisories. When a critical advisory is received, we evaluate it against our risk register and update Sentinel analytics rules as needed. We track these decisions in management review. The measure of adequacy isn’t how many groups we belong to — it’s whether intelligence is consumed, evaluated, and acted upon.”
That answer won’t satisfy every auditor. But it demonstrates thinking. It shows the organisation understands the intent of the control and has made a proportionate decision. An auditor can challenge the decision. They can’t challenge the reasoning process.
The follow-up question test
Here’s a practical exercise. Take any clause of ISO 27001 and ask yourself the auditor’s question. Then ask the follow-up. Then ask the follow-up question to the follow-up question.
Clause 5.1 — Leadership commitment:
“How does top management demonstrate commitment?” → You answer.
“When did they last participate in an ISMS activity?” → You answer.
“What decision did they make, and what changed as a result?” → Can you answer?
Clause 9.3 — Management review:
“How does management review the ISMS?” → You answer.
“Show me the inputs and outputs of the last review.” → You produce them. (Note: Clause 9.3 requires specific inputs like status of actions, changes in issues, and performance feedback, and specific outputs like decisions related to improvement.
“How were actions from the previous review tracked to completion?” → Is there an action log with owners, dates, and evidence of completion?
Annex A Control 5.3 — Segregation of duties:
“How do you enforce segregation of duties?” → You describe PIM, role assignments, and access reviews.
“What evidence do you have that these controls are effective in practice?” → You show... what? Audit logs? Access review completion records? Remediation tickets for violations?
“If you cannot segregate duties due to team size, what compensating controls do you have in place?” → This is the magic phrase. If you are too small to separate the person who approves the change from the person who implements it, you must have a compensating control—like rigorous logging and independent review of those logs.
That third level is where compliance meets reality. If you can answer it — with evidence, not assertions — the audit is straightforward. If you can’t, no amount of policy documentation will save you.
What if you could rehearse?
I’ve been compiling auditor questions — not as a study guide, but as a test harness. The idea started simply: map every question to a clause, classify its difficulty, define the expected evidence, and document the follow-up chain. What surprised me was the scale. The current compilation exceeds 788 questions across all clauses and controls, at all three difficulty levels.
But the real shift came when I stopped treating them as a static question bank and started treating them as a quality evaluation framework. If your ISMS is working, it should be able to answer routine questions automatically, probing questions with structured evidence, and challenging questions with evidence-backed reasoning.
This turns the audit from an event you prepare for into a capability you can test. Run the questions against your evidence. Score the responses. Identify the gaps — not “do we have the policy?” but “can we answer the follow-up with evidence?”
The organisations that can rehearse the audit at any moment are fundamentally different from those that need two weeks of preparation. Not because they have better documents. Because they have a system that practises answering the questions the standard was designed to ask.
The question I’ll leave you with
I noted previously that the standard asks excellent questions. It does. But most organisations never hear them, because they’re hidden behind layers of consultant interpretation and compliance preparation ritual.
The auditor doesn’t want a 200-page policy. They want to see that you understand your own environment, that your processes actually run, that you’d detect a problem if one occurred, and that you learn from what happens.
Pick any clause of ISO 27001. Could you answer the auditor’s question about it — with evidence — in 60 seconds, right now?
The audit is a formality. If you can’t, no amount of preparation will change that because the auditor isn’t testing your documents. They’re testing your organisation.
More next time, when we talk about what happens when you start measuring the wrong things.
JJ Milner is a Microsoft MVP and the founder of Global Micro Solutions, a managed services provider operating across 1,200+ Microsoft 365 tenants. He writes about rethinking compliance from first principles.