June 5, 2026

ISO 27001 Roadmap Part 7: Risk Treatment, Statement of Applicability and Continuous Improvement

ISO 27001 Roadmap Part 7: Risk Treatment, Statement of Applicability and Continuous Improvement
By Maria Luz Pereyra - Cybersecurity Consultant - Cycubix
Part 7 of our series: Audit-Ready, Team-Friendly: A Beginner’s Guide to ISO 27001

This part covers the final stages of the Cycubix Six-Step approach introduced in Part 4: Risk Treatment (Step 4), creating and maintaining the Statement of Applicability (Step 5), and establishing Monitoring and Continuous Improvement activities (Step 6). Together, these activities transform risk assessment findings into practical security improvements and help ensure your ISMS remains effective, measurable, and audit-ready over time.

In Part 6, we explored how organisations establish context through Gap Analysis, define risk criteria, and systematically identify, analyse, and evaluate information security risks. We concluded with a clear understanding of which risks fall within acceptable thresholds and which require action.

Now, in this Part 7, we address the critical question: What do we do about these risks?

Under ISO/IEC 27005, risk treatment is the process of selecting and implementing measures to modify risk.

This includes choosing appropriate risk treatment options, implementing those options through security controls, and documenting the rationale behind these decisions—all of which culminate in the Statement of Applicability. The biggest challenge at this stage is turning decisions into actionable control implementation and closing the loop between risk and execution.

Let's explore how these elements work together to create a robust, audit-ready ISMS.

Step 4: Risk Treatment Process

Understanding Risk Treatment Options

ISO 27005 defines four fundamental risk treatment options that organisations can apply to address identified risks:

Risk Modification (Mitigation)

Implementing controls to reduce the likelihood or impact of a risk. This is the most common approach and involves deploying technical, organisational, or physical safeguards to bring risks within acceptable thresholds.

Example: Implementing MFA

Risk Retention (Acceptance)

Accepting the risk without additional treatment, typically because it already falls within acceptable thresholds or the cost of treatment outweighs the benefit. This requires formal approval and documented justification.

Example: Accepting a low residual risk of data loss for a supplier change.

Risk Avoidance

Eliminating the risk entirely by discontinuing the activity that creates it. This option is appropriate when the risk cannot be adequately mitigated and acceptance is not viable.

Example: Discontinuing the use of an unsupported software application that cannot be secured and migrating to a supported alternative.

Risk Sharing

Sharing the risk with external parties, such as through insurance, outsourcing, or contractual agreements.

Note that this transfers financial or operational consequences but does not eliminate the organisation's accountability for information security.

Example: Purchasing cyber insurance to transfer financial exposure from potential data breaches.

The selection of risk treatment options should be guided by:

  • Risk evaluation results from Step 2 (Previous article: Link)
  • Organisational risk appetite and acceptance criteria
  • Cost-benefit analysis of proposed controls
  • Regulatory and contractual obligations that may mandate specific controls
  • Technical feasibility and available resources
  • Stakeholder expectations and business priorities

Organisations should document the rationale for each treatment decision, particularly when accepting or sharing risks, to demonstrate informed decision-making during audits.

A critical aspect of risk treatment is selecting the appropriate controls from ISO 27001 Annex A that address identified risks. This is where the connection between your Gap Analysis and your risks comes to life.

This mapping ensures:

  • Comprehensive coverage – all significant risks are addressed
  • Efficiency – controls serve multiple purposes where possible
  • Traceability – the rationale for each control is documented
  • Audit readiness – assessors can verify that controls address actual risks

This mapping directly informs your Statement of Applicability, which we'll explore next.

Example of Risk Treatment Rationale:

Risk Identified: Customer database breach due to compromised credentials.

  • Initial Risk Score: 9 (High)
  • Status: Unacceptable
  • Why it matters: Involves regulated data (GDPR) and a critical business asset

Your organisation will have to evaluate the risk according to the four ISO 27005 risk treatment options:

a) Risk Modification: Reduce likelihood by implementing security controls (Annex A ISO 27001). For example, a company can implement Multi-Factor Authentication (MFA), Privileged Access Management (PAM), acquire a SIEM solution (Security Information and Event Management).

b) Risk Acceptance: In this case, the risk is too high to be accepted and it involves regulated data, which would mean that accepting the risk would make the company non-compliant.

c) Risk Sharing: Likelihood can be reduced via control implementation, but business impact still remains. To reduce the business impact or consequence, the organisation can maintain cyber insurance coverage.

d) Risk Avoidance: This option would not be feasible since it would imply that no customer database would be kept, and the business requires the database for operations and more.

Taking into consideration the analysis mentioned above, the organisation can decide to move forward with a primary treatment through risk modification (control implementation) and a secondary treatment through risk sharing.

The Risk Treatment Plan Documentation

Once treatment options have been selected, organisations must document these decisions in a structured Risk Treatment Plan. For each risk requiring treatment, the Risk Treatment Plan should be captured within the Risk Register and include the residual risk score, meaning the risk remaining after the treatment plan has been implemented.

The organisation must document whether the residual risk falls within approved acceptance criteria and whether formal risk acceptance is required.

