ISO 27001 implementation plan: steps from scope to certification audit

A customer or contract now requires ISO 27001, so the first question is what the work involves before a certification body is engaged. This page sets out the phases, who owns each one, and what must be ready before the audit.

On this page

ISO 27001 implementation plan: what happens before the certification audit

When a customer, contract or regulator asks for ISO 27001, the implementation work runs in a fixed order: context and scope, then risk assessment and risk treatment, then the Statement of Applicability, then the controls themselves, then internal audit and management review. A certification body only enters once that work is finished and the management system has run long enough to show results. This ISO 27001 implementation plan describes that sequence so you can judge how much work remains before you ask for a quote or an audit date. The starting point is not a template. ISO/IEC 27001:2022 treats adopting an information security management system (ISMS) as a strategic decision shaped by your needs and objectives, your security requirements, your processes, and your size and structure. A 40-person SaaS company and a regional hospital group will reach the same clauses by very different routes. The standard also states that its requirements are not listed in order of importance, so your gap analysis can be prioritized by risk rather than worked through clause by clause. Ownership matters from the first week. Your organization owns its controls, its risk decisions and its management review. DeployOpen, where engaged, prepares systems, configurations and evidence under a written scope. Only an independent certification body issues a certificate. Before signing anything, confirm with your team which person will sign the Statement of Applicability and who will chair management review, because those decisions cannot be delegated to an implementer.

How to sequence an ISO 27001 implementation from scope to audit

The sequence turns the standard's requirements into a working management system with evidence an assessor can test. Each phase produces a named output that the next phase depends on, so the work before a certification body is involved can be checked step by step.

  1. Define context, interested parties and scope

    Leadership works through clause 4.1 to identify internal and external issues, then clause 4.2 to list interested parties and their information security requirements, such as customer contracts, regulators and staff obligations. From those inputs, clause 4.3 requires the organization to set the boundary of the ISMS, covering which business units, locations, systems and suppliers are inside. The output is a written scope statement and a list of interested party requirements. The step is done when someone outside the project can read the scope and tell what is in and out.

  2. Assess information security risks

    Clause 6.1.2 requires a defined risk assessment method that identifies risks to confidentiality, integrity and availability within the scope, assigns owners and rates likelihood and impact. ISO/IEC 27005:2022 is a useful guide for building this method, though it is not a requirement. The output is a risk register with a documented method and criteria for accepting risk. The step is done when every risk has an owner and the criteria used to rate it are written down and approved.

  3. Treat risks and produce the Statement of Applicability

    Clause 6.1.3 requires the organization to choose treatment options, select controls from Annex A (or others it designs), and compare them with Annex A to confirm none were omitted without reason. Clause 6.1.3 d) requires a Statement of Applicability that lists the necessary controls, justifies inclusions and exclusions, and states whether each control is implemented. The output is the Statement of Applicability with a risk treatment plan approved by risk owners. The step is done when every Annex A control has a recorded decision and a justification.

  4. Implement controls and collect operating evidence

    Control owners put the selected controls into operation, which the standard places under clauses 8.2 and 8.3 for risk assessment and risk treatment. Because the requirement order does not imply the order of implementation, teams should start with the highest-risk gaps rather than working through clauses in number order. Evidence such as access reviews, change records, backup restore tests and training logs must exist for a period before an assessor can sample it. The output is a control implementation record with evidence references for each control. The step is done when each applicable control has a named owner and retrievable evidence.

  5. Monitor, measure and evaluate performance

    Clause 9.1 requires the organization to decide what to monitor and measure, the methods to use, when to measure and who analyzes the results. The measures should cover control effectiveness and ISMS objectives. The output is a set of defined metrics, their collection records and periodic analysis reports. The step is done when the measures have run long enough to show trends and someone has reviewed them and recorded the outcome.

  6. Run an internal audit of the ISMS

    Clause 9.2 requires internal audits at planned intervals to check whether the ISMS conforms to the organization's own requirements and to the standard, and whether it is effectively implemented. Auditors should be independent of the areas they audit. The output is an audit programme, audit plans, and reports listing findings. The step is done when each in-scope area has been audited and the findings are logged for corrective action.

  7. Hold management review and log corrective actions

    Clause 9.3 requires top management to review the ISMS at planned intervals, covering inputs such as audit results, risk status, incidents, and feedback from interested parties. Clause 10.2 requires the organization to react to nonconformities, correct them, address their causes and verify that the corrective action worked. The output is management review minutes with decisions, and a corrective action log showing root causes and closure evidence. The step is done when the review minutes record decisions and every nonconformity has a closed or justified action.

  8. Confirm readiness before engaging a certification body

    Before a certification body is involved, confirm that the scope, risk assessment, Statement of Applicability, controls, monitoring, internal audit and management review have each produced their records. Ask the implementation partner or internal lead to walk through a sample of controls and check that evidence is current and consistent with the Statement of Applicability. Independent auditors, not DeployOpen or any consultant, decide whether the ISMS meets the standard. The output is a readiness file that the certification body can review. The step is done when the organization can show every record without rework.

