The audit is a sampling exercise, not a document review
An ISO 27001 certification audit is an evidence-sampling exercise. The auditor is not there to read your policy library and grade the prose. They are there to pick moments from the past year, a joiner, a leaver, an incident, a backup, a supplier review, and check whether the management system you described on paper actually executed at each one. Organisations that treat certification as a writing project sail through Stage 1 and get taken apart in Stage 2, because their documents were finished three weeks before the audit and describe a system that has never run.
This follows from what the certificate actually asserts. ISO/IEC 27001:2022 certifies a management system, not a security posture. The clauses require a loop: assess risk, treat it, check yourself through internal audit and management review, and correct what you find. Every step of that loop produces records when it runs and produces nothing when it does not. Records are the only thing an auditor can verify in a short visit, so records are what the audit is made of. The gap between having a policy and following it is precisely the gap between a document and its evidence trail, and it is where almost every nonconformity lives.
The Statement of Applicability is a promise you wrote yourself
Clause 6.1.3 requires a Statement of Applicability: a document that walks all 93 Annex A controls, organised in the 2022 edition into organisational, people, physical and technological themes, marks each as applicable or excluded, justifies the decision, and states whether the applicable ones are implemented. The SoA is not paperwork. It becomes the audit plan. The auditor works down it line by line, and every 'implemented' is an invitation to sample.
Two failure modes dominate. The first is over-claiming: marking controls implemented because they sound virtuous or because a template said so. Each false tick is a nonconformity waiting for the auditor to pick it. The second is unjustified exclusion: a software company excluding the secure development controls, or a firm with laptops in every home office excluding remote working. Exclusions are legitimate only when the justification traces back to your scope and your risk assessment, and auditors read those justifications closely because they are the easiest place to hide.
Write the SoA to match reality. Applicable, partially implemented, with completion scheduled in the risk treatment plan is an acceptable and honest state. Certification does not require perfection; it requires that the system knows its own gaps and is demonstrably working them. A true 'partially implemented' is defensible. A false 'implemented' is not.
Stage 1 and Stage 2 test different things
Certification runs in two stages, and preparing for the wrong one wastes months. Stage 1 is a readiness review: the auditor confirms your scope makes sense, the SoA exists and hangs together, your risk methodology is defined, and the mandatory activities have run at least once. You cannot pass Stage 1 without a completed internal audit and management review, which surprises teams who assumed those were things you start doing after certification. Stage 1 usually produces a list of areas of concern; treat it as free consulting and fix them before Stage 2 is booked.
Stage 2 is operating effectiveness. The auditor samples records, interviews staff who are not the security lead, and walks processes end to end. Passing it earns a certificate on a three-year cycle with surveillance audits roughly annually in between, so the sampling never really stops. And since the transition window from the 2013 edition closed in late 2025, every audit now runs against the 2022 control set, with particular attention on the controls that edition introduced: threat intelligence, information security for cloud services, and data leakage prevention among them.
What sampling looks like on the day
The pattern is consistent across certification bodies: the auditor picks from the population, not from your curated folder. They ask HR for the full list of starters and leavers, choose names themselves, and trace each one through your identity system. If access for a departed engineer was revoked four weeks after their last day and the offboarding procedure promises 24 hours, that is a finding, and no amount of policy quality changes it.
A representative Stage 2 day includes samples like these:
Notice what is absent from all of it: nobody reads the policy document during any of this. The policy set the standard the evidence is judged against. That is its entire role on the day.
- Joiners and leavers: provisioning and revocation traced through tickets and directory logs, against the timeframes your own procedure promises.
- Backups: the most recent restore test and its result, not the backup job configuration. A backup that has never been restored is a hope, not a control.
- Incidents: one entry from the incident log walked end to end, detection, triage, the decision on whether it was notifiable, lessons recorded.
- Suppliers: one critical vendor pulled from the register, with the security review your policy says happens before onboarding.
- People: a staff member chosen at random, asked how they would report a suspicious email and where the acceptable use policy lives.
The clauses that fail first
Clause 9.2, internal audit, fails more certifications than any technical control. The standard requires audits that are objective and impartial, and an internal audit performed by the person who built the ISMS, finding nothing but strengths, tells the certification auditor the whole loop is decorative. Use someone genuinely independent: another team, a peer firm, an external reviewer. A good internal audit that surfaces real problems is evidence the system works. A suspiciously clean one is evidence it does not.
Clause 9.3, management review, fails next. The standard specifies inputs the review must consider, including audit results, incident trends, changes in the risk picture and progress against objectives, and it expects documented decisions coming out. A calendar invite is not a management review; minutes showing leadership saw the inputs and decided things are. Behind those two sit the slower failures: a risk assessment performed once and never revisited despite a cloud migration and two new products, and corrective actions raised at the last audit and still open at the next one. Minor nonconformities in these areas are survivable and normal. A major, meaning a required element is absent or has totally broken down, stops certification until you fix it and prove the fix.
Making the audit boring
The preparation that works is unglamorous. Run the full system for at least one complete cycle, a genuine internal audit, a genuine management review and a round of corrective actions, before Stage 2 is booked. Make evidence a by-product of normal operation rather than an artefact assembled for the visit: access changes through tickets, deployments through pipelines, directory changes captured in Entra ID audit logs. If producing evidence requires a special effort, the finding already exists; you are just choosing who discovers it.
Two Australian notes. First, pick a certification body accredited through JAS-ANZ; an unaccredited certificate will not survive the procurement due diligence it was bought to satisfy. Second, be honest about whether you need ISO 27001 at all. For a smaller business being nudged by one enterprise customer, SMB1001 certification or a maturity uplift against the ACSC Essential Eight often answers the actual question being asked at a fraction of the sustained cost, and we say that as a firm that runs certification-readiness work and holds SMB1001 Gold itself. If ISO 27001 is genuinely the requirement, prepare the way the auditor will work: assume every claim in your SoA will be sampled, and make sure the sample is boring.