Annex A 5.36: Compliance With Policies, Rules and Standards for Information Security

Annex a 5.36: compliance with policies, rules and standards for information security requirement means you must (1) define the information security policies, rules, and standards that apply to your organization, (2) make them actionable for teams and third parties, and (3) prove—through recurring checks and evidence—that people and systems actually follow them ¹.

Key takeaways:

• Treat 5.36 as an “operational compliance” control: rules exist, are communicated, are embedded into workflows, and are tested with evidence.
• Your fastest path is a policy-to-control mapping plus a recurring compliance monitoring cadence with clear owners and exceptions handling.
• Auditors will focus on proof of ongoing adherence, not policy quality alone; build evidence capture into normal operations.

A 5.36 fails most often for a simple reason: teams can show a library of security policies, but they cannot show that the policies are followed consistently across engineering, IT, security operations, and third parties. Annex A 5.36 is the control that closes that gap. It forces you to operationalize the “governance layer” of your ISMS so it becomes measurable behavior, not a PDF repository ¹.

For a Compliance Officer, CCO, or GRC lead, this requirement is about turning expectations into repeatable checks: Who owns each policy requirement? Where is it implemented (technical controls, procedures, contracts)? How do you detect drift? What happens when a policy is violated? If you can answer those questions with documents, tickets, logs, and review records, 5.36 becomes straightforward to defend in an ISO 27001 audit or internal assessment ².

This page gives you requirement-level implementation guidance you can execute quickly: applicability, step-by-step actions, evidence to retain, audit traps, and a practical execution plan.

Regulatory text

Provided excerpt (framework summary): “ISO/IEC 27001:2022 Annex A control 5.36 implementation expectation (Compliance With Policies, Rules and Standards for Information Security).” ¹

Operator interpretation (what you must do)

To satisfy Annex A 5.36, you must be able to demonstrate all of the following, using your own documented system:

1. Your organization has defined information security policies, rules, and standards relevant to its risks and operations ².
2. Those requirements are communicated and made actionable for the people and teams who must follow them, including where relevant third parties ³.
3. You verify compliance on a recurring basis (monitoring, checks, reviews, testing, or attestations) and you can produce evidence that the verification happened and what it found ².
4. Noncompliance is handled through a defined mechanism (exceptions, remediation, or disciplinary paths, as appropriate), and you can show closure ³.

Think of 5.36 as the “proof-of-follow-through” control for your entire policy framework.

Plain-English requirement

You need a reliable way to confirm that people and systems follow your security policies, rules, and standards—and to show that confirmation to an auditor. Writing policies is not enough; you must embed them into processes (access requests, change management, SDLC, incident response, supplier onboarding) and periodically check adherence with recorded results.

Who it applies to

Entity scope

This applies to service organizations pursuing or maintaining ISO/IEC 27001 certification or alignment ².

Operational scope (where it shows up)

Annex A 5.36 becomes “real” anywhere a documented security expectation exists:

• Corporate / ISMS governance: policy lifecycle, approvals, exceptions, training acknowledgments.
• IT operations: account provisioning, privileged access, patching, logging, endpoint management.
• Engineering / product: secure SDLC rules, code review requirements, secrets handling, deployment approvals.
• Security operations: alert handling rules, incident escalation, vulnerability remediation expectations.
• Third-party management: contract security clauses, security requirements, onboarding controls, periodic reassessments.

If a policy applies but you cannot show implementation and verification in these workflows, 5.36 is exposed.

What you actually need to do (step-by-step)

Step 1: Define your “binding requirements set”

Create a single inventory that lists the documents that count as binding information security requirements, such as:

• Information Security Policy (top-level)
• Acceptable Use Policy
• Access Control Standard
• Cryptography Standard
• Secure Development Standard
• Supplier / Third-Party Security Standard

Output: “Information Security Policy & Standards Register” (a table is fine). Owner: ISMS manager / GRC lead. Audit test: Can you show the current approved versions and the scope they apply to? ²