The Risk Treatment Plan becomes your roadmap for improving your security posture and reducing organisational risk exposure. The plan is developed based on the methodology and criteria defined in your Risk Assessment Procedures Document, ensuring consistency across all risk treatment decisions.

Implementing Risk Treatment

Once treatment decisions are made, implementation follows a structured approach that ensures controls are deployed effectively and their impact is verified:

Planning Phase
  • Prioritise treatments based on risk severity and business impact.
  • Allocate resources and assign ownership.
  • Define implementation timelines and milestones.
  • Identify dependencies and potential obstacles.
Execution Phase
  • Deploy selected controls according to the treatment plan.
  • Document implementation details and evidence.
  • Communicate changes to affected stakeholders.
  • Provide necessary training and awareness.
Validation Phase
  • Test controls to verify they function as intended.
  • Measure effectiveness against defined success criteria.
  • Document any deviations or issues encountered.
  • Update risk assessments and the Statement of Applicability to reflect implemented controls.

This systematic approach ensures that risk treatment translates into measurable security improvements rather than remaining purely theoretical.

Step 5: Statement of Applicability (SoA)

The decisions made during risk treatment must be formally documented. Under ISO 27001, the primary mechanism for documenting control selection is the Statement of Applicability (SoA), which demonstrates how identified risks have influenced control implementation decisions.

What is the Statement of Applicability?

The Statement of Applicability (SoA) is a mandatory document under ISO 27001 Clause 6.1.3(d) that serves as the authoritative record of which Annex A controls your organisation has selected and why.

The SoA is not merely a checklist—it is a strategic document that demonstrates how your organisation has thoughtfully applied the 93 Annex A controls based on your specific risk assessment outcomes, business context, and compliance requirements.

Creating Your Statement of Applicability (SoA)

The SoA is developed iteratively, informed by the Gap Assessment (Step 2) and finalised after Risk Treatment decisions (Step 4).

Cycubix recommends using your Gap Analysis as the primary database for building your SoA, based on the Annex A ISO 27001 Controls.

As outlined in Part 6 of the ISO 27001 Roadmap, your Gap Analysis should include the control reference, description, category of control, implementation status, evidence of implementation, and gap description.

After completing your Risk Assessment, update your Gap Analysis to reflect newly implemented or partially implemented controls. You can also link controls to specific Risk IDs to establish clear traceability.

Building Your SoA from the Gap Analysis

To build your SoA, create a filtered view that captures the following information:

  • Control number and name
  • Applicability (Yes/No)
  • Implementation status (from Gap Analysis)
  • Justification for inclusion or exclusion
  • Linked Risk IDs (critical for demonstrating risk-based control selection)
  • Responsible party
  • Implementation notes

What Auditors Verify

Auditors will verify that:

  • Each identified risk is mapped to appropriate controls
  • Every applicable control links back to a risk, legal requirement, or business need
  • Every control marked as "not applicable" has valid justification

Maintaining Living Documentation

The risk assessment and treatment process is not a one-time exercise—it is a continuous cycle. Connecting your registers and databases is fundamental to keeping everything up to date and ensuring your ISMS remains effective and audit-ready.

Step 6: Continuous Monitoring

The Foundation of Ongoing Risk Management

ISO 27005 emphasises that risk management is not a one-time project but a continuous process. Clause 8 of ISO 27005 requires organisations to monitor and review their risk management activities to ensure they remain effective and relevant as the business environment evolves.

Continuous monitoring serves multiple critical purposes: it verifies that implemented controls are functioning as intended, identifies new or changing risks, detects control failures or degradation, and provides evidence of ongoing compliance for auditors and stakeholders.

What to Monitor

Your monitoring programme should encompass several key areas:

  • Track the performance and effectiveness of implemented controls through defined metrics and key performance indicators (KPIs).
  • Monitor the risk landscape for emerging threats, new vulnerabilities, and changes in the threat environment that could affect your risk profile.
  • Observe changes in your business context, including new systems, processes, organisational changes, or regulatory requirements that could introduce new risks or alter existing ones.

Establishing Your Monitoring Framework

  • Define clear success criteria for each control based on the objectives established during risk treatment.
  • Establish monitoring frequencies appropriate to each risk level—critical controls may require daily or weekly monitoring, while lower-risk areas might be reviewed quarterly.
  • Assign monitoring responsibilities to specific roles within your organisation, ensuring accountability and consistency.
  • Implement automated monitoring tools where possible to provide real-time visibility into control performance and security events.

Review Cycles and Reporting

ISO 27005 recommends regular, scheduled reviews at defined intervals:

  • Operational reviews should occur monthly or quarterly to assess control performance and identify tactical issues.
  • Management reviews should take place at least annually to evaluate the overall effectiveness of the risk management programme and ensure strategic alignment.
  • Trigger-based reviews should occur whenever significant changes happen—such as major incidents, organisational restructuring, new regulations, or substantial technology changes.

Document all monitoring activities, findings, and decisions. Create regular reports for management that highlight risk trends, control effectiveness, identified issues, and recommended actions. This documentation provides the audit trail demonstrating your commitment to continuous improvement.

