ISO 27001 Process Explained: Scope, Risk Assessment and the 93 Annex A Controls Without the Jargon

A client sends you their vendor security questionnaire. You open it, and the questions read like a foreign language. ISMS scope. Risk assessment methodology. Statement of Applicability. Stage 1, Stage 2. You run a perfectly good IT company, and suddenly you feel like you need a translator just to get certified for the thing you already do.

Here is the plain version. ISO 27001 certification is a six-step journey, and every piece of jargon maps to one ordinary question. What are we protecting? What could go wrong? What are we doing about it? Can we prove it? Has someone independent checked? That is the whole process. The rest of this guide is just the detail.

What is the ISO 27001 process, in one paragraph?

ISO 27001 certification means an accredited certification body audits your information security management system — your ISMS — and confirms it meets ISO/IEC 27001:2022. You draw the boundary of what the system covers, assess your information security risks, choose controls to treat those risks, record every choice in a Statement of Applicability, run the system long enough to gather evidence, audit yourself, and then pass a two-stage external audit. The certificate lasts three years, with a surveillance audit each year and a full recertification at the end of the cycle.

First, what you are actually building

ISO 27001 does not certify a product, a server, or a firewall. It certifies a management system: the set of policies, roles, processes and habits by which your company handles information security day after day. The standard's management clauses — clauses 4 to 10 — are mandatory for everyone. They cover understanding your context, leadership commitment, risk assessment, objectives, resources, operations, performance checks and improvement. Annex A, the famous list of 93 controls, is not the system. It is the menu you choose from once you know your risks. That distinction matters, because it decides the order of everything that follows.

Step 1: Draw the scope — the fence around the work

Scope is the first decision and the most consequential. It answers a simple question: which people, systems, sites and services does this certificate cover? It can cover your whole company, or one product line, one office, one delivery team. The scope statement, required by clause 4.3, is written down and printed on the certificate itself.

Clients read that line. If your certificate covers your head office but the product they buy is built by a team in another city that sits outside the scope, the certificate does not cover what they are buying. They will notice. A tight, honest scope is better than a grand one: it keeps the project manageable, the audit shorter, and the certificate believable. You can always widen the scope in a later audit cycle. What you cannot do is quietly pretend a wide scope covers work it never touched.

Step 2: Assess the risks — diagnosis before prescription

Think of this step the way a doctor thinks about a diagnosis. Nobody sensible walks into a clinic and asks for every medicine in the pharmacy. The doctor examines you first, names what is actually wrong, and prescribes for that. A risk assessment works the same way. You list your information assets — client data, source code, credentials, laptops, the office network — then work out what could go wrong with each one, how likely it is, and how bad it would be.

The output is a risk register: each risk written down, scored, and given an owner. Then comes the risk treatment plan, required by clause 6.1.3. For every risk you choose one of four responses: modify it (put a control in place), avoid it (stop doing the risky thing), share it (insurance, or a supplier contract that carries the risk), or retain it (accept it consciously, with a reason). Generic risk descriptions with no business context are the classic failure here. "Malware" is not a risk. "A developer laptop with production database credentials, lost on a train, exposing one named client's customer data" is a risk — and it points straight at the controls that fix it.

Step 3: Meet the 93 controls — and stop panicking about the number

Annex A of ISO/IEC 27001:2022 lists 93 controls in four themes. The 2022 revision replaced the 2013 edition's 114 controls across 14 domains, and added 11 new controls for modern threats, including threat intelligence, cloud services and data masking. The four themes are:

You do not implement all 93. You review all 93 and implement the ones your risks call for. A company with no office of its own will have little use for physical entry controls. A company that writes no software can reasonably leave the secure-development controls aside — provided that is genuinely and durably true, not a hope. The number 93 is a checklist to work through, not a shopping list to buy in full.

Step 4: Write the Statement of Applicability — the document auditors open first

The Statement of Applicability, or SoA, is the document that ties the whole project together. Required by clause 6.1.3(d), it lists every one of the 93 Annex A controls and records, for each: does it apply to you, why, and whether it is implemented. It is the bridge between your risk register and your actual defences.

Here is the trap most first-timers walk into. The SoA is an output, not an input. The correct order is: assess risks, decide treatments, determine the controls those treatments require, then check that set against Annex A as a completeness check. Do it backwards — pick controls off the Annex A list first, then invent risks to justify them — and an experienced auditor will usually spot it within an hour. The SoA also exposes weak justifications fast. A control marked implemented with no evidence behind it, or excluded with a one-line shrug, is one of the most common audit findings. Write each justification as if the client who asked for the certificate will read it. They might.

Step 5: Run it, then audit yourself before anyone else does

Controls on paper are worth nothing until they have operated. This is the step impatient projects try to skip, and it is where timelines usually slip. Certification bodies want to see the ISMS actually running — policies followed, logs collected, incidents recorded — for a few months before the Stage 2 audit, because an audit tests evidence, not intentions.

