What Clause 6.1 Means in ISO 27001

The Purpose of Clause 6.1 in the ISMS

Clause 6.1 ensures that your ISMS is built on deliberate, structured decision-making rather than assumptions or scattered security efforts.
ISO 27001 does not prescribe controls blindly; instead, every control must stem from a risk that has been identified, analysed, and treated.

At its core, Clause 6.1 mandates that organisations:

• Identify risks that could affect the ISMS
• Identify opportunities that can strengthen the ISMS
• Define criteria for evaluating those risks
• Build a repeatable assessment process
• Select appropriate treatment options
• Maintain documented evidence

This clause forms the backbone of both risk management and improvement, which are central themes across the entire ISO 27001 standard.

For a foundational view of ISO 27001’s structure, you can refer to your earlier cluster page on the History and Evolution of ISO 27001.

How Risks and Opportunities Shape ISO 27001 Compliance

ISO 27001 requires organisations to take a risk-based approach.
This means:

1. You must understand your threats before choosing controls.
2. You must define your own criteria for measuring likelihood and impact.
3. You must decide what level of risk you are willing to accept.
4. Your Statement of Applicability should reflect these decisions.

Opportunities sit alongside risks and serve a different purpose.
Opportunities are not about threats — they are about possibilities for improvement, such as:

• Implementing automation
• Standardising processes
• Clarifying governance
• Improving cross-department collaboration

Opportunities support the continuous improvement cycle mandated throughout ISO 27001, especially in Clauses 9 and 10.
Hicomply’s article on ISO 27001 certification steps gives broader context on how Clause 6.1 feeds into the audit process.

Why Clause 6.1 Is Critical for Continual Improvement

Clause 6.1 ensures organisations operate their ISMS intentionally, not reactively.
When implemented correctly, it leads to:

• Stronger governance
• Clearer accountability
• Fewer surprises during audits
• Controls that are justified, monitored, and improved
• Alignment between business objectives and security practices

Auditors pay close attention to Clause 6.1 because it acts as the source of truth for why you selected or excluded specific Annex A controls.

Clause 6.1.1 — Actions to Address Risks and Opportunities

What ISO 27001 Requires in Clause 6.1.1

Clause 6.1.1 establishes the overarching requirement:
Your organisation must determine risks and opportunities that could impact the ISMS’s ability to achieve its intended outcomes.

This includes risks such as:

• Process failures
• Governance gaps
• Resource shortages
• Human error
• Control weaknesses
• Supplier vulnerabilities

And opportunities such as:

• Enhanced automation
• Streamlined workflows
• Increased training and awareness
• Tool consolidation
• Improved reporting

Clause 6.1.1 doesn’t require measurement — that comes in 6.1.2.
Here, you simply need to identify and document them.

Identifying Risks That Could Affect the ISMS

ISMS-level risks differ from information security risks.
These are broader strategic risks that may impact the success of the ISMS itself.

Examples include:

• Lack of leadership engagement
• Insufficient budget
• Poorly defined scope
• Unclear roles and responsibilities
• Lack of competence or training
• Inadequate documentation structure

These risks often emerge during creation of the ISMS and should be captured early.

Identifying Opportunities That Improve the ISMS

Opportunities can be structural, technological, or operational.

Examples include:

• Switching to an evidence automation tool
• Introducing policy templates or standard operating procedures
• Improving communication across teams
• Establishing metrics that enhance decision-making
• Running cross-functional risk workshops
• Enhancing supplier due diligence workflows

ISO 27001 encourages organisations to view improvement as a proactive, ongoing practice.

Examples of Common Organizational Risks

• Key ISMS roles lacking clear accountability
• Staff turnover impacting process consistency
• Tools without proper configuration or governance
• Inadequate monitoring of outsourced processes
• Weak change management and shadow IT
• Incomplete asset inventory or ownership
• Misalignment between security and business strategy

These risks frequently appear during Stage 1 audits.

Examples of Opportunities (Efficiency, Automation, Alignment)

