What is ISO 27001 Annex A 5.36?

ISO 27001 Annex A 5.36 requires organizations to regularly review compliance with their own information security policies, topic-specific policies, rules, and standards.

Creating security policies is not enough. An organization should also verify that people, processes, and technology are actually following those requirements.

In simple terms

A company may have policies saying:

• MFA is mandatory.
• Employees must use company-approved devices.
• Production access must be restricted.
• Sensitive information must be classified.
• Security incidents must be reported.
• Access rights must be reviewed.
• Backups must be tested.
• Changes to production must be authorized.
• Information must not be transferred through unauthorized channels.

A.5.36 asks:

“Are we actually following the security requirements we have established?”

This is the difference between having a policy and demonstrating that the policy is working in practice.

What A.5.36 helps an organization achieve

• Detect policy violations.
• Identify control gaps.
• Verify that employees follow security requirements.
• Verify that technical controls operate as expected.
• Identify recurring non-compliance.
• Track exceptions and corrective actions.
• Improve the effectiveness of the ISMS.
• Provide evidence of ongoing compliance to auditors and customers.

---

Why is Annex A 5.36 Important?

Many organizations have excellent-looking security policies but weak implementation.

For example:

Policy says:

All privileged accounts must use MFA.

Reality:

Two administrator accounts do not have MFA enabled.

The policy exists, but the organization is not fully compliant with its own requirement.

Similarly:

Policy says:

User access must be reviewed every quarter.

But nobody can provide evidence that the quarterly access review was performed.

This creates a gap between documented requirements and actual practice.

Simple principle

Don’t just create security policies. Regularly check whether people, processes, and systems are actually following them.

---

What Does Annex A 5.36 Require?

The organization should establish a process for periodically reviewing compliance with:

1. Information security policies.
2. Topic-specific security policies.
3. Information security rules.
4. Security standards.
5. Security procedures.
6. Applicable technical requirements.
7. Other internally established security requirements.

The review should be appropriate to the organization’s:

• Size
• Business model
• Risk profile
• Technology environment
• Regulatory requirements
• Customer requirements
• Complexity of the ISMS

The objective is not to create unnecessary bureaucracy.

The objective is to obtain reasonable evidence that established security requirements are actually being followed.

---

A.5.35 vs A.5.36 — What is the Difference?

These two controls are closely related but have different purposes.

Control	Main Question
A.5.35 Independent Review of Information Security	Is information security being independently reviewed?
A.5.36 Compliance with Policies, Rules and Standards	Are people, processes and systems actually complying with established security requirements?

Example

A company performs an independent security review once a year.

The reviewer examines:

• ISMS governance
• Risk management
• Policies
• Access control
• Incident management
• Supplier security
• Business continuity

That supports A.5.35.

During the year, the company also checks whether:

• Employees completed security training.
• MFA is enabled.
• Access reviews were completed.
• Production changes were approved.
• Security incidents were reported correctly.
• Sensitive data was handled according to policy.

That supports A.5.36.

Simple distinction

A.5.35 asks: “Has information security been independently reviewed?”

A.5.36 asks: “Are we actually following our security requirements?”

---

What Should Be Checked Under A.5.36?

The organization should determine which security requirements need periodic compliance checking.

Common areas include:

1. Access Control

Check whether:

• Users have appropriate access.
• Privileged access is restricted.
• Former employees have been removed.
• MFA is enabled where required.
• Periodic access reviews are completed.
• Shared accounts are controlled.

2. Acceptable Use

Check whether employees:

• Follow acceptable-use requirements.
• Use approved systems.
• Protect company devices.
• Avoid unauthorized software.
• Handle company information appropriately.

3. Information Classification

Check whether sensitive information is:

• Properly classified.
• Properly labelled where required.
• Stored in approved locations.
• Shared only with authorized parties.

4. Information Transfer

Check whether sensitive information is transferred through:

• Approved channels.
• Secure file-sharing platforms.
• Encrypted communication.
• Authorized third parties.

5. Incident Management

Check whether:

• Security incidents are reported.
• Incidents are classified correctly.
• Escalation requirements are followed.
• Incident records are maintained.
• Required notifications are completed.

6. Backup

Check whether:

• Required systems are backed up.
• Backup schedules are followed.
• Backups are protected.
• Restoration tests are performed.
• Backup failures are investigated.

7. Change Management

Check whether:

• Production changes are approved.
• Emergency changes are documented.
• Testing requirements are followed.
• Change records are maintained.

8. Supplier Security

Check whether:

• Required supplier assessments are completed.
• Security requirements are included in contracts.
• Supplier reviews occur as planned.
• High-risk suppliers are monitored.

9. Secure Development

For software companies, check whether:

• Code reviews are performed.
• Security testing is completed.
• Production access is restricted.
• Vulnerabilities are addressed.
• Development and production environments are appropriately separated.

---

Activities Required to Implement A.5.36

Step 1 — Identify the Security Requirements

Create an inventory of important security policies, standards, rules and procedures.

Example:

Requirement	Area	Owner	Review Frequency
Information Security Policy	Governance	CISO	Annual
Access Control Policy	Access	IT	Quarterly
Acceptable Use Policy	Employees	HR/IT	Annual
Data Classification Standard	Data	Security	Annual
Incident Response Procedure	Incident Management	Security	After incidents / Annual
Backup Standard	Resilience	IT	Quarterly
Secure Development Standard	Engineering	CTO	Quarterly
Supplier Security Standard	Third Parties	Procurement	Annual

---

Step 2 — Define What Compliance Means

A policy should have measurable requirements where possible.

For example:

Requirement:

All privileged accounts must use MFA.

Compliance test:

Review the privileged-account list and verify MFA status for 100% of privileged accounts.

Another example:

Requirement:

User access must be reviewed quarterly.

Compliance test:

Verify that quarterly access reviews were completed and approved.

This makes the review objective rather than subjective.

---

Step 3 — Establish a Compliance Review Schedule

Different requirements may require different frequencies.

Requirement	Example Frequency
Privileged access	Monthly/Quarterly
User access review	Quarterly
MFA compliance	Monthly/Quarterly
Backup compliance	Monthly
Security awareness	Quarterly/Annual
Supplier security	Annual
Policy acknowledgement	Annual
Secure development compliance	Quarterly
Information classification	Periodic
Acceptable-use compliance	Annual/Periodic

The organization should determine the frequency based on risk.

---

Step 4 — Perform the Compliance Review

A review can use multiple methods.

Document review

Check:

• Policies
• Procedures
• Approvals
• Records
• Review reports

Technical verification

Check:

• IAM systems
• Cloud configurations
• Endpoint management
• MFA status
• Security tools
• Logging systems
• Configuration reports

Sampling

For example:

Select 20 employees and verify security training completion.

Or:

Select 25 user accounts and verify access approval.

Sampling can be useful for large organizations.

Interviews

Speak with relevant employees to determine whether actual practices match documented requirements.

Observation

Observe how processes are performed.

---

Step 5 — Record Exceptions and Non-Compliance

Not every review will be perfect.

Suppose the organization finds:

2 of 150 employees have not completed mandatory security training.

The issue should be documented.

Example:

Finding	Requirement	Status	Owner	Due Date
2 employees missed training	Annual security training	Non-compliant	HR	15 Oct
1 former contractor still listed in application	Access removal	Non-compliant	IT	5 Oct
3 production changes missing approval	Change management	Exception	Engineering	10 Oct

---

Step 6 — Correct the Problem

Depending on the issue, corrective action may include:

• Removing unnecessary access.
• Enabling MFA.
• Completing training.
• Updating a procedure.
• Fixing a system configuration.
• Updating a policy.
• Improving monitoring.
• Retraining employees.
• Changing an approval workflow.

---

Step 7 — Verify Corrective Actions

Closing a finding should not simply mean:

“We fixed it.”

The organization should verify the fix.

Example:

Finding:

Two administrator accounts did not have MFA.

Correction:

MFA enabled.

Verification:

Security team checked the administrator account report and confirmed MFA was enabled for all privileged accounts.

This creates stronger audit evidence.

---

Startup Example

Consider a 35-person SaaS startup preparing for SOC 2 and ISO 27001.

The company has the following requirements:

• MFA required for production systems.
• Quarterly access review.
• Annual security awareness training.
• Production changes require approval.
• Critical vulnerabilities must be remediated within defined timelines.
• Security incidents must be reported through the incident-management process.

The startup performs a quarterly compliance review.

Review results

The security team checks:

Access

→ 78 active users reviewed
→ 3 users had unnecessary permissions

MFA

→ 100% of production administrators using MFA

Training

→ 34 of 35 employees completed training

Change management

→ 20 production changes sampled
→ 19 had documented approvals
→ 1 emergency change lacked complete documentation

Vulnerability management

→ Critical vulnerabilities reviewed
→ One remediation exceeded the defined SLA

The organization records the exceptions, assigns owners and tracks corrective actions.

Flow

Define Requirements

↓

Check Compliance

↓

Collect Evidence

↓

Record Exceptions

