ISO 27001 risk management: connecting information security and enterprise risk

ISO 27001 risk management: how information security and enterprise risk connect

Most organisations that pursue ISO 27001 certification treat it as an IT compliance exercise. The IT team handles it. The Information Security Management System (from here on, the "ISMS") lives in a SharePoint folder. The risk register is a spreadsheet maintained by someone in infrastructure. And the broader business risk programme, run by the operations or quality team, carries on without ever referencing it.

That is a fundamental misreading of what ISO 27001 actually requires, and it creates exactly the kind of blind spots that turn manageable incidents into serious ones.

ISO 27001 risk management is not a checkbox for auditors. It is a structured, repeatable process for identifying, assessing, treating, and monitoring information security risks. Critically, it is designed to connect to your wider enterprise risk picture, not sit apart from it.

This article explains how ISO 27001's risk management process works, how it relates to ISO 31000 and ISO 27005, and how to stop running two separate risk programmes when one integrated approach would serve you far better.

What ISO 27001 actually requires on risk

ISO 27001 is a certifiable standard for Information Security Management Systems. It specifies what an organisation must do to establish, implement, maintain, and continually improve its approach to managing information security risks.

The risk management requirements sit in two clauses.

Clause 6.1.2 (Information Security Risk Assessment) requires you to define and apply a process that identifies information security risks, assigns owners to those risks, analyses them by likelihood and impact, and evaluates them against your defined risk acceptance criteria. The scope is explicitly the CIA triad: confidentiality, integrity, and availability of information.

Clause 6.1.3 (Information Security Risk Treatment) requires that once risks are assessed, you select appropriate treatment options. ISO 27001 offers four: modify the risk (apply controls), avoid it, share it (through insurance or outsourcing), or accept it. Your chosen controls must be documented in a Statement of Applicability (explained further below), which maps your controls to Annex A and records why each is included or excluded.

Notice what is not prescribed here. ISO 27001 does not tell you to use a specific scoring method, a particular likelihood scale, or a fixed set of risk categories. It requires a consistent, documented process, not a particular template. That flexibility is deliberate. It allows the standard to align with whatever enterprise risk management methodology an organisation already uses.

The standard ISO 27001 references and most organisations ignore

Here is something most ISMS documentation fails to mention: ISO 27001 explicitly references ISO 31000.

ISO 31000 is the international standard for enterprise risk management. It is non-certifiable (you cannot get an ISO 31000 certification), but it provides the overarching principles and framework for managing any type of risk across an organisation. ISO 27001 states that its risk assessment and treatment requirements are aligned with ISO 31000.

That alignment is intentional and consequential. It means your information security risk management process is not supposed to be a separate methodology running on different principles. It is supposed to follow the same logic, terminology, and process structure as your broader risk management approach.

ISO 31000 also addresses areas that ISO 27001 does not touch directly: risk governance structures, the role of leadership in setting risk appetite, and how to embed risk thinking into strategic decision-making. Those elements are the scaffolding that makes ISO 27001's requirements meaningful at a business level rather than just a technical one. For a deeper look at how ISO 31000 applies in practice, our article on ISO 31000 in practice and what the standard actually delivers covers the gaps between the standard's intent and how organisations actually use it.

In practice, most organisations do not realise the connection exists. They run their ISO 27001 programme and their enterprise risk management programme in parallel with different scoring scales, different owners, and no shared governance. That is a structural problem that better documentation alone cannot solve.

Where ISO 27005 fits in

If ISO 31000 is the overarching framework and ISO 27001 is the certifiable standard, ISO 27005 is the practical methodology guide.

ISO 27005 is a supporting standard that provides detailed guidance on how to conduct information security risk assessments and risk treatment within the context of an ISO 27001 programme. It covers how to identify assets and their vulnerabilities, how to identify relevant threats, how to estimate likelihood and impact, and how to select and document treatment options.

ISO 27001 requires a risk assessment. ISO 27005 tells you in detail how to do one properly. If your current information security risk process feels vague or inconsistent (if different people assess similar risks differently, or if your risk register lacks a clear rationale for the scores) ISO 27005 is where the rigour comes from.

