Somewhere in a board deck or a customer email, someone has written "we need ISO 27001" as if it were a form to fill in. It is not. ISO/IEC 27001 certifies an Information Security Management System — a management system, the same category of thing as a quality management system under ISO 9001 — not a one-time technical audit of your firewall and your laptops. That distinction sounds pedantic until you are three months into a project and realise the auditor is not going to ask "is your data encrypted?" so much as "show me the record of the decision to encrypt it, who approved that decision, and how you know it is still true six months later."
Founders who have been told to "get ISO 27001" by a customer's procurement team usually picture a fixed-price, fixed-duration purchase, like buying a penetration test. It is closer to standing up a small, permanent process inside the company — one that has to run for a while, generating its own evidence, before anyone external will certify it exists. That difference drives almost everything else in this article.
What the standard is actually certifying
ISO/IEC 27001 sets requirements for an ISMS: the policies, risk assessments, controls, and management oversight an organisation uses to protect information deliberately rather than by accident. The standard's main clauses (4 through 10) cover things like context, leadership commitment, planning, support, operation, performance evaluation, and improvement. Annex A is a reference list of controls — access control, cryptography, supplier relationships, incident management, and so on — that you select from based on your own risk assessment, not implement wholesale.
ISMS, in one sentence: a management system is the recurring cycle of assess risk, decide what to do about it, do it, check that it worked, and improve — done on a schedule, with records, rather than once and forgotten.
This is why "we encrypted our database" is not, by itself, evidence of anything to an auditor. Evidence is the risk assessment that identified the need, the decision to treat that risk with encryption, the control operating in production, and a record showing someone checked it was still operating three months later. Any one of those on its own is incomplete.
Why the request usually shows up in the first place
Almost nobody starts an ISO 27001 project out of general enthusiasm for information security governance. It arrives as a gating requirement: an enterprise customer's vendor risk team, an investor's due diligence checklist, or — more often lately — a security questionnaire that keeps returning the same unresolved row no matter how well you answer everything around it. That context matters for scoping, because it tells you what "done" needs to look like to the people asking, and roughly how much time you actually have before it becomes a blocker.
The phases, in the order they really happen
A certification project has a fairly consistent shape, even though the calendar time in each phase varies enormously by organisation.
- Gap assessment. Before committing budget, map current practice against ISO/IEC 27001's clauses and Annex A controls to see what already exists, what is close, and what does not exist at all. This is also where you find out whether "we have a policy for that" means a document someone wrote once or a policy anyone actually follows — those are very different starting points and the gap assessment should distinguish them honestly.
- Scoping the ISMS. Decide which part of the business the certificate will cover — one product line, one data centre, the whole company — and document the boundary. A narrow, honest scope that matches what you can actually operate well beats an ambitious scope nobody staffs properly.
- Risk assessment and treatment. Identify information assets, the threats and vulnerabilities relevant to them, and decide for each significant risk whether to treat it, accept it, transfer it, or avoid it. This produces the risk register and feeds directly into the next step.
- Annex A control selection and implementation. Using the risk assessment as justification, select which Annex A controls apply, document the reasoning in a Statement of Applicability, and then actually build and operate them — not just write a policy referencing them. A control that is not operating is not a control; it is a paragraph.
- Internal audit. Someone independent of the day-to-day operation of the ISMS — internal staff from a different team, or an external party — checks whether the system as documented is actually what is happening, and records the findings. This has to happen at least once before certification, and the standard expects it to recur afterwards.
- Management review. Leadership formally reviews the ISMS's performance — audit results, incidents, risk status, whether objectives were met — and records decisions arising from that review. This is not a slide deck for its own sake; it is the evidence that the system has real ownership above the person who happens to be doing the day-to-day work.
- Stage 1 audit, run by an accredited certification body, checks documentation and readiness — does the ISMS as designed actually meet the standard's requirements, and is there enough operating history to proceed.
- Stage 2 audit, by the same certification body, examines whether the ISMS is operating as documented, sampling evidence across controls, interviewing staff, and testing whether what is on paper matches what people actually do. This is the audit that results in certification, or in findings that must be closed first.
The distinction that gets glossed over and shouldn't
This is the point in the project where the roles need to be completely clear, because getting it wrong is not a minor mix-up — it undermines the independence the whole certification scheme depends on. Safe Tech AI's ISO 27001 consulting covers the gap assessment, building the ISMS, selecting and implementing Annex A controls, and preparing you for audit. We do not issue the certificate. Certification can only be granted by an accredited certification body — a separate, independent organisation whose accreditation is itself checked by a national accreditation authority. That separation is deliberate: the party that helped you build the management system cannot also be the party that certifies it meets the standard, because that would remove the independence the certificate is meant to represent. Any consultant who implies otherwise is describing the scheme incorrectly, and it is worth asking directly how a prospective advisor draws this line before engaging them.
In practice this means two purchases, in sequence: consulting work to build and operate the ISMS, then a separate contract with an accredited certification body to run the Stage 1 and Stage 2 audits. Good ISO 27001 consulting should make the second purchase straightforward — evidence organised, staff rehearsed, gaps closed — rather than treat it as someone else's problem.
What actually drives the timeline
There is no honest fixed number here, whatever a sales page tells you. The real drivers are:
- Scope. Certifying one well-defined product line with fifteen staff moves faster than certifying an entire multi-office organisation with legacy systems nobody fully understands.
- Starting maturity. An organisation with SSO, logging, a documented incident process, and named control owners already in place has most of Annex A partly built. One running on tribal knowledge and ad hoc practice is starting closer to zero.
- Operating history required. Certification bodies expect to see the ISMS running long enough to generate real records — a completed risk assessment cycle, at least one internal audit, one management review. You cannot compress this to a week no matter how much you spend, because the evidence has to exist before someone can examine it.
- How fast the organisation can staff control ownership. This is usually the actual bottleneck, and it is discussed below.
Where certification projects actually stall
Having run gap assessments on ISMS builds that were already underway, three patterns account for most of the delay, and none of them is "the standard is too hard."
No real control owner. A control assigned to "IT" or "the team" in a spreadsheet is not assigned. When the internal auditor asks who reviews access quarterly, there needs to be a name, not a department. Projects stall when ownership was written down but never actually handed to a person with the authority and the calendar time to do it.
Policies copied from a template and never operated. A policy pack bought off the shelf reads well and satisfies nobody once evidence is requested, because the auditor's actual question is always "show me this happening," not "show me this being described." A five-page access control policy that matches what the team genuinely does will survive an audit; a forty-page template describing a process that does not exist will not, and unwinding that gap late in a project costs far more than writing an honest, shorter policy would have cost at the start.
Treating it as a paperwork exercise rather than an operating change. Annex A includes controls like periodic technical testing of the environment — which is one of the places VAPT fits directly into an ISMS rather than sitting beside it as an unrelated purchase — and an auditor expects to see that testing actually happened, with findings tracked to closure, not merely a line item promising it will happen someday. Projects that treat every control as a document to produce rather than a practice to run tend to pass Stage 1, because Stage 1 checks documentation, and then struggle at Stage 2, because Stage 2 checks whether the documentation is true.
Where this lands
If you take one thing from this: budget for an ISMS that has to run for a real stretch of time before it can be certified, not a document package you can buy and hand over. The fastest route through is usually the most boring one — a scope you can actually staff, control owners with names attached, and policies that describe what you already do rather than what looks impressive on paper. If you are trying to work out how wide to scope an ISMS, how much of Annex A genuinely applies to your risk profile, or how far off a realistic certification timeline actually is for where you stand today, that gap assessment conversation is the right place to start.