Getting ISO 27001 certified is one of the strongest signals you can send to clients, partners, and regulators that your organisation takes information security seriously. But figuring out how to achieve ISO 27001 certification, from scoping your Information Security Management System (ISMS) to passing the Stage 2 audit, can feel overwhelming, especially if you’re doing it for the first time. There’s a lot of conflicting advice out there, and most of it skips over the practical detail that actually matters when you’re building a compliant ISMS from scratch.
The process isn’t a mystery, though. It follows a clear, logical sequence: understand the standard’s requirements, assess your current security posture, implement the necessary controls, and then prove it all works under audit. Where most organisations stumble is in the gap between reading the standard and actually operationalising it, writing policies that reflect real practice, conducting a meaningful risk assessment, and preparing evidence that satisfies an external auditor. This guide covers each of those steps in detail, including what the certification audit involves and the costs you should budget for.
At TrustedIA, we’ve spent over 30 years working in IT services and managed security, with a specific focus on ISO 27001 implementation and certification support. We’ve guided organisations through every stage of this process, from initial gap analysis using our internally developed CRAFT assessment tooling, right through to successful certification. This article draws directly on that experience to give you a practical, step-by-step roadmap you can follow, whether you’re working with a consultancy or going it alone.
What ISO 27001 certification is and what it proves
ISO 27001 is an internationally recognised standard for information security management, published jointly by the International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC). Its full designation is ISO/IEC 27001, and the current version is the 2022 edition, which replaced the 2013 version with revised control categories, a more streamlined structure, and a stronger emphasis on risk-based thinking. The standard specifies the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS), which is the documented framework through which your organisation identifies, assesses, and manages information security risks.
What the standard actually requires
The standard is structured around two main components. The first is Clauses 4 to 10, which define the core management requirements your ISMS must satisfy, covering areas such as organisational context, leadership commitment, planning, resource allocation, operational controls, performance evaluation, and continual improvement. The second component is Annex A, which contains 93 controls grouped across four themes: Organisational, People, Physical, and Technological. You are not required to implement every Annex A control, but you must document your reasoning for any you exclude. That documentation lives in a specific ISMS document called the Statement of Applicability, which auditors will examine in detail.
You are not being assessed on whether you have eliminated all security risk. You are being assessed on whether your organisation has a systematic, documented, and maintained approach to managing it.
The standard is deliberately non-prescriptive about how you implement controls. This means a law firm and a manufacturing company can both achieve certification while running very different security programmes, provided each can demonstrate they have assessed their specific risks and applied proportionate, evidence-backed controls in response. That flexibility is a strength, but it also places real responsibility on you to make well-justified decisions rather than copying a generic template.
What certification proves to clients and regulators
When your organisation achieves ISO 27001 certification, an accredited third-party certification body has independently verified that your ISMS meets every applicable requirement in the standard. This is a meaningful distinction from self-assessment or self-declaration. The certificate tells clients, partners, and regulators that a qualified external auditor examined your policies, procedures, and controls, tested evidence against them, and determined the system is operating effectively.
In practical terms, certification communicates three things clearly:
- Your security practices are documented and structured, not reactive or inconsistent.
- You assess and treat risks systematically, with records and evidence to demonstrate it.
- You are committed to continual improvement, with internal audits and management reviews embedded into your process.
For organisations working in financial services, healthcare, legal, or any sector handling sensitive personal data, ISO 27001 certification is increasingly a baseline expectation rather than a differentiator. Enterprise procurement teams and regulated industries routinely require it as a minimum supplier qualification. Understanding how to achieve ISO 27001 certification is, for many businesses, both a security priority and a direct commercial requirement.
What you need before you start
Before you invest time and budget into the certification process, you need three things firmly in place: executive support, a named project owner, and an honest baseline of your current security posture. Skipping any of these will cost you more time later than it saves now. Understanding how to achieve ISO 27001 certification is one thing; having the right internal conditions to complete it successfully is another.
Management commitment and a named project owner
ISO 27001 explicitly requires top management involvement throughout the ISMS, not just a sign-off on a policy document at the start. Management must demonstrate active leadership by allocating resources, approving the information security policy, and participating directly in management reviews. Without genuine commitment at the top, your ISMS will stall the moment it requires budget, headcount, or cooperation across departments.
You also need to appoint a named project owner, typically an IT Manager, CISO, or Operations Director, who has the authority to make decisions and own the project timeline from start to certification. This person does not need to write every policy themselves, but they must have the organisational mandate to assign tasks, set deadlines, and hold people accountable across the business.
A baseline gap assessment
Before writing a single policy, you need to assess where you currently stand against the ISO 27001 requirements. A gap analysis compares your existing controls and documentation against what the standard demands, and it gives you a clear picture of how much work lies ahead and where to focus first.
Running a gap analysis before you start scoping saves you from designing an ISMS around assumptions that later turn out to be wrong.
A structured gap assessment should cover these core areas:
| Area | What to assess |
|---|---|
| Documentation | Existing policies, procedures, and records |
| Risk management | Whether a formal risk assessment process exists |
| Access controls | How user access is granted, reviewed, and revoked |
| Incident response | Whether a documented response process is in place |
| Supplier management | How third-party security obligations are currently handled |
Once you have completed this baseline review, you can prioritise your remediation effort and build a realistic project plan, rather than discovering critical gaps mid-audit when fixing them is both disruptive and expensive.
Step 1. Define your ISMS scope and security objectives
The scope defines exactly which parts of your organisation the ISMS covers, and it is the foundation every subsequent step builds on. Get this wrong, and you risk designing controls for processes that do not need them, or leaving critical assets outside the boundary of your certified system. Before you write a single policy, you need to make a deliberate, documented decision about which locations, departments, functions, and information assets fall within scope.
Writing a clear scope statement
Your scope statement needs to be specific enough that an external auditor can immediately understand what is and is not included. A vague statement such as "our IT systems" will not satisfy an auditor. A well-written scope names the specific services, systems, or business units covered, the physical or cloud environments involved, and any intentional exclusions with a brief justification for each.
Here is a practical scope statement template you can adapt. The key is to be precise about boundaries rather than broad:
"The ISMS covers [service or department] delivered from [location or cloud environment], including [key assets and processes], excluding [any excluded functions] on the basis that [justification for exclusion]."
As a concrete example, a UK-based managed service provider might write: "The ISMS covers the delivery of managed IT security services from our Leeds office and AWS-hosted infrastructure, including client data processing and incident response operations, excluding our marketing function on the basis that it handles no sensitive client information." This approach gives auditors immediate clarity about what is and is not in scope.
Setting your information security objectives
Once your scope is defined, you need to set measurable security objectives that align with your organisation’s risk appetite and business goals. The 2022 standard requires objectives to be documented, communicated, and tracked over time, not simply stated once and forgotten.
Practical objectives typically cover areas such as reducing the mean time to detect security incidents, achieving a defined completion rate for staff security awareness training, or maintaining vulnerability remediation within a set SLA. Understanding how to achieve ISO 27001 certification means accepting that objectives are not a checkbox exercise; they feed directly into your management review process and demonstrate that your ISMS is actively improving rather than standing still.
Step 2. Set governance, roles, and core policies
With your scope defined, you now need to establish who owns information security decisions and document the policies that govern your ISMS. Auditors look closely at governance at both Stage 1 and Stage 2, because weak role definitions and vague policies are among the most common reasons organisations fail their first certification attempt. Getting this right early prevents confusion later when evidence collection begins.
Assign clear roles and responsibilities
ISO 27001 requires you to formally assign information security responsibilities across your organisation. At a minimum, you must define the role of the Information Security Manager (or equivalent), who owns the ISMS on a day-to-day basis, and confirm that top management has a documented, active role in oversight and review. These assignments must appear in writing, whether in a roles and responsibilities matrix, a job description addendum, or a dedicated ISMS governance document.
Undocumented responsibilities create audit gaps that are difficult to close quickly, so assign and record them before any other policy work begins.
For organisations working through how to achieve ISO 27001 certification for the first time, a simple responsibility assignment matrix (RACI) covering key ISMS activities is a practical starting point. Map each activity, such as conducting risk assessments, maintaining the asset register, and running internal audits, against the roles of Responsible, Accountable, Consulted, and Informed.
Write your core ISMS policies
Your information security policy is the foundational document that sets direction for your entire ISMS. It must be approved by top management, communicated to all relevant parties, and reviewed at planned intervals. Beyond this top-level policy, you need a set of supporting policies that address specific control areas required by the standard.
The following core policies cover the areas most commonly examined at Stage 1 audit:
- Information security policy (top-level, management-approved)
- Access control policy (covering user provisioning, least privilege, and review cycles)
- Acceptable use policy (defining permitted use of systems and data)
- Incident response policy (outlining classification, escalation, and reporting)
- Supplier security policy (setting baseline security expectations for third parties)
Each policy must be version-controlled, dated, and stored in a location your team can access. Write policies that reflect how your organisation actually operates, not an idealised version of it, because auditors will test whether staff can describe and follow them in practice.
Step 3. Inventory assets and set information classification
You cannot protect what you have not identified. An asset register is a core ISMS document that lists everything your organisation uses, stores, or processes information with, and it forms the direct basis for your risk assessment in the next step. Without a complete inventory, your risk assessment will have blind spots, and auditors at both Stage 1 and Stage 2 will ask to see it.
Build your asset register
Your asset register needs to capture every asset that falls within your defined ISMS scope, including hardware, software, data stores, cloud services, and people. For each asset, you must record an assigned owner, which is the individual responsible for ensuring that asset receives appropriate protection. Ownership is a requirement of the standard, not an optional field.
Assigning an asset owner without giving them clear security responsibilities is one of the most common gaps auditors find in first-time certification attempts.
Use this template as a starting point for your register:
| Asset name | Asset type | Owner | Location | Classification | Criticality |
|---|---|---|---|---|---|
| Customer CRM database | Data | IT Manager | AWS EU-West-1 | Confidential | High |
| Staff laptops | Hardware | IT Manager | Office / Remote | Internal | Medium |
| Email platform | Software / SaaS | IT Manager | Microsoft 365 | Internal | High |
| Source code repository | Data | Development Lead | On-prem / GitHub | Restricted | High |
Define your classification scheme
Once your assets are listed, you need to apply an information classification label to each one so that your team knows how to handle, store, and share different types of information. Understanding how to achieve ISO 27001 certification includes recognising that classification is not purely a documentation exercise; it drives access control decisions, encryption requirements, and disposal procedures.
A practical four-tier classification scheme works well for most organisations:
- Public: Information approved for general release with no restrictions
- Internal: Information for use within the organisation only
- Confidential: Sensitive business or client data requiring restricted access
- Restricted: Highest sensitivity, with strict handling and access controls
Keep your scheme simple enough that all staff can apply it consistently without referring to the policy every time. Unnecessary complexity creates inconsistency, which auditors will identify quickly when they test staff understanding during the Stage 2 audit.
Step 4. Assess risk and create a risk treatment plan
Your risk assessment is the engine of your ISMS. Every control you implement, every policy you write, and every resource you allocate should trace back to a documented risk that your organisation has identified and evaluated. This step is where understanding how to achieve ISO 27001 certification moves from preparation into substantive analytical work, and auditors at both Stage 1 and Stage 2 will scrutinise the quality of your risk methodology closely.
Run a structured risk assessment
Before you score a single risk, you must document and consistently apply a repeatable methodology so that your results are defensible. ISO 27001 does not prescribe a specific method, but it does require one that produces comparable and reproducible results. The most practical approach for most organisations is to assess each risk against two dimensions: the likelihood of it occurring and the impact if it does, each scored on a defined scale.
Inconsistent scoring across assets is one of the most common reasons auditors raise nonconformities at Stage 1, so define your scale and apply it uniformly before you start.
Use this template as the basis for your risk register:
| Risk ID | Asset | Threat | Vulnerability | Likelihood (1-5) | Impact (1-5) | Risk score | Risk owner |
|---|---|---|---|---|---|---|---|
| R-001 | Customer CRM | Unauthorised access | Weak access controls | 4 | 5 | 20 | IT Manager |
| R-002 | Staff laptops | Malware infection | No endpoint detection | 3 | 4 | 12 | IT Manager |
| R-003 | Email platform | Phishing attack | No MFA enforced | 4 | 4 | 16 | IT Manager |
Calculate your risk score by multiplying likelihood by impact, then define a threshold above which risks require treatment. Any risk that exceeds your agreed risk acceptance level must appear in your risk treatment plan.
Build your risk treatment plan
Your risk treatment plan documents the specific action you will take for each unacceptable risk, the control you will apply, the person responsible, and the target completion date. For each risk, you have four treatment options: mitigate it by applying a control, transfer it through insurance or a third party, avoid it by stopping the activity that generates it, or accept it if it falls below your threshold with documented rationale.
Each treatment decision links directly to an Annex A control, which is what connects your risk assessment to your Statement of Applicability in the next step. Record these links explicitly so auditors can follow the thread from identified risk to applied control without having to ask you to explain it verbally.
Step 5. Build your Statement of Applicability for Annex A
The Statement of Applicability (SoA) is a mandatory ISMS document that lists all 93 Annex A controls, states whether each one applies to your organisation, and provides a documented justification for every inclusion and exclusion. Auditors treat this document as a direct window into your risk-based decision-making, so a vague or incomplete SoA is one of the fastest routes to a major nonconformity at Stage 1.
What the SoA must contain
Your SoA must connect directly to your risk treatment plan from Step 4, because every control you include should trace back to a specific risk, legal obligation, or contractual requirement. For each of the 93 controls across the four Annex A themes (Organisational, People, Physical, and Technological), your SoA needs to record four things: whether the control is applicable, the reason for its inclusion or exclusion, the current implementation status, and a reference to the policy or procedure that governs it.
Use this template structure for each row in your SoA:
| Control ref | Control name | Applicable (Y/N) | Justification | Implementation status | Policy reference |
|---|---|---|---|---|---|
| 5.1 | Policies for information security | Y | Risk treatment requirement | Implemented | Information Security Policy v1.2 |
| 5.15 | Access control | Y | Risk treatment + legal obligation | Implemented | Access Control Policy v1.0 |
| 7.4 | Physical security monitoring | N | Out of scope (no physical data centre operated) | N/A | N/A |
A control excluded without a clear, documented justification is not a legitimate exclusion; it is an undocumented gap that auditors will flag as a nonconformity.
How to justify inclusions and exclusions
Inclusions should reference either a specific risk in your risk register or a legal, contractual, or regulatory obligation, such as UK GDPR requirements for personal data protection controls. Exclusions must state the precise reason a control does not apply, for example, that your scope excludes physical premises or that a particular technology is not used within the organisation. Vague justifications such as "not relevant" or "low risk" are insufficient and will draw direct scrutiny from your auditor during Stage 1.
Understanding how to achieve ISO 27001 certification depends significantly on how well your SoA bridges your risk assessment and your implemented controls. Treat it as a living document that you update whenever your risk profile, technology environment, or ISMS scope changes, not a static file you complete once and archive.
Step 6. Implement controls and collect audit-ready evidence
Implementing controls is where your ISMS moves from documentation into operational reality. The goal here is not to implement every possible security measure, but to deploy the specific controls you identified in your risk treatment plan and SoA, then collect evidence that proves each control is working consistently over time. Auditors do not take your word for it; they follow a paper trail, so building that trail deliberately is central to understanding how to achieve ISO 27001 certification.
Prioritise controls by risk score
Start with the risks that scored highest in your risk register. High-scoring risks must have a treatment in place before your Stage 1 audit, because an auditor who finds an unmitigated high risk with no treatment timeline will raise a major nonconformity immediately. Work through your risk treatment plan in order of priority, assigning each control a named owner and a target completion date so you can track progress accurately.
Common controls organisations implement at this stage include multi-factor authentication (MFA) for all privileged accounts, endpoint detection and response on all in-scope devices, access reviews on a defined cycle, and staff phishing simulation training. Each of these requires a corresponding evidence record to demonstrate it is active and maintained, not merely configured once.
Build an evidence log your auditor can follow
Your evidence log is a structured record that maps each implemented control to the documentation proving it works. For each control, you need at least one piece of tangible evidence, such as a screenshot, configuration export, training completion report, or access review record, dated within a reasonable period before your audit.
Auditors assess what you can demonstrate, not what you intend to do, so your evidence must be current, dated, and clearly linked to a specific control.
Use this template to maintain your evidence log:
| Control ref | Control name | Evidence type | Evidence description | Date collected | Owner |
|---|---|---|---|---|---|
| 5.15 | Access control | Screenshot | MFA enabled on all admin accounts | 2026-03-01 | IT Manager |
| 6.3 | Information security awareness | Report | Phishing simulation results Q1 2026 | 2026-03-15 | HR Lead |
| 8.8 | Management of technical vulnerabilities | Report | Vulnerability scan output, March 2026 | 2026-03-20 | IT Manager |
Collect evidence continuously throughout the implementation period, not in a rush before your audit date. Auditors can identify retrospectively assembled documentation, and it undermines confidence in the overall effectiveness of your ISMS.
Step 7. Run an internal audit and complete a management review
Before you invite an external certification body into your organisation, you need to verify your own ISMS through a formal internal audit. This step is a mandatory requirement of the standard, and it serves a practical purpose beyond compliance: it lets you find nonconformities and evidence gaps on your own terms, where you can fix them without the pressure of a live certification audit. An internal audit also demonstrates to your certification body that your ISMS operates as a system, not a collection of disconnected documents.
Conduct your internal audit
Your internal auditor must be independent from the area being audited, which means the person responsible for writing your access control policy should not audit access control. This does not require an external resource; a colleague from another department with basic audit training is sufficient, provided they have no direct conflict of interest. Document their independence in your audit records because auditors will ask.
Your internal audit must produce a written report with findings, not just a verbal debrief, so plan for documentation from the start.
Structure your internal audit around a formal audit programme that covers every clause of the standard and every Annex A control included in your SoA. For each area, record what evidence you examined, whether it was found to be conformant, and any nonconformities or observations raised. Use this template as the basis for your audit log:
| Audit area | Clause / Control | Evidence reviewed | Finding | Corrective action required |
|---|---|---|---|---|
| Access control | 5.15 | MFA screenshots, access review records | Conformant | None |
| Incident response | 5.24 | Incident log, response procedure | Minor NC | Update procedure to reflect current escalation path |
| Internal audit | 9.2 | Previous audit report | Conformant | None |
Complete the management review
Once your internal audit findings are documented, top management must convene a formal management review before your Stage 1 audit. This meeting is a core clause 9.3 requirement, and it must be minuted. The agenda must cover ISMS performance data, internal audit results, risk treatment progress, and any changes to the business context that could affect information security. Understanding how to achieve ISO 27001 certification means treating this review as substantive evidence of leadership engagement, not a formality. Your auditor will read the minutes and assess whether management is actively steering the ISMS or simply approving it on paper.
Step 8. Pass the stage 1 and stage 2 certification audits
The certification audit runs in two distinct stages, and understanding what each one examines helps you prepare the right evidence at the right time. Both stages are conducted by an auditor from your chosen accredited certification body, and both will produce a formal written report. If you have completed the preceding steps thoroughly, you should arrive at Stage 1 with no significant surprises waiting for you.
What happens at Stage 1
Stage 1 is a documentation review, sometimes called a readiness review. Your auditor examines your ISMS documentation to determine whether you are ready for the full audit: they will review your scope statement, information security policy, risk assessment, risk treatment plan, Statement of Applicability, internal audit report, and management review minutes. This stage typically takes one to two days and can be conducted remotely.
If your auditor raises a major nonconformity at Stage 1, they will not proceed to Stage 2 until you have resolved it, so treat your internal audit findings seriously before this point.
Your auditor will confirm a Stage 2 date once they are satisfied that your documentation is sufficiently complete and coherent. Use the period between Stage 1 and Stage 2, typically four to eight weeks, to close any observations or minor issues raised and refresh any evidence that is approaching the end of its useful date range.
What happens at Stage 2
Stage 2 is the full conformity assessment, and it is conducted on-site or via a combination of on-site and remote sessions. Your auditor will interview staff, observe processes, and test whether your implemented controls match the documentation they reviewed in Stage 1. They are assessing whether your ISMS is genuinely operational, not just documented.
Prepare your team by briefing key staff on their roles within the ISMS and making sure they can describe the processes relevant to their work without reading from a policy. Auditors frequently speak to people outside the IT function, including HR, finance, and operations leads, to verify that security responsibilities are understood across the organisation. Successfully navigating both stages is the final step in how to achieve ISO 27001 certification, and the certificate issued on completion is typically valid for three years, subject to annual surveillance audits.
Costs, timeline, and common pitfalls to avoid
Understanding how to achieve ISO 27001 certification involves more than following the right steps; it also means budgeting accurately and knowing where organisations most frequently go wrong. Costs and timelines vary significantly depending on your organisation’s size, existing security maturity, and whether you use external consultants. Planning for both from the outset prevents the project from stalling when resources run short mid-implementation.
What certification typically costs
Certification body fees are the most predictable cost, typically ranging from ยฃ3,000 to ยฃ12,000 for the initial Stage 1 and Stage 2 audits combined, depending on your organisation’s size and scope complexity. Beyond the audit itself, you should budget for internal resource time, which is often the largest hidden cost, alongside consultancy support, staff training, and any technology controls you need to implement, such as endpoint detection or vulnerability scanning tools.
| Cost area | Typical range (UK) |
|---|---|
| Certification body audit fees | ยฃ3,000 to ยฃ12,000 |
| External consultancy support | ยฃ5,000 to ยฃ25,000 |
| Internal staff time | Varies by team size |
| Technology controls | ยฃ2,000 to ยฃ15,000+ |
| Annual surveillance audits | ยฃ1,500 to ยฃ5,000 |
Realistic timeline to certification
Most organisations take six to twelve months from starting their ISMS project to receiving their certificate, assuming reasonable security maturity and dedicated internal resource. Organisations starting from scratch with significant control gaps should plan for the longer end of that range, or beyond it if leadership availability becomes a constraint.
Rushing to meet an arbitrary deadline is the single most common reason organisations fail their Stage 2 audit on the first attempt.
Common pitfalls that delay or derail certification
Avoiding these mistakes will save you significant time and rework:
- Treating documentation as the end goal rather than evidence of a working system
- Scoping too broadly by including business units that add complexity without adding real value
- Writing policies that do not reflect actual practice, which staff cannot describe accurately under audit questioning
- Leaving evidence collection to the final weeks before the audit rather than building it continuously throughout the project
- Failing to assign real ownership to assets and risks, resulting in controls that no one actively maintains
Each of these is fixable before your audit if you identify it during the internal audit process covered in Step 7.
Where to go from here
You now have a complete picture of how to achieve ISO 27001 certification, from scoping your ISMS and running your risk assessment, through to preparing evidence and passing both audit stages. The process rewards consistent, well-documented effort over time far more than last-minute preparation, and every step in this guide builds directly on the one before it.
Starting alone is possible, but most organisations reach certification faster and with fewer audit findings when they work with experienced practitioners who know exactly what auditors examine. At TrustedIA, we have supported businesses through every stage of this process, using our CRAFT assessment tooling to identify gaps early and our ISO 27001 subject matter expertise to close them efficiently. If you want structured support from initial gap analysis through to your Stage 2 audit, speak to the TrustedIA team to find out how we can help your organisation achieve certification with confidence.
