ISO 27001 Clause 6.1: Risks and Opportunities

Clause 6.1 is the risk engine of your ISMS. It requires you to identify information security risks and opportunities, define a repeatable risk assessment process, and plan how to treat unacceptable risks. Everything from your Statement of Applicability to your control selection flows from what you do here.

What the clause requires

ISO 27001:2022 Clause 6.1 has three sub-clauses, each building on the previous one:

6.1.1 General

When planning the ISMS, you must consider your organizational context (Clause 4.1) and interested parties (Clause 4.2), then determine the risks and opportunities that need to be addressed. The goal is threefold:

Ensure the ISMS achieves its intended outcomes
Prevent or reduce undesired effects
Achieve continual improvement

You must plan actions to address these risks and opportunities, integrate them into your ISMS processes, and evaluate whether those actions are effective.

6.1.2 Information security risk assessment

You must define and apply a risk assessment process that:

Establishes and maintains risk acceptance criteria
Ensures assessments produce consistent, valid, and comparable results
Identifies risks to the confidentiality, integrity, and availability of information within your ISMS scope
Identifies risk owners
Analyzes the consequences and likelihood of each risk
Evaluates results against your acceptance criteria and prioritizes risks for treatment

The standard requires you to retain documented information about this process and its results. That means your methodology, risk register, and assessment outcomes must be recorded.

6.1.3 Information security risk treatment

For risks that exceed your acceptance criteria, you must:

Select appropriate treatment options (reduce, accept, avoid, or transfer)
Determine the controls necessary to implement those options
Compare your selected controls against ISO 27001 Annex A to ensure nothing critical is overlooked
Produce a Statement of Applicability documenting which Annex A controls apply and which do not, with justifications
Formulate a risk treatment plan
Obtain approval from risk owners for the treatment plan and the acceptance of residual risks

How to build your risk assessment process

The standard requires a defined methodology but does not prescribe one. Here is a practical approach that works for most organizations:

Define your risk criteria

Before assessing anything, define how you will measure impact and likelihood. A simple 5-point scale works well for most organizations:

Likelihood: 1 (rare) to 5 (almost certain)
Impact: 1 (negligible) to 5 (critical)
Risk score: likelihood x impact, giving you a 1-25 range
Acceptance threshold: risks scoring above a defined level (commonly 10 or 12) require treatment

Document these criteria and get them approved before running assessments. Changing criteria mid-assessment invalidates your results.

Identify your risks

Start with your information assets and think about what could go wrong for each one. For a SaaS company, this typically means:

Customer data exposed through a misconfigured cloud service (confidentiality)
Source code modified by an unauthorized party (integrity)
Production systems unavailable due to a provider outage (availability)
Phishing attack compromising employee credentials
Departed employee retaining access to critical systems

A 20-person SaaS company typically identifies 30-60 risks in their first assessment. You do not need hundreds - focus on risks that are meaningful to your business context rather than padding the register with theoretical scenarios.

Assign risk owners and analyze

Every risk needs an owner - a person accountable for monitoring and treating that risk. This connects directly to your roles and responsibilities under Clause 5.3. Rate each risk for likelihood and impact, calculate the score, and compare against your acceptance threshold.

Build your treatment plan

For risks above your threshold, decide how to treat them. Most risks in practice get treated through controls - technical, organizational, or procedural measures that reduce likelihood or impact. Your treatment plan should specify:

What control is being implemented
Who is responsible
Timeline for implementation
Expected effect on the risk score

Compare your selected controls against the 93 controls in Annex A of ISO 27001:2022. This cross-reference ensures you have not missed critical control areas. The result is your Statement of Applicability - a document listing every Annex A control, whether it applies, and your justification.

Connecting 6.1 to the rest of your ISMS

Clause 6.1 sits at the center of your ISMS. Almost everything flows into or out of it.

Clauses 4.1-4.3 connection. Your organizational context, interested parties, and ISMS scope are direct inputs to risk assessment. You cannot assess risks without knowing what your organization faces and what your ISMS covers.

Clause 5.3 connection. Roles and responsibilities establish who owns risks and who is accountable for treatment actions. Without clear risk ownership, your treatment plan has no teeth.

Clause 6.2 connection. Information security objectives should be informed by your risk assessment results. Your objectives address the most significant risks and opportunities you have identified.

Clause 8.2-8.3 connection. Clause 8.2 requires you to actually perform risk assessments at planned intervals. Clause 8.3 requires you to implement your treatment plan. Clause 6 defines the methodology; Clause 8 executes it.

Clause 9.3 connection. Management review evaluates the results of risk assessments and the status of the treatment plan. This is where leadership decides whether the current risk posture is acceptable.

What auditors check

Risk management is one of the most heavily scrutinized areas during certification audits.

Documented methodology. Auditors expect to see a written risk assessment procedure that defines your criteria, scales, acceptance threshold, and process. If you cannot show them the methodology before showing the results, that is a gap.

Consistency between assessments. If two different people assess the same risk and arrive at wildly different scores, your methodology is not producing consistent results. Auditors may ask different team members how they would rate a hypothetical risk to test this.

Risk register completeness. Auditors compare your risk register against your organizational context and scope. If your context analysis identifies cloud infrastructure as critical but your risk register has no cloud-related risks, they will question the thoroughness of your assessment.

Risk owner involvement. Auditors check that risk owners have actually reviewed and approved treatment plans and accepted residual risks. If risk owners cannot explain the risks they own, that is a Clause 5.3 and 6.1 finding combined.

Statement of Applicability. The SoA must be consistent with your risk assessment. Every control you have selected should trace back to a risk or a legal/contractual requirement. Controls marked “not applicable” need clear justification.

Evidence of reassessment. For surveillance audits, auditors look for evidence that risk assessments have been repeated - not just the initial assessment from certification. The risk register should show changes over time: new risks added, closed risks removed, scores updated after control implementation.

Common mistakes to avoid

Copy-pasting a generic risk register. Starting from a template is fine, but auditors can spot a register full of generic risks that do not reflect your actual business. “Natural disaster affecting the data center” is not meaningful if you run entirely on AWS. Tailor your risks to your real context.

Skipping the methodology definition. Some organizations jump straight into listing risks without documenting their criteria and process first. This means their risk scores are subjective and inconsistent - exactly what auditors test for.

Treating risk assessment as a one-time activity. The initial assessment gets you certified. But Clause 8.2 requires reassessment at planned intervals and after significant changes. If your risk register looks identical 12 months after certification, auditors will question whether you are actually managing risks or just maintaining a static document.

Ignoring opportunities. Clause 6.1.1 mentions both risks and opportunities. Most organizations focus entirely on threats. Opportunities might include adopting a new security technology that reduces multiple risks, or achieving certification to unlock a new market segment. Auditors do not heavily test this, but addressing opportunities shows maturity.

Setting the acceptance threshold too low. If your threshold is so low that almost every risk requires treatment, you create an unmanageable treatment plan. If it is too high, you accept risks that should be treated. A threshold that results in 40-60% of risks requiring treatment is typically practical.

How 27kay can help

We help organizations build risk assessment processes that produce meaningful results - not spreadsheets full of generic risks that exist only for the auditor. As part of ISO 27001 implementation, we facilitate risk workshops, define your methodology, and help you build a treatment plan that addresses real threats to your business. For the full picture, see our ISO 27001 knowledge hub.

Want help building a risk assessment process that actually works? Get in touch - we will walk through your situation and help you identify what matters most.