Risk Assessment

Building a Risk Treatment Plan That Auditors Respect

Alex Fuerst

05 Nov 2025 — 7 min read

What Auditors Actually Look For

I've reviewed thousands of risk treatment plans over my career. Most of them are exercises in creative fiction—elaborate documents that check boxes without actually treating risks. They list controls that sound impressive, assign ownership to people who didn't know they were responsible, and set deadlines that passed months ago. Then organizations act surprised when I write findings against them during certification audits.

The risk treatment plan sits at the heart of ISO 27001. It's where your risk assessment translates into actual security improvements. Get it wrong, and you're not just failing an audit—you're operating with a false sense of security while real risks remain unaddressed. Get it right, and you have a living document that genuinely drives your security posture forward.

Let me be direct about what I'm evaluating when I review a risk treatment plan. I'm not looking for perfection. I'm looking for evidence that your organization has made deliberate, justified decisions about how to handle identified risks and is actually following through on those decisions.

Clause 6.1.3 requires organizations to formulate a risk treatment plan and obtain risk owner approval. That second part trips up more organizations than you'd expect. I routinely find risk treatment plans signed off by the CISO or IT Director when the actual risk owners—business unit heads, for instance—have never seen the document. That's a finding, every time.

Here's what I'm checking:

Traceability: Can I follow a risk from the assessment through to specific treatment actions and then to evidence of implementation?
Proportionality: Do the proposed controls actually address the risk, or are they generic security measures bolted on regardless of context?
Ownership: Is someone named and accountable for each treatment action, and do they actually know about it?
Timelines: Are deadlines realistic based on the organization's capacity and the risk severity?
Resource allocation: Has the organization actually committed budget and people to make this happen?
Progress tracking: Is there evidence of regular review and status updates?

What I'm not impressed by: color-coded heat maps with no substance behind them, treatment plans that list "implement training" as the solution to every human-factor risk, or documents clearly created the week before my audit.

The Four Treatment Options and When to Actually Use Them

ISO 27001 gives you four options for treating risk: modify (reduce), retain (accept), avoid, or share (transfer). Most organizations default to "modify" for everything and slap on controls without thinking through whether that's the right approach.

Modification: The Default That Shouldn't Be Default

Modifying risk means implementing controls to reduce likelihood or impact. This is appropriate when the cost of control is proportionate to the risk reduction achieved and when effective controls actually exist for the risk in question.

I audited a manufacturing company that had identified the risk of proprietary designs being stolen by competitors. Their treatment? "Implement DLP solution." Six months and €200,000 later, they had a DLP tool that generated 3,000 false positives daily, which the security team ignored entirely. The actual risk—a handful of engineers with legitimate access to designs—remained completely unaddressed.

A better approach would have been implementing targeted controls: enhanced background verification for design engineers (Control 6.1), strict need-to-know access controls (Control 8.2), and monitoring of unusual data access patterns (Control 8.16). Cheaper, more effective, actually addressing the risk.

Retention: The Honest Option That Scares People

Retaining risk means accepting it without additional controls. This is legitimate when the cost of treatment exceeds the potential impact, when the likelihood is genuinely negligible, or when no effective controls exist.

Organizations fear documenting risk retention because they think auditors will penalize them. We won't—as long as the decision is justified, documented, and approved at the appropriate level. What I will penalize is pretending to treat a risk when you're actually just hoping it doesn't materialize.

I've seen organizations spend hundreds of thousands on controls for risks they should have simply accepted. A regional accounting firm spent €50,000 on advanced persistent threat detection when their actual threat profile didn't warrant it. That money would have been better spent on basics like proper backup testing and phishing resistance training.

Avoidance: The Option Nobody Thinks About

Risk avoidance means eliminating the activity that creates the risk. This is often the most effective approach but requires business decisions that security teams can't make unilaterally.

A law firm I audited identified unacceptable risks around storing client data in a particular cloud region due to jurisdiction concerns. Instead of implementing complex encryption and access controls that would have cost more than the revenue from that region, they simply stopped offering services there. Problem solved.

Sharing: Beyond Insurance Policies

Risk sharing doesn't just mean buying cyber insurance. It includes outsourcing risky activities to parties better equipped to handle them, implementing supplier security requirements (Control 5.19), or using secure cloud services instead of managing infrastructure internally.

When evaluating shared risks, I look for evidence that you've actually transferred the risk, not just the responsibility. Contracts that say "supplier shall implement appropriate security measures" don't transfer risk—they create new ones.

Controls Selection: Beyond Copy-Paste from Annex A

