ISO 27001 Control 5.36: Compliance with Policies, Rules and Standards

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Policies are easy to write. They have become even easier since AI tools started producing them on request, complete with confident language about encryption standards and access reviews. What has not become any easier is getting people to follow them.

I see the result all the time: a set of policies that read well, were approved before the certification audit, and became shelfware within days of it. Nobody is being deliberately careless. The policies were written to pass an audit, not to describe how the business works, so nobody uses them.

Control 5.36 is the check on that. It asks for regular reviews of whether your information security policies, rules and standards are actually being followed. This page covers what it requires, how the gap usually shows itself, and how managers can check compliance without it turning into a box-ticking exercise. There is a free compliance log further down.

What control 5.36 actually asks for

The control requires that compliance with your information security policy, topic-specific policies, rules and standards is regularly reviewed. In practice that means:

• Somebody is responsible for checking. Usually the managers responsible for each area, because they are closest to the work.
• Checks happen regularly. On a schedule you set and can show, not just when an audit is coming.
• Checks cover people and technology. Whether staff follow the rules, and whether systems are configured the way your standards say they should be.
• Gaps are dealt with. When a check finds non-compliance, the cause is identified and something is done about it.
• Results are recorded. What was checked, what was found and what happened next.

In the 2013 edition this was split across two controls: A.18.2.2 for compliance with policies and standards, and A.18.2.3 for technical compliance review. The 2022 version merges them, so checking that systems are configured to your standards is now part of the same control.

Where 5.36 sits

Several parts of ISO 27001 ask whether things are working. 5.36 is the one closest to the ground.

5.1 writes the rules, 5.36 checks they are followed, and 5.35 checks the rules are right. They need each other. A good policy that nobody checks drifts; a check against a bad policy produces paperwork and no improvement.

Policies that read well and nobody follows

AI-generated policies have made this problem worse in a particular way. A policy written by someone in the business, however clumsily, tends to describe what the business actually does. A policy generated on request describes what a well-run organisation of no particular size or sector ought to do. It sounds authoritative, it covers everything, and it bears no relation to the way anyone works.

Then the audit passes, the policies go into a folder, and day-to-day work carries on exactly as before. The gap was there from the start, and nothing in the ISMS is set up to notice it. That is precisely what 5.36 is for.

The zip file test

My favourite example happens before I have even started. When a new client sends me their documentation and risk register to review, it very often arrives as an unencrypted zip file attached to an email. Inside, the information transfer policy says that sensitive information must be sent encrypted, to a stated standard, using an approved mechanism.

Nobody did it on purpose. The person sending it has probably never read the transfer policy, because it was written by somebody else, or generated, and nobody has ever checked whether it is followed. The risk register, of all documents, is exactly the kind of information the policy was written to protect.

It is a useful test to run on yourself. Pick a rule from one of your policies that should show up in everyday behaviour, and look at what actually happens:

• Information transfer. How did the last sensitive document you sent outside the business actually travel?
• Clear desk and screen. Walk round the office at six o’clock.
• Access reviews. When was the last one, and is there a record?
• Leavers. Pick someone who left last quarter and check every system they had access to.
• Patching. Look at the patch status report, not the patching policy.
• MFA. Check the admin console for accounts without it.

If the behaviour does not match the policy, you have found a 5.36 issue. Better you find it than the auditor.

Check the evidence, not the documentation

The way to stop compliance checking becoming a box-ticking exercise is to stop checking documents and start checking evidence. A box-ticking check asks whether the access control policy exists and has been approved. An evidence check asks to see the last access review, picks two names from it and confirms their access was actually changed.

The evidence of whether a policy works is in the day-to-day: in records, in what people do, and in how systems are set up. There are four ways to draw it out.

Conversations

Ask people how they do things. Not “do you follow the transfer policy?”, which only ever gets one answer, but “how would you send a client’s contract to our lawyer?” The answer tells you whether the policy is known and whether it works.

Records

Access review records, leaver checklists, backup logs, training completion, visitor logs, change tickets. If the policy says something happens, there should be a trace of it happening.

Observation

Walk round. Look at screens, desks, doors, whiteboards and the printer tray. Watch somebody onboard a new starter. Ten minutes of looking often tells you more than an hour with the documents.

Technical checks

This is the part that used to be a separate control. Your standards say every account has MFA, every laptop is encrypted, every server is patched within a set period. Most of that can be checked directly from an admin console or a device management report, and it should be, regularly. It is the most objective evidence you have.

Done this way, compliance checking is what breathes life into an ISMS. It turns the policies from a set of documents into a description of how the business works, and it keeps them honest.

When a check finds a gap

Before fixing anything, find out why the rule was not followed. There are usually three possible answers.

• People did not know. The rule was never communicated, or was buried in a document nobody reads. Fix it with awareness, not discipline.
• The rule is impractical. The approved method is too slow, too fiddly or does not exist. People found a workaround. Fix the process or the tooling, and possibly the policy.
• The rule is wrong. It was generated or copied and never fitted the business. Change the policy to say what you actually need, then check that.

