Control Definition
Compliance with the organization's information security policy, topic-specific policies, rules, and standards must be reviewed regularly — by the managers and owners responsible for each area — and any non-compliance found must be corrected at the cause, with the fix verified to work.
Control Objective
To verify that information security is actually implemented and operated the way the organization's own policies, rules, and standards say it is.
What This Really Means
Think of assurance as three layers, each answering a different question at a different frequency. The first layer is this control: the managers and owners of each area regularly checking that their own area follows the security policies, rules, and standards that apply to it. The second is the clause 9.2 internal audit: independent auditors, on a planned program, checking the ISMS for conformity to ISO 27001 and the organization's own requirements. The third is A.5.35: an independent review asking whether the whole approach to security still fits the organization at all. Most organizations build the second and third layers because the standard forces the conversation — and skip the first, which means policy-practice drift gets discovered once a year by an auditor instead of continuously by the people who own the work.
What A.5.36 asks for is deliberately unglamorous: each manager or service owner knows which policies and standards apply to their area, and verifies on a regular cadence that reality matches. The mechanisms scale with the area: self-assessment checklists derived from the actual policy text, automated compliance checks — configuration scanning against baselines, cloud security posture tools, the policy tests inside compliance platforms — and simple spot checks of practice against procedure. Frequency follows risk: areas handling production access or customer data deserve quarterly attention; low-risk areas can run annually. The output is a recorded result either way, because an unrecorded review is indistinguishable from no review.
The second half of the control is what happens when a check fails. Non-compliance is not just fixed — it is investigated: identify the cause, decide and implement corrective action, then verify the action worked and look for the same weakness elsewhere. The distinction between correction (re-enable the misconfigured setting) and corrective action (find out why the setting drifted and stop it recurring) is exactly the discipline the rest of the management system uses for nonconformities, applied at line level. Results and actions are recorded, and they feed upward — into management review, and to the independent reviewers under A.5.35 when they assess whether self-verification can be trusted.
What auditors treat as the heart of the control: managers who can answer "how do you know your team follows the policy?" with records — completed reviews, deviations found, actions closed and verified. A review program that has never found anything is read as theater, not excellence; real environments drift, and a credible first line catches some of it.
Why It Matters
Drift is the default state of any control environment. Policies decay from the day they are published — a new tool bypasses the standard, a deadline justifies one exception that becomes permanent, a re-org orphans a procedure. The only question is who finds each gap first: the manager who owns the area, the internal auditor a year later, the certification auditor at the next surveillance, or an attacker. A.5.36 exists to make the answer the manager, because every later discovery costs more.
This control is also what makes the rest of the ISMS more than paperwork. The Statement of Applicability claims dozens of controls are operating; first-line review is the cheapest ongoing test of whether that claim is true. When it is missing, the organization is certified on the strength of an annual sample — and everything between samples is hope.
Without regular first-line compliance review, organizations face:
- •Policy-practice drift – the documented ISMS and the operated reality separate quietly, and the gap is discovered by whoever looks first — often an auditor or an attacker
- •Avoidable audit findings – certification auditors sample exactly the things a manager's quarterly check would have caught, and each finding costs more to remediate under audit pressure
- •A paper ISMS – controls claimed in the SoA that nobody operates, which auditors treat as a credibility problem extending well beyond the single control
- •Repeat incidents – deviations patched without cause analysis resurface, because the conditions that produced them were never addressed
- •Hollow management assurance – compliance attestations to boards, customers, and regulators signed on assumption rather than verification
Regional Compliance Context
For Indian organizations in regulated sectors, first-line compliance verification is not just ISO hygiene — it is what periodic regulatory reporting rests on. RBI master directions expect regulated entities to monitor and report their information security compliance posture to management and the regulator, and SEBI's CSCRF requires market intermediaries to submit periodic compliance status. Those attestations have to come from somewhere: a working A.5.36 program is what lets a CISO sign them on evidence rather than assumption, and it generates the records examiners ask for first.
Implementation Guidance
Map Every Policy and Standard to a Responsible Manager
Build a compliance ownership matrix: each policy, topic-specific policy, and technical standard mapped to the manager or service owner accountable for verifying compliance in their area. Access control policy to the IT or platform lead per system, secure development standard to engineering managers, HR security policy to HR. Unowned documents are the first finding — every row needs a name, not a team.
Translate Each Policy Into Checkable Statements
For each area, derive a short checklist from the actual policy text: concrete, verifiable statements — "all production access requests this quarter have approval records", "no shared accounts exist on system X", "laptops sampled show disk encryption enabled". Generic templates produce generic answers; checklists quoting your own rules force the reviewer to look at their own environment. Ten to twenty sharp items per area beats a hundred vague ones.
Set Review Cadences Proportionate to Risk
Schedule reviews per area based on what the area touches: quarterly for production access, customer data handling, and change management; semiannual or annual for lower-risk areas. Publish the schedule in the compliance calendar alongside internal audits so the two layers are visibly distinct and neither silently absorbs the other. Trigger out-of-cycle reviews after major changes or incidents in an area.
Automate the Checks That Machines Do Better
Wire continuous verification wherever configuration expresses policy: baseline scanning against hardening standards, cloud security posture management for cloud rules, identity governance reports for access policy, and the automated tests inside compliance platforms. Route failures to the responsible manager, not just a dashboard. Automation feeds the manager's review with evidence — it does not replace the manager's judgment on what the results mean.
Record Every Review and Its Result
Capture each completed review as a record: who reviewed, when, against which checklist version, what was found, with evidence references for the answers. Fully-compliant results get recorded too — the record is what distinguishes a working program from a claimed one. Lightweight forms, tickets, or a compliance platform all work; the medium matters less than the habit.
Drive Deviations Through Cause Analysis and Verified Correction
When a review finds non-compliance, log it with an owner and due date, fix the immediate issue, then ask why it happened — unclear policy, missing training, broken process, tooling gap — and act on the cause. Verify the corrective action actually worked before closing, and check whether the same weakness exists in sibling areas. Route entries through the same corrective-action register the ISMS uses for audit nonconformities.
Report Results Upward and Into the Other Assurance Layers
Summarize compliance review results — coverage, findings, aging actions, trends — as a standing input to management review, and hand them to independent reviewers under A.5.35 and internal auditors planning clause 9.2 work. Recurring deviations in one area are a signal the policy or the area needs redesign, not another reminder email. The three layers only function as a system when the first one's output reaches the other two.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.36:
Documentation
- Compliance ownership matrix mapping each policy and standard to the manager responsible for verifying it
- Completed self-assessment checklists or review records with dates, reviewers, results, and evidence references
- Automated compliance reports — configuration scans, posture dashboards, platform test results — feeding the review cycle
- Deviation log with cause analysis, corrective actions, owners, due dates, and effectiveness verification
- Management review inputs and minutes showing compliance status reported and acted on
Interviews
- Line managers or service owners on how they verify their own area's compliance — and the last deviation they found
- CISO or ISMS manager on how the review program is scoped, scheduled, and tracked across areas
- The owner of a recent deviation on what caused it and how the fix was verified as effective
Observations
- An automated compliance check or dashboard run live, with failures traced to the responsible manager's queue
- A sampled deviation followed from detection through cause analysis to verified closure
- A recent self-assessment answer tested on the spot against the actual system configuration or practice it attests to
Practitioner Insights
At Stage 2 I interview line managers, not just the CISO, and the question that decides this control is "how do you know your team follows the access policy?" When the answer is "the security team checks that", the control has already failed — A.5.36 is precisely the layer where managers verify their own area, distinct from internal audit and from independent review. The organizations that pass cleanly can name their three assurance layers and show me the first one's records: completed checklists, deviations found, actions closed. The ones that struggle have one annual audit doing the work of all three and a year of drift between samples.
The failure mode I see most is the all-green self-assessment — a generic template where every manager ticks "compliant" in ten minutes because nothing in it references their actual systems. Two fixes change everything: derive the checklist from your own policy text so each item names a real rule, and require an evidence reference for every answer — the report, the screenshot, the ticket ID. A small company does not need a GRC platform for this; a fifteen-line quarterly checklist per area, honestly completed and filed where you can find it, is exactly the evidence an auditor wants. A finding rate of zero across a year is not a good sign — it means the checks are not really looking.
Common Challenges & Solutions
Challenge
Managers see compliance checking as the security team's job, not theirs.
Solution
Make the ownership explicit and management-backed: the compliance matrix names each manager, A.5.4 management responsibilities gives the mandate, and the security team's role is defined as building checklists and tooling, not doing the checking. Brief managers on why first-line review exists — they find drift cheapest because they see the area daily. Track completion rates in management review so non-participation is visible.
Challenge
Reviews happen informally, but nothing is recorded — so at audit there is no evidence the control operates.
Solution
Lower the recording cost to near zero: a short form, a recurring ticket per area, or a compliance platform task that captures reviewer, date, checklist, and result in minutes. Record clean results too, since the absence of findings still needs proof the look happened. The rule that sticks: a review that produced no record did not happen.
Challenge
Self-assessments degrade into box-ticking — every quarter, every area, all green.
Solution
Require an evidence reference per answer and have the second line spot-check a sample of "compliant" claims each cycle, feeding misstatements back to the manager. Rotate or refresh checklist items so answers cannot be copied forward, and trend finding rates per area — sustained zero findings triggers a deeper look, not congratulations. Honest amber is the culture to reward.
Challenge
Deviations get quietly fixed without cause analysis, so the same issues recur every cycle.
Solution
Separate correction from corrective action in the deviation log: one field for the immediate fix, one for the cause, one for the action that prevents recurrence, one for the effectiveness check. Treat a repeat deviation as an automatic escalation — it is evidence the previous action failed. Reuse the ISMS corrective-action process rather than inventing a parallel lightweight one that skips the discipline.
Challenge
Teams cannot articulate how this differs from internal audit and independent review, so layers duplicate or drop work.
Solution
Document the three layers in one paragraph of the ISMS manual: A.5.36 is managers verifying their own areas continuously; clause 9.2 is independent audit of ISMS conformity on a planned program; A.5.35 is independent review of whether the whole approach remains fit. Scope each layer's calendar separately and let each consume the previous one's output. The written mapping ends both the duplication and the audit-day confusion.
