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.
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:
- Mitigate it.
- Transfer it.
- 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.
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.