↓

Correct

↓

Verify

↓

Report to Management

This is a practical implementation of A.5.36.

---

Startup-Focused Quick Summary

For a startup, A.5.36 does not need to become a massive compliance exercise.

Start with the security requirements that matter most.

Simple Startup Approach

1. List your important security requirements

↓

2. Convert them into measurable checks

↓

3. Review them periodically

↓

4. Collect evidence

↓

5. Record exceptions

↓

6. Assign corrective actions

↓

7. Verify closure

A spreadsheet, ticketing system, GRC platform or simple compliance tracker can be sufficient depending on the organization’s size and complexity.

---

Example Information Security Compliance Checklist

Control Area	Compliance Question	Evidence
MFA	Is MFA enabled where required?	IAM report
Access	Are access rights reviewed?	Access review
Offboarding	Are terminated users removed promptly?	HR/IT records
Training	Have employees completed security training?	Training report
Classification	Is sensitive information classified?	Data inventory
Backup	Are required backups completed?	Backup report
Restore	Are restoration tests performed?	Restore test
Change Management	Are production changes approved?	Change tickets
Incident Management	Are incidents reported according to procedure?	Incident tickets
Vulnerabilities	Are critical vulnerabilities addressed within defined timelines?	Vulnerability report
Supplier Security	Are required supplier reviews completed?	Supplier assessment
Secure Development	Are required security reviews performed?	Code/security records
Policy Acknowledgement	Have employees acknowledged applicable policies?	Acknowledgement report

---

Compliance Review Register

A startup can maintain a simple register such as:

Review Date	Requirement	Test Performed	Result	Finding	Owner	Status
01-Jul	MFA	Checked privileged accounts	Compliant	None	IT	Closed
01-Jul	Access Review	Reviewed sample	Exception	3 excess permissions	IT	Open
01-Jul	Security Training	Checked completion	Exception	1 employee pending	HR	Open
01-Jul	Change Management	Sampled 20 changes	Exception	1 missing approval	CTO	Closed
01-Jul	Backup	Reviewed backup reports	Compliant	None	IT	Closed

This provides a straightforward audit trail.

---

Audit Evidence for A.5.36

An auditor may expect evidence such as:

Policies and Procedures

• Information Security Policy
• Topic-Specific Security Policies
• Compliance Monitoring Procedure
• Access Control Policy
• Acceptable Use Policy
• Change Management Procedure
• Incident Management Procedure
• Backup Procedure

Compliance Reviews

• Compliance review plan
• Compliance checklist
• Review records
• Internal compliance assessments
• Sampling records
• Technical compliance reports
• Access review reports
• Configuration reports
• Policy acknowledgement records

Exceptions and Corrective Actions

• Non-compliance register
• Exception register
• Corrective action tracker
• Assigned owners
• Target dates
• Closure evidence
• Verification records

Management Reporting

• Compliance dashboards
• Management review reports
• Security committee reports
• Recurring compliance summaries
• Trend analysis

---

What an Auditor May Look For

An auditor may ask:

“How do you verify that employees comply with your information security policies?”

You should be able to demonstrate a process.

For example:

“We perform quarterly compliance checks covering access control, MFA, security training, change management and other applicable security requirements. Exceptions are recorded, assigned to owners and tracked through corrective action until verified.”

The auditor may then ask:

“Show me the most recent review.”

You should be able to provide the actual record.

The auditor may then select a requirement and ask:

“Show me the evidence supporting this result.”

This is why actual compliance evidence is more valuable than simply showing the policy.

---

Common Mistakes in Implementing A.5.36

1. Policy exists but nobody checks compliance

This is the most common problem.

Policy ≠ compliance.

---

2. Compliance is checked only before certification

ISO 27001 expects an operating management system, not a one-time certification exercise.

Compliance should be monitored periodically.

---

3. Only documents are reviewed

A policy review alone does not demonstrate operational compliance.

Technical and operational evidence may also be required.

---

4. No sampling

For larger organizations, checking every activity may not be practical.

Appropriate sampling can provide useful evidence.

---

5. No exception process

Organizations will sometimes have legitimate deviations.

There should be a process to:

• Record the exception.
• Assess the risk.
• Approve it where appropriate.
• Define an expiry date.
• Track corrective action.

---

6. Findings have no owner

A compliance review that produces findings but no accountability is unlikely to result in improvement.

---

7. Findings are never verified

Closing a ticket is not necessarily the same as verifying that the underlying problem has been resolved.

---

8. Confusing A.5.35 and A.5.36

Independent review and compliance monitoring are related but different activities.