Step 2: Translate policies into testable statements

For each policy/standard, break requirements into testable controls, written as “shall” statements you can verify. Example:

• “Privileged access shall require documented approval” becomes a test: “Sample privileged access grants show recorded approval.”

Output: Policy-to-control mapping (policy clause → control objective → verification method → evidence source). Tip: Keep it lightweight. Start with the policies that auditors will sample first: access control, logging, change management, incident response.

Step 3: Assign ownership and embed into workflows

For every mapped requirement, assign:

• Control owner (person accountable)
• System of record (IAM tool, ticketing system, CI/CD logs, MDM console, etc.)
• Operational procedure (how teams comply day-to-day)
• Exception path (how deviations are approved and time-bounded)

Output: RACI or responsibility notes embedded in the control mapping. Common hangup: “Security owns the policy” is not the same as “Security operates the control.” In practice, IT and Engineering often operate the control; Security/GRC monitors it.

Step 4: Establish recurring compliance checks (monitoring + reviews)

Define a cadence for verifying adherence. Choose checks that match how the control is implemented:

• Automated evidence: access logs, configuration baselines, CI checks, device compliance dashboards.
• Process evidence: ticket sampling for approvals, change records, incident records, vendor onboarding packages.
• Human attestations: targeted attestations only where automation is unrealistic.

Output: Compliance Monitoring Plan for 5.36 (what gets checked, by whom, where evidence is stored). Minimum viable approach: a standing monthly or quarterly sampling plan plus trigger-based checks after major changes.

Step 5: Manage noncompliance: exceptions, findings, and remediation

Auditors expect reality: exceptions happen. What matters is control.

• Create an Information Security Exception Request process: scope, rationale, compensating controls, expiry date, approver, review date.
• Track noncompliance as findings in a register (risk rating, owner, due date, status).
• Tie repeated or high-impact violations to your corrective action process.

Output: Exception log + findings log + remediation tickets linked to closure evidence.

Step 6: Prove it with recurring evidence capture (make it audit-ready)

Annex A 5.36 is frequently lost on evidence organization. Fix it by designing “evidence packets” per requirement area:

• Access control packet (approvals, reviews, admin accounts)
• Change management packet (CAB approvals, emergency changes)
• Secure development packet (PR reviews, pipeline checks)
• Third-party packet (due diligence, contract clauses, reassessments)

Daydream fit (earned mention): If you struggle to keep policy-to-control mappings, owners, and recurring evidence in one place, Daydream-style workflows help by linking each 5.36 requirement to control operation steps and scheduled evidence requests, so you can produce an audit-ready trail without chasing screenshots at the last minute.

Required evidence and artifacts to retain

Use this as an evidence checklist. Store it in your GRC repository with clear naming and dates.

Evidence	What it proves	Typical source
Approved policy/standard documents + version history	Requirements exist and are controlled	Document system / ISMS repository
Policy & Standards Register	You know what is binding	GRC register
Policy-to-control mapping	Requirements are translated into controls	Control matrix
Communication records (training, acknowledgments, intranet posting)	People were informed	LMS, HR system, intranet logs
Monitoring plan + completed check records	Ongoing compliance verification	Checklists, scripts, dashboards
Sample test results (access tickets, change tickets, config exports)	Controls operate as written	ITSM, IAM, cloud consoles
Exception log (approved, time-bounded)	Deviations are governed	GRC/ITSM workflow
Findings log + remediation evidence	Noncompliance is corrected	Ticketing + verification notes
Management review or governance minutes (where relevant)	Oversight and decisions	Meeting minutes

Common exam/audit questions and hangups

Questions auditors ask (and what to have ready)

1. “Which policies and standards are in scope, and who approved them?”
   Have your register, approval records, and current versions ready.

2. “Show me evidence that staff follow the access control standard.”
   Provide a sample set of access grants with approvals, plus periodic access reviews where applicable.

3. “How do you know engineering follows secure development rules?”
   Show PR review settings, pipeline controls, and a sample of completed reviews tied to the standard.

