Policy Compliance Review Checklist

1. Purpose

The Policy Compliance Review Checklist provides a structured method for reviewing whether organizational information-security policies are:

Approved
Current
Applicable
Communicated
Understood
Implemented
Consistently followed
Supported by evidence
Reviewed periodically
Updated when business, technology, legal, regulatory, or security requirements change

The checklist helps identify gaps between what the policy requires and what the organization actually does.

Core Principle

Policy Requirement → Implementation → Evidence → Compliance Review → Gap → Corrective Action → Verification → Improvement

2. Scope

This checklist may be used for policies covering:

Information security
Access control
Passwords and authentication
Acceptable use
Remote working
Asset management
Information classification
Data protection
Privacy
Cryptography
Backup
Incident management
Vulnerability management
Change management
Supplier security
Cloud security
Business continuity
Disaster recovery
Security awareness
Physical security
Software development
AI security
Information retention
Intellectual property
Legal and regulatory compliance

It can also be adapted for other organizational policies.

3. Review Information

Field	Details
Review ID
Policy Name
Policy ID
Policy Version
Policy Owner
Business Owner
Reviewer
Review Date
Review Period
Approval Date
Next Review Date
Classification
Review Status

4. Policy Review Status

Use the following status:

☐ Compliant
☐ Partially Compliant
☐ Non-Compliant
☐ Not Applicable
☐ Evidence Required
☐ Under Remediation

Overall Policy Status

☐ Effective
☐ Effective with Improvements Required
☐ Partially Effective
☐ Ineffective
☐ Requires Revision

5. Policy Identification

Verify:

☐ Policy has a unique title
☐ Policy ID assigned
☐ Version identified
☐ Owner identified
☐ Approval authority identified
☐ Effective date identified
☐ Review date identified
☐ Classification identified where applicable
☐ Related policies/procedures identified
☐ Document location identified

6. Policy Purpose

Review whether the policy clearly explains:

☐ Why the policy exists
☐ What security objective it supports
☐ What risks it addresses
☐ What business requirement it supports
☐ What compliance obligation it addresses where applicable

Review Comments

7. Policy Scope

Verify whether the policy clearly defines:

☐ Organizational scope
☐ Employees covered
☐ Contractors covered
☐ Third parties covered where applicable
☐ Systems covered
☐ Information covered
☐ Locations covered where relevant
☐ Business processes covered
☐ Exceptions/exclusions documented where necessary

Scope Assessment

8. Policy Authority and Approval

Verify:

☐ Policy approved by authorized management
☐ Approval date recorded
☐ Approver identified
☐ Approval evidence retained
☐ Policy version controlled
☐ Unauthorized changes prevented
☐ Current approved version identifiable

9. Policy Ownership

Verify:

☐ Policy owner assigned
☐ Owner understands responsibilities
☐ Owner has authority to maintain policy
☐ Review responsibility defined
☐ Escalation responsibility defined
☐ Policy dependencies identified

10. Policy Requirements

Review each major policy requirement.

Applicable	Implemented	Compliant
☐	☐	☐
☐	☐	☐
☐	☐	☐
☐	☐	☐

The reviewer should assess actual implementation rather than simply confirming that the requirement is written in the policy.

11. Policy-to-Practice Assessment

For each significant policy requirement, determine:

Requirement

What does the policy require?

Actual Practice

What does the organization actually do?

Evidence

What demonstrates that the practice occurs?

Assessment

☐ Compliant
☐ Partially Compliant
☐ Non-Compliant
☐ Not Applicable

12. Policy Implementation

Verify:

☐ Policy requirements have been translated into procedures
☐ Responsible owners identified
☐ Required controls implemented
☐ Supporting processes established
☐ Supporting technology configured where required
☐ Employees understand relevant requirements
☐ Third parties are informed where applicable
☐ Evidence of implementation exists

13. Policy Communication

Verify:

☐ Policy published through an approved channel
☐ Employees can access the current version
☐ Relevant contractors can access it
☐ Relevant third parties are informed where appropriate
☐ Policy changes communicated
☐ Communication records maintained where required

Communication Evidence

14. Employee Awareness

Determine whether personnel understand applicable requirements.

☐ Policy awareness provided
☐ Security training completed
☐ Policy acknowledgement obtained where required
☐ Role-specific requirements communicated
☐ New employees receive applicable policies
☐ Policy changes communicated
☐ Awareness effectiveness considered

15. Policy Acknowledgement

Where required:

☐ Employees acknowledge policy
☐ Contractors acknowledge applicable requirements
☐ Acknowledgement records maintained
☐ Overdue acknowledgements tracked
☐ Exceptions documented

Acknowledgement Evidence

16. Policy Currency