Two internal exercises are mandatory before the external audit. The internal audit, clause 9.2, means auditing your own ISMS for conformity and effectiveness and logging what you find. The management review, clause 9.3, means leadership formally reviewing audit results, risks, objectives and improvements at a planned interval, with minutes to show it happened. Both must be complete before Stage 2. Book them early enough to fix what they find. A finding discovered in your own internal audit is a cheap fix. The same finding discovered by the certification body costs you a delayed certificate.

Step 6: The two-stage certification audit

The external audit comes in two stages, and confusing them is the other classic beginner mistake.

Stage 1 is the paperwork test: does the system exist on paper, and is it ready to be examined? Stage 2 is the reality test: do people actually work the way the documents say? Pass both, close any findings, and the certification body issues a certificate valid for three years, with surveillance audits in years two and three and a full recertification audit before the cycle ends. Miss a surveillance audit and the certificate can be suspended — usually at exactly the moment a client asks to see it.

How long does all of this take?

Guides disagree, and the disagreement is honest: it depends on scope, size, starting maturity and how much time your own team can give it. For a small technology company, one phased breakdown puts scope and risk work at 2–4 weeks plus 3–6 weeks, implementation and evidence-gathering at 2–4 months, and the audits at 4–10 weeks — roughly 5–8 months end to end. A timeline guide for startups puts companies under 50 people at 3–6 months and SMEs at 6–9 months. Broader implementation guides quote 6–12 months for most SMEs and 12–18 months for larger or more complex organisations.

Reconciled plainly: a small IT company that already runs decent security habits can realistically reach certificate in 3–6 months; most SMEs land somewhere in 6–12 months; a wide scope, multiple sites or a team with no spare capacity pushes it longer. Anyone promising a certificate in two weeks is not selling the process described above. They are selling a document, and enterprise clients who verify will treat it as one.

Five mistakes that stall the process

• Writing the SoA first. Controls chosen before risks are just guesses with formatting. Risks first, treatments second, SoA last.
• Scoping for vanity, not for clients. A scope that excludes the product your biggest client buys makes the certificate useless to them.
• Treating it as an IT project. HR owns screening and offboarding, leadership owns the management review, operations owns suppliers. One department cannot carry it.
• Leaving the internal audit to the last week. Its findings need fixing time before Stage 2. Run it early.
• Buying on price alone. A certificate from a body your clients cannot verify through an accreditation register is a cost, not an asset. Check the body's accreditation before you pay — in India, that usually means NABCB or another IAF member.

What does ISO 27001 certification cost, and who does the work?

Cost is covered in detail in our companion guide to ISO 27001 certification cost for IT companies and startups, but the short version belongs here too: there are two bills, consultancy to build the ISMS and the certification body's audit fee, charged separately. Our consultancy costs ₹14,999 for companies up to 25 employees and ₹29,999 for 26 to 100, with certification-body audit fees extra at actuals — the same honest split described in that guide. If you want the full picture for your scope, our ISO 27001 certification page sets out what the consultancy covers. Companies certifying more than one standard at once often run the audits together, and our ISO 9001 certification page explains the combined route. And if you want a first estimate before you commit, the compliance fee calculator gives you a number to compare against a written quote.

Frequently asked questions

Do I have to implement all 93 Annex A controls?

No. You must review all 93 and record each decision in the Statement of Applicability, with a justification for every exclusion. Controls apply where your risk assessment says they should; a control with no risk behind it can be excluded, honestly and in writing.

What is the difference between Stage 1 and Stage 2?

Stage 1 reviews your documentation and readiness — scope, policies, risk assessment, SoA, internal audit and management review records. Stage 2 tests whether the ISMS operates effectively in practice, through evidence, interviews and observation. Gaps found in Stage 1 must be fixed before Stage 2 is booked.

How long does ISO 27001 certification take for a small company?

A small IT company with reasonable security habits already in place can typically reach certificate in 3–6 months; most SMEs land in 6–12 months. Wide scopes, multiple sites and limited internal capacity push it longer. The evidence-gathering period — running the ISMS long enough to prove it works — is usually what sets the floor.

Is an ISO 27001:2013 certificate still valid?

No. ISO/IEC 27001:2022 is the current edition, and the transition period for certificates issued against the 2013 edition ended on 31 October 2025. New certifications are issued against the 2022 edition, with its 93-control Annex A.

Can I certify only part of my company?

Yes. The scope can cover a defined product, team, site or business unit rather than the whole company. But the certificate covers only what the scope statement names, so a scope that leaves out the work your clients buy will not satisfy them.

The process looks long on paper because it is thorough, not because it is complicated. Draw the fence, diagnose before you prescribe, write down every decision, run the system until it has evidence, then let someone independent check it. Do those five things in that order and the jargon stops being a barrier. It becomes what it was always meant to be: a record of security work your clients can verify.