• Implementing Hicomply’s policy management to reduce time spent on documentation
• Automating evidence collection to improve audit readiness
• Introducing dashboards for ISMS performance metrics
• Aligning the ISMS with ISO 9001 or ISO 14001 for integrated management
• Reducing manual processes and adopting workflow automation

These improvements often reduce audit fatigue and improve long-term ISMS maturity.

How to Decide Which Actions Are Appropriate

When you identify risks or opportunities, you must determine:

• Whether action is required
• What the best course of action is
• Who owns the action
• How and when it will be implemented
• How success will be measured

Actions may include:
implementing a control, redesigning a process, updating documentation, reallocating resources, or introducing new technology.

The output of these decisions moves into 6.1.2 (assessment) and 6.1.3 (treatment).

Clause 6.1.2 — Information Security Risk Assessment

What ISO 27001 Expects in a Risk Assessment

ISO 27001 requires that your organisation perform a documented, repeatable risk assessment that:

• Establishes risk criteria
• Identifies information assets and their owners
• Analyses threats and vulnerabilities
• Evaluates likelihood and impact
• Determines the level of risk
• Identifies whether risks are acceptable

Your risk assessment must follow your own defined methodology — auditors will check for consistency.

Defining the Risk Assessment Criteria

ISO 27001 requires explicit criteria for:

• Likelihood
• Impact
• Risk scoring
• Acceptable vs unacceptable risk

These criteria must be defined before the assessment begins.

Your methodology becomes part of your mandatory documentation set.

For broader context, your earlier article on the benefits of ISO 27001 for businesses shows how risk management supports sales, governance, and efficiency.

Likelihood, Impact, and Risk Scoring

Likelihood measures how probable a threat scenario is.
Impact measures the consequences if the scenario occurs.

Common models include:

• 3×3 or 5×5 scoring
• Numerical scales
• Qualitative descriptors (low, medium, high)
• Weighted scoring for confidentiality, integrity, availability (CIA)

Risk scoring typically follows:
Risk = Likelihood × Impact

Risk Acceptance Criteria Requirements

Organisations must define what constitutes:

• Acceptable risk
• Tolerated risk
• Unacceptable risk

Auditors expect to see:

• Clear thresholds
• Consistent application
• Evidence of leadership involvement

Risk acceptance cannot be arbitrary.
It must be justified based on your methodology.

Steps of the ISO 27001 Risk Assessment Process

Risk Identification

List the assets, threats, vulnerabilities, and potential impacts.
Assets may include data, systems, people, facilities, or suppliers.

Risk Analysis

Determine the likelihood and impact for each risk scenario.
Analysis methods vary, but they must be applied consistently.

Risk Evaluation

Compare each risk against your acceptance criteria.
This determines whether treatment is necessary.

Clause 6.1.3 — Information Security Risk Treatment

Selecting Appropriate Risk Treatment Options

ISO 27001 defines four treatment decisions:

• Mitigate (apply controls)
• Transfer (insurance or outsourcing)
• Avoid (stop the risky activity)
• Accept (risk falls within criteria)

Mitigation is most common, but acceptance is allowed if properly justified.

Building the ISO 27001 Risk Treatment Plan (RTP)

The Risk Treatment Plan (RTP) documents:

• Selected controls
• Residual risk
• Implementation responsibilities
• Deadlines
• Required resources

The RTP is a mandatory artifact used heavily during Stage 1 and Stage 2 audits.

How Clause 6.1.3 Interacts With Annex A

Annex A contains a catalogue of security controls that organisations may apply to treat identified risks.
These controls must be mapped to risks, justified, and recorded in the Statement of Applicability (SoA).

Selecting Applicable Controls

Controls must be selected based on:

• The identified risks
• Legal and regulatory requirements
• Contractual obligations
• Organisational objectives

Controls are not optional, but selection is risk-driven.

Justifying Control Selection or Exclusion

For every Annex A control, you must state:

• Whether it is applicable
• Why or why not
• How it will be implemented
• What evidence will support it

This justification lives in the Statement of Applicability.

