ISO Requirement for Risk Acceptance

Question

ISO seems to suggest that there needs to be a risk initial/residual exposure threshold where, if exceeded, there needs to be evidence of "acceptance" by someone with approved authority. The ISO auditor opined that a data element could be established in the risk log that would explicitly show a risk was accepted and by whom.

In my current risk process, I do not have such an explicit data element and, in my view, it is unnecessary. My view is based on this: if we were to follow the evolution of a risk event, it seems acceptance is implied. Here's why:

All risks derive from the uncertainty of probable hazards. Before the hazard is put into play, i.e., we engage in the hazardous activity, we are not at risk of loss. It is just a hazard.

At this point, based on our measured or perceived exposure, we either accept the risk and engage in the hazardous activity or we avoid the risk and do something else. If we have engaged in the activity, putting the hazard into play, then we have accepted the risk. Because of this logic, what value does a data element to explicitly report ACCEPTANCE provide?

ISO further states that, after risk handling, if the residual risk exposure remains higher than some stated risk tolerance or capacity level, the risk once again needs "acceptance" approval. However, even after risk treatment if the exposure remains high, and we continue with the hazardous activity, then risk acceptance is obviously implied. Again, what value does a data element explicitly showing acceptance provide?

If the residual risk is unacceptable for the organization, then the risk handling becomes "avoidance" and the activity stops and the risk exposure drops to zero.

If my logic is sound, do I have a nonconformance with ISO standards? The fix is rather easy but I am concerned that it will cause the risk teams to underestimate the risk exposure in order to avoid obtaining some type of official acceptance that is already there.

Answer 1

TL;DR

Auditing or security questions might be more answerable on Information Security Stack Exchange, but it's also on topic here on PMSE as risk registers are legitimately part of project management even though they often overlap with the information security domain. If meeting security requirements is fundamental to a successful project, then the question certainly belongs here, but ISO/IEC risk compliance or organizational risk acceptance criteria aren't generally things that a project manager ought to define without input from infosec, cybersecurity, or other stakeholders, so I would certainly engage with those folks as part of the project planning and execution phases.

ISO/IEC 27005:2012 doesn't actually contain the term "risk register" at all. However, careful reading of the document and a knowledge of related frameworks will show that documented risks and justifications for accepted risks are required by the standard, but you may need to refer to updated documents or secondary sources if you want to see that exact term. In addition, how and where you represent the risk acceptance isn't prescriptive in this version of the document, but there are strong reasons to keep them all within a single risk register when possible.

Foundational Advice

This is a complicated question in some ways, but quite easy in others. If you're speaking to specific ISO/IEC requirements, part of the issue is that many of the requirements documents are behind paywalls, so while I can certainly refer to some sections from an older copy of ISO/IEC 27005, if you're looking for more up-to-date citations you'll have to get copies of all the most recently published document versions, sub-documents, and related materials since ISO/IEC periodically updates its standards, and each standard often makes references to other documents within its standards portfolio (as you will see in the citation section I placed after this one).

Pragmatically, though, from a risk management perspective there are only three meaningful ways to handle risk:

1. Mitigate it.
2. Transfer it.
3. Accept it.

Some versions of ISO/IEC documents (re)define these industry-standard terms using their own nomenclature such as modification, sharing, and avoidance (among others), but they basically roll up to the same top-level things. Even if you have to conform to ISO/IEC standards for your audit, I strongly recommend using other frameworks and mappings such as the NIST Risk Management Framework (RMF) for additional guidance on how to meet the standards defined in the ISO/IEC documents.

Many open standards have explicit mappings from their framework to ISO/IEC standards. As just one example, NIST SP 800-53 Rev. 5 has a mapping document to ISO 27001 that you may find useful.

ISO/IEC 27005:2012

In this version of the Information Security Risk Management standard, section 10 covers information security risk acceptance. This section specifically states:

The decision to accept the risks and responsibilities for the decision should be made and formally recorded (this relates to ISO/IEC 27001:2005 paragraph 4.2.1 h))...[T]he decision maker should explicitly comment on the risks and include a justification for the decision to override normal risk acceptance criteria.

Since acceptance of residual risk that is higher than the organization's defined risk appetite must be formally recorded, it should be included in the artifact functioning as a risk register. Also note here the requirement to include the acceptance with justifications within the artifact. Since the output from this section is:

A list of accepted risks with justification for those that do not meet the organization’s normal risk acceptance criteria.

you can consider this part of the risk register, although 27005:2012 doesn't explicitly call it that.

Taking it a step further, any good auditor will tell you that decision-making authority is itself an auditable item that must be delegated through traceable artifacts, so failing to provide some sort of traceability within the risk register itself would likely raise flags.

Pragmatic Advice About Artifact Consolidation

To put it another way, the ISO/IEC standard is basically just saying that accepting a risk outside of the pre-approved risk acceptance criteria has to be formally documented by someone with decision-making authority. While you could theoretically pepper your risk artifacts with references to other documents and artifacts, or split up your various risk-management artifacts (e.g. documented risk assessment criteria, documented risks, and documented justifications), the auditors will ultimately need to be able to map and trace them all. With that in mind, even if it's not called out in one of the related standards it's simply more pragmatic to have the risk acceptance criteria, identified risks, and risk disposition (including justifications for acceptance of inherent or residual risks) in a single artifact such as a risk register.

Unless you have a competing requirement, or just enjoy having to walk auditors through a more complex set of artifacts and risk management processes, I'd strongly recommend keeping all of the risk management items as consolidated as possible. It will make your life easier in the long run, and when done right will likely result in fewer clarification requests from the auditors.