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:
- Information security policies.
- Topic-specific security policies.
- Information security rules.
- Security standards.
- Security procedures.
- Applicable technical requirements.
- 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
- Which security policies and standards are subject to compliance review?
- Who is responsible for monitoring compliance?
- How frequently are compliance reviews performed?
- How is the review frequency determined?
Operational Compliance
- How do you verify compliance with access-control requirements?
- How do you verify MFA compliance?
- How do you verify security-training requirements?
- How do you verify change-management compliance?
- How do you verify backup requirements?
- How do you verify secure-development requirements?
Exceptions
- What happens when someone does not comply with a policy?
- How are exceptions documented?
- Who approves security exceptions?
- Are exceptions time-bound?
- How do you verify corrective actions?
Evidence
- Can you show the most recent compliance review?
- Can you show evidence supporting the review results?
- Can you show an example of a previous non-compliance issue?
- What corrective action was taken?
- 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.