The sadly neglected Risk Treatment Plan (LONG)

For some curious reason, the Statement of Applicability steals the limelight in the ISO27k world, despite being little more than a formality. Having recently blogged about the dreaded SoA, 'nuff said on that.

Today I'm picking up on the SoA's shy little brother, the Risk Treatment Plan. There's a lot to say and think about here, so coffee-up, settle-down, sit forward and zone-in.

ISO/IEC 27001 barely even acknowledges the RTP. Here are the first two mentions, tucked discreetly under clause 6.1.3:

Hmmm. But wait, there's more:

... and, hiding in plain view under clause 9.3 is the final, almost casual mention:

Having studied those four statements, what do you think the RTP is intended to look like? There's not exactly a lot to go on there! Even within the context of the standard, it's still somewhat unclear, verging on cryptic.

Luckily for us and the certification auditors, there's more helpful advice elsewhere.

ISO/IEC 27003 offers a page of 'guidance on formulating an information security risk treatment plan (6.1.3 e))', which I won't quote in full but summarise and critique here:

The RTP documents the outputs from '27001 clause 6.1.3 a) through c) ...

... meaning the selection of 'appropriate information security risk treatment options' and a check against Annex A to 'verify that no necessary controls have been omitted';

Even with the '27001 corrigendum, the revised wording of this clause remains problematic and contradictory, implying that Annex A is at once both a complete ('comprehensive') and an incomplete ('not exhaustive') list of possible/suggested/recommended/required controls;
Users and auditors of the standard may disagree on their interpretations of the requirement, leading to tears at bed time;
The forthcoming new edition of ISO/IEC 27001 improves but may not totally resolve the ambiguity. We'll see.

For each [identified, evaluated and] treated [information] risk, the RTP records the:

Selected treatment option(s);

Presumably meaning that the RTP should state, for every identified risk, that it is to be avoided, mitigated, shared and/or accepted;
An example in the standard mentions that a control may 'change the likelihood, or change the consequences of the risk' - as if that helps! Is that another aspect also to be recorded in the RTP or an alternative to avoid/mitigate/share/accept?;
Since risks cannot be totally eliminated in practice, some residual risk is inevitable and must be accepted - so should that be recorded against every single risk, or against a separate high-level entry for 'risks relating to the ISMS and risk management process'?

Necessary control(s);

Where both 'controls' and 'necessary' are decidedly ambiguous.
'Controls' is generally taken to mean something similar to those in '27001 Annex A - basically a set of succinct one-liners rather than detailed descriptions such as the page or so expanding on each 'control' in ISO/IEC 27002;
'Necessary' generally means something like 'relevant, appropriate and hence a valuable means to mitigate one or more unacceptable information risks' - unless a jobsworth auditor doggedly insists that every single control in Annex A (and perhaps others of his/her own invention) is 'necessary' until he/she can somehow be convinced otherwise.

Implementation status.

Yet another ambiguous phrase!
The wording implies a neat binary measure i.e. each control is either implemented or not implemented.
Things are not always so clear-cut in practice, more analogue than binary with controls being partially implemented, in the process of being implemented, in the process of being retired/removed, of uncertain status etc.
Plus there's the added question of whether even fully implemented controls are in fact effectively mitigating the risks as intended: are they in use, active, working properly, generating value for the organisation and earning their keep?
How would anyone determine that, or gain assurance?
There's a naughty little cluster of potentially nasty concerns lurking behind 'implementation status' which the standards, and the RTP, largely ignore, presumably for the sake of the poor certification auditors who are expected not just to interpret the language but use it to test for conformity.

'27003 tells us the RTP can include other useful content i.e.:

Risk owner(s);

Casually hinting at what can be a very useful governance approach and risk management mechanism - except the hint is so subtle as to be easily overlooked. ISO/IEC 27000 defines risk owner as a "person or entity with the accountability and authority to manage a risk" - one of the precious few ISO27k mentions of accountability; and

Expected residual risk after the implementation of actions.

Errrrr, how are we meant to state this in the RTP? Obviously, we expect risks to be mitigated (reduced) or stabilised by the controls, but by how much?
What if the residual risk is still unacceptable - what then?
What if the residual risk remains uncertain, just as the true implementation status is uncertain?
What if the presumption that a control is 'maintaining' the risk turns out to be unfounded?
There are fundamental problems here due to the very nature of 'risk'.

'27003 even indicates/suggests a tabular format and content of the RTP:

The word 'plan' in RTP clearly implies an intention to treat identified and evaluated information [security] risks at some future point ... but:

