3.7 KiB
Ideas on Risk Ownership
As far as conformity with '27001 goes, risk owners must be identified within the information security risk assessment process as per 6.1.2 c) 2), and risk owners must approve risk treatment plans and acceptance of residual risks as per 6.1.3 f).
However, 27001 does not specify how they are to be identified, nor what their obligations or expectations might be beyond those noted in 6.1.3 f).
So, aside from that, we have the discretion to do whatever works best for our organisations - perhaps formally define the role, nominate people or functions or departments, prepare a policy and procedure, or whatever we like really. Or not: remember that if you have a policy or procedure within your ISMS, you are naturally expected to do what it says, consistently. So, be careful with the wording, operation, oversight and assurance.
This is a governance matter for senior management. It is tricky for anyone other than them to insist that workers (including management generally) do anything, especially if it means they are personally accountable for any failings, and implies giving them the authority and resources to 'make it so'.
ISO/IEC 27005 defines 'risk owner' succinctly as the “Person or entity with the accountability and authority to manage a risk”, summing it up nicely. ISO 27005:2022 Clause 3.1.5: risk owner = person or entity with the accountability and authority to manage a risk
I define 'risk owner' as the "Organisation, rôle or person who notionally ‘owns’ and may be held to account if a risk eventuates, causing unacceptable impacts, on the basis that they patently failed to ensure it was adequately treated e.g. mitigated with controls. As the explicit or implicit owner of residual risk, they also have an interest in the incident management and business continuity arrangements." By the way, 'risk owner' is just one example or application of the general concept of 'ownership'. Some others include: asset owner, control owner, data owner, information owner, infrastructure owner, network owner, process owner, system owner, service owner and problem owner. SImilar considerations can apply to them all, particularly the ideas that the nominal owners should be (a) trusted agents or custodians for the true legal owners, acting on their behalf and protecting their interests; and (b) personally accountable for the associated decisions, actions or inactions etc., motivating them to achieve the true owners' expectations or requirements.
In specifying your ISMS-related governance arrangements, I would caution against going too far beyond the standard's requirements unless:
(a) you have good business reasons for doing so,
(b) management is fully aware of and agrees to the arrangements including the implications on resourcing, oversight, roles and responsibiltiies, accountability etc., and
(c) you are prepared to ensure that the arrangements are actually going to be used consistently as specified - in order to avoid nonconformities being raised by the auditors.
Hinson tip: using weasel-words such as "as appropriate", "if justified" or "should" rather than "shall" or "must" in your strategies, policies and procedures leaves a little room for management discretion to cope with particular circumstances, and yet still conform. Reserve the "shalls" and "musts" for those situations where there really is absolutely no choice (although, even there, you may have a mechanism for management to authorise specific exemptions, explicitly accepting the associated risks). This approach also leaves you some leeway to adjust the management controls later, tightening or relaxing them based on experience - all part of ISMS maturity.
Kind regards/Ngā mihi, Gary