UnixTime

Research Note

ISO 27001 A.5.36 - Compliance with Policies, Rules and Standards for Information Security

The organization must regularly check whether people, processes, and systems comply with its information security policies, rules, standards, and technical implementation requir...

On this page

Requirement

Requirement lens

Treat this as the control objective. The implementation, evidence, and audit sections explain how to make it operational and provable.

“Compliance with the organization’s information security policy, topic-specific policies, rules and standards shall be regularly reviewed.”

Plain-language meaning

The organization must regularly check whether people, processes, and systems comply with its information security policies, rules, standards, and technical implementation requirements.

Why this matters

Policies and standards are useless if nobody checks whether they are followed. Regular compliance review finds drift, weak enforcement, misconfigured systems, repeated nonconformities, and control failures before they become incidents or audit findings.

Implementation guidance

Implementer focus

Turn this section into owners, procedures, records, review cadence, and evidence locations. A control is not implemented until it operates repeatedly.

  1. Define management compliance reviews for each area of responsibility, using formal reviews, spot checks, or both.
  2. Define technical compliance checks for systems, networks, servers, cloud platforms, firewalls, endpoints, and other information systems based on risk.
  3. Ensure technical checks are performed only by competent and authorized people, especially where testing tools, vulnerability scanners, or penetration testing are used.
  4. Control security testing tools so unauthorized use is prevented and suspicious use is handled as a security incident.
  5. Plan and document review scope, frequency, methods, responsible reviewers, tools, authorization, and expected evidence.
  6. Record results, nonconformities, root causes, corrective actions, follow-up checks, and effectiveness evidence.
  7. Look for similar issues in other systems or areas when one nonconformity is found.
  8. Report management review results into internal review, management review, or other governance reporting routes.

Audit guidance

Auditor focus

Look for evidence that the process operates in practice, not just that a document exists.

Auditors should verify that management and technical compliance reviews are planned, risk-based, documented, authorized, performed by competent personnel, and traceable from findings to corrective action and effectiveness checks. They should sample both managerial policy compliance and technical conformity evidence.

Evidence examples

Evidence quality

Strong evidence links requirement, owner, action, date, review, and outcome. Weak evidence usually proves only intent.

Evidence What it proves
Compliance review plan covers policies, rules, standards, management areas, technical systems, frequency, method, and owner. Supports design, implementation, operation, or review
Management reviews or spot checks show policy compliance in each area of responsibility. Supports design, implementation, operation, or review
Technical compliance check records Show relevant systems were checked by competent authorized personnel
Testing tool authorization and scope records Show tools are controlled, approved, and scoped before use
Findings trace to root cause, corrective action, implementation evidence, and effectiveness verification. Supports design, implementation, operation, or review

Strong evidence

  • Compliance review plan covers policies, rules, standards, management areas, technical systems, frequency, method, and owner.
  • Management reviews or spot checks show policy compliance in each area of responsibility.
  • Technical compliance checks cover relevant systems and are performed by competent authorized personnel.
  • Testing tools are controlled, approved, and scoped to prevent misuse or accidental testing of wrong systems.
  • Findings trace to root cause, corrective action, implementation evidence, and effectiveness verification.
  • Patterns are reviewed to find similar issues elsewhere.

Weak evidence

  • Compliance review is only an annual attestation.
  • Technical checks are informal and not risk-based.
  • Scanning or testing tools are available to unauthorized users.
  • Findings are tracked in spreadsheets without closure evidence.
  • Root cause is not analyzed and similar issues are not checked elsewhere.
  • Managers cannot show how they review compliance in their own areas.

Common failures

Implementation watchouts

These are the fastest ways this topic fails in real ISMS work.

Failure Why it matters
Managers do not review compliance in their areas Policy compliance becomes a security-team-only activity
Technical checks are not performed by competent authorized personnel Testing can miss issues or disrupt systems
Security testing tools are uncontrolled Tools can be misused or mistaken for attack activity
Findings are not traceable to action and retest Nonconformities may remain unresolved
Patterns are not analyzed The same technical or behavioral issue can exist elsewhere

Exam traps

Exam focus

Read these as distractor patterns. Exams often test scope, timing, ownership, applicability, and evidence quality.

  • A.5.36 is about regular compliance review against policies, rules, and standards.
  • Manager reviews and technical checks are both relevant.
  • Technical compliance testing must be authorized and competent because it can disrupt systems or create legal risk.
  • Findings should trace to root cause, corrective action, follow-up, and effectiveness.
  • One nonconformity should prompt consideration of similar issues elsewhere.

KB-ready summary

Quick refresher

Use this section for last-day review and for explaining the topic to a control owner.

A.5.36 is part of the assurance and operations governance layer. The practical test is whether the organization can show planned review, controlled work, competent owners, documented evidence, traceable findings, and corrective action where the process does not work.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Organizational controls
  • Governance
  • Audit
  • Compliance review
  • Policy compliance
  • Technical compliance
  • Nonconformity

Note Metadata

Aliases: A.5.36, Compliance with Policies, Rules and Standards for Information Security

Source: 02 Annex A Organizational Controls/A.5.36 Compliance with Policies, Rules and Standards for Information Security.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

10

links

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.