When? Who? How? In what manner? To what extent?
If the 'plan' is, in reality, merely a vague suggestion with no real substance to it, no resources, no schedule, no management approval etc., does it have any credibility at all?
Even if there is a budget line item, an initiative, a project, a to-do list or whatever, it is still just a plan: jam tomorrow. Free beer next week. Trust me, nirvana is just around the corner - or, as we Kiwis say, "She'll be right", sometimes followed by "Yeh, right".
Is it reasonable for the RTP to state that a significant and patently unacceptable information risk is to be accepted and not mitigated for, say, at least a year? Technically, if that's what management decides having followed the proscribed risk management process, the certification auditors' unease is not sufficient grounds for raising a nonconformity.
The ISMS management reviews, internal audits, certification and surveillance audits could usefully check progress against the RTP, hopefully generating assurance that the RTP is actually being executed and completed more or less as intended except that is presently neither suggested or required by the standards, unfortunately - an opportunity lost, I say. Yes, I appreciate it would be tricky to specify the requirements and could lead to yet more effort and expense on assurance, but the focus and pressure on putting plans into action and meeting deadlines would be worthwhile IMNSHO.

As to other standards:

The current 2018 release of ISO/IEC 27005 doesn't even mention RTP - not once! Even 'risk treatment' only appears twice, in an annex quoting from ISO 31000 (see below).
In stark contrast, the forthcoming new 2022 edition of '27005 offers a much more sensible 2½ pages of RTP advice, mostly under clause 8.6.

The purpose of formulating the RTP is 'to create plan(s) for treating specific sets of the risks that are on the list of prioritized risks'.

Hmmm, that's a bit self-referential and, anyway, what are those 'specific sets of the risks' and how are risks prioritised? Subclause 7.4.2 refers to prioritisation as 'considering assessed levels of risks' which sort of makes sense. Although I haven't spotted any mention of those 'specific sets of the risks' in '27005, ISO/IEC 27007 talks of mitigating some risks with sets of related controls: maybe that's a clue - or is that a separate concern?

The RTP is 'a plan to modify risk such that it meets the organization's risk acceptance criteria'.

Fair enough, although the standard doesn't actually explain how those risk acceptance criteria might be determined/specified by the organisation.

The implementation guidance under '27005:2022 subclause 8.6.1 will include this gem:

Nicely put! 'Design plan' hints at the organisation having developed an information risk and security architecture. Good move, although personally as a fan of security engineering I'd have preferred an explicit mention and further guidance on that.

The expansive German infosec standard IT-Grundschutz talks of the RTP in terms of a project plan.
ISO 31000 describes risk treatment in clause 6.5 as involving 'an iterative process of:

Formulating and selecting risk treatment options;
Planning and implementing risk treatment;
Assessing the effectiveness of that treatment;
Deciding whether the remaining risk is acceptable;
If not acceptable, taking further treatment.'

Such iterations have implications for the RTP. For one thing, it should be seen as a dynamic, flexible, living plan showing a bunch of things currently in progress as well as those yet to start and perhaps those already completed. After due analysis and consideration, information risk and security-relevant changes (such as novel threats or attack modes, newly-disclosed vulnerabilities and new legal, regulatory or contractual obligations) may well require updates to the RTP (e.g. adjusting the relative priorities, resourcing and deadlines for planned activities). Any reviews or audits, therefore, should not expect or require the RTP to be static or complete. Some latitude is appropriate. Loose ends are likely to be dangling.
Potentially every treatment for every identified information risk needs to be formulated, selected, planned, (approved, funded and) implemented, assessed (somehow) for 'effectiveness', and evaluated, then sent back around the loop if the residual risk is unacceptable. For just about any organisation, that's an enormous amount of planning and work if done thoroughly ... which, arguably, is appropriate given that, in theory, even small gaps or weaknesses in our information security arrangements render us liable to incidents. In practice, however, it is unreasonable to expect such a thorough, detailed approach. Most managers would consider it red tape, not cost-effective and hence inappropriate and unjustified. A more realistic business-like approach involves prioritising the more significant risks with higher probabilities and/or impacts for detailed analysis and explicit treatment, while tackling lesser risks by other means such as generic/baseline security controls plus incident management and business continuity arrangements to cope with any incidents that do occur if and when residual risks materialise.

Section 6.5.1 of '31000 offers further useful guidance on the RTP:

That's a lot more detail than most RTP's I've seen or written so far, more akin to a project or program plan - suggesting that organisations could simply use their usual project/programme management methods rather than an RTP, at least for the initial ISMS implementation phase.
Once the ISMS is operational, I'm not convinced something called an RTP would add value to the routine, iterative information risk management activities aside from satisfying the requirement of the standard and the conformity assessment criteria. So, as far as I'm concerned, feel free to stamp "RTP" on whatever risk management documents you currently use!
That still leaves open the possibility of developing an RTP of the other kind mentioned in the forthcoming fourth edition of '27005, namely a 'design plan' or security architecture. Now that's an intriguing thought ...

OK, that's enough for today. I'm done. Topic discussed. Grey matter stimulated. Axes ground and honed to a razor's edge. Time to get outside and enjoy the first matariki public holiday here in NZ. Mind you, I'm tempted to prepare a guideline about the SoA and RTP, supporting the existing templates and elaborating on the security architecture, for the SecAware ISMS toolkits - maybe next week.