The Technology Standards Conundrum

The world of technology standards[1] is a mess, populated with well-meaning attempts to come to grips with some of the biggest problems in IT management, at the international, national and industry levels.

The mess is created because as each new problem, such as ‘Information Security’, arises, the solution tends to be addressed in isolation, by knowledgeable technicians rather than management experts, who can see commonalities across different standards.

This can be illustrated by considering three relatively recent but important standards on ‘information security management’ and ‘cyber risk’, which address roughly the same problem:

  • ISO 27001[2] – ‘IT Security Management Systems’;
  • NIST 800-53 – ‘Security and Privacy Controls for Federal Information Systems and Organizations’; and
  • BS 31111[3] – ‘Cyber Risk and Resilience’, a new standard developed by the British Standards Institute (BSI) Risk Management Committee, and published in 2018.

Each of these standards comes at the problem of ‘cyber risk’ from different angles and each group responsible for a particular standard, has developed a different ‘risk management framework’ (RMF) for tackling the problem of cyber risk in a financial institution or government department. For example, in NIST 800-53[4], the US National Institute of Standards and Technology (NIST) develops a framework of six steps:

  • Categorize: “the information system based on a [another standard] impact assessment”;
  • Select: “the applicable security control baseline based on the results of the security categorization …”;
  • Implement: “the security controls and document the design, development, and implementation details for the controls”;
  • Assess: “the security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system”;
  • Authorize: “information system operation based on a determination of risk to organizational operations and assets, individuals, other organizations …”; and
  • Monitor: “the security controls in the information system and environment of operation on an ongoing basis to determine control effectiveness, …”.

It should also be noted that NIST also developed a more general ‘cybersecurity framework’ [5], in conjunction with NIST 800-53, which consists of five risk management steps: identify, protect, detect, respond, and recover.  These steps align with the ISO 31000 risk management[6] standard but are in a different sequence and key processes are merged.

By itself, there is nothing wrong with any of these NIST frameworks, which are based on the well-known Plan-Do-Check-Act (PDCA) management paradigm, except that the standards are standalone, aimed at a specific problem and, as a result, will cause unnecessary duplication when employed alongside other standards such as ISO 31000 or COSO[7].

On the other hand, the BS 31111 standard is organized on six key themes, which closely follow risk management standards such as ISO 31000:

  • cyber governance policies with strong structures, operating models and supporting resources;
  • demonstrating commitment to recognised security and risk management frameworks that include mitigate, accept, respond and transfer capabilities;
  • clear risk reporting that shows the commercial and operational impact of the risks based upon actionable and real-time intelligence;
  • ability to learn from experience including starting from first principles to a more innovative, adaptive response as a situation changes;
  • the need to recognise that cyber risk and resilience be incorporated into all new programmes and initiatives;
  • having a threat intelligence capability and information sharing programmes to ensure that the organization and any appropriate third parties are quickly kept up-to-date with the level of risk including the ability to quickly adoption of any external guidance necessary to control identified risks.

The ISO 27001 standard also proposes a similar PDCA model which has six stages that are different to BS 31111 but cover similar processes: policies, planning, risk assessment, manage, control and monitor. Again similar (but a different order to) ISO 31000 and COSO.

These three standards are well-considered and comprehensive but are incompatible at the process level and could not all be implemented within an organisation, without significant duplication and inevitable conflict.

These standards are not contradictory, they merely place emphasis on different aspects of the problem – NIST on detailed implementation leading to management, BSI and ISO on management leading to implementation.  However, although these standards are quite different, because they have been developed by experts in a formalized process that encourages consultation and agreement, they do provide a comprehensive, if difficult to entangle, coverage of the problem being considered.

It is obvious that a well-developed standard is likely to be better than one developed from scratch by a firm itself, as a firm will just not be able to access the breadth of expertise available to a standards committee.

This is the ‘standards conundrum’ – any formal standard will invariably be better than one developed internally by a firm, but which one to standardize on?

And there is no easy answer to this conundrum.

Adopting any standard, even if only in part, is in effect a risk-mitigating decision, allowing a firm’s strategic decisions to be audited against external expertise. And it should be remembered that being ‘fully compliant’ with a standard is not an end in itself, but rather a way of testing the firm’s processes against so-called ‘best practice’.

It means that business and support units, such as Risk Management and IT must take a pragmatic approach towards adopting new standards; and must do so within well-developed framework(s), that are agreed and understood by all. They must then map new standards onto their frameworks, attempting to understand what each new standard brings to the industry (it will inevitably bring something) and recognizing that a new standard will mean inevitable changes to their frameworks.

This also means that a board, when considering technology strategy, must be aware whenever new standards are emerging in particular areas and make strategic decisions based on the ‘maturity’ of a particular set of standards, not on their novelty!

It also means that standards developers must also be pragmatic and recognize that their (precious) standards must be capable of being integrated with other standards and that it is the principles not the details of a particular standard that are important.

Unfortunately, we are a long way from achieving those ideals.

[1] Adapted from McConnell P.J. ,2017, Strategic Technology Risk, Risk Books, London

[2] ISO, 2013, ‘ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems – Requirements’, International Standards Organization, Geneva, http://www.iso.org

[3] BSI, 2018, ‘BS 31111:2018 – Cyber risk and resilience. Guidance for the governing body and executive management’, British Standards Institute, London

[4] NIST, 2013, ‘Security and Privacy Controls for Federal Information Systems and Organizations’, National Institute of Standards and Technology, Washington, D.C., http://dx.doi.org/10.6028/NIST.SP.800-53r4

[5]NIST, 2014, ‘Framework for Improving Critical Infrastructure Cybersecurity’, National Institute of Standards and Technology, Washington, D.C., https://www.nist.gov/document-3766

[6] ISO, 2009, ‘ISO 31000:2009, Risk management – Principles and guidelines, Geneva (International Standards Organisation).

[7] COSO, 2016, ‘Enterprise Risk Management – Aligning Risk with Strategy and Performance’, Committee of Sponsoring Organizations of the Treadway Commission.