What Is ISO 27001 Clause 6.1 and Why Does It Matter?
If you are working towards ISO 27001 certification, Clause 6.1 is one of the most important sections you will encounter. It sits inside Section 6, which covers Planning, and it deals with how your organisation identifies and responds to information security risks and opportunities. Getting this clause right is not just about ticking a box for an auditor. It is about building a system that genuinely protects your business from threats that can cause real financial and reputational damage.
On this page
Clause 6.1 is structured around three core requirements. First, you must consider the context of your organisation and the needs of interested parties (which you would have already worked through in Clause 4) and determine what risks and opportunities need to be addressed. Second, you must carry out a formal information security risk assessment. Third, you must plan and implement risk treatment actions. Each of these has specific sub-requirements, and auditors will look for documented evidence at every step.
This guide walks through each part of Clause 6.1 in plain English, with practical examples that reflect real situations businesses face. Whether you are a small tech firm in Melbourne or a mid-sized managed service provider in Brisbane, the principles apply the same way. If you want broader context on the standard first, our beginner's guide to ISO 27001 is a good starting point.
Understanding the Structure of Clause 6.1
Clause 6.1 is broken into three sub-clauses:
- Clause 6.1.1 covers the general requirement to address risks and opportunities
- Clause 6.1.2 covers the information security risk assessment process
- Clause 6.1.3 covers the information security risk treatment process
These three sub-clauses work together. You cannot do 6.1.3 properly without having done 6.1.2, and 6.1.2 only makes sense in the context of 6.1.1. Think of them as sequential steps in a planning process, not standalone requirements.
Clause 6.1.1: General Requirements
This sub-clause asks you to consider what risks and opportunities are relevant to your Information Security Management System (ISMS). Specifically, it says you need to address risks and opportunities to ensure the ISMS can achieve its intended outcomes, prevent or reduce undesired effects, and achieve continual improvement.
The standard links this directly back to Clause 4.1 (understanding your organisation and its context) and Clause 4.2 (understanding the needs and expectations of interested parties). In practice, this means your risk planning should reflect what you already know about your business environment, your regulatory obligations, your customers, and your suppliers.
What Counts as an Opportunity in ISO 27001?
Many businesses focus entirely on risks and forget that the standard also asks you to identify opportunities. An opportunity in this context is anything that could improve your ISMS or strengthen your information security posture. Some examples include:
- Adopting a new cloud security tool that reduces your exposure to a known vulnerability
- Consolidating suppliers to reduce the number of third-party access points into your systems
- Training staff in phishing awareness, which reduces the likelihood of a successful social engineering attack
- Implementing multi-factor authentication across all remote access, which improves your control environment
Auditors do check that you have considered opportunities, not just risks. If your risk register only lists threats and nothing else, expect a question about this during your audit.
Clause 6.1.2: Information Security Risk Assessment
This is the heart of Clause 6.1. The standard requires you to define and apply an information security risk assessment process that produces consistent, valid, and comparable results. There are several specific requirements inside this sub-clause.
Step 1: Establish Risk Acceptance Criteria
Before you assess any risks, you need to define what level of risk your organisation is willing to accept. This is called your risk appetite or risk acceptance criteria. You document this in a Risk Assessment Methodology or Risk Management Policy.
A practical example: a small accounting firm might decide that any risk rated above a score of 12 on a 5x5 likelihood versus impact matrix is unacceptable and must be treated. Risks below that threshold can be monitored but do not require immediate action. The number itself is less important than having a documented, defensible rationale.
Step 2: Identify Information Security Risks
The standard requires you to identify risks associated with the loss of confidentiality, integrity, and availability of information. This means looking at your information assets and asking what could go wrong.
You need to identify:
- The assets or processes within the scope of your ISMS
- The threats that could affect those assets
- The vulnerabilities that those threats could exploit
- The potential consequences if a risk materialises
A practical example for a software development company: one of their key assets is their source code repository. A threat is an unauthorised insider copying the repository before leaving the company. A vulnerability is that access rights are not reviewed when an employee gives notice. The consequence is loss of intellectual property and potential competitive damage.
Step 3: Analyse and Evaluate the Risks
Once you have identified your risks, you need to assess them. This involves estimating the likelihood of each risk occurring and the impact it would have if it did. You then compare the results against your risk acceptance criteria to determine which risks require treatment.
Most organisations use a simple matrix approach. Likelihood and impact are each rated on a scale (commonly 1 to 5), and the two scores are multiplied to give a risk rating. Risks above the acceptance threshold are prioritised for treatment.
The standard requires that this process produces consistent and comparable results. That means you need a documented methodology that different people in your organisation could apply and arrive at similar conclusions. Ad hoc, undocumented assessments will not satisfy an auditor.
For more context on how risk assessment fits into the broader ISO 27001 framework, our guide on ISO 27001 risk assessment for non-technical business owners covers this in accessible detail.
Documented Evidence Required for Clause 6.1.2
The standard explicitly requires you to retain documented information about the risk assessment process and its results. This typically means:
- A Risk Assessment Methodology document
- A Risk Register listing all identified risks, their ratings, and the risk owners
- Evidence that the assessment was reviewed and approved by appropriate personnel
Clause 6.1.3: Information Security Risk Treatment
Once you know what your risks are and how they are rated, you need to decide what to do about them. Clause 6.1.3 covers the risk treatment process. The standard gives you four treatment options:
- Modify the risk by implementing controls to reduce likelihood or impact
- Retain the risk by accepting it, usually because the cost of treatment outweighs the benefit
- Avoid the risk by deciding not to engage in the activity that creates the risk
- Share the risk by transferring it to a third party, such as through insurance or outsourcing
Selecting Controls From Annex A
One of the most important requirements in Clause 6.1.3 is that when you decide to modify a risk through controls, you must select controls from ISO 27001 Annex A, or justify why a control from Annex A is not applicable. This is documented in a Statement of Applicability (SoA).
The SoA is one of the most audited documents in any ISO 27001 certification. It lists every control in Annex A, states whether it is applicable or not, and provides the justification for that decision. For controls that are applicable, it also states whether they have been implemented.
A practical example: your risk assessment identifies a high risk of unauthorised access to your customer database. You select Annex A control 8.3 (Information access restriction) as a treatment. In your SoA, you mark this control as applicable and implemented, and you link it back to the specific risk it addresses.
Producing a Risk Treatment Plan
For each risk that requires treatment, you need a plan. The risk treatment plan documents what actions will be taken, who is responsible, what resources are needed, and when the actions will be completed. This does not need to be a complex document. A well-maintained spreadsheet or a table in your risk register can serve this purpose.
The key is that the plan is actionable and monitored. An auditor will want to see that treatment actions are being tracked and that progress is being reviewed. A risk treatment plan that was written during implementation and never looked at again is a red flag.
Obtaining Risk Owner Approval
The standard requires that risk owners approve both the risk treatment plan and the residual risks, meaning the risks that remain after treatment controls are applied. This is an important governance step. It ensures that someone with authority and accountability has formally accepted the remaining exposure.
In a small business, the risk owner might be the director or the IT manager. In a larger organisation, different risk owners might be assigned to different risk categories. What matters is that the approval is documented.
Real-World Examples of Clause 6.1 in Practice
Example 1: A Managed Service Provider
An MSP in Sydney is implementing ISO 27001 for the first time. During their risk assessment, they identify that several clients share the same administrative portal with different access levels. A vulnerability is that misconfigured permissions could allow one client to view another client's data. The likelihood is rated medium and the impact is rated high, giving a risk score above their acceptance threshold.
Their treatment plan includes implementing role-based access controls, conducting quarterly access reviews, and enabling audit logging on the portal. The controls are mapped to Annex A 8.3 and 8.15. The IT manager is assigned as risk owner and formally approves the residual risk after controls are implemented. All of this is documented in their risk register and SoA.
Example 2: A Financial Services Firm
A boutique investment advisory firm identifies a risk that staff working remotely could expose client data through unsecured home networks. Likelihood is rated high (most staff work from home at least three days a week) and impact is rated very high due to regulatory obligations under Australian privacy law.
Their treatment includes mandatory use of a corporate VPN, endpoint encryption on all devices, and a remote working security policy. They also identify an opportunity: implementing a mobile device management solution that was already being considered for operational reasons, which they can now accelerate as part of their ISMS implementation. Both the risk treatment and the opportunity are documented.
Example 3: A Healthcare Technology Company
A health tech startup processes sensitive patient data on behalf of hospitals. During their risk assessment, they identify a risk that a third-party software component they use has a history of unpatched vulnerabilities. The risk is rated high.
Their treatment includes adding the vendor to a formal supplier review process (mapped to Annex A 5.19), requiring the vendor to provide evidence of their own security controls, and establishing a contractual obligation for timely patching. They also retain a small residual risk related to zero-day vulnerabilities, which the CEO formally accepts in writing as part of the risk treatment approval process.
Common Mistakes Businesses Make With Clause 6.1
Having audited ISO 27001 systems across many industries, the same problems come up repeatedly. Here are the ones to watch out for:
- Treating the risk register as a one-time exercise. Clause 6.1 requires an ongoing process. Your risk register needs to be reviewed at planned intervals and updated when significant changes occur.
- Not linking risks to controls in the SoA. Auditors look for a clear thread from identified risk to selected control to documented implementation. If these are in separate documents with no cross-references, it creates confusion and audit findings.
- Setting risk acceptance criteria after the fact. If you assess your risks first and then set your acceptance threshold to conveniently exclude all the hard ones, an auditor will notice. The methodology must be established before the assessment is conducted.
- Forgetting to document residual risk approval. Many businesses do the treatment but skip the formal approval step. This is a straightforward nonconformity that is easy to avoid.
- Ignoring opportunities entirely. As mentioned earlier, the standard requires you to address both risks and opportunities. If your planning documentation only mentions threats, you have a gap.
If you are unsure how to find a consultant who can guide you through these requirements properly, our guide on how to compare ISO 27001 consultants is worth reading before you engage anyone.
How Clause 6.1 Connects to the Rest of Your ISMS
Clause 6.1 does not operate in isolation. It feeds directly into several other parts of the standard. The controls you select in your risk treatment process become the basis for Clause 6.2 (information security objectives) and Clause 8 (operational planning and control). The outcomes of your risk assessment inform management reviews under Clause 9.3. And when things go wrong, Clause 10 (improvement) requires you to revisit your risk assessment to determine whether new risks have emerged.
Understanding these connections matters because auditors assess your ISMS as an integrated system, not as a collection of standalone documents. A risk register that is disconnected from your objectives, your controls, and your improvement activities will raise questions about whether your system is genuinely implemented or just documented on paper.
For a broader look at how information security management systems are structured, our article on what is an Information Security Management System provides useful background.
Getting Help With Clause 6.1
Clause 6.1 is one of those areas where having experienced guidance makes a genuine difference. The concepts are not complicated, but the execution requires discipline and consistency. A poorly designed risk assessment methodology, an incomplete SoA, or a risk treatment plan with no evidence of implementation will create nonconformities that delay your certification.
If you are working through ISO 27001 implementation and want to make sure you get Clause 6.1 right, CertBetter can connect you with verified ISO 27001 consultants and accredited certification bodies who have done this work across many industries. You submit one form, receive up to three competing quotes, and can compare your options before committing to anything. The service is completely free for businesses seeking certification help.
