Last Updated on September 23, 2025 by Melissa Lazaro

Introduction: ISO/IEC 27001 Clause 6 – Risk Management & Planning

If there’s one area where ISO/IEC 27001 really separates the prepared from the unprepared, it’s Clause 6 – Risk Management & Planning. This is where organizations often stumble, because “risk” sounds technical, abstract, and complicated. Some overcomplicate it with endless scoring models; others oversimplify it by copying a generic risk register they found online. Both approaches miss the point.

Here’s what I’ve noticed in practice: companies that get Clause 6 right don’t just satisfy auditors—they actually improve resilience and decision-making. Why? Because they’re aligning their information security risks and objectives with the real-world context of their business. Instead of reacting to problems, they plan ahead.

Clause 6 matters because it sets the direction for everything that follows in your ISMS. If you don’t define risks properly, your treatment plan and objectives won’t hold up. But if you do, you end up with a system that’s practical, focused, and much easier to improve over time.

By the end of this article, you’ll understand:

• Why risk-based planning is at the core of ISO/IEC 27001.

• How to conduct a risk assessment and treatment that auditors will trust.

• What effective ISMS objectives look like in practice.

• The pitfalls that cause most organizations to trip up—and how you can avoid them.

Now that we’ve set the stage, let’s dig into Clause 6.1 and why risk-based thinking is the backbone of ISO/IEC 27001.

ISO/IEC 27001 Clause 6.1 – Why Risk-Based Planning Matters

Clause 6.1 is where ISO/IEC 27001 really shows its teeth. The standard isn’t about throwing controls at problems randomly—it’s about using risk-based planning to decide where to focus effort, money, and resources.

In simple terms: if you don’t know your risks, you don’t know what to protect or how. That’s why Clause 6.1 tells you to look at both risks (things that could harm your ISMS) and opportunities (ways to strengthen it). Most organizations naturally focus on threats—like data breaches, system outages, or supplier failures. But they often forget opportunities, like using strong security to win new clients or boost trust with existing ones.

I’ve seen companies treat risk assessment as a one-off “audit requirement.” They run a workshop, produce a spreadsheet, and file it away until the next certification cycle. The problem? Their ISMS stays static while their environment changes. New technologies, new regulations, and new threats emerge, but the risk register doesn’t move. Auditors catch this quickly.

Here’s a real example: one client, a logistics company, identified “cyberattacks” as a top risk—pretty standard. But when we dug deeper, their real exposure came from supply chain disruptions. A ransomware hit on a supplier could cripple their operations. By capturing that in Clause 6.1 and planning for it, they built redundancy into their supplier network and saved themselves from major downtime later on.

The takeaway is simple: Clause 6.1 isn’t paperwork—it’s the backbone of your ISMS. Done right, it turns your security plan from reactive firefighting into proactive risk management.

ISO/IEC 27001 Clause 6.1.2 – Information Security Risk Assessment Process

Clause 6.1.2 takes the big idea of “risk-based planning” and makes it concrete: you need a defined, repeatable process for assessing information security risks. Auditors don’t just want to see a risk register; they want to see how you got there.

A strong risk assessment process should cover:

• Criteria for risk evaluation – How will you decide if a risk is acceptable or not?

• Methodology – Will you use qualitative scoring (low/medium/high), quantitative values, or a hybrid?

• Consistency – Everyone in the organization should apply the same method, so results are comparable.

• Documentation – The process itself needs to be documented, not just the results.

Where companies slip up is by treating risk assessment like a brainstorming session with no structure. I’ve seen organizations create lists of risks with no scoring, no prioritization, and no clear rules for acceptance. When an auditor asks, “How do you know this risk is acceptable?”—they can’t answer.

Here’s what works in practice:

• Define a risk matrix with likelihood on one axis and impact on the other.

• Score each risk according to the agreed criteria.

• Prioritize risks that fall into the high-impact/high-likelihood zone.

For example, a financial services company I worked with scored the risk of phishing attacks as “high likelihood, high impact.” That placed it in the critical zone, which justified investment in training and email filtering. Lower risks, like occasional printer downtime, were accepted as tolerable.

The strength of Clause 6.1.2 lies in its structure. When your risk assessment process is clear, repeatable, and documented, you avoid arguments, guesswork, and audit findings.

ISO/IEC 27001 Clause 6.1.3 – Information Security Risk Treatment

Once you’ve identified and assessed risks under Clause 6.1.2, the next step is deciding how to deal with them. Clause 6.1.3 requires you to define a risk treatment plan that clearly shows which option you’ve chosen for each risk and why.

In practice, you have four main choices:

A common mistake is picking controls directly from Annex A without showing how they link back to risks. Auditors want to see the logic: which risk is being treated, how, and why this option is the right fit.

For example, a fintech firm I worked with identified phishing as a high-priority risk. Instead of just “adding a control,” they documented their reasoning: “Risk of credential theft will be mitigated by implementing MFA, strengthening email filters, and mandatory staff training. Residual risk after treatment is acceptable.” That clear chain of thought satisfied both management and auditors.

The treatment plan isn’t just about controls—it’s about showing accountability for how risks are handled. Done well, it connects your risk assessment to real-world action.

ISO/IEC 27001 Clause 6.2 – Information Security Objectives and Planning

Clause 6.2 requires organizations to set information security objectives that guide the ISMS and prove leadership commitment. These objectives need to be aligned with business goals, measurable, and regularly reviewed.

Too often, I see objectives written as vague promises like “improve security.” That doesn’t satisfy auditors, and it doesn’t help employees know what to aim for. Objectives need to be SMART (Specific, Measurable, Achievable, Relevant, Time-bound).

Weak vs. Strong ISMS Objectives

Planning to Achieve Objectives

Once objectives are set, organizations need to plan:

• What will be done – activities to reach the objective.

• Resources required – budget, technology, staff.

• Who is responsible – accountability assigned clearly.

• Timeline – deadlines for completion.

• Evaluation – how progress will be tracked and measured.

For example, one client set the objective of reducing phishing incidents. Their plan included: quarterly staff training, deploying a new email filter, assigning the IT security manager ownership, and tracking results monthly. When the auditor asked about progress, they had clear evidence tied back to their Clause 6.2 objectives.

Strong objectives turn Clause 6 from theory into action. They give employees focus, auditors confidence, and leadership measurable proof that the ISMS is working.

Summary of ISO/IEC 27001 Clause 6 – Risk Management & Planning

Clause 6 is where your ISMS becomes practical. It ensures that risks are identified, assessed, treated, and linked to measurable objectives. Done right, it keeps the ISMS focused on protecting what matters most while supporting business goals.

Key takeaways:

• Clause 6.1 – Risk-based planning drives the ISMS.

• Clause 6.1.2 – Risk assessments must be structured, consistent, and documented.

• Clause 6.1.3 – Risk treatment must clearly link back to identified risks.

• Clause 6.2 – Objectives should be SMART and supported by detailed plans.

FAQs on ISO/IEC 27001 Clause 6