ISO 27001: What an Audit Actually Looks Like, From the Inside

What does an ISO 27001 audit day actually involve?

Most people preparing for their first ISO 27001 audit have no idea what the actual day looks like.

An audit day is mostly conversation and evidence review. The auditor asks how a control actually works in practice, asks to see evidence — a ticket, a log, a signed policy — and checks whether what's documented matches what people actually do.

The teams that struggle aren't usually the ones with imperfect controls — they're the ones whose documentation doesn't match reality.

Why does the documentation-practice gap matter more than the controls themselves?

Because an auditor isn't grading your ISMS against an abstract ideal — they're checking whether the control you wrote down is the control you're actually running. A team with a slightly weaker but honestly-documented access review process will usually fare better than a team with a strong process on paper that nobody actually follows, because the second gap undermines confidence in every other control in the audit.

That's the real preparation work: not perfecting controls in the weeks before an audit, but closing the gap between what's written and what's practiced, year-round. Evidence should be a byproduct of doing the work — a ticket that gets created because access really was reviewed — not something assembled retroactively once the audit is scheduled.

Key Takeaways

Audit days are conversational, not adversarial inspections

Auditors check whether documented process matches actual practice

Evidence means a ticket, a log, or a signed policy — not a slide

The biggest audit risk is a gap between what's written and what's actually done

FAQ

How long does a typical ISO 27001 audit take?

It varies by organization size and scope, but expect it to be structured as a series of conversations and evidence walkthroughs across multiple controls, not a single all-day inspection. Stage 1 and Stage 2 audits are typically scheduled separately.

What's the difference between a control and a control objective?

A control objective is the outcome you're trying to achieve (e.g. 'access is restricted to authorized users'); a control is the specific mechanism implementing it (e.g. role-based access control with quarterly access reviews). Audits check both — that the mechanism exists and that it actually achieves the objective.

Can engineering teams prepare for an ISO 27001 audit without a dedicated GRC function?

Yes, though it takes deliberate effort — the core preparation is making sure documented procedures match what the team actually does day to day, and that evidence (tickets, logs, approvals) is being captured as a byproduct of normal work, not created retroactively before the audit.