How to Get ISO 27001 Certified: Steps, Costs & Timeline

If a client, insurer, or tender document has just asked you to prove ISO 27001 compliance, you’re probably wondering where to even start. Working out how to get ISO 27001 certified isn’t complicated once you know the sequence, but most businesses waste months chasing the wrong first step or paying for consultancy they don’t need yet.

This guide answers the practical questions you actually have: what the certification process looks like from gap analysis to the final audit, how much it realistically costs for an SMB versus a larger organisation, and what timeline to budget, typically six to twelve months depending on your starting point. We’ll also flag where most projects stall, usually documentation and staff awareness, so you don’t repeat those mistakes.

We’ve guided businesses through ISO 27001 implementation and certification for years, so what follows isn’t theory. It’s the same step-by-step path we use with clients for implementing ISO 27001 end to end, covering scoping your ISMS, choosing a certification body, running the required audits, and maintaining compliance once you’re certified.

What ISO 27001 certification involves, and what it costs

Certification against ISO 27001 confirms that an independent auditor has checked your information security management system (ISMS) against the standard’s requirements and found it fit for purpose. It’s not a one-off exam. You’re not proving your security is perfect on a single day, you’re proving you’ve built a repeatable system for identifying risks, applying controls, and correcting weaknesses over time. That distinction matters because it shapes everything else in this guide: the scope you choose, the evidence you collect, and the audits you’ll repeat every year to keep the certificate valid.

Certification isn’t a document you buy, it’s proof of a management system you actually run.

The two-stage audit explained

Every certification body follows the same basic audit structure, set out by the accreditation bodies that oversee them (in the UK, that’s UKAS). Stage 1 is a documentation review, the auditor checks your policies, your Statement of Applicability, and your risk assessment exist and make sense together. Stage 2 is the substantive audit, where the auditor tests whether what you’ve documented actually happens in practice, interviewing staff, sampling records, and checking controls on the ground. Passing Stage 1 doesn’t guarantee you’ll pass Stage 2, and gaps between paper and practice are the most common reason organisations pick up non-conformities at this later stage, so it pays to understand how each audit stage is run and what to prepare.

Stage 1: document review and readiness check, typically 1-2 days on site or remote
Stage 2: operational audit with evidence sampling and staff interviews, typically 2-5 days depending on organisation size
Certification decision: issued once any non-conformities are closed out
Annual surveillance audits: required every year to keep the certificate valid

What ISO 27001 certification costs

Budgeting for the ISO 27001 certification cost means accounting for more than the audit fee. Certification body fees are usually the smallest line item once you add everything up. The bigger costs are internal staff time, any gap analysis and remediation roadmap or consultancy support you bring in, and tooling for risk management and evidence collection. Scope size, number of sites, and how much groundwork you handle in-house versus outsourcing all push these numbers up or down.

Cost element	Typical range (SMB)	Typical range (larger enterprise)
Gap analysis / consultancy	£2,000-£8,000	£10,000-£30,000+
Certification body audit fees (Stage 1+2)	£3,000-£6,000	£8,000-£20,000+
Internal staff time	Significant, often underestimated	Significant, often underestimated
Tooling (risk register, policy management)	£500-£3,000/year	£3,000-£15,000+/year
Annual surveillance audits	£1,500-£3,000/year	£4,000-£10,000+/year

Numbers vary widely once you factor in how many sites are in scope, how mature your existing documentation is, and whether you’re starting from an established security programme or from nothing at all.

Who needs to be involved

Nobody gets certified alone. You’ll need a project lead, usually someone in IT or compliance, who owns the ISMS day to day, plus genuine buy-in from senior management, since the standard specifically audits leadership commitment as part of the certification process. Smaller businesses without in-house security expertise often bring in outside support at this stage rather than learning the standard from scratch, and the steps, costs and timeline for a small business look quite different from an enterprise programme. Specialists who’ve run this process repeatedly, like TrustedIA’s ISO 27001 professional services, can shortcut the false starts that come from figuring out scope, risk methodology, and control selection while also trying to run your actual business day to day.

Step 1. Define the scope of your ISMS

Defining your ISO 27001 scope correctly at the outset saves you months later. Scope defines which parts of your business the ISMS actually covers, which locations, departments, systems, and services sit inside the boundary, and which sit outside it. Get this wrong and you’ll either audit far more than the client actually asked for, wasting budget and staff time, or leave out something a customer specifically needed covered, forcing you to redo the whole exercise once a tender rejects your certificate.