Responding to Monitoring Findings

When monitoring reveals issues—whether control failures, new risks, or changing risk levels, activate your risk treatment process. Reassess affected risks, update treatment plans as necessary, and implement corrective actions. Track these actions through to completion and verify their effectiveness through subsequent monitoring.

Maintaining the Gap Analysis as a Living Document

The Gap Analysis is a living document that must evolve alongside your ISMS. As you implement controls, address gaps, and respond to changing risks, your Gap Analysis must be updated to reflect the current state of your information security programme.

When to Update Your Gap Analysis

Your Gap Analysis should be updated regularly and triggered by specific events. Following each monitoring cycle, update implementation statuses and evidence to reflect actual conditions.

After completing risk treatment activities, record newly implemented controls and close addressed gaps. When your annual risk assessment identifies new risks or changes to existing ones, update control mappings and priorities accordingly. Document any changes to business context, technology infrastructure, or regulatory requirements that affect control applicability or implementation.

The Update Process

Begin by reviewing monitoring results and incident reports to identify controls that have been implemented, enhanced, or require attention:

  • Update implementation status fields to accurately reflect current conditions, for example, moving controls from "Not Implemented" to "Partially Implemented" or "Fully Implemented" as progress is made.
  • Refresh evidence documentation with current artefacts, logs, or records that demonstrate control effectiveness.
  • Revise gap descriptions to reflect remaining deficiencies and update priority levels based on current risk assessments.

When new risks are identified, link them to relevant Annex A controls in your Gap Analysis. This maintains the critical connection between your risk register and control framework. Similarly, when controls are implemented or enhanced, update the corresponding Risk IDs to show which risks are now better addressed.

Feeding Back into the SoA and Risk Treatment

Updates to your Gap Analysis directly inform other key documents:

  • Changes in implementation status should be reflected in your Statement of Applicability, ensuring it remains an accurate representation of your control environment.
  • New gaps or changing priorities should feed into your risk treatment planning, helping you allocate resources effectively.
  • Evidence updates provide auditors with current proof of control effectiveness and ongoing improvement.

Maintaining Traceability and Version Control

Implement proper version control for your Gap Analysis to maintain a historical record of your ISMS evolution. Date each update and document who made changes. This creates an audit trail showing continuous improvement over time and demonstrates to certifying bodies that your ISMS is actively managed, not static.

Closing the Loop: Continuous Improvement

The cycle from Gap Analysis to Risk Assessment, Risk Treatment, Statement of Applicability, Monitoring, and back to Gap Analysis creates a continuous improvement loop aligned with ISO 27001's Plan-Do-Check-Act methodology. Each iteration strengthens your security posture, reduces gaps, and provides increasing assurance that your information security risks are effectively managed.

By maintaining this disciplined approach to updating your Gap Analysis, you ensure that your ISMS documentation remains accurate, your risk management decisions are based on current information, and your organisation demonstrates the ongoing commitment to information security that ISO 27001 certification requires.

What Have We Covered?

In this part, we have completed the core risk management cycle by exploring how organisations transform risk assessment findings into tangible security improvements through structured risk treatment, documented control selection via the Statement of Applicability, and ongoing effectiveness monitoring that feeds back into the Gap Analysis.

Together with Part 6, we have walked through the complete Cycubix Six-Step approach, from establishing context and identifying risks, through analysis and evaluation, to treatment decisions, formal control documentation, and continuous monitoring. This creates a closed-loop system where every security decision is justified by risk, every control is purposefully selected, and ongoing monitoring ensures the ISMS remains effective over time.

At this stage, your organisation should have:

✓ A comprehensive Risk Register documenting identified risks, treatment decisions, and residual risk levels
✓ A Risk Treatment Plan specifying which controls will be implemented and why
✓ A Statement of Applicability that formally declares your selected controls with clear justification
✓ A monitoring framework that tracks control effectiveness and identifies emerging risks
✓ A continuously updated Gap Analysis that reflects your current implementation status

The Journey from Risk Management to Certification

The six-step approach detailed in Parts 4-7 forms the analytical core of your ISMS, the risk-based foundation that justifies every control and security decision. However, an ISMS cannot function on risk management alone. It requires capable people, clear communication, controlled documentation, measurable objectives, and ongoing verification.

By systematically addressing Clause 7 you will complete the journey from initial planning to certification readiness, with an ISMS that is not only audit-ready but genuinely effective in protecting your organisation's information assets.

Need Support Turning Risk Assessments into Action?

At Cycubix, we help organisations move beyond risk identification and build practical, risk-driven ISMS programmes aligned with ISO 27001 and ISO 27005. Whether you are developing your Statement of Applicability, implementing risk treatment plans, or preparing for certification, our consultants can help you build an ISMS that is both audit-ready and operationally effective.

Contact Us to discuss your ISO 27001 implementation journey.

Missed a step?

The ISO 27001 Roadmap series by Cycubix provides a step-by-step guide to building, implementing, and maintaining an Information Security Management System (ISMS), helping organisations worldwide turn ISO 27001 from theory into action.