ISO 27001 Annex A 5.36: how managers check policy compliance

The enterprise questionnaire asks how you know your teams follow your own security policies. You have an annual internal audit and a hope. This guide shows how managers run ISO 27001 Annex A 5.36 in a 25–250 person firm: who checks what, how often, which checks tooling does for them, and what an auditor will sample.

It is written for security managers, compliance leads and operations directors who need the routine to run without a compliance team or a sprawling spreadsheet.

What does ISO 27001 Annex A 5.36 actually require?

ISO 27001 Annex A 5.36 requires the people who own the work to check periodically that their teams and systems follow the organisation's security policies, rules and standards. When they do not, owners find the cause, fix it, confirm the fix worked and keep records. The 2022 revision merged the old policy and technical compliance controls into it.

The yardstick is wider than the top-level security policy. It takes in the topic-specific policies beneath it, such as access control or acceptable use, and the rules and technical standards that put them into practice, including your hardening baseline. Writing a policy is one control. Checking that anyone follows it is this one.

The merge matters in practice. The 2013 edition split the duty across A.18.2.2 for policies and A.18.2.3 for technical checks, while the 2022 control covers behaviour and configuration together. An unacknowledged policy and an unpatched server are now the same owner's problem, and the standard nudges you towards automated measurement over manual inspection.

The control connects to three other requirements. Annex A 5.35 is the independent review that receives these results. Clause 9.1 covers monitoring and measurement, and Clause 9.2 runs the internal audit programme.

The reason to do it well is the stage 2 audit, the main certification assessment. The bruising ones nearly always trace back to a policy that said one thing while sampled reality said another. This control is the one whose job is to spot that gap first.

Skipping it also compounds. Controls drift silently, the paperwork stays green, and the discovery arrives through an incident or an enterprise client's technical diligence instead of an internal report.

How is A.5.36 different from internal audit and independent review?

Annex A 5.36 is frequent self-checking by the people who own each area. Clause 9.2 internal audit is periodic and independent, and Annex A 5.35 adds an outside reviewer looking in. Managers reviewing their own areas is the design here, so the reviewer does not need to be independent; the results should feed the independent reviewer.

Three layers work together, and each answers a different question:

• Annex A 5.36, managers: the owner of each area checks it against policy, frequently, and fixes what fails.
• Clause 9.2, internal audit: a planned programme run by someone independent of the area, on a periodic cycle.
• Annex A 5.35, independent review: a reviewer outside the area looks in and receives the results of the first layer.

Because the reviewer is the owner, the weak point is candour rather than independence. Two safeguards keep it honest: every check leaves a record, and the results travel upward to management review and across to whoever performs the independent review.

An annual internal audit cannot tell you what happened in the other eleven months.

The ICO Data Protection Audit Framework takes the same self-checking approach for data protection. It is built for organisations to audit their own practices against the regulator's expectations, track and report progress, and raise senior management engagement.

The common pitfall is calling the annual audit your A.5.36 programme. Auditors separate the two quickly, and the difference is a favourite interview question. Run properly, the two help each other: the internal auditor can start from the managers' own records instead of re-checking every area from scratch.

How do you assign A.5.36 reviews in a 25–250 person firm?

Write one page naming who checks what and how often. In a 50-person firm that means three or four people: the engineering lead for technical controls, the operations or office lead for physical and process rules, HR for people controls, and the CEO or COO holding the whole. That page is the procedure.

The page for a firm of that size has four rows:

• Engineering lead: cloud and device configuration, patching and access, mostly read from the dashboards described below.
• Operations or office lead: physical security and process rules.
• HR: people controls, including policy acknowledgement and training completion.
• CEO or COO: reads the summary and takes findings to management review.

At 250 staff the same pattern splits by department. The page grows by rows, not by pages.

Line managers without security expertise do not need a compliance officer beside them. Give each owner a short list of plain-language questions for their area, a link to the dashboard that answers the technical ones, and a named person in the security function to ask when a result is unclear. The manager's job is to look, decide and record, with specialist interpretation on call.

Tell each owner the duty is theirs in writing, before the first cycle. Managers who learn of it in the audit interview have no records to show and no habit to describe.

Resist importing an enterprise checklist. Keep each one short enough that a manager reads every line.

A forty-item monthly checklist is not rigour. By week six it is fiction.

Rubber-stamping is the visible symptom. A review signed off in minutes with no finding, cycle after cycle, tells the auditor nobody investigated.

How often should A.5.36 compliance reviews run?

Set frequency by risk and change, not by a uniform calendar. Check the technical estate quarterly or faster, covering access reviews, patching posture and configuration against your hardening baseline, and low-churn administrative policies annually. Add event triggers such as a new system, a failed scan threshold or an incident closure, so checking intensity follows risk.

Three questions place any area on the calendar:

• How often does this area change?
• How much damage follows if it drifts unnoticed?
• Can a tool measure it continuously?

The answers sort a 50-person firm quickly. Access reviews sit in the fast tier because joiners, movers and leavers change them constantly. An acceptable use statement changes rarely, so an annual look is enough.

Write the reasoning into one line on the schedule. Auditors ask how you decided the frequencies, and a simple calendar with a rationale beats an elaborate framework with none.

