ISMS internal audit priorities

A thread on the ISO27k Forum sparked my imagination over coffee this morning.

Hope had previously asked for assistance with an ISO/IEC 27001:2022 audit plan. 

Bhushan offered a lengthy and generally sound response explaining how to use a spreadsheet with tabs to plan and record the audit work performed on 100% of the main body clauses and 50% of the 93 Annex A controls, day-by-day. That's OK ... except it wasn't entirely clear that he was interpreting and elaborating on the standard's actual requirements.

ISO/IEC 27001 does not explicitly require, for example, that (as Bhushan stated) "ALL the management system clauses from 4 to 10 AND their sub-clauses need to be listed and audited" in an ISMS internal audit, although evidently he interprets it in that way. In clause 9.2.1, the standard states a requirement for internal audits to provide information on whether the ISMS conforms to the organization’s own requirements for the ISMS plus the requirements of the standard, and is effectively implemented and maintained. There is no "ALL" in the standard's main body clauses. Spreadsheets are not mentioned at all, not even once.

While 100% audit coverage of ALL the mandatory requirements would be one way to demonstrate conformity, clause 9.2.2 hints at an alternative approach: "When establishing the internal audit programme(s), the organization shall consider the importance of the processes concerned and the results of previous audits." I would argue that it is therefore acceptable to audit only the 'main' (most important) ISMS processes and pick up on any issues noted in previous audits - not just internal audits by the way.

That, in turn, begs questions about what are the most important things to audit, the priorities. When scoping and preparing for an ISMS internal audit, I typically start by reviewing all available information about the ISMS including previous audit files, reports, findings, recommendations, ISMS changes, strategies, policies, management reviews, preventive and corrective actions and so on. Although I'm a voracious reader, there is so much information to review that it normally spills over into the audit fieldwork phase, asking questions and examining further evidence about any emerging concerns or issues. 

In practice, I can't reasonably expect to cover 100%, so I prioritise the stuff (not just 'the processes concerned') that I believe is most important in context, typically the areas that seem to present the greatest information risks and/or where the audit can hopefully add the most value to the business. Occasionally, it might also involve specifically looking into certain aspects that the client's senior management considers priorities, without compromising my independence as an auditor.

That's simply how I do it. Although I believe it satisfies the ISO/IEC 27001 requirement, I freely admit that it goes beyond the mandatory minimum in my quest to add value to the business. The challenge, always, is to make the best use of the available resources - particularly the time - and the opportunity.

Prioritisation applies also to auditing the information risks and security controls: again, the standard does not formally demand that they are 100% audited. In fact, it doesn't literally demand that they are audited at all! I use my discretion in practice. Rather than attempting to cover ALL the risks and controls, I might, for example, take a deep dive into the information risk and security aspects of 'joiners, movers and leavers' to explore the nature and quality of the organization's HR arrangements - its policies, procedures and practices, including conformity, documentation and broader issues such as governance and relationships with other departments/service providers. 

This is a typical form of 'audit sampling': rather than attempting to audit everything (which implies fairly superficial coverage given the constraints of the audit), I pick out just a few aspects to review in detail as a way to explore and learn about the organisation's approach in general. Subsequent audits would probably pick on different aspects, as well as following-up on the findings of previous audits.

Finally, prioritisation comes into play in the audit analysis and reporting phases. It is unhelpful to attempt to report 'everything', not least because so much of the information comes from the auditee. There is no point reproducing the previous audit reports etc., and I am unlikely to list the items of information I obtained and reviewed, except perhaps in a general sense when explaining how the audit was performed and when citing specific items of evidence to support my findings.

Hmmmm, so does that answer Hope's original request for assistance? Not quite. There is one more thing. What is an 'audit plan', in fact? Again, referring to ISO/IEC 27001 in the first instance, clause 9.2.2 starts "The organization shall plan, establish, implement and maintain an audit programme(s), including the frequency, methods, responsibilities, planning requirements and reporting." In that sentence, 'plan' is a verb concerning the process of preparing "an audit programme(s)". Since 'programme' is not formally defined in the standard, the normal dictionary definition or understanding applies. Google tells me that one of the Oxford Languages definitions of a programme is "a set of related measures or activities with a particular long-term aim". 

So, strictly speaking, ISO/IEC 27001:2022 does not specify an 'audit plan' at all. We should really have asked Hope to clarify the original request for assistance rather than assuming what was meant. Is 'plan' the same as 'programme'? Have we adequately described either one? You tell me! Comments welcome ...