Verify:

☐ Policy is within review period
☐ Current business processes are reflected
☐ Current technology is reflected
☐ Current organizational structure is reflected
☐ Current risks are reflected
☐ Current legal requirements are reflected
☐ Current contractual requirements are reflected
☐ Security incidents have been considered
☐ Previous findings have been considered

17. Policy Review Triggers

Determine whether the policy was reviewed following:

☐ Major security incident
☐ Data breach
☐ Major vulnerability
☐ New technology
☐ New cloud service
☐ Organizational change
☐ Business-process change
☐ New regulation
☐ Regulatory amendment
☐ New customer requirement
☐ Contract change
☐ Major supplier change
☐ ISMS scope change
☐ Significant audit finding

18. Policy Consistency

Check whether the policy is consistent with:

☐ Information-security objectives
☐ Risk assessment
☐ Risk treatment plan
☐ Statement of Applicability
☐ Related policies
☐ Procedures
☐ Standards
☐ Technical controls
☐ Business processes
☐ Legal requirements
☐ Contractual requirements

Inconsistencies Identified

19. Policy Hierarchy

Determine whether the relationship between documents is clear.

Example

Policy

Defines what is required.

↓

Standard

Defines required security criteria or minimum requirements.

↓

Procedure

Defines how the requirement is performed.

↓

Guideline

Provides recommended implementation guidance.

↓

Evidence

Demonstrates what actually happened.

Verify:

☐ Policy has supporting procedures where required
☐ Procedures do not contradict policy
☐ Standards align with policy
☐ Guidelines are consistent with requirements
☐ Evidence demonstrates implementation

20. Roles and Responsibilities

Verify whether policy responsibilities are:

☐ Clearly defined
☐ Assigned to appropriate roles
☐ Communicated
☐ Understood
☐ Supported by authority
☐ Reflected in job responsibilities where appropriate

Role	Policy Responsibility	Evidence

21. Management Responsibilities

Verify that management:

☐ Approved the policy
☐ Provides appropriate direction
☐ Provides necessary resources
☐ Supports implementation
☐ Reviews significant compliance issues
☐ Addresses significant policy exceptions
☐ Supports corrective actions

22. Policy Exceptions

Verify:

☐ Exception process defined
☐ Exceptions documented
☐ Business justification recorded
☐ Security risk assessed
☐ Compensating controls identified where appropriate
☐ Appropriate approval obtained
☐ Expiry/review date defined
☐ Exceptions periodically reviewed

Exception	Reason	Risk	Compensating Control	Approver	Expiry

23. Actual Compliance Testing

Test whether employees and processes follow the policy.

Possible methods:

☐ Interview
☐ Observation
☐ Sampling
☐ Document review
☐ System review
☐ Configuration review
☐ Access review
☐ Transaction/sample testing
☐ Log review
☐ Evidence review

Sample Testing

Sample	Policy Requirement	Expected	Actual	Result

24. Evidence Review

Review appropriate evidence such as:

☐ System records
☐ Access reviews
☐ Training records
☐ Security logs
☐ Incident records
☐ Change records
☐ Approval records
☐ Risk assessments
☐ Supplier assessments
☐ Configuration evidence
☐ Monitoring reports
☐ Meeting records
☐ Exception records
☐ Audit records

Evidence Quality

☐ Relevant
☐ Current
☐ Complete
☐ Traceable
☐ Reliable
☐ Sufficient

Do not collect unnecessary:

Passwords
API keys
Private keys
Authentication secrets
Production credentials

25. Policy Compliance Sampling

Where appropriate, use representative samples.

Examples:

Access Control Policy

Sample:

New employees
Employees who changed roles
Terminated employees
Privileged users
Supplier accounts

Security Awareness Policy

Sample:

New hires
Existing employees
Contractors

Change Management Policy

Sample:

Standard changes
Emergency changes
High-risk changes
Production changes

Incident Management Policy

Sample:

Recent security incidents
High-severity incidents
Closed incidents

26. Policy Compliance Findings

Record gaps between policy requirements and actual practices.

Finding ID	Policy Requirement	Actual Condition	Evidence	Risk	Owner	Due Date

27. Finding Classification

Classify findings according to the organization’s methodology.

☐ Observation
☐ Improvement Opportunity
☐ Minor Non-Compliance
☐ Major Non-Compliance
☐ Significant Risk
☐ Critical Risk

Classification should be based on the organization’s approved risk and finding methodology.

28. Root Cause Analysis

For significant findings, determine why the policy requirement was not met.

Possible causes:

☐ Policy unclear
☐ Procedure missing
☐ Procedure not followed
☐ Training gap
☐ Ownership gap
☐ Technology limitation
☐ Resource limitation
☐ Process weakness
☐ Management oversight gap
☐ Change not reflected in policy
☐ Supplier issue
☐ Other