You do not need to formally adopt ISO 27005 to benefit from it. Reading it alongside ISO 27001 gives your risk assessment process a level of methodological depth that purely template-based approaches typically lack.

The two problems this creates in practice

We see this confusion play out in two distinct ways, both of which are worth naming clearly.

Problem one: the information security silo. An organisation has ISO 27001 certification. The IT manager maintains the information security risk register, which contains 30-odd risks assessed against a likelihood-impact matrix. The operations director maintains a separate risk register covering safety, operational continuity, supplier risks, and regulatory exposure. The two documents have never been reconciled. Nobody has ever asked whether a risk in one register creates or amplifies a risk in the other.

The consequences are predictable. When a ransomware attack hits, the IT team escalates through the incident process defined in their ISO 27001 programme. But the operational impact (production downtime, customer service-level agreement breaches, supplier notifications) is managed by a completely different team using a completely different framework. The response is fragmented because the risk picture was fragmented.

Problem two: enterprise risk management without information security. An organisation builds an enterprise risk management programme from scratch. They categorise risks as operational, financial, strategic, compliance, and reputational. Information security risks are nowhere in the taxonomy, or they are bundled vaguely under "IT risk" without the structured assessment that ISO 27001 would bring. The programme looks comprehensive on paper but is not.

Consider a logistics company with 200 employees that implemented ISO 27001 for a customer contract requirement. Their programme was thorough: 28 controls documented, risks formally assessed, Statement of Applicability in place. But their wider risk register, reviewed quarterly by the leadership team, contained a single line item: "IT system failure — likelihood 2, impact 4." That single line represented a risk universe their ISO 27001 process had assessed at 28 separate entries with distinct owners and treatment plans. Leadership had no real picture of their information security exposure.

Information security risk is not a subset of IT risk

This is the counterintuitive point that most organisations miss.

Information security risk is not the same as IT risk. IT risk is typically about system reliability, infrastructure availability, and technical failures. Information security risk is about threats to confidentiality, integrity, and availability of information, which extends far beyond the IT department.

A rogue employee sharing a customer database with a competitor is an information security risk. A paper-based process where contracts are left on a shared desk is an information security risk. A supplier with access to your systems who has inadequate controls is an information security risk. None of these are purely IT problems, and all of them need to sit in a risk framework that the right people across the organisation can see and act on.

When information security risks are filed under "IT" and managed only by the IT team, the ownership problem becomes obvious. The person responsible for supplier management is not monitoring the IT team's risk register. The HR manager is not checking the information security documentation for risks related to employee data handling. The silos ensure that the risks with the highest cross-functional exposure are managed by the people with the narrowest view of them.

How integration actually works

Integrating ISO 27001 risk management into your broader enterprise risk programme does not mean dismantling your ISO 27001 programme. It means connecting the outputs.

A practical integration looks like this. Your ISO 27001 programme continues to operate as required. Clause 6.1.2 assessments are conducted on schedule, typically annually or when significant changes occur. Risks are assessed against the CIA triad using a consistent methodology. Treatment plans are documented and owners are assigned.

The significant information security risks (those above your defined risk acceptance threshold) are then elevated into the organisation's main risk register. They are represented using the same format, the same scoring approach, and the same owner accountability structure as operational, financial, and strategic risks, and reviewed by the same governance forum.

Lower-level information security risks that are being actively managed through your ISO 27001 programme can remain within that documentation without cluttering the enterprise register. The principle is that anything with material business impact needs board and leadership visibility, regardless of which management system identified it.

This is what ISO 27001's alignment with ISO 31000 is designed to enable. The ISO 27001 programme provides the detailed methodology for identifying and managing information security risks. The enterprise risk framework provides the governance structure for escalating, reporting, and making decisions about them.

What a shared risk register enables

When information security risks live in the same risk register as operational and strategic risks, something important becomes visible: the interactions between them.

A supplier concentration risk in the operational register and a third-party access control risk in the information security assessment are related. A strategic risk around digital transformation and an information security risk around shadow IT are related. When they are managed separately, the relationship is invisible. When they share a register, a risk-aware manager can see that two risks in different categories are amplifying each other and address both.

