It's a little frustrating

More than once I've been on the wrong end of an ISO27001 auditor that misunderstands this concept, and it's pretty awkward having to explain it to them.

I've also audited companies for ISO27001 where the previous auditor got this wrong, raised a Minor Non Conformity against the business and generated a stack of unnecessary work as a result!

Why is something that should be simple so tricky? The misunderstanding is routed in the semantics of the standard, coupled with the fact that not many people actually read it!

Semantics are tricky

The word "Policy" is used interchangeably in the ISO27001 standard to mean two distinct things:

1. An established understanding of the way something is done (...and yes, that does sound a LOT like a process!); and

2. A document that defines or describes a how things are done

Aren't they the same thing?

Well, yes...sort of. Let's look at a couple of examples of ISO27001 Annex A controls:

Where ISO27001 requires a documented policy

A.9.1.1
Access control policy
An access control policy shall be established, documented and reviewed based on business and information security requirements.

A.9.1.1 requires a documented policy. You can tell, because it explicitly states that it be "established, DOCUMENTED, and reviewed..."

Where ISO27001 doesn't require a documented policy

A.12.3.1
Information backup
Backup copies of information, software and system images shall be taken and tested regularly in accordance with an agreed backup policy.

In A.12.3.1, ISO27001 even uses the word "agreed" in relation to a backup policy. What it doesn't say is that the policy should be documented, or written down somewhere.

A real-world scenario

As an auditor, if you can show me your backup schedule (perhaps using a system like Veeam, Datto, AFi or similar), then you have a backup policy - an understanding or established way of doing backups.

Did you need a document? No. However, you have an established way to back data up, but what about:

1. What should be backed up;

2. When, or how frequently it should be backed up;

3. How the backups are "tested regularly"

Your challenge, should you choose to accept it, is how you prove to me that you have an established way of doing all of the above. If you can prove/demonstrate that all of that happens, then you don't need a document.

Isn't that harder?

Well, it might be. For some of the ISO27001 controls it's easier to write a document that explains what you do (such as a Backup Policy). Sometimes, however, it's a LOT harder. Let's looks at another (really confusing) example:

A.15.1.1
Information security policy for supplier relationships
Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets shall be agreed with the supplier and documented.

Here we have the word "Policy" in the control, and the word "documented" in the control statement. Surely that means ISO27001 wants a documented information security policy for supplier relationships right?

Wrong. Let's take it back into an audit setting. If you can demonstrate to me that:

1. you consider the information security risks that a supplier with access to your information assets might present; and

2. you have a way of identifying suitable controls that might be required to mitigate those risks and, where necessary; and

3. you have agreed those mitigating controls with the supplier (where applicable)

...then you have met the requirement of the standard - all without a documented policy. Honestly, this ISO27001 control in particular is MUCH easier without having to write a document that explains how you do it - here's how I implement this with my clients...

A worked example of Annex A.15.1.1

We start with a high level risk assessment that ALL suppliers go through. This identifies whether or not the supplier will have any access to our information assets. If they don't, we take no further action.

If they do have access to our information assets, then we start a simple risk assessment, exactly the same as you might do for the rest of your identified information risks. Something like:

impact * likelihood

...usually does the trick! So, for example, if we're talking about using Azure, or AWS, to host a new system, the impact of something going wrong (as a result of Azure or AWS, not as a result of the way we use them) is probably going to be high, but the likelihood will be low.

A little Due Diligence

This gives us a risk score for the supplier. If the risk score is considered "too high", then we apply further due diligence such as:

• Ask for security certifications (ISO27001, Cyber Essentials, NIST...)

• Ask for proof of insurance

• Run a credit check

If the risk score is really high, we might also add the use of this supplier to our risk register to see identify what controls we might want to apply and, where appropriate, agree those controls with the supplier.

All of the due diligence findings can be stored in a "supplier folder" within your ISO27001 ISMS as evidence of your "policy" in action - and THIS will satisfy the audit requirements for this control - without having to write down how you do it.

That said, writing it down might help if your ever not around and someone else needs to pick it up!

Conclusion

I'm hoping this helps distinguish between when ISO27001 expects a documented policy versus when how you do things will suffice. It's confusing mostly because documentation can be helpful in explaining how you do something. Where that's not the case, you can save yourself a LOT of work by NOT documenting! (See A.14.2.1 if you're not convinced).