Most of the anxiety around an ISO 27001 certification audit comes from treating it as a document review. It is not. A competent auditor spends most of their time talking to people and watching how information security actually happens day to day — your documentation is the reference they check that conversation against, not the thing being graded on its own.
Understand what the auditor is actually testing
The auditor is testing whether your information security management system (ISMS) is real: whether the controls you say you have implemented are actually operating, whether people understand their role in them, and whether the system catches and corrects its own gaps. A stack of well-written policies that nobody on the floor recognizes is a bigger red flag than an imperfect but genuinely followed process.
Stage 1 and Stage 2, and why the distinction matters
Stage 1 is a documentation and readiness review — the auditor checks that your ISMS scope, risk assessment, Statement of Applicability, and core policies exist and are coherent, and identifies anything that would cause the full audit to fail outright. Stage 2 is the substantive audit: interviews, evidence sampling, and testing whether controls operate as documented. Treating Stage 1 as a formality is a common mistake — issues raised at Stage 1 are far cheaper to fix than the same issues surfacing at Stage 2.
Risk assessment: the document everything else should trace back to
Auditors read your risk assessment early, because it is meant to be the origin point for almost everything else in your ISMS — your SoA justifications, your control priorities, your incident response focus. A common weakness is a risk assessment done once during initial implementation and never genuinely revisited: new systems added, new vendors onboarded, or a past incident that should have triggered a reassessment but didn't. Before the audit, confirm your risk register reflects your organization as it actually operates today, not as it operated when the ISMS was first built.
Get your Statement of Applicability genuinely audit-ready
The Statement of Applicability (SoA) is the document auditors return to most often, because it is your organization's own claim about which Annex A controls apply and why. A generic SoA copied from a template, with every control marked "applicable" regardless of relevance, is an immediate credibility problem. A defensible SoA reflects real decisions: controls excluded with a genuine justification, controls included with a clear owner, and consistency between the SoA and your actual risk treatment plan.
What "objective evidence" really means
Auditors are trained to distrust assertions and trust evidence. "We review access rights quarterly" is an assertion. A dated access review log with an owner's name and follow-up actions is evidence. Before the audit, walk through your key controls and ask: if someone asked me to prove this happened last quarter, could I produce something in under two minutes? If the honest answer is no, that control needs an evidence trail before the auditor arrives, not during the interview.
Common nonconformities — and how to avoid them
The findings we see most often are not exotic: internal audits that were scheduled but not actually completed on time, risk assessments that were never updated after a genuine change in the business, access rights that were not revoked promptly when someone left or changed roles, and training records that do not match who actually attended. Every one of these is avoidable with a simple tracking habit, not a technical fix — which is exactly why they keep recurring. A slightly less common but higher-severity finding is a documented incident response procedure that has genuinely never been tested — auditors increasingly ask to see evidence of at least a tabletop exercise, not just a policy nobody has rehearsed.
Prepare your people, not just your paperwork
An auditor interviewing a department head who cannot explain, in their own words, what they are responsible for under the ISMS is a far worse outcome than a minor documentation gap. Before the audit, brief every function that will be interviewed — not to rehearse a script, but so each person genuinely understands their role, where their evidence lives, and who to call if a question falls outside their area.
The week before: a practical checklist
- Confirm your internal audit and management review for the current cycle are both complete and documented
- Re-check that your SoA, risk register, and risk treatment plan tell a consistent story
- Sample-test three or four controls yourself: can you produce evidence in minutes, not hours?
- Confirm access rights and asset registers reflect current staff and current systems
- Brief interviewees on scope and evidence location, not on what to say
If your team is heading toward a first-time ISO 27001 certification and wants a structured run-up to the audit rather than a last-minute scramble, our internal auditor and implementation training builds exactly this kind of readiness — take the free assessment to see where your ISMS currently stands.