Root Cause

29. Corrective Action

For each significant finding:

☐ Immediate correction identified
☐ Root cause identified
☐ Corrective action defined
☐ Owner assigned
☐ Target date defined
☐ Remediation implemented
☐ Evidence collected
☐ Effectiveness verified
☐ Residual risk assessed
☐ Finding closed or escalated

30. Policy Effectiveness Assessment

Assess whether the policy is achieving its intended purpose.

Policy Design

☐ Requirements are clear
☐ Requirements address relevant risks
☐ Requirements are practical
☐ Requirements are measurable where appropriate

Implementation

☐ Requirements implemented
☐ Responsible personnel identified
☐ Supporting procedures exist
☐ Supporting controls exist

Operation

☐ Requirements consistently followed
☐ Exceptions controlled
☐ Evidence available
☐ Non-compliance addressed

Overall Effectiveness

☐ Effective
☐ Partially Effective
☐ Ineffective
☐ Unable to Determine

31. Policy Metrics

Where appropriate, monitor:

Metric	Target	Actual	Status
Policy acknowledgement
Policy training completion
Policy exceptions
Policy-related findings
Repeat findings
Overdue corrective actions
Policies reviewed on time
Policies requiring revision

32. Policy Review Register

Maintain a register of policies requiring review.

Policy	Owner	Version	Last Review	Next Review	Status
Information Security Policy
Access Control Policy
Incident Management Policy
Supplier Security Policy
Backup Policy
Acceptable Use Policy

33. Policy Change Management

When a policy is changed:

☐ Change reason documented
☐ Change impact assessed
☐ Relevant stakeholders consulted
☐ Legal/regulatory impact considered
☐ Security impact considered
☐ Management approval obtained
☐ Version updated
☐ Previous version retained where required
☐ New version published
☐ Personnel informed
☐ Training updated where required
☐ Supporting procedures updated

34. Obsolete Policy Control

Verify:

☐ Obsolete versions removed from normal use
☐ Archived versions protected
☐ Current version clearly identified
☐ Employees cannot accidentally rely on obsolete versions
☐ External copies addressed where appropriate
☐ Obsolete references updated

35. Policy Accessibility

Verify that authorized personnel can:

☐ Find the policy
☐ Access the current version
☐ Understand applicable requirements
☐ Identify policy owner
☐ Identify related procedures
☐ Report questions or violations

36. Policy Violation Management

Where policy violations occur:

☐ Violation reported
☐ Violation assessed
☐ Security impact assessed
☐ Appropriate escalation completed
☐ Immediate risk addressed
☐ Corrective action defined
☐ Personnel/process issue addressed
☐ Recurrence considered
☐ Evidence retained

37. Legal and Regulatory Alignment

Verify that the policy reflects applicable:

☐ Legal requirements
☐ Regulatory requirements
☐ Privacy requirements
☐ Customer obligations
☐ Contractual requirements
☐ Industry requirements

Where requirements change:

Requirement Change → Impact Assessment → Policy Review → Approval → Communication → Implementation → Verification

38. Customer and Contractual Alignment

Where applicable:

☐ Customer security commitments identified
☐ Contract requirements reflected
☐ Security commitments are achievable
☐ Policy does not contradict customer obligations
☐ Required controls implemented
☐ Customer-specific exceptions documented

39. Supplier Alignment

Where policies apply to suppliers:

☐ Supplier requirements identified
☐ Contractual requirements included
☐ Supplier security requirements communicated
☐ Supplier compliance monitored
☐ Supplier exceptions documented
☐ Critical supplier findings tracked

40. Technical Alignment

Where a policy establishes technical requirements, verify that actual technology supports the policy.

Examples:

MFA Policy

☐ MFA enabled
☐ Exceptions controlled
☐ MFA status monitored

Password Policy

☐ Technical configuration aligns with requirements
☐ Exceptions controlled

Encryption Policy

☐ Required encryption implemented
☐ Key-management controls implemented

Logging Policy

☐ Required events logged
☐ Retention configured
☐ Monitoring implemented

41. AWS SaaS Startup Example

A SaaS startup has an Access Control Policy requiring:

Access to production systems must be authorized, limited according to business need, and reviewed periodically.

The reviewer tests:

Evidence

AWS IAM users/roles
GitHub access
Production database access
Employee access records
Access-review records

Sample Finding

Requirement: Production access must be periodically reviewed.

Condition: One former contractor’s access remained active.

Evidence: IAM and GitHub access records.

Risk: Unauthorized access to production resources.

Immediate Correction: Access revoked.

