What should an ISO27001 certification audit plan/agenda contain?

Before we get going with this it is worthwhile remembering that the job of an ISO27001 certification auditor is NOT to assess your approach to information security. Their job is to assess your conformance to the requirements of ISO27001. To do this they check that you have designed, implemented and are operating effectively all the things that ISO27001 clauses 4 to 10 say you must do.

Note that ISO27006 which is the rules for certification bodies and auditors states this "The audit objectives shall include the determination of the effectiveness of the management system to ensure that the client, based on the risk assessment, has identified the necessary controls and achieved the established information security objectives."

As also defined in ISO27006 the auditor does this by defining the audit criteria. This is stated in ISO27006 as "The criteria against which the ISMS of a client is audited shall be the ISMS standard ISO/IEC 27001."

Question 1 “Does the ISMS design conform to the requirements of ISO27001?”.

In the first instance the job of the auditor is to say “Does the ISMS design conform to the requirements of ISO27001?”. This is mostly but not exclusively about the policies, procedures and processes that you have put in place to meet the requirements of clauses 4 to 10 of ISO27001. This includes such things as the risk assessment process and how you are monitoring and measuring the performance of your ISMS.

This is the main focus of the Stage 1 certification audit although this is often covered at quite a high level. (Sometimes too high a level in my opinion.)

This is covered in detail at the Stage 2 audit. The surveillance audits look at a sample of this.

Question 2 – “Is the ISMS operating effectively to meet all the requirements of ISO27001 clauses 4 to 10?”

The next question is “Is the ISMS operating effectively to meet all the requirements of ISO27001 clauses 4 to 10?” This includes auditing all those things you have put in place to meet the requirements of clauses 4 to 10 and to meet your objectives of the ISMS. E.g. the controls and because they are such an important part of the ISMS we give the controls special attention when answering this question.

Aspects of this are sometimes covered in the Stage 1 audit but this is covered in detail at the Stage 2 audit. The surveillance audits look at a sample of this.

What should an ISO27001 audit plan contain?

Apart from such things as opening/closing meetings, introductions, findings from the last audit, changes since last visit, overview of the organisation and breaks for lunch and tea/coffee this means an ISO27001 audit plan/audit agenda should contain only the following:

A list of all the clauses 4 to 10. This is usually at a level something like this:

➜ “4.1 The organisation and its context”

➜ “4.2 Needs and expectations of interested parties”

➜ Etc.

This is needed for all ISO27001 certification audits although some auditors will only cover a subset of these at a surveillance audit.

Technically speaking that is all you need in the agenda. When the auditor then gets to some of the clauses they then spend some time sampling some of the controls to check that the clauses requirements are being met.

However, nobody ever does it that way. They always test the controls separately from the clauses. So in practice the second half of the agenda is a list of some or all of the controls identified as applicable/justified and implemented in the Statement of Applicability (SOA). This is usually at the level of the control name rather than the actual control description. Something like this:

➜ “A.14.2.9 System acceptance testing”

➜ “C003 – Malware protection”

➜ Etc.

This applies to the Stage 2 and surveillance audits. Most auditors will want to test all the controls at the Stage 2 although they don’t have to. They just need to test enough controls to convince themselves that the clauses are all OK.

It might be that to test the controls and possibly some of the clauses the audit plan will also need to identify locations/services/systems/people/etc to ensure that the testing of these covers a reasonably representative sample across these areas. A few examples:

➜ To test awareness and communication the plan may need to identify that a number of people will need to be spoken to and asked about this. These could be people at different locations – e.g. at the small local office in Patagonia as well as people in head office.

➜ If the scope is more than one location and there are any physical controls identified as applicable/justified in the SOA the plan will probably need to identify which locations will be visited for the testing of those controls. However, all that should happen is that those controls should be tested at each location. Not just a general walk around to see if the auditor can spot anything they don’t think is right.

➜ If there are a number of services and systems in the scope the plan may need to identify which ones will be audited if only a subset are going to be looked at.

What this means is that the plan needs to make it clear which controls are to be audited at or with respect to which location, system, service, person, etc, etc.

It is not sufficient for the audit plan to say things like:

"Interviews with a sample of 4 staff."

The audit plan needs to be more specific than this, for example:

"Interviews with a sample of 4 staff to audit the following clauses and controls:

➜ 7.3, 7.5 Awareness and communication.

➜ C004 Classification policies and procedures.

➜ A.12.2.1 Controls Against Malware.

➜ A.8.1.3 Acceptable use of assets."

As another example, it is not sufficient for the audit plan to say things like:

"Site visit – Patagonia office."

The audit plan needs to be explicit about exactly what controls are going to be audited at the Patagonia office. For example:

"Site visit – Patagonia office to audit the following controls:

➜ A.11.1.1 Physical security perimeter

➜ A.11.1.2 Physical entry controls

➜ A.11.1.3 Securing offices, rooms and facilities.

➜ A11.2.1 Equipment siting and protection

Interviews with a sample of staff at the Patagonia office to audit the following clauses and controls.

➜ 7.3, 7.5 Awareness and communication.

➜ C004 Classification policies and procedures.

➜ A.8.1.3 Acceptable use of assets."

Note the use of controls names as shortcuts in the above although it is the control description that will be actually audited.

To simplify this further the audit plan could just include the clause or control reference, for example:

"Site visit – Patagonia office to audit the following clauses and controls: A.11.1.1, A.11.1.2, A.11.1.3,A11.2.1, 7.3, 7.5, C004, A.8.1.3."

But this is not as clear to whoever is looking at the audit plan.

So why don’t the audit plans look like this?

A good question. Over the years it is not often I see an audit plan that properly adheres to this. Below are a few examples of oddities from actual audit plans I have seen recently:

➜ The audit plan listed general information security topics (e.g. “Human Resources Security”) rather than controls identified as applicable/justified in the SOA.

➜ The audit plan was based on Annex A controls and domains even though the client was using all custom controls.

➜ The audit plan had an item “Site Visit – Crewe office” without any clear statement of what clauses and controls were going to be tested at the Crewe office.

➜ The audit plan had a number of items to be tested that were not controls identified in the SOA as applicable/justified and implemented.

➜ The audit plan had an item “Legal and Regulatory requirements” even though there is no ISO27001 clause that requires this and there was no control that referenced anything like this. Control A.18.1.1. was not marked as applicable/justified in the SOA.

➜ The audit plan had an item “Privacy” even though there is no clause in ISO27001 that covers anything on this. There is an Annex A control that might be relevant for some organisations but it is very specific and not under a general heading of “Privacy”. The client did not have any controls that had anything do to with “Privacy”.

A few years ago when GDPR started becoming a thing a lot of auditors wanted to ask about. Again, not relevant.

This problem of rogue plan items is especially common when it comes to the controls. ISO27007 which is the guidance to ISO27001 auditors states this “Auditors should look for conformance with the organization’s specification of its necessary controls, not with the specification given in Annex A.”. However, far too often I see auditors thinking that they can test general areas rather than the controls as such. What does not help is that if an organisation is using any of the Annex A controls because some of these are very high level and are very broad in coverage.

The primary root cause of this is auditors thinking they are there to test information security rather than conformance to ISO27001.

How does the auditor know what the controls they should test?

They look in the SOA for those controls marked as justified/applicable and implemented.

For the Stage 1 audit the auditor will not know which controls these are but this does not matter because the controls are not tested at a Stage 1 audit. However, they will be known before the Stage 2 audit and the surveillance audits. For this to work it is important that the auditor properly “tests” the risk assessment at the Stage 1 to get some level of comfort that the all the necessary controls have been identified. You don’t really want to wait until the Stage 2 audit to find out that you may have some controls missing from the risk assessment.

Other rules and guidelines for auditors.

It is worth noting that there are lots of ISO documents that gives the rules and guidelines that must/should/can be used by auditors for ISO27001 certification audits. The mandatory requirements are ISO27006 and ISO17021. Useful guidance is also in ISO27007, ISO27008 and ISO19011.

Summary

If the audit plan has anything in it that is about auditing/testing something that not a reference to a clause or a control listed as applicable/justified and implemented in the SOA then it is not a valid audit plan.

I am going to repeat and emphasis this point. The audit plan must only refer to auditing clauses 4 to 10 and controls marked as justified/applicable and implemented in the SOA. And yes, I know I have already said this several times already.

Chris

www.btrp.co.uk

(P.S. I know that my audit plans when I was an ISO27001 certification auditor did not fully adhere to this 😊.)