A.5.36 focuses specifically on compliance with established policies, rules and standards.

---

Practical Startup Implementation Model

A practical model for startups is:

Define

Identify the security policies, rules and standards that must be followed.

Check

Perform periodic compliance checks.

Evidence

Collect objective evidence.

Record

Document compliance, exceptions and findings.

Correct

Assign and implement corrective actions.

Verify

Confirm that corrective actions actually resolved the issue.

Report

Provide relevant results to management.

Improve

Use recurring findings to strengthen the ISMS.

---

Policy vs Process vs Evidence

A common ISO 27001 mistake is confusing these three.

Category	Example
Policy	Information Security Policy
Policy	Access Control Policy
Policy	Acceptable Use Policy
Process	Security Compliance Monitoring Procedure
Process	Access Review Procedure
Process	Policy Compliance Review Process
Process	Exception Management Procedure
Evidence	Completed compliance checklist
Evidence	Access review report
Evidence	MFA compliance report
Evidence	Training completion report
Evidence	Change-management sample
Evidence	Exception register
Evidence	Corrective action records
Evidence	Verification of remediation

Simple rule

Policy tells people what should happen.

Process explains how it is checked.

Evidence demonstrates that it actually happened.

---

Relationship with Other ISO 27001 Controls

A.5.36 connects with many other controls.

Control	Relationship
A.5.1	Information security policies
A.5.10	Acceptable use
A.5.12	Information classification
A.5.15	Access control
A.5.18	Access rights
A.5.31	Legal, regulatory and contractual requirements
A.5.35	Independent review
A.5.37	Documented operating procedures
A.8.8	Management of technical vulnerabilities
A.8.15	Logging
A.8.16	Monitoring activities
A.8.32	Change management

A.5.36 therefore acts as an important compliance verification mechanism across the ISMS.

---

Useful Documents for A.5.36

Organizations may create or maintain:

• [Insert Draft Document Link] — Information Security Compliance Monitoring Procedure
• [Insert Draft Document Link] — Security Compliance Checklist
• [Insert Draft Document Link] — Policy Compliance Review Checklist
• [Insert Draft Document Link] — Information Security Exception Register
• [Insert Draft Document Link] — Corrective Action Tracker
• [Insert Draft Document Link] — Access Compliance Review Checklist
• [Insert Draft Document Link] — Security Policy Acknowledgement Register
• [Insert Draft Document Link] — Information Security Compliance Report Template

---

Questions an Auditor May Ask

Governance

1. Which security policies and standards are subject to compliance review?
2. Who is responsible for monitoring compliance?
3. How frequently are compliance reviews performed?
4. How is the review frequency determined?

Operational Compliance

5. How do you verify compliance with access-control requirements?
6. How do you verify MFA compliance?
7. How do you verify security-training requirements?
8. How do you verify change-management compliance?
9. How do you verify backup requirements?
10. How do you verify secure-development requirements?

Exceptions

11. What happens when someone does not comply with a policy?
12. How are exceptions documented?
13. Who approves security exceptions?
14. Are exceptions time-bound?
15. How do you verify corrective actions?

Evidence

16. Can you show the most recent compliance review?
17. Can you show evidence supporting the review results?
18. Can you show an example of a previous non-compliance issue?
19. What corrective action was taken?
20. How did you verify that the issue was resolved?

---

A.5.36 Audit Readiness Checklist

Before an ISO 27001 audit, ask:

• Have we identified our important security policies and standards?
• Have we defined what compliance means for each requirement?
• Do we have a compliance monitoring process?
• Are compliance reviews performed periodically?
• Do we use appropriate evidence and sampling?
• Are technical configurations checked where applicable?
• Are exceptions documented?
• Does every significant finding have an owner?
• Are target dates defined?
• Are corrective actions tracked?
• Is remediation independently or objectively verified where appropriate?
• Are recurring issues analyzed?
• Are significant compliance results reported to management?

---

Startup-Focused Final Takeaway

ISO 27001 Annex A 5.36 is fundamentally about turning security policies into actual behavior and measurable compliance.

A startup does not need hundreds of complicated compliance checks.

Start with the requirements that matter most to your business:

Define the requirement

↓

Check actual compliance

↓

Collect evidence

↓

Record exceptions

↓

Correct the problem

↓

Verify the correction

↓

Report and improve

The key question for A.5.36 is:

“We have established our security policies, rules and standards — how do we know people, processes and systems are actually following them?”

If the organization can answer that question with a repeatable process and objective evidence, it is in a much stronger position to demonstrate the effectiveness of its ISO 27001 ISMS.