Triggered checks stay narrow. After an incident, look again at the control that failed; for a new system, check its settings once, early. Neither needs a full review cycle.

Start the calendar with one baseline pass across every area as soon as the schedule is approved. The first cycle then surfaces the gaps you already have, instead of waiting a quarter to find them.

How do you automate technical compliance reviews for A.5.36?

Let tooling carry the technical checking. Cloud security posture management, MDM compliance dashboards, vulnerability scan trends and CIS benchmark scans stream pass or fail state continuously, so the manager's review becomes reading and acting on a dashboard that doubles as the evidence record. The manager still owns the decision.

The NCSC Vulnerability Management guidance frames vulnerability management as a process to validate, and where necessary remediate, how well your software update process and security configuration controls are working. A scan trend is therefore a compliance review input, not a side task.

Your review frequency has a formal counterpart in NIST SP 800-53 Control Assessments (CA-2). It asks for controls to be assessed at a defined frequency, to confirm they are implemented correctly and operating as intended.

Wire a feed in four steps:

1. Pick the measurable policy statements. Patching, baseline configuration and access are candidates; physical rules are not.
2. Point a tool at each one. Use posture management for cloud configuration, MDM for devices, scans for patching and CIS benchmarks for hardening.
3. Name an owner per dashboard and set the threshold that counts as a failure.
4. Read it on the cadence and note the decision: accepted, ticketed or escalated. The export is the record.

People signals work the same way. The system flags the unacknowledged policy or lapsed training by exception, so HR reads a short list instead of auditing completion sheets.

Checking by hand what a machine already measures burns goodwill. A manager who spends a morning trawling configuration screens will stop by the second cycle, while the posture dashboard did the same job for free.

What is the nonconformity loop and how do you close it?

Every finding runs through the same small loop: log it, find the root cause rather than the symptom, assign and fix, then verify later that the fix worked. Track it in the ticketing system you already use, with owners and dates, and send findings and closure status to management review.

The loop has four stages:

1. Root cause. Ask why it happened. A server may be unpatched because its owner left and nobody inherited the task, so patching it treats only the symptom.
2. Assigned corrective action. One named owner and one date, held in a ticket.
3. Verified closure. Someone confirms later that the fix worked. A re-scan is verification; a comment saying "done" is an assertion.
4. Escalation to management review. Findings and closure status go upward, and across to whoever performs the independent review under Annex A 5.35.

Automation can start the loop for you. Failed checks raise tickets with owner and severity, so nobody has to remember to log anything, and the tool that raised the ticket confirms the closure.

If a fix will miss the next review, record progress on the ticket instead of letting it vanish. An open finding with a visible trail reads as a loop that works.

Firefighting the symptom is the common failure. The same nonconformity then returns every cycle, and auditors read that as the loop not working. Asking why is the cheapest step in the loop and the one firms most often skip.

What evidence proves ISO 27001 A.5.36 is working?

An auditor testing ISO 27001 A.5.36 expects five things: the one-page review schedule with management approval, completed review records across at least two cycles, a findings register showing cause analysis and verified closure, the technical outputs behind the reviews, and management review minutes. Dashboards and tickets you already produce usually qualify.

Most of it is a by-product of the routine. Here is where each item comes from:

• Schedule: written once and approved at a management review.
• Review records: dashboard exports and sign-offs saved on each cadence date.
• Findings register: an export from the ticketing system, with owner, dates, cause and closure check.
• Technical outputs: scan results, benchmark reports and access review exports, already generated by the tools.
• Management review minutes: a standing agenda line for compliance results.

Two cycles is the threshold because one cycle is a snapshot and two is a routine. The auditor wants to see the loop having run, with different dates on the records.

Informal checks are the usual gap. A manager who glanced at the access list and found it fine did the work but kept no proof of it. A dated two-line entry in the register closes that gap.

A review that leaves no record, in audit terms, never happened.

What will an auditor ask about A.5.36, and how is it graded?

Expect questions such as how you know teams follow policies between audits, and to walk through one nonconformity from discovery to verified closure. The auditor samples a review record and follows one finding, checking for cause analysis and closure verification. Missing cause or closure grades minor, aggregating to major as a pattern; no review activity grades major.

Questions to expect in the room:

• How do you know your teams follow these policies between audits?
• Show me the last compliance review for this area. What did it find, and what happened next?
• Walk me through one nonconformity from discovery to verified closure.
• How did you decide these review frequencies?
• How is this different from your internal audit, and do the results reach the independent reviewer?

Choose your walk-through finding before the audit. Pick one with a clear cause, a dated ticket and a re-scan, and rehearse it with the manager who owns it.

Expect cross-referencing. An incident or internal audit finding from earlier in the visit will be tested against whether these reviews should have caught it, so know which checks cover which areas.

Grading follows the usual certification-body practice. No managerial review activity at all, with controls failing around the unchecked gap, means the requirement is missing outright, which grades major. A finding never root-caused, or a closure never verified, grades minor, and the same gap repeated across areas or cycles aggregates to a major.

A firm whose managers catch and close their own findings walks into audits, client reviews and regulator conversations with evidence that the system runs itself. The next enterprise questionnaire becomes an export, not a scramble.

Frequently asked questions