Speed up risk assessment, treatment and SOA production

Sufficiency of the chosen event scenarios

The purpose of the ISO/IEC 27001 risk assessment and risk treatment requirements is to determine your necessary controls. The SOA requirement is to compare your necessary controls so determined with those in the reference of controls in ISO/IEC 27001, Annex A.

Early research work by Brewer and Nash showed that Annex A controls can be mapped onto a few event scenarios. Thus, consideration of just those event scenarios (referred to as the “standard set”) guarantees that a comparison of the necessary controls I.e., those that the organisation has determined as being necessary to mitigate those risks with the Annex A controls will not detect any necessary control that has been inadvertently omitted (because each Annex A control is used in the event scenarios at least once).

Recent research has confirmed that the control set, which is the third editions of ISO/IEC 27001 and 2, best maps onto the nine event scenarios.

As pointed out in BS 7799-3:2017“Information security management systems — Part 3: Guidelines for information security risk management (revision of BS ISO/IEC 27005:2011)”, Clause 7.2.2, page 13, which states: “If a new scenario fails to identify any additional necessary controls, it is redundant.”, there is no need to consider additional scenarios as they will not determine any Annex A control that has not been considered already. Therefore, these event-scenarios are sufficient for the purposes of ISO/IEC 27001 risk assessment.

Sufficiency of the SOA processes

Performing the comparison

Typically, organisations consider each Annex A control in turn. If they do something like was it says, they mark it as applicable and declare it as such in their SOA. If they don’t do it (and assuming that this result doesn’t identify an overlooked necessary control), then they declare it in their SOA as being not applicable and justify the exclusion as required by ISO/IEC 27001. The structure of their SOA follows that of Annex A.

Unfortunately, if they do not do exactly what it says in Annex A for the controls they have marked as applicable, they can be given a nonconformity in a certification audit. This is because the requirement is to include the necessary controls in the SOA, not to identify applicable Annex A controls.

The safest approach is to use the variation device described in ISO/IEC 27007“Guidelines for information security management systems auditing”, Clause A.4, page 12: if one does something like what it says in Annex A, write down exactly what you do, declare it as a necessary control in the SOA and associate it with that Annex A control.

Moreover, it is also prudent to consult the guidance text in ISO/IEC 27002 as the control specifications in ISO/IEC 27001, Annex A are just summaries and sometimes fail to capture important control characteristics.

Reversing the process

The introduction to ISO/IEC 27001 states that requirements can be performed in any order. Why not then reverse the order of Clauses 6.1.3 b) and c), i.e., use the comparison process to determine the necessary controls?

For this to work:

• The standard event-scenarios are mapped to a set of questions, which in turn map to the reference controls (e.g. the Annex A controls). The mapping of Annex A controls to event-scenarios is preserved, thus preserving the guarantee of event scenario sufficiency for risk assessment.
• The questions are derived from the ISO/IEC 27002 control guidance as well as the ISO/IEC 27001, Annex A control descriptions and objectives.
• The permitted answers to these questions are:

1. Yes: the statement form of the questionFor example: the statement form of the question “Does the organisation do X?” is “The organisation does X”. is used as the specification of the necessary control in the SOA;
2. Similar: replace the question with a similar question to which the answer is “yes” and use the statement form of the replacement question as the specification of the necessary control in the SOA;
3. No: if the question corresponds to an Annex A controlThe book and SAAS use a reference control set that is a superset of the current Annex A controls. If the answer to a question that relates to a new edition control, is “no” then there is no requirement to include the rationale in the SOA, ask why, and use the answer as the rationale for excluding that Annex A control in the SOA.

Generation of risk treatment plans

The risk treatment plans (RTP) are constructed using the statement forms of the questions used to generate the necessary controlsI.e., those answered “yes” and “similar”. In the case of “similar”, the statement form of the replacement question is used. in the SOA. The questions are mapped not only to the appropriate event scenario, but also to its position in the RTPI.e., prevent, detect. or react, and even the order of presentation so that the RTP reads well. Users of the SAAS can make adjustments to such text if they wish..

The risk assessment answers are used to generate the inherent risks. A similar set of questions and answers facilitate the determination of the residual risks. Risk treatment plan generation is thereby automatic.

Conclusion

The SOA is constructed from the answers to questions that map to all the controls in the reference set, which in turn are mapped to the event scenarios and their positions in the corresponding RTPs. Inherent and residual risks are determined by the answers to other questions pertinent to the event scenario and the necessary control text. Thus, all that is needed to perform the ISO/IEC 27001 risk assessment and risk treatment processes, and produce the SOA is the standard events specification, reference control set specifications, questions, and the instructions given in the book and automated in the SAAS. Why not give it a try?