Transition arrangements for ISO/IEC 27001

Last week's release of a completely restructured ISO/IEC 27002:2022 has naturally prompted a rash of questions from anxious ISO27k users around the world about the implications for ISO/IEC 27001:2013, particularly around certification since '27002:2022 no longer aligns with '27001:2013 Annex A.

The situation, today, is that ISO/IEC 27001:2013, plus the associated accreditation and certification processes, remain exactly as they were:

• 
  Organisations that choose to adopt the standard are required to use Annex A of '27001:2013 to check that they have not accidentally neglected any relevant/necessary information security controls, documenting the associated justified decisions to include/exclude the controls in a Statement of Applicability.
• Accredited certification bodies are required to confirm that clients comply with the mandatory obligations in '27001:2013, including that SoA requirement among others, both during the initial certifications and any subsequent interim audits and re-certifications.

In other words, it's business as usual ... but looking forward, there are of course changes afoot.

A formal amendment to ISO/IEC 27001:2013 is currently being prepared:

• A draft of the amendment is already available through ISO if you can't wait for it to be finalised and released.
• The draft amendment essentially replaces Annex A with an equivalent that references and summarises the controls from ISO/IEC 27002:2022. It is likely to retain the succinct tabular format of the original Annex A i.e. it will reference each control by its '27002:2022 clause number prefixed with "A." (for Annex A), then state the control's title, followed by a single sentence outlining the control. As before, it will not elaborate on that outline: readers should consult '27002 for the supporting explanation and implementation advice - typically half a page of detail per control - and/or look to other sources of guidance, of which there are many.
  
• There may also be minor wording changes in the main body clause about the SoA, specifically in the notes for clause 6.1.3. More specifically: 
• Note 1 may drop the word 'comprehensive' since Annex A is patently not a totally comprehensive list of information security controls. The very fact that '27002:2022 adds 11 new controls puts the lie to that. This change underlines the point that organisations may need controls not even outlined in Annex A or described in '27002:2022.
  
• Notes 1 and 2 may drop references to 'control objectives'. Those have been morphed into 'control purposes' in '27002:2022. Moreover, it has been claimed that some users of the standard struggle with the very concept that information security controls are intended to achieve something useful for the business [! Personally, I feel it is a shame to have dumbed-down the standard and further weakened the link between information security controls, information risks and information of value to the business ... but it was a committee decision, not mine.]
  

The release of that amendment will formally trigger the process of revising the direction given to certification bodies by their accreditation bodies about how to audit clients to the amended standard - including, I anticipate, guidance on the transitional arrangements for clients who are seeking or maintaining certification against ISO/IEC 27001:2013 - either with or without the amendment. Previously, similar changes have led to a grace period of up to two years, hence organisations may be able to continue using the original Annex A as the basis of their SoA for some while. Meanwhile, they can, as at present, use '27002:2022 or other control catalogues for inspiration if they feel other controls are appropriate or necessary to mitigate unacceptable information risks. Again, nobody is required to use the Annex A controls, nor are they constrained by it. That key point will not be affected by the changes ahead [unless something dramatically changes, which I doubt.]

 

Strictly speaking, there is nothing to stop organisations stating in their SoAs that NONE of the ISO/IEC 27001:2013 Annex A controls are applicable, justifying that extreme position "because the reference standard ISO/IEC 27002 has been updated" (or words to that effect) ... but if so, they should still anticipate the need to convince the certification auditors that they have, in fact, duly considered all the Annex A controls but chose to adopt others (e.g. those from '27002:2022 and/or other sources) to mitigate unacceptable information risks.

The situation is a bit messy because ISO does not formally get involved in accreditation and certification: there is a deliberate division of responsibilities between generating standards and certified compliance, apart from ISO's Conformity Assessment Committee that bridges the gap. The accreditation bodies take their direction from the International Accreditation Forum. So, if this blog piece leaves you confused over the transitional arrangements, I suggest contacting your national accreditation body or certification body, or the IAF (not me, not ISO!) for more details.

 

Certification and SoA aside, I recommend using ISO/IEC 27002:2022 as one of several sources of good security practices. The latest revision to '27002 brings it bang up to date, as much as a formal product from a busy international committee can ever be cutting-edge anyway! If you are into, say, IoT or AI, you should look elsewhere for additonal information security guidance. For the rest, though - the basics - '27002 does very nicely thank you.

ISO/IEC 27002 update

The newly-published third edition of ISO/IEC 27002 is a welcome update to the primary ISO27k controls catalogue (officially, a 'reference set of generic information security controls'). 

Aside from restructuring and generally updating the controls from the 2013 second edition, the committee (finally!) seized the opportunity to beef-up the coverage of information security for cloud computing with new control 5.23, plus ten other new controls, mostly in section 8 (technological controls): 

• Configuration management (8.9) - concerns the need to manage security and other configuration details for [IT] hardware, software, [information] services and networks.
  
• Data leakage prevention (8.12) - DLP is required to protect sensitive information against unauthorized disclosure/extraction (theft, surveillance).
  
• Data masking (8.11) - in line with the organisation’s access control policy, plus other business requirements and compliance obligations, scurity controls are apropriate to mitigate the risk of disclosing sensitive personal and proprietary information.
  
• ICT readiness for business continuity (5.30) - organisations need to prepare themselves to handle serious incidents affecting/involving critical ICT e.g. through disaster recovery.
  
• Physical security monitoring (7.4) - intruder alarms, CCTV, guards etc. for business premises [such a basic, commonplace control that I can barely believe it was missing from the second edition ...].
  
• Information deletion (8.10) - at face value, another 'obvious' control: data should of course be deleted when no longer required to prevent unnecessary disclosure and for compliance reasons.  The fine details, however, about how information gets deleted, matter in practice.
  
• Monitoring activities (8.16) - 'anomalies' on IT networks, systems and apps should be detected and responded to, to mitigate the associated risks.
  
• Secure coding (8.28) - software should be [designed and] coded securely, reducing the number and severity of exploitable vulnerabilities arising from [design flaws and] bugs. This control almost - but not quite - nailed the widely respected principle of 'secure by design'.
  
• Threat intelligence (5.7) - gathering relevant, actionable intelligence about threats to the organization's information, feeding it into the information risk management process.
  
• Web filtering (8.23) - limiting our access to inappropriate, unsavoury or plain risky websites is, apparently, an information security control important enough to warrant inclusion in the third edition.
  

We've been busy updating the SecAware ISMS templates such as the detailed security controls maturity metric/checklist:

Whether to check out and measure your own information security controls, or those of your partners, suppliers and prospective suppliers, the revised '27002 structure and advice is a rational basis for a review, assessment or audit - abeit with some supplementary criteria in a few areas (the resilience and contingency aspects of business continuity, for instance).

To supplement the extensive suite we already offer, we are currently finalising topic-specific policy templates on threat intelligence and data masking (details to follow).

The revised standard is weak on Internet of Things security - not surprising really given that the field is so immature, the IoT things proliferating so quickly and the technology so limited in terms of processing, storage and other capabilities, that information security controls are bound to be problematic. That said, there is a stack of work going on within SC 27 and other ISO committees, bringing the benefits of standardisation and shared good practices to IoT ... hopefully.