ISO 27001 Risk Assessment: How to Map Business Risks to Annex A Controls

In a previous blog post, I explored whether organisations should choose scenario-based or asset-based risk management techniques when implementing ISO 27001. Today, I want to build on that discussion by examining a critical aspect that many organisations overlook: ensuring your risk register properly addresses the broader organisational risks that underpin the controls in Annex A.

This isn’t just about compliance box-ticking. When done correctly, your risk mapping demonstrates that you’ve genuinely considered the full spectrum of risks facing your organisation, not just the obvious technology-focused ones.

The Missing Link: From Controls Back to Risks

Many organisations approach ISO 27001 implementation by starting with the 93 controls in Annex A and working backwards. They’ll look at control A.5.1 (policies for information security) and think “we need policies,” then write some policies and consider the job done.

But this approach misses the fundamental purpose of the standard. The controls exist to address risks, and your Statement of Applicability should demonstrate that you understand what those risks actually are for your organisation.

Let’s consider that documentation control example I mentioned. Control A.5.1 requires that information security policies are established and communicated. But what’s the underlying risk this control addresses?

risk management

The real risks might include:

  • Policies and procedures becoming outdated, creating compliance gaps or security vulnerabilities
  • Staff not being aware of current security requirements, leading to inadvertent breaches
  • Inconsistent application of security measures across different departments
  • Inability to demonstrate due diligence in the event of a security incident

Each of these represents a genuine business risk that could impact your organisation’s operations, reputation, or regulatory standing.

Thinking Beyond the Technical

One of the biggest mistakes I see organisations make is focusing their risk assessment purely on technical assets and threats. While protecting your servers and networks is crucial, Annex A controls address much broader organisational risks.

Take control A.6.7 (remote working), for example. The obvious risk might seem to be “laptops getting stolen” or “unsecured Wi-Fi connections.” But dig deeper, and you’ll find risks such as:

  • Blurred boundaries between personal and professional activities creating data protection issues
  • Difficulty monitoring and supporting remote workers, leading to security shortcuts
  • Family members or others gaining inadvertent access to confidential information
  • Challenges in maintaining company culture and security awareness when teams are widely distributed

Similarly, control A.8.9 (configuration management) isn’t just about keeping systems patched. The underlying risks include:

  • Unauthorised changes creating vulnerabilities or system instability
  • Lack of visibility into what’s actually running in your environment
  • Inability to quickly recover from incidents due to poor baseline documentation
  • Compliance failures when you can’t demonstrate what controls were in place at specific times

Making the Connection in Your Risk Register

So how do you ensure your risk register properly reflects these broader organisational risks? Here’s my recommended approach:

Start with business context, not controls. Before you even look at Annex A, understand your organisation’s key business processes, critical information assets, and strategic objectives. What could go wrong that would genuinely impact your ability to operate?

Map risks to multiple controls. A single risk often relates to several Annex A controls. The risk of “inadequate incident response capability” might connect to controls covering incident management, business continuity, supplier relationships, and staff training.

Consider the risk behind the risk. Don’t just identify what could happen; understand why it matters to your business. The risk isn’t “staff clicking on phishing emails” – it’s “unauthorised access to customer data leading to regulatory fines, reputational damage, and loss of business.”

Think about failure modes. For each critical business process or information asset, consider what could cause it to fail, become unavailable, lose integrity, or be disclosed inappropriately.

A Practical Example: Access Management

Let’s walk through how this works in practice with access management controls (A.5.15 through A.5.19).

Instead of starting with “we need access controls,” begin with the risks:

  • Former employees retaining access after leaving, potentially accessing confidential information or systems
  • Excessive privileges allowing staff to access information beyond their role requirements
  • Shared accounts making it impossible to track who did what, creating audit and accountability gaps
  • Weak authentication allowing unauthorised access through compromised credentials
  • Privileged access abuse by administrators or other high-access users

Each of these risks has clear business impacts – data breaches, compliance failures, fraud, or operational disruption. Your risk register should capture these impacts and their likelihood in your specific context.

The access management controls in Annex A then become your chosen treatments for these risks, and your Statement of Applicability explains which controls you’re implementing and why.

The Broader Benefits

When you approach risk mapping this way, several benefits emerge:

Better buy-in from senior management because you’re talking about business risks they understand, not just technical controls.

More targeted implementation because you understand what you’re actually trying to protect and why.

Clearer metrics and monitoring because you can measure whether your controls are actually reducing the risks you’ve identified.

More effective audits because you can demonstrate the thinking behind your control choices.

Getting Started

If you’re working on ISO 27001 implementation or reviewing your existing risk management approach, consider these questions:

  • Does your risk register include organisational and process risks, or just technical ones?
  • Can you clearly explain the business impact of each risk you’ve identified?
  • Do your chosen Annex A controls directly address the risks in your register?
  • Would a non-technical senior manager understand why each risk matters to your organisation?

Remember, ISO 27001 isn’t about implementing every possible security control – it’s about understanding your risks and choosing appropriate treatments. When your risk mapping properly addresses the organisational context behind Annex A controls, you’ll have a much stronger foundation for both compliance and genuine security improvement.

Need help mapping your organisational risks to ISO 27001 requirements? I work with businesses across various sectors to develop risk management approaches that work for their specific context and compliance needs. Get in touch to discuss how we can strengthen your information security foundations.