Philosophical phriday - in/excluding Annex A controls

In a discussion thread on the ISO27k Forum about selecting appropriate information security controls, a member told us: "As far as software development is concerned, we really need the controls A8.25 and following". I queried that determination, guessing their thought process may have been along these lines: 

  1. We do software development.

  2. Controls A8.25+ concern software development.

  3. Therefore, for conformity with ISO/IEC 27001, controls A8.25+ are applicable and cannot be excluded.
#3 is patently a false conclusion, a logical error. The Annex A controls are not formally required for conformity with the standard. They are not mandatory - none of them, not one. If you believe otherwise, kindly explain which specific clause from ISO/IEC 27001 contains that explicit requirement because, despite hunting high and low over many years, and despite numerous claims from so-called experts in the field, I simply can't find it.

There is, however, a formal requirement in '27001 to check through Annex A for any controls that might reduce unacceptable information [security*] risks, but even then there is no actual obligation to implement the controls as stated in Annex A. You can implement whatever controls management feels are appropriate ("necessary" in ISO-speak) to mitigate your organisation's unacceptable risks, provided the risk management process fulfils the formal requirements of the standard laid out in the main body clauses (assuming you intend to claim conformity with the standard - and if not, well you are under no obligations towards it).

Here's an alternative train of thought, a risk-driven information risk management approach:
  1. We do software development.

  2. We have identified a bunch of information risks associated with software development.

  3. We have explored and evaluated those risks, and - on behalf of the business - management has decided that some need to be reduced using controls in order to achieve various business objectives such as "Be a trusted partner", "Protect our brands" and "Be a quality outfit".

  4. We have some existing controls in this area, which are valuable and we intend to keep, and maybe others that could be improved or dropped.

  5. We have brainstormed, Googled, checked Annex A, ISO/IEC 27002, OWASP, CIS, SANS, TISAX, GDPR, ISF and any other reference sources we can lay our hands on to identify and choose a suite of potentially valuable controls in this and other areas.

  6. By systematically implementing or improving various controls, we are proactively reducing the risks and monitoring/measuring/managing the changes.

  7. Thanks to the information we have generated and retained, including our metrics and assorted checks, tests, reviews and audits (assurance controls), management is happy that we are headed in the right direction at the right pace.

  8. For conformity with ISO/IEC 27001, we have systematically reviewed all of Annex A to confirm that we haven't neglected any significant risks and valuable controls.

  9. If any of the chosen controls precisely match the brief descriptions (little more than titles, in fact) in Annex A, we mark those as 'applicable' in our SoA; otherwise, the Annex A controls are marked 'inapplicable', or perhaps 'replaced by custom control' in our Statement of Applicability. Either way, the evidence we have accumulated allows us to demonstrate our systematic, rational, conformant approach to the certification auditors on demand.

  10. Nevertheless, we remain open to the need for changes, improvement opportunities, emerging risks, changing control effectiveness, security innovation and so on, thanks to the ISMS - including any constructive suggestions from the auditors.
Clearly, the alternative approach is longer and more involved ... but the end result is that information risks are better understood and mitigated, meaning that the ISMS is achieving more than just conformity: it is earning its keep and justifying management's continued interest and investment. In particular, being rational and information [security*] risk-driven rather than simply doing whatever Annex A suggests, it reflects the organisation's unique situation, challenges, resources, concerns etc. The ISMS is a demonstrably valuable part of the organisation, actively contributing to the business objectives, not something generic foisted upon it by some well-meaning international committee that management and others may not appreciate and might even resent.

There are other approaches too, such as starting out with a minimalist list of basic information security controls (drawn from Annex A, existing practice or elsewhere), then gradually refining them as the ISMS matures. Maybe existing controls are deemed adequate for now, or of lesser priority than other areas at the current time, and that's fine too. An ISO/IEC 27001 ISMS gives management the tools and latitude to make such determinations according to the organisational context, specifically its information [security*] risks.  


* ISO/IEC 27001 uses the term "information security risk" without actually defining it as such, although it does define both "information security" and "risk" individually. In this blog and my other writings, I use "information risk" defined as "Risk pertaining to information".

PS  ISO/IEC 27013:2021 "Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000-1" was formally amended (patched) in December 2024. A quarter of the 4-page amendment concerns the SoA, including the following absolutely clear and definitive statement:
"The controls in ISO/IEC 27001:2022, Annex A, are not requirements and are not mandatory."
So, there it is, in black and white. My case rests m'lud.