A scope that’s too big kills your budget, a scope that’s too narrow kills your certificate’s credibility.

Why scope decisions make or break your project

Most businesses starting the ISO 27001 certification process default to scoping the entire organisation, assuming that’s what "proper" certification looks like, without first checking which systems, people and controls the standard actually covers. It isn’t always the right call. If your client only needs assurance around the software product you deliver to them, scoping just that product line, its supporting infrastructure, and the staff who touch it can cut your assessment time and audit fees significantly compared to certifying every department you run. Talk to whoever is requesting the certificate before you finalise anything. Read their contract clauses or tender requirements literally, because vague scoping is the single biggest reason organisations end up recertifying within a year of their first audit.

What to include in your scope statement

Your scope statement is a formal document, referenced directly in your Statement of Applicability and checked by the auditor at Stage 1. It needs to name specific boundaries, not vague aspirations. A workable scope statement typically covers:

Physical locations included (head office, data centres, remote sites)
Organisational units or departments in scope (e.g. product engineering, not the whole company)
Information assets and systems covered (specific applications, databases, cloud services)
Interested parties whose requirements shape the scope (customers, regulators, insurers)
Exclusions, clearly justified (e.g. a legacy system being decommissioned)

Documenting exclusions properly matters as much as documenting inclusions. Auditors expect a rationale for anything left out, not just a silent omission.

Getting sign-off before you move on

Finalising scope needs sign-off from senior management before you build anything else, since every later step, your risk assessment, your control selection, your evidence collection, depends on the boundary you’ve set here. Skipping this sign-off is how projects drift: teams start implementing controls for systems nobody agreed were in scope, then discover at Stage 1 that the paperwork doesn’t match reality. Locking scope early keeps the rest of the project focused and auditable.

Step 2. Build your information security management system

Once scope is locked, you need to actually build the information security management system that Annex A controls will later sit inside. An ISMS isn’t a single document, it’s a structured set of policies, procedures, and records that together prove you manage information security deliberately rather than reactively. Businesses that treat this step as "write a security policy and move on" tend to fail Stage 1, because auditors are checking for a coherent system, not a folder of unrelated templates.

An ISMS is a system you run every day, not a binder you produce once a year for the auditor.

Core documents every ISMS needs

Clause 4 through 10 of the standard sets out mandatory documentation, and missing any of it is one of the fastest ways to pick up a non-conformity at Stage 1. At minimum, your ISMS documentation needs to include:

Information security policy, approved by senior management and communicated to staff
Risk assessment methodology, describing how you’ll identify, score, and treat risks
Statement of Applicability (SoA), listing which Annex A controls apply and why
Risk treatment plan, showing how identified risks get addressed
Roles and responsibilities, naming who owns information security tasks
Records of management review, internal audits, and corrective actions

Each of these documents needs an owner and a review date. Auditors routinely ask who approved a policy and when it was last checked, and "we wrote it eighteen months ago and haven’t touched it since" is a guaranteed finding.

Assigning ownership before you write anything

Building the ISMS works best when one person owns the overall structure, even if different department heads own individual policies. Without a named owner, documentation drifts, versions multiply, and nobody can tell the auditor which policy is current. Smaller teams often combine this with the project lead role from earlier; larger organisations sometimes split it across an information security manager and a compliance function, provided responsibilities are documented clearly rather than assumed.

Choosing a management system structure

Deciding how your ISMS integrates with existing processes matters more than most businesses expect. If you already run a quality management system under ISO 9001, structuring your ISMS along the same document control, review, and audit cycle saves duplicated effort and keeps staff from learning two parallel systems. If you’re starting from nothing, a simple structure, policies, procedures, and records, kept in a single shared location that staff can actually find, beats an elaborate framework nobody uses. Whichever route you choose, the standard doesn’t mandate a specific format. It mandates that the system works, gets reviewed, and produces evidence an auditor can trace from policy to practice.

Step 3. Assess and treat your information security risks

With your ISMS structure in place, you move into the work that actually justifies every control you’ll select later: the ISO 27001 risk assessment. This is where you identify what could go wrong with the information assets inside your scope, how likely that is, and how severe the impact would be if it happened. Skipping straight to picking Annex A controls without this step is a common shortcut, and it’s also the fastest way to end up with a Statement of Applicability that doesn’t match your actual risk profile, something an experienced auditor spots almost immediately.