Only occasionally is the answer that someone deliberately ignored a rule they knew and could follow. That is when the disciplinary process comes in, and an auditor will want to see that it exists. But if most of your gaps end there, look harder at the policies.

Making it routine

Checks that only happen before an audit are not regular, and an auditor will spot it from the dates. The simplest way to make them routine is a short calendar. Each manager owns a handful of checks for their area, each check has a frequency, and the results go into a log.

• Monthly: MFA coverage, device encryption and patch status from the admin consoles.
• Quarterly: access reviews for key systems, a leaver spot check, and a walk-round for physical and clear desk.
• Twice a year: one conversation-based check per policy area, such as asking three people how they would send sensitive information.
• Annually: a check that each policy still describes what the business does, feeding the policy review under 5.1.

For a small business that is perhaps an hour or two a month in total, spread across several people. The log below has a tab for exactly this.

What auditors will look for

As a Lead Auditor, this is broadly how I would work through 5.36.

1. Who checks, and how often. Is it defined? Do managers know they are responsible for compliance in their own areas?
2. The record of checks. Dates, what was checked, what was found. If every check happened the fortnight before the audit, that tells me something.
3. The method. Did the check look at evidence, or just confirm that a document exists?
4. Technical compliance. How do you know systems are configured to your standards? Show me the report.
5. A gap, followed through. Pick a finding: what was the cause and what changed?
6. My own sampling. I will test a few policies against reality myself. If I find a gap your checks should have found, that is the finding.

Common issues

• Policies generated or copied, approved, and never compared with how the business works.
• No compliance checks at all outside internal audit.
• Checks that confirm documents exist rather than that the rules are followed.
• Technical standards that nobody checks against: MFA “required” with several accounts exempt, encryption “mandatory” on most laptops.
• All the checks dated just before the audit.
• Gaps found and fixed by telling people off, with the impractical rule left unchanged.
• Sensitive documents, sometimes the ISMS documents themselves, sent in ways the policy forbids.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• How did the last sensitive document your business sent externally actually travel, and does that match your policy?
• Which manager checks compliance in each area, and when did they last do it?
• Can you produce a report today showing every account has MFA and every laptop is encrypted?
• What was the last gap a compliance check found, and what changed as a result?
• Does every policy you hold describe what your business actually does?

The first and last are the ones to sit with. They tell you whether your policies are working documents or shelfware.

A worked example

The details below are typical rather than drawn from a single engagement. This is a composite of a first round of compliance checks in a business of this size.

A 35-person professional services firm, certified for a year. Its policies were largely generated from a template pack and approved in one meeting. Internal audit had happened once. No other compliance checks were recorded.

What the first checks found

• The information transfer policy required an approved encrypted file sharing service. Most staff sent client documents as email attachments; the approved service had never been set up.
• The access control policy required quarterly access reviews. None had been recorded since certification.
• The admin console showed four accounts without MFA, including one belonging to a leaver.
• The clear desk policy required locked storage. There was no locked storage.

What changed

• The file sharing service was set up and the transfer policy rewritten around it. Two follow-up conversation checks showed people using it.
• Quarterly access reviews added to the calendar with the system owners named, and the first one completed.
• The leaver account was disabled, MFA enforced on the rest, and a monthly MFA report added to the checks.
• The clear desk policy rewritten to match a largely paperless office, with lockable drawers bought for the few who need them.

Two of the four fixes were changes to the policy, not the people. That is normal, and it is the point.

How control 5.36 links to other clauses and controls

• Control 5.1, Policies for information security. The policies being checked. Gaps found under 5.36 should feed the policy review.
• Control 5.35, Independent review of information security. Someone else checking. 5.36 is managers checking their own areas.
• Control 5.14, Information transfer. The policy behind the zip file test, and one of the most commonly ignored.
• Control 8.9, Configuration management. Your technical standards and baselines. Technical compliance checks are checks against these.
• Control 6.3, Information security awareness, education and training. The fix when people did not know the rule.
• Control 6.4, Disciplinary process. The fix when they knew and chose not to follow it.
• Clause 9.1, Monitoring, measurement, analysis and evaluation. Compliance check results are some of the most useful measures you have.
• Clause 9.2, Internal audit. and Clause 10.2, Nonconformity and corrective action. Significant gaps become nonconformities with corrective action.

What I find in audits

When a new client sends me its documents, around 7 in 10 times they arrive unencrypted, as an open attachment or zip file. In my audits I also increasingly find policies generated with AI that do not match what actually happens. More detail is in my findings report.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• 10 Steps to Cyber Security. NCSC guidance on the core areas of cyber security, a useful basis for compliance checks.
• Cyber Essentials. The UK government-backed scheme covering basic technical controls such as MFA, patching and secure configuration.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.
• NCSC cyber security culture principles. Why people work around policy, and how to design policies they will follow.
• NCSC 10 Steps: engagement and training. Building security into how people actually work.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call