"Will we pass the audit?" The question comes up in every one of our ISMS projects, usually about three months before the date, and almost always with an undertone of exam nerves. Understandable. For most people in the room, the last external exam was decades ago, and now a stranger shows up to judge their work.
The short answer: if your ISMS runs in daily operations, the certification audit is the least risky part of the entire ISO 27001 certification. The long answer is still worth your time. In practice, the fear of the audit does more damage than the audit itself, because it tempts companies to build for the auditor instead of for themselves.
Two stages, few surprises
The process is structured the same way at every accredited certification body, because it is defined in the standard that governs the certifiers themselves (ISO/IEC 17021-1). That is good news: there are no secret rituals and no certification body that "audits harder" than the standard prescribes. The initial audit runs in two stages.
Stage 1 is the documentation and readiness review. The auditor checks whether your ISMS is complete on paper: scope, risk assessment, statement of applicability, internal audits, management review. And he assesses whether attempting stage 2 is realistic. The result is a list of open points, and that list is the point of the exercise: finding gaps while they are still cheap to close.
Stage 2 follows a few weeks later and tests effectiveness. Now the auditor no longer checks whether documents exist, but whether the system is lived. He talks to employees, asks for evidence (access grants, handled incidents, training, supplier reviews) and compares what actually happens in your company with what you have defined.
That last clause is the most important one in the whole process. The benchmark is not some ideal level of security defined elsewhere. The auditor audits against the standard and against your own system. If you write into your processes what you do in everyday operations, you have a far easier time than if you copy the prettiest template and then hope nobody asks questions.
The scope of the audit is not up for negotiation either, and it holds no surprises: the certification body derives the number of audit days from the size of your organization and your scope, following fixed rules (set out in ISO/IEC 27006). You receive the audit plan before the date, with topics, interview partners and times. Anyone who gets surprised on audit day has not read the plan.
What the audit day itself looks like
A certification audit starts with an opening meeting in which the auditor confirms the agenda, and it ends with a closing meeting in which he discloses all findings. In between, he works through the plan: interviews with the people responsible, samples from systems, evidence for individual controls. There is no letter that arrives weeks later with unannounced findings. What ends up in the report, you have already heard in the closing meeting and usually discussed as well.
One peculiarity of the procedure confuses many people the first time: the auditor is not allowed to advise you. The separation of consulting and certification is part of his accreditation. To the question "So how should we solve this?" you will get no answer, however much he might like to give one. He states findings, you decide. It feels unsatisfying in the moment, but it protects exactly what makes the certificate valuable to your customers: nobody audits their own work.
Nonconformities are the normal case
Hardly any audit ends without findings, and that is by design. There are two categories, and the difference decides how stressful they are.
A minor nonconformity means: at one specific point, practice deviates from the system, while the system as a whole works. A recovery test was run later than planned, one leaver process was not documented cleanly. You will usually receive a few of these. You answer them with a corrective action plan, and the certification body issues the certificate anyway.
A major nonconformity means: the system fails fundamentally at some point. Internal audits never took place, the risk assessment exists only as an empty template, an entire part of the scope was never looked at. Then you have to fix it and provide evidence of the correction before the certificate is issued. Even that does not end the project, it delays it. Annoying, but avoidable.
In our experience, an audit with no findings at all deserves a follow-up question. Either the ISMS is exceptionally mature, or the audit was superficial. A good auditor finds something, and a good company wants him to find something. That is exactly what you pay him for.
Where SMEs fail in the ISO 27001 certification
Not on trick questions. In the projects we support or take over, it comes down to three patterns, all avoidable and all visible long before the date.
First: no operations before the audit. A management system needs runtime before there is anything to audit. Internal audits and a management review must have taken place at least once before stage 2, and the auditor wants to see evidence from daily operations, not freshly created documents that all share the same creation date. An ISMS that is three weeks old can be formally complete and still prove nothing. Plan several months of lived operations between completion and stage 2.
Second: built for the auditor. The 200-page binder from a purchased template that nobody except the project lead has ever opened. In the interviews, the auditor notices within minutes whether the person at reception, in IT or in HR knows the processes they supposedly live. That is the moment paper security gets exposed. The irony: a leaner system that people know passes the audit better than the thick one built to impress.
Third: the scope is cut wrongly. If you ambitiously put the whole company into the scope even though your customer only requires certification of one area, you will audit and maintain twice as much from now on. If you cut it too small, you get a certificate that is useless to your customer. The scope is a business decision, not a technical one, and it belongs at the start of the project, not at the end.
All three patterns share the same root: the audit is treated as an exam you cram for shortly before the date. The more useful direction is the reverse. First measure where you stand, then build what is missing, then certify what runs. Why that order saves money is described in our post Security assessment before ISO 27001. And what the whole thing costs is broken down honestly in What does ISO 27001 cost?
After the certificate, the cycle begins
The certificate is valid for three years. In each of the two years in between, the auditor comes once for a surveillance audit, shorter than stage 2 but with a real look at ongoing operations. After three years, recertification is due.
This is the part many project plans leave out. Certification is not a summit you climb once, it is a rhythm you enter: internal audits, management reviews, tracking corrective actions, a visit every year. An ISMS built only for one deadline becomes a burden from the first surveillance audit onward, because the same effort is now due every year. An ISMS built into daily operations produces the evidence as a by-product.
Part of that cycle is choosing the certification body, and here is a sober hint: make sure it is accredited for ISO 27001, in Switzerland typically by the Swiss Accreditation Service SAS. A certificate from a non-accredited body is cheaper on paper and worthless in a customer audit, because the enterprise procurement teams you are getting the certificate for check the accreditation. Also ask whether the body knows your industry. A lower day rate helps little if you spend three years with an auditor who does not understand your business.
For operators of critical infrastructure who are building an ISMS because of the ISG deadline at the end of 2026, the same applies in sharpened form: a system built only to meet one deadline is paid for twice and used once.
This is exactly where we come in when companies bring us on board for building their ISMS and supporting the certification: build a system that survives operations, not one that survives an audit. If you want to know where you stand on that path, an initial conversation is free of obligation.
The better question before you sign up
Not "Will we pass the audit?". But: "Would our ISMS keep running if there were no audit?"
If the answer is yes, you can book the date calmly. The auditor will find nonconformities, you will fix them, the certificate will come, and along the way you will have received a paid outside view. If the answer is no, you do not have an audit problem, you have an operations problem, and no last-minute preparation sprint in the final three weeks will solve it.
One observation from our own mandates to close: the companies most afraid of the audit are rarely the ones with the weakest ISMS. They are the ones that do not know what to expect. How is it in your company: does the internal audit stay in the calendar even when no certificate depends on it?