Root Cause: Contractor offboarding did not automatically trigger application-access removal.

Corrective Action: Integrate contractor offboarding with access-revocation workflow.

Verification: Perform a subsequent access review and confirm removal.

42. Startup-Friendly Policy Review Model

A startup does not need to review every policy with the same intensity.

Monthly

Review high-risk operational policies where appropriate:

Access control
Authentication
Vulnerability management
Incident management
Backup

Quarterly

Review:

Supplier security
Security awareness
Change management
Cloud security
Data protection

Semiannual

Review:

Business continuity
Disaster recovery
Information classification
Acceptable use

Annual

Review:

Information-security policy
ISMS-related policies
Legal/regulatory alignment
Security objectives
Major policy framework

Event-Driven

Immediately review relevant policies following:

Major incident
Data breach
Regulatory change
Major technology change
Organizational change
New customer requirement
Significant audit finding

43. Policy Review Summary

Area	Result	Finding
Policy Governance
Approval
Scope
Requirements
Implementation
Communication
Awareness
Actual Compliance
Evidence
Exceptions
Legal/Regulatory Alignment
Contractual Alignment
Effectiveness
Corrective Actions

44. Overall Review Result

Policy Status

☐ Compliant
☐ Compliant with Improvement Actions
☐ Partially Compliant
☐ Significant Non-Compliance
☐ Policy Revision Required
☐ Further Assessment Required

Reviewer Summary

Key Findings

Required Actions

45. Management Review

Significant policy issues should be reported to appropriate management.

Management should consider:

Significant policy violations
Repeated non-compliance
Policy gaps
Outdated requirements
Regulatory changes
Customer commitments
Security risks
Resource requirements
Required policy revisions

Management Comments

46. Approval

Policy Owner: __________________________

Reviewer: ______________________________

Security Owner: _________________________

Management Approver: ___________________

Review Date: ____________________________

Approval Date: __________________________

Next Review Date: _______________________

47. Records and Evidence

Retain appropriate evidence such as:

Approved policy
Previous policy version where required
Policy review record
Approval evidence
Communication records
Training records
Acknowledgements
Compliance testing results
Sample testing evidence
Exceptions
Findings
Corrective actions
Verification records
Management review records

Records should be protected according to their classification and retention requirements.

48. Common Mistakes

Avoid:

Reviewing only the document and not actual implementation.
Treating policy approval as proof of compliance.
Keeping policies that no longer reflect actual operations.
Failing to assign a policy owner.
Failing to communicate policy changes.
Not testing employee compliance.
Ignoring policy exceptions.
Allowing procedures to contradict policies.
Ignoring customer or contractual requirements.
Ignoring regulatory changes.
Closing policy findings without verification.
Keeping multiple uncontrolled versions of the same policy.
Writing requirements that the organization cannot realistically implement.

49. Relationship With Other ISMS Documents

Document	Relationship
Information Security Policy	Establishes overall security direction
Security Standards	Defines detailed security requirements
Security Procedures	Defines operational implementation
Compliance Monitoring Procedure	Monitors ongoing compliance
Security Compliance Checklist	Provides broader security compliance assessment
Risk Assessment	Identifies risks addressed by policies
Statement of Applicability	Identifies applicable controls
Internal Audit Procedure	Provides independent audit assessment
Security Findings Register	Records policy compliance gaps
Corrective Action Tracker	Tracks remediation
Management Review	Reviews significant policy and ISMS issues
Legal & Regulatory Requirements Register	Tracks external obligations

50. ISO/IEC 27001 Connection

Policy compliance reviews support the organization’s ability to maintain and evaluate its information-security management system, including:

Security policies
Defined responsibilities
Risk management
Control implementation
Compliance monitoring
Internal audit
Corrective action
Continual improvement

The Policy Compliance Review Checklist is not itself a universally prescribed ISO/IEC 27001 form.

The organization should determine the policies required for its ISMS based on its:

Business context
Information-security risks
Applicable controls
Legal and regulatory obligations
Customer requirements
Contractual commitments
Technology environment
Organizational structure

51. Final Policy Compliance Audit Trail

For every important policy, the organization should be able to demonstrate:

Why does this policy exist?
Who owns it?
Who approved it?
What requirements does it establish?
Who must follow it?
How is it communicated?
How is compliance verified?
What evidence demonstrates implementation?
Were exceptions identified?
Were violations identified?
What risks resulted from non-compliance?
Were corrective actions implemented?
Was effectiveness verified?
When will the policy be reviewed again?

Final Principle

A policy is effective only when the organization’s actual behavior matches its documented requirements. Policy compliance review therefore connects governance documents with real-world implementation, evidence, accountability, and continual improvement.