Setting the ISMS scope that customers and assessors will accept

The ISMS scope is the boundary of everything the certificate covers, so it is the first decision to get right. Clause 4.3 of ISO/IEC 27001:2022 requires the organization to determine the scope of its information security management system, and it builds on two inputs: the internal and external issues found under clause 4.1, and the interested parties and their requirements under clause 4.2. Write the inputs down before drafting the boundary. For clause 4.1, list the business context, locations, technology and legal duties that affect information security. For clause 4.2, list the parties who depend on the ISMS, such as customers, regulators, parent companies and insurers, and record what each one requires. The 2024 climate amendment (ISO/IEC 27001:2022/Amd 1:2024) adds a determination under 4.1 of whether climate change is a relevant issue, and a note under 4.2 that interested parties can hold climate-related requirements. Record the outcome of that determination even if it is negative, so an assessor can see it was considered.

A narrow scope and a broad scope lead to different work. A narrow scope, such as one product platform or one site, reduces the number of systems, people and suppliers that the risk assessment and the Statement of Applicability must cover, and it usually shortens the audit. A broad scope covers more of the organization and more of the controls, but it also widens the risk register, the evidence set and the internal audit programme. Two rules matter. First, the scope must not exclude activities that affect the security of the in-scope services, because an assessor will test the interfaces. Second, any exclusion must be justified in writing and reflected in the Statement of Applicability. Ask your certification body early how it counts audit time for the scope you propose, because the time calculation depends on the number of persons and sites in scope and on the nature of the activities, not on the size of the certificate you want.

Draft the scope statement against two sources: the customer contract that triggers the certification, and an inventory of the systems that hold or process that customer's data, including hosting accounts, identity providers, backup stores, support tooling and the staff with privileged access. The statement should name the services, the locations and the exclusions in plain language, because it is printed on the certificate. Confirm the wording with the customer's security team and check that the systems in the inventory fall inside the boundary. Expect the scope to change as the business changes, and plan a review at each management review under clause 9.3. Ask your implementation partner to document the scope and its justification as part of the deliverables, and ask your certification body to confirm in writing that it accepts the proposed boundary before stage 1.

Risk assessment, treatment and the Statement of Applicability

Risk assessment decides which Annex A controls the organization needs and why. Each card below covers one step in that chain, from choosing a method to getting owners to accept the results. The Statement of Applicability records the outcome, but it is an internal record that a certification body reviews, not a certificate.

Choose a risk method and criteria

Set a risk method before anyone scores a risk. The method defines the likelihood scale, the impact scale, the rating matrix and the level at which a risk must be treated. Clause 6.1.2 requires the assessment to produce consistent and comparable results, so the same inputs should give the same rating when two assessors run it. Write the method down, approve it, and check that the scales match how the business actually measures harm. Ask any consultant to show the written criteria before work starts.

Identify assets and owners

Build the register of information assets before rating risks, because each risk attaches to an asset. Include information, software, hardware, cloud services, suppliers' systems and the people who run them. Each asset needs a named owner who is accountable for its protection and who can confirm its data, location and dependencies. Missing owners usually surface later as risks nobody will accept, so resolve them at this stage. Confirm the register against the ISMS scope set under clause 4.3.

Assess likelihood and impact

For each asset, identify the threats and vulnerabilities that could breach confidentiality, integrity or availability, then score likelihood and impact using the agreed scales. Record the existing controls that already reduce each risk, because the residual rating depends on them. Keep the reasoning short and traceable: a reviewer should be able to see why a score was given. Where evidence is thin, record the gap as an assumption to test rather than assigning a confident score.

Select treatment options

Under clause 6.1.3, each risk above the acceptance level needs a treatment decision. The usual options are to modify the risk by applying controls, retain it with documented acceptance, avoid the activity, or share it, for example through insurance or a contract with a supplier. Treatment choices that rely on controls must name the controls, owners and the evidence that will show they work. A treatment without an owner or a checkable outcome is a plan on paper only.

Write the Statement of Applicability

The Statement of Applicability, required by clause 6.1.3 d), lists every Annex A control and states whether it is included or excluded. Each included control needs a short justification tied to the risk treatment, and each exclusion needs a reason, such as a control that does not apply to the scope. Exclusions are a common source of nonconformity, so justify each one in terms of the risk it does not address. The SoA is a living internal record that a certification body samples. It is not a certificate, and only an accredited certification body can issue certification.