Risk Companion's risk register is built for exactly this kind of integration. Every risk, regardless of category, gets an owner, a probability score, an impact score, and linked measures. You can run information security risk assessments using the same structured approach your operational team uses for safety or compliance risks. The dashboard gives leadership a single view across all categories, without requiring a separate system or a separate process.

The risk assessment process in Risk Companion supports the structured identification and evaluation that ISO 27001 Clauses 6.1.2 and 6.1.3 require, without forcing your information security risks into a silo that disconnects them from the rest of your risk picture.

The Statement of Applicability: misunderstood and underused

One ISO 27001 requirement that deserves more attention in an enterprise risk context is the Statement of Applicability, commonly abbreviated as the SoA.

The SoA is a document that records which of Annex A's controls your organisation has selected, which it has excluded, and the justification for both decisions. Most organisations treat it as an audit artefact: something produced to satisfy the certifying auditor, filed, and rarely revisited.

The SoA is actually a direct expression of risk appetite. When you exclude a control, you are saying that the risk it addresses is within your acceptance threshold. When you include a control, you are committing resources to risk treatment. Those are business decisions, not technical ones, and they should be made with input from leadership rather than left solely to the IT team.

An integrated approach treats the SoA as a living document that reflects current risk appetite decisions, revisited whenever the risk landscape changes significantly. For organisations pursuing both ISO 27001 certification and broader risk maturity, the SoA is a useful bridge: it translates the technical language of information security controls into the business language of risk acceptance.

ISO 27001 vs ISO 31000: not a competition

A question that comes up often in organisations building an enterprise risk management programme: do we need both?

The short answer is yes, if you want ISO 27001 certification and a credible enterprise risk programme. But they are not in competition.

ISO 31000 gives you the principles and framework for managing risk across the organisation. It covers risk governance, risk culture, and how risk thinking integrates into strategic decision-making, including who owns the risk management process, how risk appetite gets set at board level, and how to make risk reporting useful rather than ceremonial.

ISO 27001 gives you a certifiable standard for managing information security specifically. Its risk management process must be rigorous, documented, and repeatable, and when done well it produces exactly the kind of output that an enterprise risk programme can absorb.

The practical test is this: can your information security risk assessment produce outputs that your enterprise risk register can consume? If the answer is no, the problem is not the standards. It is the implementation.

Understanding how the broader risk management cycle works across all risk types helps clarify where your ISO 27001 risk process fits and where the handoffs to enterprise governance should happen.

Where to start if you have a silo problem

If you recognise your organisation in the silo description above, the fix is less complicated than it sounds.

Start with an honest comparison. Put your information security risk register and your enterprise risk register side by side. Identify where the same underlying risk appears in both, under different names or in different formats. Identify what is in your ISO 27001 documentation that leadership has never seen. That gap is your starting point.

Then agree on a common methodology. Likelihood and impact scores should mean the same thing whether they are applied to an information security risk or a supply chain risk. If they do not, your risk assessments are not comparable, and your reporting to leadership will always be misleading.

Finally, agree which risks need enterprise-level visibility. Not every information security risk needs to appear in the board risk register. Any risk that could materially affect operations, customers, regulators, or reputation does, regardless of where it was identified.

The compliance features in Risk Companion support ISO 27001 and broader compliance requirements within a single framework, so you are not maintaining separate tools for separate standards. That is the structural enabler that makes integration sustainable rather than a one-off reconciliation exercise.

One register, one framework, one picture

The organisations that manage information security risk well are not the ones with the most elaborate ISO 27001 documentation. They are the ones where information security risk is treated as a real business risk, owned, reviewed, and acted on by people with the authority to do something about it.

That requires integration. ISO 27001 provides a rigorous methodology for the information security subset of enterprise risk. ISO 31000 provides the framework for everything else. ISO 27005 provides the methodological depth that makes risk assessments credible. None of them work as well in isolation as they do together.

Your risk register should have one version of the truth. Confidentiality, integrity, and availability risks belong there alongside operational, financial, and strategic risks, assessed consistently, owned clearly, and visible to the people making decisions. Treating them as a separate programme is risk management theatre.

Ready to bring your information security risks into the same framework as the rest of your risk programme? Book a 30-minute demo to see how Risk Companion handles it.