Updating the Statement of Applicability (SoA)

The SoA is one of the most critical documents in ISO 27001.
It lists all Annex A controls and provides justification for inclusion or exclusion.

Auditors rely on the SoA to understand your organisation’s control landscape.
Any mismatch between the SoA and your risk assessment will be flagged as a nonconformity.

Evidence and Documentation Needed for Clause 6.1

Clause 6.1 is heavily documentation-driven.
Auditors must be able to trace every decision, every control, and every action back to your risk assessment and treatment process.

ISO 27001 does not prescribe formats, but documentation must be:

• Structured
• Consistent
• Traceable
• Version-controlled
• Easy for auditors to navigate

This section outlines every mandatory document and the role each plays.

Mandatory Documents Required for Compliance

Risk Assessment Methodology

This is the foundational document that defines:

• Likelihood scale
• Impact scale
• Risk scoring formula
• Risk acceptance criteria
• Evaluation rules
• Roles and responsibilities

Auditors use this document to check whether you’re applying your methodology consistently.
Any deviation between the methodology and your risk register will be flagged immediately.

For guidance on structuring methodologies within a modern ISMS, refer to our ISO 27001 requirements section for context.

Risk Register

The risk register includes every identified risk, along with:

• Asset
• Threat
• Vulnerability
• Initial risk score
• Risk owner
• Treatment decision
• Residual risk after treatment

This must be kept up to date.
A stale risk register is one of the most common findings during a Stage 2 audit.

Risk Treatment Plan (RTP)

The RTP is the action-plan counterpart to the risk register.
It outlines:

• Which Annex A controls will be implemented
• How each control addresses a specific risk
• Who is responsible
• The timeline for implementation
• Required resources
• Expected outcomes

The RTP is a mandatory audit artifact and is often requested early during Stage 1 documentation review.

Statement of Applicability (SoA)

The SoA is the single most scrutinised document in ISO 27001.
It lists all Annex A controls and must include:

• Whether the control is applicable
• Why the control is applicable
• If excluded, clear justification for exclusion
• How applicable controls are implemented
• Evidence references or links
• Control owners

Our article on the Annex A controls hub page reinforces how the SoA and Annex A interact.

Auditors expect the SoA to be:

• Up-to-date
• Aligned with the risk assessment
• Aligned with the RTP
• Aligned with operational evidence

Even minor misalignments can lead to nonconformities.

How to Demonstrate Compliance to Auditors

Auditors will expect:

• Clear traceability from risks → controls → evidence
• Logical justification for every decision
• Evidence that treatment actions were implemented
• Evidence that risks are monitored
• Evidence that opportunities were considered

The more organised your ISMS, the easier this becomes.

This is why many organisations adopt Hicomply’s ISMS dashboard to centralise documentation, ownership, and evidence in one interface.

Common Documentation Mistakes to Avoid

• Inconsistent scoring across similar risks
• Unclear ownership for risk and control actions
• Missing justification for excluded Annex A controls
• Overly complicated risk assessment models
• SoA not updated after changes in risk profile
• Evidence not linked to corresponding controls
• Treating risk acceptance casually without criteria

Auditors expect discipline — not perfection.
But inconsistency is always a red flag.

Clause 6.1 Across Other ISO Standards (Helpful Context)

Clause 6.1 does not exist only in ISO 27001.
It appears across multiple ISO standards because of the Annex SL unified structure.

Understanding Clause 6.1 across other standards helps demonstrate how ISO’s management system framework is designed to integrate seamlessly.

Clause 6.1 in ISO 9001 (Quality Management)

In ISO 9001, Clause 6.1 requires organisations to identify risks and opportunities that affect product and service quality.
Risk-based thinking ensures quality management is proactive rather than reactive.

The difference from ISO 27001 is the type of risk being analysed — but the structure and intent are almost identical.

Clause 6.1 in ISO 14001 (Environmental Management)

ISO 14001 uses Clause 6.1 to assess environmental risks and opportunities.
This includes compliance obligations, environmental impacts, and improvement opportunities.