4. “How do you detect and handle violations?”
   Provide your monitoring plan, findings log, and examples of exceptions with expiry and compensating controls.

Hangups that trigger nonconformities

• Policies exist but no defined verification method exists per policy requirement.
• Checks happen informally but no evidence is retained.
• Exceptions are granted in chat/email with no expiration or compensating controls.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating 5.36 as “policy management.”
   Avoidance: Build a monitoring plan and show results. Policies are inputs; evidence is the output.

2. Mistake: One generic annual attestation for everything.
   Avoidance: Use targeted attestations only where needed; prioritize system evidence and sampling for operational controls.

3. Mistake: No ownership below the CISO/Head of Security.
   Avoidance: Assign control owners in IT, Engineering, and Security Ops where the work happens.

4. Mistake: Exception process without expiry.
   Avoidance: Require expirations and periodic review; expired exceptions must be reapproved or closed.

5. Mistake: Third-party requirements not enforced.
   Avoidance: Map supplier security requirements into onboarding and contract steps; retain due diligence and contract artifacts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control. Practically, 5.36 affects risk in two direct ways:

• Audit risk: weak evidence of operational compliance often drives ISO 27001 nonconformities because the organization cannot demonstrate that governance controls operate ².
• Incident risk: policy gaps that are not monitored tend to become “unknown drift” (privilege creep, unapproved changes, logging disabled). 5.36 pushes you to detect drift early through recurring checks ³.

Practical 30/60/90-day execution plan

Use this as an execution outline; adjust sequencing to your audit calendar and resourcing.

First 30 days (stabilize scope and accountability)

• Build the Policy & Standards Register (binding requirements set).
• Identify top policy families that drive operational behavior (access, change, SDLC, incident, supplier).
• Create the first version of the policy-to-control mapping for those families.
• Assign control owners and define systems of record.
• Stand up an exception workflow and central exception log.

Days 31–60 (start monitoring and capturing evidence)

• Write a compliance monitoring plan aligned to mapped requirements.
• Run initial sampling checks (access grants, change tickets, SDLC reviews, logging settings) and record results.
• Open remediation tickets for any gaps and link them to findings.
• Build evidence packets per domain so evidence lands in a consistent place.

Days 61–90 (harden and make it audit-ready)

• Repeat monitoring checks to show recurrence (not a one-off scramble).
• Tune checks to reduce manual effort (scripts, dashboards, ticket queries).
• Review exception log for expirations and compensating controls.
• Prepare an “auditor view” folder: register, mapping, monitoring plan, last two cycles of evidence, findings and closures.

Frequently Asked Questions

Do we need to prove compliance with every policy statement?

You need a defensible method to verify compliance with the policies, rules, and standards that govern information security, with evidence that checks occur and issues are addressed ². Start with high-impact requirements and expand coverage as your monitoring matures.

What counts as “rules and standards” versus “policies” for Annex A 5.36?

Use your internal definitions, but be consistent: policies set intent, while standards/rules define specific required behaviors. Maintain a register so auditors can see which documents are binding and in scope ³.

Can we meet 5.36 with training acknowledgments alone?

Training helps prove communication, but it rarely proves operational compliance. Pair acknowledgments with control evidence such as ticket sampling, configuration baselines, and recurring review records.

How should we handle exceptions without creating audit problems?

Centralize exceptions, require documented risk acceptance and compensating controls, and set an expiry with review. Auditors generally accept exceptions that are controlled, time-bounded, and tracked to closure evidence.

Does 5.36 apply to third parties?

If your policies and standards impose requirements on third parties (for example, supplier security standards), you need a way to ensure those requirements are communicated and met through onboarding, contracts, and reviews ².

What’s the simplest evidence set to pass an audit sampling for 5.36?

Keep (1) the register of policies/standards, (2) a policy-to-control mapping with owners, (3) a monitoring plan, and (4) completed monitoring records with findings and remediation tickets. That combination demonstrates definition, ownership, verification, and corrective action.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index