Get owner sign-off

Ask each risk owner and control owner to review the risk register, treatment decisions and SoA lines that concern them, then record their approval. Sign-off turns the assessment into a management commitment, which clause 5.1 expects leadership to support. Keep dated approvals and version history, because auditors check whether the SoA in use matches the reviewed risk treatment. Repeat the review when scope, systems or suppliers change, and when the risk method itself is revised.

Who owns each step: your team, an implementation partner and the certification body

Your organization owns the information security management system. Leadership decides the scope, accepts the risks, approves the Statement of Applicability and runs management review. No outside firm can make those decisions on your behalf, and an assessor will expect to see evidence that the people named in the policies actually made them.

  • Scope and context: Your leadership sets the ISMS scope under clause 4.3 and records the internal and external issues and interested party requirements that shape it.
  • Risk decisions: Your risk owners accept, reduce, transfer or avoid each risk identified in the risk assessment and treatment process.
  • Statement of Applicability: Your leadership approves which Annex A controls apply, why, and their status, and keeps that approval current.
  • Management review and internal audit: Your managers review performance and your internal auditors test the ISMS against the standard, with results recorded and acted on.
  • Day-to-day operation: Your staff run the controls, owners maintain their evidence, and nonconformities are corrected under clause 10.2.

Before engaging any outside help, confirm in writing which of these named roles will be filled by your staff, because an assessor will ask who approved each decision.

What must be in place before a certification audit is requested

Before a certification body will schedule a stage 1 audit, the ISMS must already have run its performance evaluation activities. The four cards below cover the records an assessor will ask for first, and each includes a simple walkthrough you can run against your own files.

Monitoring and measurement records

Clause 9.1 requires the organization to monitor, measure, analyze and evaluate its ISMS performance. Assessors look for a defined list of what is measured, who measures it, how often, and what the results showed. To check this, pick three metrics from your own list, open the logs for the last several months, and confirm each metric has dated results and a documented review decision. Metrics that exist only in the plan, with no data behind them, are a common gap.

Completed internal audit

Clause 9.2 requires internal audits at planned intervals to check whether the ISMS conforms to the organization's own requirements and to the standard, and whether it is effectively implemented and maintained. The audit must be carried out by people with a defined, impartial process. To check it, confirm there is an audit programme, a dated audit plan, a checklist or sample record, and a written report with findings. An audit that found nothing and was never written up will not satisfy an assessor.

Management review minutes

Clause 9.3 requires top management to review the ISMS at planned intervals. The review must consider a defined set of inputs, such as audit results, monitoring data, stakeholder feedback and the status of risk treatment, and it must produce decisions about improvements and resource needs. To check it, open the minutes and confirm attendance by top management, that each input appears in the record, and that actions have named owners and due dates. Minutes that only say the review took place are weak evidence.

Corrective action log

Clause 10.2 requires the organization to react to nonconformities, decide on corrections, evaluate whether action is needed to remove the cause, and keep records of the actions and their results. Assessors use this log to judge whether the ISMS learns from problems. To check it, select one nonconformity from an internal audit or incident, then trace it forward to the root cause analysis, the corrective action, the owner, and evidence that the action was verified as effective. An empty log is itself a question for the assessor.

Why the 2022 edition sets the plan, and the deadlines that have passed

Any new ISO 27001 implementation should target ISO/IEC 27001:2022, not the 2013 edition. The transition period under IAF MD 26:2023 ended with certifications to ISO/IEC 27001:2013 expiring or being withdrawn by 31 October 2025. An organization starting now therefore builds its Statement of Applicability, risk treatment plan and control set against the 2022 text, with its 93 Annex A controls grouped in four themes: organizational, people, physical and technological. Teams that inherited a 2013-based document set should map their existing controls to the 2022 structure early, because the 2022 edition replaces the 114 controls of the earlier version with a smaller set, and some earlier controls now merge or change wording. The Statement of Applicability should list every 2022 control with its inclusion or exclusion and justification, so the plan shows which controls were reviewed rather than carried over by habit.

The certification body ISO/IEC 27001 certificates depend on also has a deadline. IAF MD 29:2024 required accredited certification bodies to apply ISO/IEC 27006-1:2024 to all clients by 31 March 2026, so an audit booked now will be run against that requirement. Practically, this means the certification body's audit plan, time calculations and multi-site approach may differ from what a team saw in an earlier cycle. Ask the certification body you shortlist how it applies ISO/IEC 27006-1:2024 to your scope, how it calculates audit time, and which transition arrangements, if any, still affect your file.