The most common mistake I see is organizations treating Annex A like a shopping list. They select controls based on what sounds important rather than what actually addresses their specific risks. This creates implementation burdens without corresponding risk reduction.

Control 8.5 (Secure deletion) is a perfect example. Organizations implement elaborate data destruction procedures without considering whether their actual risks relate to data remnants or something else entirely. If your risk is insider theft of customer databases, secure deletion won't help—you need Control 8.2 (Privileged access management) and Control 8.16 (Monitoring activities).

I also see organizations miss obvious control opportunities because they're not in Annex A. Business-specific controls—like requiring dual approval for high-value transactions or implementing supply chain integrity checks—often provide better risk treatment than generic IT controls.

Practical tip: Start with your risk statement, then ask: "What would actually prevent this from happening?" Don't start with a control and try to justify it.

Cross-Standard Considerations

If you're operating in cloud environments, ISO/IEC 27017 provides additional control guidance that your risk treatment plan should consider. For personal data processing, ISO/IEC 27018 offers specific controls that might be necessary for regulatory compliance.

Supply chain risks increasingly require treatment approaches that go beyond traditional information security controls. ISO/IEC 27036 provides frameworks for supplier relationship security that can inform your treatment decisions when risks involve third parties.

Implementation Planning That Actually Works

A good risk treatment plan doesn't just say what to do—it explains how to do it. I look for evidence that someone has thought through the practical implementation challenges.

Resource allocation is where most plans fall apart. "Implement security awareness training" sounds simple until you realize it requires curriculum development, trainer time, tracking systems, and ongoing measurement. I want to see budget allocations, staffing plans, and realistic timelines.

Dependencies matter enormously but are rarely documented. Implementing Control 8.22 (Segregation of networks) might require firewall policy changes, network architecture reviews, and application testing. None of these happen in isolation.

Success criteria should be measurable and linked to risk reduction. "Complete training" isn't a success criterion—"Reduce successful phishing simulation rate to below 5%" is.

Phased Implementation

Smart organizations implement controls in phases that deliver incremental risk reduction while maintaining operational stability. I prefer seeing a plan that says "Implement basic access controls by Q1, enhance monitoring by Q2, add advanced analytics by Q3" rather than "Implement comprehensive access management solution by end of year."

Monitoring and Measurement

Clause 9.1 requires monitoring the effectiveness of your risk treatment. This means your treatment plan must include measurement criteria from the start. I look for specific, measurable indicators tied to the actual risks being treated.

If you're treating the risk of data exfiltration through Control 8.16 (Monitoring activities), your measurement might track unauthorized data access attempts, large file downloads, or after-hours database queries. Don't just measure whether the monitoring tool is working—measure whether it's reducing the actual risk.

I've seen organizations measure everything except effectiveness. They track control implementation percentages, compliance scores, and incident response times, but never answer the fundamental question: "Is this risk actually being treated?"

Common Implementation Failures

Three patterns cause most risk treatment plan failures:

The "Set and Forget" Syndrome: Plans that never get updated after initial approval. I find treatment plans with actions completed years ago sitting alongside new risks that haven't been addressed. Risk treatment is ongoing, not a one-time activity.

The "Technical Solution to Everything" Approach: Organizations that think every risk can be solved with technology. People risks need people solutions, process risks need process solutions, and governance risks need governance solutions.

The "Perfect Plan" Paralysis: Waiting to develop the comprehensive solution before starting any implementation. I'd rather see a simple control implemented well than a complex plan that never gets executed.

What the Auditor Looks For

During audits, I focus on three key areas:

Evidence of actual implementation: Show me the firewall rules, the access lists, the training records. Screenshots of configuration screens, policy documents with approval signatures, and system logs that demonstrate controls are working.

Alignment between risk and treatment: Can you explain why this specific control addresses this specific risk? If you can't make that connection clear, neither can your users.

Management engagement: Are the people responsible for implementing treatments actually involved in the planning? Have they committed resources? Do they understand their responsibilities?

I also look for evidence of learning and adaptation. The best risk treatment plans evolve based on implementation experience, changing threat landscape, and business developments. Static plans suggest static thinking.

Your risk treatment plan should read like a practical project plan created by people who understand both the risks and the business. It should demonstrate clear thinking about how to actually reduce risks while maintaining operational effectiveness. When I can see that level of thoughtfulness, I know I'm reviewing an organization that takes security seriously.

Need help building a risk treatment plan that will satisfy auditors and actually improve your security posture? Connect with experienced practitioners at the IX ISO 27001 Info Hub for practical guidance and peer insights.

Need personalized guidance? Reach our team at ix@isegrim-x.com.