What A.5.36 asks you to prove about policy compliance
A.5.36 asks the organization to show that its information security policy, topic-specific policies, rules and standards are actually followed, and that this is checked on a regular basis. Having the documents is not enough. An assessor will look for a repeatable review process, evidence that the reviews happened, and proof that gaps were tracked to closure. The control merges two 2013 controls, A.18.2.2 on compliance with security policies and standards and A.18.2.3 on technical compliance review, so the 2022 edition treats policy adherence and technical verification as one job. The risk is drift. A policy can say that administrator accounts use multi-factor authentication, that laptops are encrypted and that changes need a second approver, while the environment quietly departs from those rules. Drift usually builds up through exceptions that are granted and never revisited, tools that are retired without updating the standards they supported, and new systems that were never brought under the policy. The reader's first job is to list which policies and standards make specific, checkable promises, because those are the ones an assessor will test.
Two things make this control hard in practice. The first is that managers are asked to review compliance in their own areas, which tends to produce confirmations rather than findings. Reviews work better when the manager's checklist is tied to named evidence, such as an access list exported from the identity provider, and when someone outside the team samples the results. The second is that technical compliance checks often run and produce reports that nobody owns. A failing check with no ticket, owner or due date does not satisfy the control. Before the next audit, confirm who receives each check's output, who decides on remediation, how exceptions are approved and how long they last, and whether the review records show that decisions were made.
Which policies, systems and teams a compliance review must cover
A.5.36 is only as strong as its scope. Before any review runs, the organization must decide which policies and standards it is checking, which systems get technical compliance checks, who owns each managerial review, and how suppliers operating systems on its behalf fit in. Each decision below changes the evidence an assessor will ask for.
Policy and standard inventory
List the information security policy, every topic-specific policy under it, and the rules and standards that staff must follow, such as hardening baselines and secure configuration standards. Record the owner and review date of each one. An assessor who asks how you know a policy is being followed will expect every item on this list to have a named check. Confirm that nothing is missing from the inventory before you scope the reviews.
Systems and endpoints under technical checks
Decide which servers, cloud accounts, containers and endpoints are in scope for automated configuration and compliance checks. The in-scope population must match the asset inventory from A.5.9, or the review will miss systems that auditors can find. Document any exclusions with a reason and an owner, such as legacy hosts being retired on a fixed date.
Managers who own each review
Assign each policy and standard to a manager who is accountable for checking compliance in their area, and state how often that manager reviews it. Managers are not the same people as the independent reviewers under A.5.35. Write the assignment into the role descriptions from A.5.2 so the duty is not left to goodwill. Ask who signs off on a review that finds gaps.
Suppliers that operate systems for you
When a supplier runs a platform, hosts data or administers systems on your behalf, decide whether its configurations and policy adherence fall inside your review, and how you obtain evidence of them. Contract terms from A.5.20 and supplier monitoring from A.5.22 supply the rights and reports. Without them, you cannot show that outsourced systems meet the same rules as your own.
Exceptions and their approval
Every rule that a system cannot meet needs a recorded exception, an approver, a compensating measure and an expiry date. Exceptions are where reviews most often lose credibility, because an assessor will sample them to see whether they were approved and reviewed. Confirm who may grant an exception and how long it can last before it is reassessed.
How an assessor tests policy compliance reviews
This table sets out the steps an auditor typically takes to test A.5.36, the evidence each step asks for, and the findings that most often come up. Read it as a test plan: each row is something the assessor will sample or trace, and gaps in the first column usually lead to findings in the last.
| Test step | What the assessor samples or traces | Common finding |
|---|---|---|
| Review the policy set | The information security policy and topic-specific policies, checked for approval, version, owner and a stated review date | Policies with no named owner or review date, or policies that have not been approved by management |
| Check review frequency | Records that managers reviewed compliance in each area at the frequency the organization set for itself | Reviews planned on paper but with no record that they took place |
| Sample technical compliance checks | Configuration and compliance scan results for a sample of systems, with the policy each check tests against | Checks that exist but were never run, or results that were exported without review |
| Trace findings to remediation | For a sample of failed checks or review findings, the ticket, owner, due date, fix and re-test evidence | Findings never closed, closed without evidence of a fix, or accepted as risk without a documented decision |
| Confirm management follow-up | Management review minutes or reports showing compliance status was presented and actions were assigned | Compliance results that never reach the people who can act on them |
| Check exceptions | Approved exceptions to policies or standards, with rationale, expiry and compensating controls | Exceptions that are informal, never expire or are not visible to the reviewer |
| Compare reviews with the independent review | Whether the work of reviewers is consistent with what the independent review under A.5.35 found | Contradictory results between internal reviews and independent reviews with no explanation |
How to set up a compliance review cycle that produces evidence
This sequence turns A.5.36 from a policy statement into a repeatable cycle that assigns owners, tests policies with technical checks, records what the reviews find, and gives management a documented basis for decisions. Each step ends with an artifact an auditor can sample.
Inventory the policies and standards in scope
Start by listing every information security policy, topic-specific policy, rule and standard the organization has adopted, including the top-level policy and the topic policies that sit under it. Add the technical standards and build baselines that engineers are expected to follow, and record where each one is stored and which systems it applies to. Confirm the list with the policy owners so nothing that binds staff is missing. The output is a controlled register with a version and an applicable scope for each document, which becomes the scope boundary for every later step.
Assign a review owner and frequency
For each item in the register, name one accountable owner, usually a manager responsible for the process or system the rule governs, and set a review frequency that the organization can actually keep. Record the owner, the frequency and the reason for it in the register. Ask owners to confirm in writing that they accept the role. The output is a register where every line has a named person and a review interval, so an auditor can ask who reviews what and get a direct answer.
Define the technical checks that test each rule
For each rule that can be tested by machine, define the check that shows whether systems actually follow it. Examples include configuration baselines scanned on endpoints, device policies expressed as queries, and access or patch reports. Open-source tools such as Wazuh Security Configuration Assessment, which uses YAML policies and checks files, registry keys and processes, or Fleet policies, which pose yes or no questions to devices through osquery, can produce this evidence. Rules that cannot be tested this way need a documented manual check with a named reviewer. The output is a check catalog that maps each rule to its test, its data source and its pass or fail criteria.
Run the first review cycle
Run the manager reviews and the technical checks for the first cycle in the agreed scope. Managers review whether their area follows the policies and standards, and the technical checks report which systems pass and which fail. Keep the raw output of each check, the date it ran and the identity of the reviewer. The output is a dated set of review records and check results for every item in the register, including items that passed, because an auditor will want to see that the review covered the full scope and not only the failures.
Record findings and assign remediation
Log every departure from a policy, rule or standard as a finding with its evidence, its severity as judged by the owner, and the affected systems or people. For each finding, assign a remediation action, an accountable owner and a target date set by that owner, then track the action to closure. Where a rule is deliberately not followed, record a documented exception with its approver and its expiry. The output is a findings log where each entry shows the evidence, the decision and the closure record, which is the trail that shows the review led to action.
Verify closure and check the checks
Before a finding is closed, confirm that the fix was made and that the technical check now passes on the affected systems, using fresh evidence rather than the owner's word. Periodically check that the checks themselves still test the current rules, because policies change and checks can drift out of date. The output is closure evidence for each finding and a short record of any check that was updated, retired or added after a policy change.
Feed results into management review
Summarize the cycle for management review: which rules were reviewed, the pass and fail trends, open and overdue findings, accepted exceptions and changes proposed to policies or checks. Management decides on resourcing, risk acceptance and policy changes and records those decisions. Confirm with the organization's ISMS requirements how this review is scheduled and minuted, because the timing sits with the management system rather than with this control. The output is minuted management review input and decisions, which links A.5.36 to the broader improvement cycle.
Manager reviews versus technical compliance checks
Manager reviews test whether people and teams work the way the information security policy, topic-specific policies, rules and standards say they should. A manager looks at practice that a scanner cannot see: whether access requests are approved by the right person, whether exceptions were documented, whether staff understand the acceptable use rules, and whether a team has changed a process without updating its procedure. The review should follow a fixed checklist tied to each policy so that the same questions are asked each cycle and gaps are comparable over time.
- Scope and checklist: Each review names the policy or standard, the team, the period and the specific statements being checked, such as clean desk rules or change approval steps.
- Evidence sampled: The reviewer records what was examined, for example a sample of tickets, approvals or training acknowledgements, and the sample size chosen.
- Findings and actions: Each deviation is logged with an owner, a corrective action and a due date, and linked to the risk register where relevant.
- Sign-off: The reviewing manager signs the record, and a more senior owner accepts the residual findings. Confirm with your certification body who it expects to sign and how it wants the record kept.
- Limits: Manager reviews depend on people reporting honestly and on samples that may miss rare failures, so they rarely prove that a configuration holds across every device.
Check that each review has a dated record, a named reviewer and a traceable follow-up for every finding.
Technical compliance checks compare systems against defined configuration and policy rules and report which devices pass or fail. They run on a schedule or continuously, cover every in-scope endpoint rather than a sample, and produce output that can be exported as dated evidence. Open-source tools cover this ground in different ways, so the choice depends on which systems you need to check and what rules you have written.
- Configuration assessment: Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and checks files, directories, registry keys and running processes. It also recommends remediation steps.
- Yes or no policy queries: Fleet policies ask devices yes or no questions written as osquery queries, and the policies page shows which devices in each fleet pass or fail each policy.
- Exported evidence: Keep scan reports, policy definitions and version history together, so an assessor can see what rule was applied, to which asset and on which date.
- Exception handling: Record approved deviations with an owner and expiry date, so failing checks are either fixed or formally accepted.
- Limits: Automated checks only test what has been written as a rule. They cannot tell whether a policy is appropriate, and they do not cover behavior such as a manager approving a request outside the process.
Before relying on a check, confirm which assets it reaches, which rules it applies, and whether its exports carry dates and asset identifiers that an auditor can trace.
Neither review type is sufficient alone. Technical checks show that a setting is present on a device at the time of the scan, while manager reviews show whether the surrounding process is followed and whether the rule itself still fits the business. Auditors generally expect to see both, and a gap in either one tends to surface as a finding. The useful pattern is for technical results to trigger manager follow-up and for manager findings to become new technical rules where they can be automated.
- Technical failure to manager review: A failing configuration check on a set of laptops prompts the manager to find out why the exception exists and whether it was approved.
- Manager finding to technical rule: A recurring process lapse, such as unapproved software installs, can become a query that flags it on every device.
- Shared calendar: Schedule technical scans and manager reviews against the same policy list so each policy has both a technical and a human check.
- Shared records: Link scan results and review findings to the same corrective action log.
- Illustrative example: A quarterly review finds that offboarding steps are skipped for contractors, and a technical query then checks for active accounts on terminated identities.
Ask your implementation partner or auditor to confirm how these links will be shown in your evidence pack before you start.
Evidence that passes A.5.36 and how to keep it current
A.5.36 is tested by what the organization can show over time, not by a policy document alone. The artifacts below fit together: a schedule sets when reviews happen, the records prove they did, and the findings flow into exceptions and remediation. Keeping them current means generating as much of this as possible from systems rather than rebuilding it before each audit.
Review schedule and owners
A dated calendar listing each information security policy, topic-specific policy, rule and standard, the named owner of each, and the review interval the organization has set. Auditors check that the schedule covers every document in the ISMS and that reviews happened when the schedule said they would. Keep it in the same system as the policy register so a missed date surfaces as a task rather than a surprise. Confirm the intervals with your own risk appetite, since the standard does not fix them.
Signed manager review records
Records in which line managers confirm that their teams follow the policies and rules relevant to their area, with the date, the reviewer, the scope checked and any issues raised. A signed attestation with no scope is weak evidence, so ask for the specific rules covered in each review. These records show that A.5.36 is applied by managers, not only by the security team. Store them with the reviewer's identity from your directory so the signature can be traced.
Dated technical compliance check reports
Output from automated checks that compare live systems with the required configuration, such as endpoint policy queries or configuration assessments, each with a timestamp and the policy version it tested against. Auditors sample these reports against systems on the asset inventory to confirm the checks cover real assets. Open-source agents can produce pass and fail results per device, which makes trends visible across review cycles. Confirm which checks your tools can run on each platform before relying on them as evidence.
Exception register with approvals
A register of every approved deviation from a policy or standard, with the business reason, the compensating control, the approver, the expiry date and the review date. Exceptions are where auditors look first, because an unrecorded deviation is a nonconformity. Set a maximum duration for each exception so they cannot quietly become permanent. Review the register at each management review and close exceptions as systems are brought into line.
Remediation tickets linked to findings
Tickets that record each noncompliant result, the owner assigned, the target date, the fix applied and the verification that followed. The link from finding to ticket to closure is what proves the organization acts on what reviews find. Tickets that close without a re-check are a common gap, so require a passing result from the next check before closing. Export ticket history with the check report so both sides of the loop can be sampled together.
Management follow-up minutes
Minutes from management meetings that summarize review results, list overdue remediation, record decisions on exceptions and set actions with owners. These minutes connect the operational reviews to top management oversight. Keep the agenda fixed so every cycle covers the same inputs, which makes gaps easy to spot. Generate the summary of open findings from the ticket and exception data so the minutes reflect the records rather than memory.
What meeting A.5.36 costs in money and effort
This table breaks the cost of running A.5.36 reviews into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to see where self-hosted open-source tooling can reduce license spend, while the staff time to review and act on findings stays with your organization.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Tooling or licenses | Software vendor or open-source project; self-hosted infrastructure cost | Licenses recur; self-hosted tools carry infrastructure and upkeep cost | Number of endpoints, users or cloud accounts licensed; whether checks run on self-hosted tools |
| Engineering time to build checks | Internal platform or security engineers, or an implementation partner under a written scope | One-time build, then recurring maintenance when policies change | Number of policies mapped to automated checks; how much existing configuration can be reused |
| Manager time for reviews | Internal managers who attest that their teams follow policy | Recurring at the review frequency your policies set | Number of policies and teams in scope; how much review evidence is generated automatically |
| Evidence upkeep | Internal compliance or GRC staff who store, label and retrieve results | Recurring | Retention period, how results are stored, and how often checks are run and exceptions tracked |
| Remediation of findings | Asset and control owners who fix failing settings, plus engineers | Variable, driven by the number of failing checks each cycle | Quality of baseline configuration, speed of change management, and clarity of exception approval |
| External review and auditor sampling | Independent certification body or auditor, who charges for audit days under its own terms | Recurring at each audit cycle | Size and complexity of scope, number of sites, and how readily evidence can be sampled |
| Independent review input | Reviewers outside the area reviewed, under A.5.35 | Recurring at planned intervals | Whether internal reviewers are independent of the teams they review |
Who owns policy compliance reviews and who can help
The organization owns its controls, so the review itself belongs to people inside it. Policy owners decide which policies, topic-specific policies, rules and standards apply and whether they still reflect how the business works. Managers review compliance within their own areas, and engineers run the technical checks and act on failures. None of this can be handed to a consultant, because the organization must show that its own people reviewed, decided and followed up.
- Policy owners: approve the review scope, set the review cycle and sign off on any changes to policies or standards.
- Line managers: confirm that their teams follow the policy, topic-specific policies and procedures, and record what they found.
- Engineers: run or schedule technical compliance checks, triage failures and fix or risk-accept each one.
- Risk and compliance leads: track findings to closure, escalate repeat failures and feed results into management review.
- Management: receive the review results, decide on resources and keep an audit trail of decisions.
Check that each named owner has accepted the role in writing and that the review calendar exists before any outside party is engaged.
An implementation partner can prepare the systems that make reviews repeatable. Typical work includes selecting and configuring tools that run technical compliance checks, writing check definitions against the organization's own policies, wiring results into ticketing and reporting, and organizing evidence so a reviewer can find it. DeployOpen works this way for self-hosted open-source platforms inside the client's own infrastructure. The partner does not decide what the policy requires, approve exceptions or judge whether the organization is compliant.
- Tooling setup: deploying check engines such as configuration assessment or device policy tools in the client's environment.
- Check design: translating the organization's own standards into tests the tools can run, with the owner approving each one.
- Evidence pipelines: scheduling exports of results, retaining them and linking them to the policy they support.
- Documentation: recording how reviews run, who receives results and how exceptions are raised.
- Testing support: helping the organization confirm the checks fire correctly before a review is relied on.
Ask for a written scope listing which artifacts the partner delivers and confirm that the organization keeps ownership of the policies, decisions and results.
Only an independent auditor or certification body tests whether the organization meets A.5.36 and issues any report or certificate. The auditor samples the review records, checks that managers and technical checks covered the stated scope, and asks whether findings were acted on. Because the auditor evaluates evidence that the organization and its partner prepared, the auditor must not have designed the checks or the review process being judged. The line is clear: the partner prepares evidence, the auditor tests it and issues the result.
- Sampling: the auditor picks review cycles and asks to see the records behind them.
- Traceability: the auditor follows a finding from the check result to the decision and the fix.
- Independence: the auditor and the team that designed the review must be kept separate, and any conflict should be declared.
- Reporting: only the auditor's own report or certification decision counts for external parties.
- Certification body checks: for ISO/IEC 27001 certification, the body must be accredited, so confirm its status before contracting.
Before engaging an auditor, confirm in writing that the firm will not design the controls it is testing and that the scope of its work is agreed in advance.
Where policy compliance reviews usually fall short
Most organizations run some form of policy compliance review, yet assessors still raise findings against A.5.36 for the same few reasons. The gaps below cluster around evidence, coverage, ownership, accuracy of policies and the handling of exceptions. Each card names the gap and the fix an auditor will expect to see.
Reviews that are never recorded
A manager may check policy compliance in a meeting or a message, but without a dated record of scope, findings and sign-off, the review cannot be shown to an auditor. A.5.36 expects regular reviews, so the assessor will ask for the last several cycles and their outputs. Check that every review leaves a dated record naming the reviewer, the policies covered and the decisions taken. Fix: keep a standing review log with one entry per cycle.
Technical checks covering part of the estate
Automated configuration checks often run on the servers that were onboarded first while newer cloud accounts, laptops or containers sit outside the scan. An assessor comparing the asset inventory against the scanner's coverage will find the gap quickly. Confirm that the set of monitored endpoints matches the inventory and record any systems that cannot be scanned. Fix: reconcile scanner coverage against the asset inventory each review cycle.
Findings with no owner
A review that identifies a deviation but does not assign it to a named person tends to stall, and the same finding reappears in the next cycle. Auditors look for an owner, a due date and evidence of closure for every finding. Check whether each open item in the review log names an accountable role rather than a team. Fix: assign one named owner and a close-by date to every finding when it is logged.
Policies that do not match practice
A policy can describe a control the organization no longer runs, such as an access approval step that teams bypass in practice. Reviews that test only whether people know the policy, and not whether the policy reflects how work is done, leave this mismatch hidden. Compare each policy statement against the observed process and system configuration. Fix: update the policy to match reality or change the practice, and record which one was chosen.
Exceptions with no expiry
Approved deviations from policy are often granted for a project and then never revisited, so they quietly become permanent. An assessor will test whether each exception has a documented justification, compensating measures, an approver and an end date. Check the exception register for entries that have passed their end date without renewal or closure. Fix: give every exception a fixed expiry date and review it at the next compliance cycle.
Questions about meeting A.5.36
How much effort does meeting A.5.36 take?
The effort depends on how many policies, rules and standards the organization has and how many systems they touch, so there is no fixed amount to quote. The work has two parts: a recurring review cycle in which managers check their areas against the policy set, and technical compliance checks that run against endpoints, servers and cloud settings. The one-time cost is building the review calendar, mapping each policy to an owner and a check, and wiring the checks into tooling. The recurring cost is staff time for reviews and for acting on findings. Ask any provider to break its quote into setup and recurring effort, and to list which checks it will configure and which your own team must run.
Can a small team run A.5.36 without outside help?
Yes, a small team can run it if the policy set is short and the checks are automated. A workable approach is a named owner for each policy, a yearly review of the policy set in a single calendar, and automated configuration checks that report failures to one person. Teams usually struggle when the policy set is large, nobody is named to act on findings, or checks run but results are never reviewed. Before deciding, count your policies and topic-specific rules, confirm who will sign off on each review, and estimate how many hours a month that takes from people who already have other jobs.
How long before an audit should A.5.36 be in place?
It should be operating for long enough that an assessor can see the review cycle run at least once and see the findings acted on. Auditors sample evidence, so a review performed the week before the audit with no follow-up is weak evidence. Ask your certification body how many months of records it expects for controls that run on a cycle, and plan backward from your audit date. Note that the certification cycle under ISO/IEC 17021-1 is three years with at least one audit in every calendar year, so the control must keep running after the first certificate is issued, not only before it.
What does A.5.36 need from managers?
Managers own the compliance of their own teams, so the control depends on them reviewing their areas against the information security policy and topic-specific policies on a set schedule. Their tasks are to confirm that their team follows the rules, to record exceptions with a reason and an end date, and to agree corrective actions with the security function when a review finds a gap. Managers also need to know which technical checks apply to their systems so they can explain failures. Put these duties in job descriptions or performance objectives, or the reviews tend to lapse after the first cycle.
Do I need a tool to meet A.5.36?
No standard requires a specific tool. Assessors look for evidence that reviews happened and that findings were tracked to closure, and a spreadsheet, ticketing system or GRC platform can hold that record. Tools become useful when you need technical compliance checks at scale. Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies. Fleet policies ask yes or no questions of devices through osquery and show which devices pass or fail. CISO Assistant can record audits and assessments against ISO 27001. Confirm each tool's current licensing and features before you commit, and check how its output will be kept as evidence.
When should we bring in a partner for A.5.36?
Bring in a partner when the internal team lacks the time or skills to build the checks, or when the scope spans several self-hosted platforms that need configuration baselines. A partner such as DeployOpen can plan, implement and document the technical checks and the evidence they produce inside your own infrastructure, under a fixed-scope written agreement. The organization still owns the policies, the reviews and the decisions on findings. DeployOpen does not issue audit reports or certificates, and the independent certification body does that work. Ask any provider to show which deliverables it covers and which remain with your staff.
What drives the cost of A.5.36 up or down?
The main drivers are the number of policies and standards in scope, the number of systems and locations that need technical checks, the maturity of existing inventories, and whether reviews are already run for other frameworks. Costs are one-time for building the review calendar, check baselines and evidence templates, and recurring for running reviews, maintaining checks and acting on findings. Reusing one review cycle across ISO 27001 and other frameworks that ask for similar policy reviews can reduce duplicated work. When requesting a quote, ask for the scope list, the deliverables, who runs each recurring task and what changes the price.
How DeployOpen prepares A.5.36 evidence in your environment
DeployOpen prepares the systems and records behind A.5.36 but does not own the review cycle. Before work starts, the scope is agreed in writing: which policies and topic-specific policies are in view, which managers perform the periodic compliance reviews, how often each review runs, which technical checks feed it, and where the findings and follow-up actions are recorded. Your organization owns those decisions and the controls they govern. An independent auditor or certification body is the only party that issues reports or certificates, so the written scope should be reviewed with your auditor before it is finalized.
Once the scope is fixed, DeployOpen deploys and configures self-hosted tools inside your own cloud accounts, data centers or air-gapped network. Wazuh Security Configuration Assessment can scan monitored endpoints against YAML policies and report misconfigurations with remediation advice, and Fleet policies can ask yes or no questions of devices and show which ones pass or fail. Those results are only useful if the findings are triaged, owned and closed, so the configuration includes exporting dated results and linking each failure to a ticket. CISO Assistant can hold the review schedule and record the outcome of each assessment against ISO 27001. Confirm each tool's current capabilities and license terms with its vendor before relying on them.
The evidence package is then assembled for your auditor: the approved policy set and its version history, the review calendar, signed manager review records, configuration baselines and scan exports with timestamps, and the remediation trail showing that findings were acted on. Ask your auditor which samples they will draw and which format they accept, because a review record that cannot be dated or traced to an owner is usually the first thing questioned. Where you engage an implementation partner, agree in writing who maintains the evidence after handover, since A.5.36 is a recurring activity and its evidence must keep accumulating across the certification cycle.