Before committing to a timeline, confirm current requirements directly with the certification body and, where relevant, its accreditation body, since transition rules and accreditation roles have been updated in recent years. The ISO certification page explains how certificates are issued and checked, and the transition document in IAF MD 26:2023 sets out the dates that apply. An implementation partner can prepare the system and evidence against the 2022 text, but only the independent certification body issues the certificate.

Questions teams ask before starting an ISO 27001 implementation

How long does an ISO 27001 implementation take?

The duration depends on the scope, the number of sites and systems, the maturity of existing security practices, and how much time leadership and staff can give the work, so no general figure applies. Ask any implementation partner for a timeline in the written scope, with milestones for context and scope, risk assessment, Statement of Applicability, control rollout, internal audit and management review. Confirm separately when the certification body will schedule its stage 1 and stage 2 audits, because that calendar is set by the certification body, not by the implementer.

What does an ISO 27001 implementation cost?

Costs fall into separate buckets: internal staff time, tooling, the implementation partner or consultant, and the certification body's audit and certificate fees. Staff time and partner fees are largely one-time, while tooling subscriptions, hosting, surveillance audits and recertification recur across the three-year certification cycle. The main drivers are the number of in-scope systems and locations, how many controls need new technology, and how much evidence already exists. Ask each vendor for an itemized quote that separates these components so you can compare them with the certification body's fee schedule.

Can a small team run an ISO 27001 implementation itself?

Yes, a small team can run the implementation in-house if it has clear ownership, time for the work and a realistic scope. ISO's practical guide for small and medium organizations, PUB100484, written for ISO/IEC 27001:2022, summarizes each clause from the context of the organization in clause 4 through to improvement in clause 10, with examples and FAQs for organizations with limited staff and budgets. Guidance such as ISO/IEC 27002:2022 and ISO/IEC 27005:2022 can be purchased and used alongside it. Teams that choose this route should still plan for internal audit and management review, which the standard requires before a certification audit.

What does ISO 27001 require from leadership?

Clause 5 of ISO/IEC 27001:2022 expects top management to show leadership and commitment to the ISMS, set an information security policy, and assign responsibilities and authorities. In practice, leaders approve the scope and risk appetite, provide budget and staff time, make decisions on risk treatment, and take part in management review, which is a required performance evaluation activity under clause 9.3. Without visible sponsorship, the ISMS tends to stall at the policy stage, so name an accountable executive and a working owner before the work begins.

Can the consultant who implements ISO 27001 also perform the certification audit?

No. The organization that designs and builds the ISMS cannot also be the certification body that audits it, because that would compromise impartiality. European Accreditation guidance on consultancy and on ISO/IEC 27006-1 conflict of interest addresses this boundary, and certification bodies must manage impartiality risks in the same way. Implementation partners prepare systems, controls and evidence, while only an independent certification body issues the certificate. Choose the implementer and the certification body separately, and confirm that the certification body has no consultancy relationship with your organization.

How do I check an ISO 27001 certificate after the audit?

Search the IAF CertSearch database, which ISO points to for checking accredited certificates, and confirm that the certificate name, scope, sites and expiry date match the certificate you were given. Since 1 January 2026, Global ACI has taken over the roles of the IAF and ILAC, but the IAF CertSearch database remains the reference ISO cites. Also confirm that the certification body is accredited for ISO/IEC 27001 and that its certificate covers the scope you need for customers. A certificate that is not listed, or that shows a scope narrower than your contract requires, should be queried with the certification body before you rely on it.

How DeployOpen scopes, implements and prepares evidence before the audit

DeployOpen works as an implementation partner on the ISO 27001 work that comes before a certification body is involved. We prepare systems, documentation and evidence inside your own infrastructure, while your organization keeps ownership of its scope, risk decisions and controls. Only an independent certification body can issue a certificate.

How we scope

  • We help define the ISMS scope in writing, covering the interested parties, internal and external issues and boundaries you agree to.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any implementation work starts.
  • We document which systems, sites, suppliers and business units are inside the boundary and which are excluded, with reasons.

How we build

  • We run the risk assessment and risk treatment workshops with your owners, then draft the Statement of Applicability for your review.
  • We deploy and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to run the chosen controls.
  • We configure logging, access reviews and monitoring so that control operation produces dated, retrievable records for the audit.

How we hand over

  • You receive the ISMS documentation set, including policies, procedures, the risk register, the Statement of Applicability and an evidence index mapped to Annex A controls.
  • We prepare an internal audit and management review package so your team can run clause 9 activities and record corrective actions under clause 10.
  • Handover includes runbooks and a written list of what your staff must maintain, so the ISMS keeps running after our work ends.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
  • We can help your team answer questions from the certification body about evidence, but the organization remains the party responsible for its controls.
  • Before you select a certification body, confirm its accreditation through the IAF CertSearch database and check its independence from any consultant you hire.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.