ISO 14001 also includes Clause 6.1.3, which focuses on compliance obligations — a concept that does not exist in the same form in ISO 27001.

Clause 6.1.2.1 in ISO 45001 (Occupational Health & Safety)

In ISO 45001, Clause 6.1.2.1 introduces hazard identification requirements.
This parallels how ISO 27001 requires threat and vulnerability identification.

ISO 45001’s perspective is safety, not information security — but the structural similarity reinforces Annex SL alignment.

Clause 6.1.3 in ISO 14001 (Compliance Obligations)

ISO 14001 includes a dedicated requirement for identifying and maintaining compliance obligations.
This differs from ISO 27001, where compliance sits under Clause 4.2 and 4.1 but does not have its own subclause.

Understanding these differences is useful for organisations pursuing integrated management systems, covering ISO 9001, ISO 14001, ISO 27001, and ISO 45001 simultaneously.

Why ISO Uses Unified Clause Structures (Annex SL)

Annex SL ensures all ISO management system standards share:

• Common high-level structure
• Consistent clause numbering
• Shared terminology
• Similar expectations for leadership, planning, support, operation, evaluation, and improvement

This unification makes it possible to run multiple ISO standards under one governance system.
It also ensures ISO 27001 feels familiar to organisations already certified in ISO 9001 or ISO 14001.

Best Practices for Meeting Clause 6.1 Requirements

Clause 6.1 is not just about documents — it is about building a repeatable, auditable, and business-aligned risk management system.

Below are the practices that make organisations excel in audits and long-term ISMS maturity.

How to Build a Repeatable and Auditable Risk Assessment Process

Repeatability is the central requirement.
A mature risk assessment process should:

• Use a consistent methodology
• Assign clear ownership
• Document every risk and decision
• Tie risks into the RTP and SoA
• Be performed at defined intervals
• Be triggered by changes in scope or context

Aim for simplicity.
If your methodology is too complex, teams will struggle to follow it and auditors will find inconsistencies.

Ensuring Leadership Engagement in Risk Decisions

ISO 27001 makes leadership responsible for risk acceptance.
Executives must understand:

• Organisational risk appetite
• High-impact risks
• Resources required for mitigation
• Residual risk after treatment

Leadership engagement should appear clearly in:

• Management review minutes
• Risk acceptance approvals
• Resource allocation decisions

This also supports compliance with Clause 5 (Leadership).

Integrating Risk Management Into Daily Operations

Risk assessment must not be a once-a-year exercise.
It must integrate into:

• Change management
• Supplier onboarding
• Incident response
• New project planning
• System onboarding and decommissioning

When integrated properly, Clause 6.1 activities become part of normal operations, not a compliance burden.

Aligning Clause 6.1 Activities With Business Objectives

Risk decisions should align with:

• Growth goals
• Product development
• Customer requirements
• Regulatory expectations
• Operational changes

The most effective ISMS frameworks align risk management with strategic planning, not just IT or compliance functions.

Advanced Expansion: Practical Examples, Matrices, and Deep-Dive Guidance for Clause 6.1

Clause 6.1 is one of the most operationally important parts of ISO 27001, yet it’s also one of the most misunderstood.
To outrank competitors and give readers the clearest possible understanding, this section adds:

• Practical examples
• Sample risk assessment matrices
• Real-world scenarios
• Guidance on improving maturity
• Cross-functional workflows
• Key questions auditors ask
• How automation strengthens compliance

How to Apply Clause 6.1 in Real Organisations

Clause 6.1 is not a box-ticking exercise.
It is a living process, and it should feel natural within daily business operations.

Below are examples of what Clause 6.1 activities look like inside real companies.

Example: Risk Identification in a SaaS Company

A SaaS provider might identify risks like:

• Weak access control for admin panels
• Lack of third-party security reviews
• Cloud misconfigurations
• Insufficient log retention
• Dependence on a single DevOps engineer
• Unpatched container images
• Manual onboarding without verification steps

Each identified risk is written in the risk register.

Opportunities may also emerge:

• Automating IAM provisioning
• Adding SSO and MFA
• Replacing manual spreadsheets with an ISMS automation tool
• Increasing DevOps redundancy
• Standardising incident response templates

These opportunities help strengthen the ISMS and create efficiency gains.

Example: Risk Identification in a Financial Services Firm

Financial organisations have more regulatory pressure.
Their risks may include:

• Non-compliance with FCA or GDPR
• Outdated encryption protocols
• High-value assets lacking ownership
• Inconsistent supplier onboarding criteria
• Inadequate segregation of duties

Opportunities may include:

• Adopting compliance dashboards
• Improving training frequency
• Unifying policies across business units

Example: Risk Identification in a Healthcare Environment

Typical risks:

• Misconfigured EHR systems
• Sensitive patient data shared via email
• Unsecured legacy medical devices
• Lack of clinical staff awareness around phishing
• Overextended IT teams

Opportunities:

• Introducing automated patching
• Cloud migration for more secure hosting
• Staff simulation training

Deep-Dive: Risk Assessment Criteria Examples

Clause 6.1.2 requires that organisations define their own criteria.
Below is a model that you can include visually or adapt for templates.

Likelihood Scale Example (1–5)

1 — Rare
2 — Unlikely
3 — Possible
4 — Likely
5 — Almost Certain

Impact Scale Example (1–5)

1 — Negligible impact
2 — Minor service impact
3 — Noticeable operational disruption
4 — Significant financial or reputational damage
5 — Major breach, regulatory action, or operational meltdown

‍

Deep-Dive: Building a Strong ISO 27001 Risk Treatment Plan (RTP)

The RTP is where Clause 6.1.3 becomes actionable.
A strong RTP includes:

• Clear mapping between risks and Annex A controls
• Defined owners
• Approvals from leadership
• Expected implementation dates
• Metrics for success

Below is an example treatment entry.

Sample Risk Treatment Plan Entry

Risk ID: R-14
Risk Description: Misconfigured cloud IAM roles increasing unauthorised access risk
Initial Risk Score: 20 (High)
Treatment Decision: Mitigate
Selected Controls:

• A.5.17 (Access control)
• A.8.16 (Monitoring activities)
• A.8.9 (Configuration management)

Action Plan:

• Implement least privilege IAM roles
• Enforce MFA for privileged accounts
• Schedule weekly automated misconfiguration scans

Owner: Head of Cloud Operations
Completion Target: 60 days
Residual Risk: Reduced to Medium

This level of structure is exactly what auditors expect.

Examples of Annex A Control Selection for Risk Treatment

Below are common risks and example Annex A controls used to treat them.

Risk: Phishing attacks targeting employees

Controls:

• A.6.3 Awareness, education, and training
• A.8.16 Monitoring activities
• A.5.15 Access control

Risk: Supplier data mishandling

Controls:

• A.5.19 Supplier relationship security
• A.5.20 Addressing information security within supplier agreements
• A.5.22 Monitoring security of suppliers

Risk: Ransomware or data corruption

Controls:

• A.8.13 Data backup
• A.5.10 Acceptable use
• A.8.11 Information deletion

Risk: Uncontrolled shadow IT

Controls:

• A.5.10 Acceptable use
• A.8.9 Configuration management
• A.8.15 Logging

Control justification must appear in the SoA.

Advanced Guidance: Updating and Maintaining the Statement of Applicability (SoA)

The SoA often becomes outdated quickly if organisations are not proactive.
Here’s how to maintain it properly:

1. Update it whenever the ISMS scope changes.
2. Update it after every risk assessment.
3. Update it when new tools or processes are introduced.
4. Update it after mergers, acquisitions, or major reorganisations.
5. Review it quarterly alongside management review.

A well-maintained SoA is one of the strongest signals of ISMS maturity.

Hicomply customers often rely on automated SoA mapping through features within the ISO 27001 framework overview, another internal anchor.

What Auditors Look For in Clause 6.1 (Top Questions)

Auditors typically ask:

• How did you identify your risks?
• Who was involved in the assessment?
• What criteria did you use for likelihood and impact?
• How do you identify new risks between annual assessments?
• How do you ensure treatment plans are completed?
• Show evidence that actions were carried out.
• How do you know when a risk is acceptable?
• How do you validate that controls are effective?

If you can’t demonstrate traceability — you fail.

If you can't justify control exclusion — you fail.

If you can’t show evidence of improvement — you fail.

Clause 6.1 is all about defensibility.

How Modern ISMS Platforms Improve Clause 6.1 Implementation

Modern compliance teams increasingly use automation to manage Clause 6.1 processes because:

• Spreadsheets break easily
• Risk assessments become inconsistent
• Evidence gets lost
• Teams struggle to maintain version control
• SoA updates are error-prone
• Audits become chaotic

Platforms like Hicomply help organisations:

• Automate evidence collection
• Map controls to risks instantly
• Maintain an audit-ready SoA
• Provide dashboards for risk posture
• Standardise templates
• Assign owners and track actions

Advanced Alignment: Clause 6.1 and Business Strategy

ISO 27001 positions security as a business enabler — not a technical side project.

Below are ways organisations align Clause 6.1 with corporate objectives:

• Linking high-impact risks to revenue protection
• Using risk insights to prioritise product roadmap investments
• Integrating risk reviews into quarterly planning
• Including risk status in leadership dashboards
• Aligning risk acceptance with business appetite

Risk-based thinking becomes a natural decision-making tool across the organisation.

Clause 6.1: Maturity Model (1–5 Levels)

This section helps organisations self-assess their Clause 6.1 maturity.

Level 1 — Initial

• Ad-hoc risk assessments
• No defined criteria
• Incomplete documentation

Level 2 — Developing

• Documented methodology
• Some consistency
• SoA updated occasionally

Level 3 — Established

• Regular assessments
• Controls mapped to risks
• Auditable decision-making

Level 4 — Managed

• Metrics used to evaluate risk
• Evidence automated or streamlined
• Leadership deeply engaged

Level 5 — Optimised

• Continuous risk monitoring
• Automation integrated
• Predictive threat modelling
• Fully integrated compliance program

Most organisations aim for Level 4 by their second audit cycle.

Clause 6.1 Scenarios: What Happens If…

If you identify a risk but do nothing

This is a nonconformity. Risks must be evaluated and treated or formally accepted.

If you accept a high risk without justification

Auditors will challenge your methodology and leadership involvement.

If your risk assessment conflicts with your SoA

This is an immediate and significant issue.

If your risk register is too complex

Teams will misunderstand it → inconsistency → nonconformity.

If it's too simple

Auditors may question whether your organisation truly understands its threats.

The goal is simple but meaningful, not oversimplified or excessively technical.

ISO 27001 Clause 6.1 in Integrated Management Systems

Many organisations operate multiple ISO standards simultaneously.
Clause 6.1 can be harmonised across:

• ISO 9001: quality
• ISO 14001: environmental impact
• ISO 45001: health and safety
• ISO 27701: privacy
• ISO 22301: business continuity

When integrated effectively, teams perform one risk assessment per domain with shared governance and templates.

This significantly reduces audit overhead.

Book a Demo and Strengthen Your ISO 27001 Risk Management

Clause 6.1 is powerful, but it’s also one of the most time-consuming areas of ISO 27001 to implement manually.
Teams often struggle with maintaining consistent risk criteria, updating treatment plans, keeping evidence audit-ready, and ensuring the Statement of Applicability always reflects their current controls.

Hicomply removes that burden.

With automated evidence collection, integrated risk management tools, and real-time control tracking, you can build a fully aligned, continuously improving ISMS — without the spreadsheets, manual follow-ups, or last-minute audit panic.

If you want to make your ISO 27001 implementation faster, clearer, and far more efficient, you can see the platform in action.

Book a demo today and discover how Hicomply helps you simplify Clause 6.1, strengthen your ISMS, and prepare for ISO 27001 certification with confidence.

‍