Controls you can’t justify with a risk assessment are controls an auditor will ask you to remove or defend.

Choosing a risk assessment methodology

The standard doesn’t prescribe a specific methodology, but it does require one that’s documented, repeatable, and consistently applied. Most SMBs use a straightforward asset-based approach: list your information assets, identify threats and vulnerabilities against each, then score likelihood and impact on a simple numeric scale, often 1 to 5, and it helps to compare examples of risk assessment frameworks before you commit to one. Whatever scale you choose, define it clearly in your risk assessment methodology document, because Stage 1 auditors check that the scoring you’ve used in practice matches what you said you’d do on paper.

Building the risk register

Your risk register is the working document that ties everything together, and it needs to survive scrutiny at both audit stages. A workable register typically records:

Asset or process at risk (e.g. customer database, payroll system)
Threat and vulnerability identified against that asset
Likelihood and impact score, using your agreed methodology
Risk owner, the named individual accountable for treatment
Treatment decision: accept, avoid, transfer, or reduce
Linked controls, referencing the Annex A control(s) addressing the risk

Keep this register live. Auditors expect to see it updated as new risks emerge, not frozen at the point of certification.

Deciding how to treat each risk

Once risks are scored, you decide how to treat each one. Risk treatment options fall into four categories: reduce the risk with a control, accept it as within tolerance, avoid it by changing a process, or transfer it, typically through insurance or a third-party contract. Most risks in a typical SMB environment get treated through reduction, which is exactly why a sustainable cyber risk management capability feeds directly into control selection. Document the rationale behind every treatment decision, particularly acceptances, since an auditor will ask why a high-scoring risk was left untreated rather than assume it was an oversight. Getting risk treatment right here saves considerable rework at the next step, where you’ll formally select and justify every control against the risks you’ve just identified.

Step 4. Select Annex A controls and write your SoA

Annex A of ISO 27001 lists 93 controls across four themes: organisational, people, physical, and technological. Your job here isn’t to implement all 93. It’s to work through your risk register from Step 3 and select only the controls that genuinely address a risk you’ve identified, then document that selection in your Statement of Applicability, the single most scrutinised document in the entire certification process. Auditors read the SoA line by line, checking that every included control traces back to a risk and every excluded control has a written justification.

Every control in your SoA should answer one question: which risk does this actually address?

Working through the four Annex A themes

Go theme by theme rather than trying to tackle all 93 controls at once. Organisational controls cover policies, supplier relationships, and incident management, and it’s worth reading what each Annex A control category is for before you decide. People controls cover screening, training, and disciplinary processes. Physical controls cover site security and equipment. Technological controls cover access control, encryption, and monitoring. Cross-reference each theme against your risk register and mark controls as applicable, partially applicable, or not applicable, rather than guessing which theme matters most to your business.

Writing a defensible SoA

Your Statement of Applicability needs more than a tick against each control. For every entry, record:

Control reference and title, matching Annex A numbering exactly
Applicability status: included or excluded
Justification, linking directly to the risk it addresses or explaining why it’s not relevant
Implementation status, whether it’s already in place, partially in place, or planned
Owner, the person accountable for that control

Weak SoAs read like a copy-paste of the standard with "yes" against everything. Strong ones read like a business genuinely thought through its exposure, which is exactly what an auditor is trained to spot.

Justifying exclusions properly

Excluding a control is entirely acceptable, and most organisations legitimately exclude some. What auditors won’t accept is an exclusion with no reasoning behind it. If you don’t develop software in-house, secure development controls may not apply, but say so explicitly rather than leaving the field blank. If a control genuinely doesn’t apply because of your scope decision from Step 1, reference that scope statement directly. Vague exclusions, or exclusions that look like they’re avoiding cost rather than reflecting genuine risk, are one of the most common Stage 1 findings we see. Get this document right and Step 5, actually implementing what you’ve selected, becomes a straightforward matter of working through a list rather than second-guessing what the auditor expects to see.

Step 5. Implement controls and collect evidence

With your Statement of Applicability finalised, implementing controls is where most projects either gain momentum or stall completely. This step turns a document into daily practice, and it’s usually the longest phase of the whole certification process, often three to six months depending on how many controls were only partially in place beforehand. Treat each control from your SoA as a mini-project with an owner, a deadline, and a defined output, rather than a loose intention to "sort out access management at some point."

A control that exists only in your SoA and not in daily practice will fail you at Stage 2, no matter how well it’s written down.

Turning the SoA into an implementation plan

Work through your SoA control by control and assign each one a status: not started, in progress, or complete, alongside a named owner and a realistic deadline. Group controls by the team that owns them, so your IT lead handles technical controls like access management and encryption, while HR handles people controls like screening and onboarding training. This grouping stops the project becoming one person’s burden and spreads accountability across the business, which auditors notice favourably during Stage 2 interviews.

Collecting evidence as you go

Evidence collection is where most organisations fall behind, because it’s tempting to implement a control and move straight to the next one without recording proof it happened. Build evidence collection into the implementation itself rather than trying to reconstruct it before the audit. For each control, keep:

Screenshots or exports showing the control configured (e.g. MFA enforcement settings, firewall rules)
Signed records of training completion, policy acknowledgement, or access approvals
Meeting minutes where security decisions were made or reviewed
Ticket or log references showing the control operating over time, not just at a single point

Auditors sample rather than check every record, but gaps in your evidence trail for controls you’ve claimed as "implemented" are one of the most common Stage 2 findings.

Avoiding the common implementation traps

Organisations without dedicated security tooling often underestimate how much manual effort evidence collection takes, particularly for controls like vulnerability management or phishing simulation that need repeated, dated proof rather than a one-off screenshot. Practical tooling for vulnerability assessments and phishing simulation, such as the managed vulnerability and phishing simulation services TrustedIA runs for clients, closes this gap by generating evidence automatically as part of delivering the control, rather than leaving staff to document everything manually after the fact. Reviewing implementation progress monthly against your SoA keeps the project visible to senior management and stops controls quietly slipping behind schedule as you approach your internal audit.

Step 6. Run internal audits and management reviews

Before any external auditor sets foot in your business, the standard requires you to audit yourself first. Internal audits and management reviews aren’t a formality tucked in before certification, they’re the mechanism that proves your ISMS actually functions as a system rather than a pile of documents nobody revisits. Skip this step, or rush it, and Stage 2 becomes the first time anyone independently tests whether your controls hold up, which is exactly the wrong moment to find out they don’t.

If your internal audit doesn’t find anything wrong, you’re not looking hard enough.

Planning and running the internal audit

Organising an internal audit programme means covering every clause of the standard and every control in your SoA at least once within your certification cycle, not just the areas you feel confident about. The auditor doing this work needs to be independent of the process they’re checking, so a department head can’t audit their own team’s controls credibly. Smaller businesses often bring in an external party for this precise reason, since finding someone genuinely independent inside a ten-person company is rarely realistic. Whoever runs it should:

Sample records against each control claimed as implemented in your SoA
Interview staff to check practice matches documented procedure
Record every finding, not just the ones that look serious
Classify findings as major non-conformity, minor non-conformity, or observation
Track each finding through to a documented corrective action

Treat findings as useful information, not failure. An internal audit that surfaces genuine gaps before the certification body does is doing its job properly.

Feeding results into management review

Once internal audit findings are in hand, senior management needs to formally review them, alongside risk register changes, incident data, and progress against your SoA. This isn’t a rubber-stamp meeting. Clause 9.3 of the standard specifies exactly what a management review must cover, including the status of previous actions, changes in external and internal issues, and opportunities for improvement, and auditors will ask to see minutes proving this discussion actually happened.

Closing out findings before certification

Getting every major non-conformity closed before you book your certification audit saves you from a failed Stage 2 or a re-visit fee. Non-conformities that remain open at this stage almost always resurface with the external auditor, since the same underlying weakness that your internal audit caught rarely fixes itself without a documented corrective action. Businesses working with TrustedIA’s professional services at this stage often use the internal audit specifically to rehearse Stage 2, closing gaps while the stakes are still low.

Step 7. Choose a certification body and pass your audit

With internal audit findings closed out, you’re ready to book your certification body and go through the formal external audit. Not every certification body carries the same weight, and picking one badly can undermine the credibility of the certificate you’re paying to earn. Choosing a body accredited by a recognised national accreditation body, UKAS in the UK, matters because some clients and tenders specifically require accredited certification and will reject a certificate issued by a body operating outside that framework.

An unaccredited certificate can cost you the same money and still fail to satisfy the client who asked for it.

What to check before you sign a contract

Getting a shortlist together means comparing more than price. Before signing with a certification body, check:

Accreditation status, confirmed directly against the accreditation body’s public register
Sector experience, whether they’ve certified organisations of similar size and industry
Auditor availability, since demand for experienced ISO 27001 auditors often means booking slots months ahead
Quoted scope of audit days, matching what you expect given your organisation’s size and complexity
Contract terms around re-audits, surveillance scheduling, and cancellation fees

Requesting quotes from three certification bodies before committing gives you a realistic sense of market rate and stops you overpaying for a name recognition premium that doesn’t actually add credibility.

Preparing for the Stage 1 and Stage 2 visits

Holding a readiness review internally, ideally using the same findings-tracking approach as your internal audit, catches last-minute gaps before the external auditor does. Make sure every document referenced in your SoA is version-controlled and accessible, that staff due to be interviewed know roughly what to expect, and that evidence for the last three to six months of operation is organised rather than scattered across email threads and shared drives. Scheduling Stage 1 and Stage 2 with a gap of four to eight weeks between them gives you room to fix anything Stage 1 flags without losing momentum.

Responding to non-conformities

Surviving Stage 2 with a handful of minor non-conformities is normal and doesn’t block certification, provided you submit a corrective action plan within the certification body’s stated deadline, usually 30 to 90 days. Major non-conformities are more serious and typically require a follow-up visit before the certificate is issued, so treat any major finding from Stage 1 as something to resolve before Stage 2 starts, not after. Once outstanding findings are closed and the certification body’s technical review signs off, your certificate is issued, valid for three years, subject to the annual surveillance audits covered next.

Step 8. Maintain certification with surveillance audits

Earning the certificate isn’t the finish line, it’s the point where the real work of keeping your ISO 27001 certificate valid begins. Your certification body will schedule annual surveillance audits for the two years following your initial certification, followed by a full recertification audit at the three-year mark. Treat these as smaller versions of Stage 2 rather than a box-ticking formality, because certification bodies do withdraw certificates from organisations that let their ISMS lapse into paperwork nobody follows.

A certificate earned once and never revisited is a liability waiting to be exposed at your next surveillance visit.

What surveillance audits actually check

Surveillance visits sample a subset of your controls each year rather than reviewing everything at once, but auditors specifically look for evidence that your ISMS review cycle has continued uninterrupted since the last visit. Expect them to check:

Internal audit records from the past twelve months, confirming the programme didn’t stop after certification
Management review minutes, showing leadership still discusses risk, incidents, and corrective actions
Updated risk register, reflecting new assets, threats, or changes to your business
Corrective actions from the previous audit, confirmed as closed with evidence
Any significant changes to scope, staffing, or systems since the last visit

Missing any of these consistently across two surveillance cycles is the fastest route to a suspended certificate.

Keeping the system alive between visits

Running your ISMS properly between audits means the same cadence you built for certification continues by default, not by scrambling every twelve months. Quarterly risk register reviews, the awareness training ISO 27001 expects, and a working internal audit schedule keep evidence current so surveillance visits become routine rather than stressful. Organisations that treat surveillance prep as an annual fire drill usually discover their documentation has drifted from actual practice, exactly the gap Stage 2 was designed to catch in the first place.

Preparing for recertification

Three years in, the recertification audit repeats the full Stage 1 and Stage 2 process rather than sampling like surveillance visits do, so your scope, risk assessment, and SoA all get reassessed from scratch. Businesses that kept their ISMS genuinely live throughout the cycle, rather than reviving it only for audits, sail through recertification with minimal disruption. Ongoing monitoring through a 24/7 managed SOC service gives you continuous evidence generation between audits, which is exactly the kind of proof surveillance auditors want to see rather than a rushed reconstruction the week before their visit.

Staying certified for the long term

Getting certified follows a clear sequence: scope, build, assess, select controls, implement, audit yourselves, then let an external body check your work. None of it is mysterious once you’ve walked through it, but every stage depends on the one before it, which is why skipping ahead costs businesses months of rework further down the line.

The organisations that stay certified without drama treat their ISMS as something they run, not something they revive for an auditor once a year. Risk registers get updated, internal audits happen on schedule, and management actually reviews what’s changed. That discipline is what separates a certificate that holds up at recertification from one that quietly lapses.

If you’re weighing up whether to run this process alone or bring in support that’s done it repeatedly, talk to TrustedIA about embedding ISO 27001 into your business and what’s realistically needed to get you certified without the false starts.