1. Purpose
The Procedure Review Checklist provides a structured method for reviewing documented operating procedures to determine whether they remain:
- Accurate
- Relevant
- Approved
- Current
- Secure
- Operationally usable
- Consistent with organizational requirements
- Aligned with applicable risks and controls
- Supported by appropriate evidence
The checklist helps ensure that procedures are not simply reviewed for document formatting but are also evaluated against actual operational practices.
Core Principle
Identify → Review → Validate → Test → Update → Approve → Communicate → Evidence
2. Scope
This checklist may be used for procedures covering:
- Information security
- IT operations
- Access management
- Change management
- Production deployment
- Backup and recovery
- Disaster recovery
- Incident management
- Vulnerability management
- Cloud operations
- Secure development
- Supplier management
- Business continuity
- Compliance
- Privacy
- Security monitoring
- Other ISMS-related operational activities
3. When to Use
Perform a procedure review:
☐ At the scheduled review date
☐ After a significant technology change
☐ After a security incident
☐ After an audit finding
☐ After a major process change
☐ After a regulatory change
☐ After a customer/contractual requirement changes
☐ After a significant organizational change
☐ When control effectiveness changes
☐ When the procedure is found to be ineffective
☐ When ownership changes
☐ When a major supplier changes
☐ When the procedure is no longer required
4. Procedure Review Information
| Field | Details |
|---|---|
| Procedure ID | |
| Procedure Name | |
| Process/Area | |
| Procedure Owner | |
| Reviewer | |
| Review Date | |
| Current Version | |
| Previous Version | |
| Scheduled Review Date | |
| Review Type | |
| Criticality | |
| Status |
Review Type
☐ Scheduled Review
☐ Change-Triggered Review
☐ Incident-Triggered Review
☐ Audit-Triggered Review
☐ Regulatory Review
☐ Management Review
☐ Effectiveness Review
☐ Other: __________________
5. Review Status
☐ Review Not Started
☐ In Progress
☐ Review Completed — No Changes
☐ Minor Changes Required
☐ Major Revision Required
☐ Procedure Replacement Required
☐ Procedure Retirement Required
6. Procedure Identity
Verify:
☐ Correct procedure name
☐ Unique procedure ID
☐ Correct process identified
☐ Correct owner identified
☐ Correct approver identified
☐ Version number present
☐ Effective date present
☐ Review date present
☐ Classification identified where required
☐ Current status identified
7. Purpose Review
Confirm that the purpose remains valid.
☐ Purpose still applies
☐ Business need remains
☐ Security objective remains relevant
☐ Procedure supports the intended outcome
☐ No duplicate procedure exists
☐ Purpose accurately reflects current activity
Review Result
8. Scope Review
Verify that the scope remains accurate.
☐ Systems covered are current
☐ Applications covered are current
☐ Teams covered are current
☐ Locations are current
☐ Information types are current
☐ Third-party involvement is identified
☐ Cloud services are included where applicable
☐ Production environments are included where required
☐ Scope exclusions remain valid
Scope Changes Required
9. Process Review
Compare the documented procedure with the actual operational process.
☐ Process remains unchanged
☐ Process has changed
☐ Procedure reflects current workflow
☐ Activities are performed in the documented order where required
☐ Responsibilities remain accurate
☐ Manual activities remain applicable
☐ Automated activities are documented
☐ System dependencies are current
Process Changes
10. Roles and Responsibilities
Verify:
☐ Procedure owner remains correct
☐ Operational owner remains correct
☐ Approver remains appropriate
☐ Responsibilities remain accurate
☐ Segregation of duties remains appropriate
☐ Backup personnel identified where necessary
☐ Third-party responsibilities remain accurate
11. Procedure Steps
Review every significant step.
☐ Steps remain necessary
☐ Steps are technically accurate
☐ Steps are in the correct sequence
☐ Instructions are understandable
☐ Required approvals are included
☐ Required verification steps are included
☐ Security requirements are included
☐ Evidence requirements are included
☐ Failure handling is documented
☐ Escalation requirements are documented
Step Changes Required
12. Preconditions
Confirm that prerequisites remain valid.
☐ Required access is correct
☐ Required systems are current
☐ Required tools are current
☐ Required approvals are identified
☐ Required information is identified
☐ Required personnel are identified
☐ Required dependencies are identified
13. Tools and Systems
Review all referenced tools and systems.
| System/Tool | Current? | Change Required |
|---|---|---|
Check:
☐ System still exists
☐ System name is correct
☐ URL/reference is current where applicable
☐ Access method is current
☐ Tool is approved
☐ Security controls remain appropriate
14. Access Requirements
Verify that access requirements remain appropriate.
☐ Access roles remain correct
☐ Least privilege considered
☐ Privileged access identified
☐ MFA requirements remain appropriate
☐ Service accounts identified
☐ Emergency access requirements remain valid
☐ Third-party access requirements remain valid
15. Security Requirements
Assess whether the procedure adequately protects information and systems.
☐ Information security requirements remain applicable
☐ Confidentiality requirements addressed
☐ Integrity requirements addressed
☐ Availability requirements addressed
☐ Authentication requirements addressed
☐ Authorization requirements addressed
☐ Logging requirements addressed
☐ Monitoring requirements addressed
☐ Encryption requirements addressed where applicable
☐ Secrets protection addressed
☐ Secure handling requirements addressed
16. Information Handling
Review information involved in the procedure.
☐ Information types remain accurate
☐ Classification remains appropriate
☐ Sensitive information identified
☐ Personal data identified where applicable
☐ Customer information identified
☐ Data transfer requirements remain appropriate
☐ Retention requirements remain appropriate
☐ Secure disposal requirements remain appropriate
17. Risk Review
Determine whether the risks associated with the procedure have changed.
Consider:
- New threats
- New vulnerabilities
- New systems
- New suppliers
- New information
- New access
- Process changes
- Incidents
- Audit findings
- Regulatory changes
☐ Risk unchanged
☐ Risk increased
☐ Risk decreased
☐ New risk identified
☐ Existing risk no longer applicable
Risk Changes
18. Control Review
Review controls associated with the procedure.
☐ Controls remain applicable
☐ Controls remain correctly described
☐ Control responsibilities remain accurate
☐ Control frequency remains appropriate
☐ Control evidence remains available
☐ Control implementation remains effective
☐ New controls required
☐ Existing controls no longer required
19. Statement of Applicability Consideration
Where relevant:
☐ Related Annex A control applicability reviewed
☐ Control implementation remains appropriate
☐ SoA mapping remains accurate
☐ New risk may require additional control consideration
☐ Procedure remains consistent with the SoA
The procedure review should not automatically change the Statement of Applicability. Any change should follow the organization’s risk assessment and ISMS governance process.
20. Compliance Requirements
Review whether requirements have changed.
☐ Legal requirements
☐ Regulatory requirements
☐ Contractual requirements
☐ Customer requirements
☐ Internal policy requirements
☐ Security requirements
☐ Certification requirements
New Requirements
21. Technology Change Review
Determine whether technology changes affect the procedure.
Consider:
- Cloud architecture
- Applications
- Databases
- Network
- IAM
- CI/CD
- Infrastructure
- Monitoring
- Security tools
- SaaS platforms
☐ No relevant technology change
☐ Technology changed
☐ Procedure requires update
22. Cloud Review
If the procedure involves cloud services:
☐ Cloud provider remains correct
☐ Cloud architecture remains accurate
☐ Accounts/subscriptions remain accurate
☐ IAM requirements remain accurate
☐ MFA requirements remain accurate
☐ Network controls remain accurate
☐ Backup arrangements remain accurate
☐ Monitoring remains accurate
☐ Recovery arrangements remain accurate
23. Third-Party Review
Where third parties are involved:
☐ Supplier remains active
☐ Supplier responsibilities remain accurate
☐ Supplier access remains appropriate
☐ Subprocessor dependency considered
☐ Contractual requirements remain current
☐ Supplier escalation details remain current
☐ Supplier security requirements remain appropriate
24. Business Continuity Review
Where the procedure supports critical operations:
☐ Business dependency remains accurate
☐ Criticality remains appropriate
☐ RTO considered
☐ RPO considered
☐ Recovery dependency remains accurate
☐ Alternate process remains available
☐ Disaster recovery dependency reviewed
25. Incident and Security Event Review
Review relevant incidents since the previous procedure review.
☐ No relevant incidents
☐ Incident occurred
☐ Procedure was followed successfully
☐ Procedure was difficult to follow
☐ Procedure was insufficient
☐ Incident identified a process gap
☐ Corrective action completed
☐ Lessons learned incorporated
Lessons Learned
26. Audit Findings Review
Review previous audit findings related to the procedure.
☐ No related findings
☐ Findings remain open
☐ Corrective actions completed
☐ Effectiveness verified
☐ Recurring finding identified
☐ Procedure update required
Findings
| Finding ID | Issue | Status | Procedure Change Required |
|---|---|---|---|
27. Exceptions Review
Review approved exceptions.
☐ No exceptions
☐ Active exception exists
☐ Exception remains valid
☐ Compensating controls remain effective
☐ Exception expiry reviewed
☐ Procedure should be updated to remove recurring exception
28. Evidence Review
Determine whether the procedure generates appropriate evidence.
☐ Evidence requirement documented
☐ Evidence is actually generated
☐ Evidence is complete
☐ Evidence is attributable
☐ Evidence is dated/timestamped where appropriate
☐ Evidence is protected
☐ Evidence can be retrieved
☐ Evidence retention is defined
Examples:
- Tickets
- Approval records
- Logs
- Reports
- Screenshots
- System records
- Review records
- Test results
29. Actual Compliance Review
Do not rely only on reading the procedure.
Verify whether personnel actually follow it.
☐ Sampled transactions
☐ Reviewed system records
☐ Reviewed tickets
☐ Interviewed personnel
☐ Observed process
☐ Reviewed evidence
☐ Compared procedure against actual practice
Compliance Result
☐ Compliant
☐ Partially Compliant
☐ Non-Compliant
☐ Further Testing Required
30. Procedure Effectiveness
Assess whether the procedure achieves its intended purpose.
Consider:
- Security outcomes
- Operational outcomes
- Errors
- Exceptions
- Incidents
- Audit findings
- Delays
- Rework
- Control failures
- User feedback
Effectiveness
☐ Effective
☐ Partially Effective
☐ Ineffective
☐ Unable to Determine
Rationale
31. Usability Review
A procedure should be practical for the people expected to use it.
☐ Instructions are clear
☐ Steps are understandable
☐ Technical terminology is appropriate
☐ Excessive documentation avoided
☐ Required information is easy to locate
☐ Emergency steps are easy to identify
☐ Screenshots/examples remain current where used
☐ Procedure can realistically be followed
32. Security of the Procedure
Review the procedure itself.
☐ Appropriate classification
☐ Access restricted where necessary
☐ Sensitive operational information protected
☐ No passwords included
☐ No API keys included
☐ No private keys included
☐ No unnecessary secrets included
☐ Restricted infrastructure information appropriately protected
33. Document Control
Verify:
☐ Version number correct
☐ Revision history maintained
☐ Owner identified
☐ Approval recorded
☐ Effective date recorded
☐ Review date recorded
☐ Current version identifiable
☐ Obsolete versions controlled
34. Related Documents
Verify references to other documents.
☐ Policies current
☐ Procedures current
☐ Forms current
☐ Registers current
☐ Templates current
☐ Standards current
☐ Work instructions current
Broken or Outdated References
35. Procedure Dependencies
Review dependencies.
☐ Upstream procedures remain valid
☐ Downstream procedures remain valid
☐ Related systems remain available
☐ Supplier dependencies remain valid
☐ Personnel dependencies understood
☐ Recovery dependencies understood
36. Change Impact Assessment
If changes are required, assess impact on:
☐ Related procedures
☐ Policies
☐ Risk assessment
☐ Statement of Applicability
☐ Controls
☐ Systems
☐ Training
☐ Suppliers
☐ Contracts
☐ Business continuity
☐ Audit evidence
37. Required Changes
| Change ID | Change Required | Reason | Priority | Owner | Due Date |
|---|---|---|---|---|---|
38. Procedure Revision
Determine the required action.
☐ No change
☐ Minor revision
☐ Major revision
☐ Rewrite required
☐ Replace procedure
☐ Retire procedure
Revision Summary
39. Approval of Revised Procedure
Where changes are made:
☐ Revised version prepared
☐ Review completed
☐ Required stakeholders consulted
☐ Security impact reviewed
☐ Compliance impact reviewed
☐ Approval obtained
☐ Effective date established
☐ Previous version controlled
40. Communication
After approval:
☐ Relevant personnel notified
☐ Updated procedure published
☐ Training completed where required
☐ Acknowledgement obtained where required
☐ Obsolete version removed from normal use
☐ Related documentation updated
41. Procedure Review Findings
| Finding ID | Area | Finding | Risk | Corrective Action | Owner | Due Date |
|---|---|---|---|---|---|---|
42. Corrective Action
Where weaknesses are identified:
☐ Immediate correction completed
☐ Root cause assessed
☐ Corrective action defined
☐ Owner assigned
☐ Due date assigned
☐ Remediation evidence required
☐ Effectiveness verification planned
43. Final Review Decision
☐ No Change Required
The procedure remains current and effective.
☐ Minor Update Required
Limited changes are required.
☐ Major Revision Required
Significant changes are required.
☐ Replace
A new procedure is required.
☐ Retire
The procedure is no longer required.
44. Review Summary
Key Changes Since Previous Review
Risks Identified
Findings
Corrective Actions
Overall Review Conclusion
45. Review Approval
Reviewer: ______________________________
Role: ______________________________
Date: ______________________________
Procedure Owner: ______________________________
Approval: ☐ Approved ☐ Further Action Required
Approver: ______________________________
Approval Date: ______________________________
46. Next Review
Next Scheduled Review Date: __________________
Additional Review Trigger
The procedure should also be reviewed before the scheduled date if a material change, incident, audit finding, regulatory change, or other defined trigger occurs.
47. Procedure Review Register
Maintain a central record of completed reviews.
| Procedure ID | Procedure | Review Date | Reviewer | Result | Changes | Next Review |
|---|---|---|---|---|---|---|
48. Review Metrics
Possible metrics include:
| Metric | Result |
|---|---|
| Procedures reviewed | |
| Procedures due | |
| Procedures overdue | |
| No-change reviews | |
| Minor revisions | |
| Major revisions | |
| Retired procedures | |
| Reviews with findings | |
| Reviews with corrective actions | |
| Recurring findings |
49. AWS SaaS Startup Example
A SaaS startup performs its annual review of the Production Deployment Procedure.
During the review, the team identifies that the company has moved from manual deployments to GitHub-based CI/CD.
Review Findings
The existing procedure still states:
Production deployments are performed manually by an authorized DevOps engineer.
This no longer reflects actual operations.
Review Actions
The reviewer:
- Confirms the new CI/CD process.
- Reviews the deployment workflow.
- Verifies branch protection.
- Reviews deployment approvals.
- Checks CI/CD logs.
- Verifies production access.
- Reviews rollback capability.
- Updates the procedure.
- Obtains approval.
- Communicates the revised procedure.
Audit Trail
Scheduled Review → Compare Procedure With Actual Process → Identify Change → Assess Impact → Update Procedure → Approve → Communicate → Evidence
50. Startup-Friendly Review Model
For a small SaaS organization, every procedure does not need a lengthy review meeting.
A practical model is:
Step 1 — Document Review
Check:
- Owner
- Version
- Scope
- Steps
- References
- Review date
Step 2 — Change Review
Ask:
What changed since the last review?
Check:
- Technology
- People
- Suppliers
- Risks
- Regulations
- Incidents
- Audit findings
Step 3 — Evidence Review
Ask:
Is this procedure actually being followed?
Review a reasonable sample of operational evidence.
Step 4 — Effectiveness
Ask:
Does the procedure achieve its intended security/operational outcome?
Step 5 — Decision
Choose:
Keep → Update → Replace → Retire
This provides meaningful review without creating unnecessary administrative overhead.
51. Common Mistakes
Avoid:
- Reviewing only spelling and formatting.
- Changing the review date without assessing the procedure.
- Assuming an approved procedure is automatically effective.
- Failing to compare the document with actual operations.
- Ignoring technology changes.
- Ignoring incidents and audit findings.
- Failing to review related procedures.
- Leaving obsolete references.
- Allowing outdated screenshots or system instructions.
- Keeping passwords or secrets in procedures.
- Failing to document review evidence.
- Updating a procedure without approval.
- Failing to communicate significant changes.
- Treating annual review as the only trigger for review.
52. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Operating Procedure Register | Tracks procedures and review dates |
| Documented Operating Procedures Policy | Defines procedure governance |
| Operating Procedure Template | Provides procedure structure |
| Risk Register | Identifies risks addressed by procedures |
| Statement of Applicability | Provides relevant control context |
| Change Management Procedure | Identifies changes that may trigger procedure review |
| Incident Response Procedure | Provides incident lessons that may require updates |
| Compliance Monitoring Procedure | Identifies procedure compliance issues |
| Internal Audit Procedure | May identify procedure weaknesses |
| Corrective Action Tracker | Tracks remediation |
| Exception Register | Tracks approved deviations |
| Management Review | Provides governance oversight |
53. ISO/IEC 27001 Connection
Procedure reviews support the organization’s ability to maintain controlled and appropriate documented information and ensure that operational practices remain aligned with the ISMS.
The review should consider:
- ISMS scope
- Information-security risks
- Risk treatment
- Applicable controls
- Statement of Applicability
- Business requirements
- Technology changes
- Legal and regulatory requirements
- Customer requirements
- Contractual requirements
- Incidents
- Audit findings
- Control effectiveness
The Procedure Review Checklist is not itself a universally prescribed ISO/IEC 27001 form. The organization should determine the appropriate review method, frequency, evidence, and approval process based on its risks and operational requirements.
54. Audit Evidence Checklist
An auditor should be able to verify:
☐ Procedure identified
☐ Procedure owner identified
☐ Review date defined
☐ Review actually performed
☐ Reviewer identified
☐ Current version reviewed
☐ Actual process considered
☐ Risks considered
☐ Technology changes considered
☐ Incidents considered
☐ Audit findings considered
☐ Compliance requirements considered
☐ Evidence reviewed
☐ Effectiveness considered
☐ Changes documented
☐ Approval recorded
☐ Updated version controlled
☐ Communication completed where required
☐ Next review established
55. Final Procedure Review Audit Trail
For every significant procedure, the organization should be able to demonstrate:
When was the procedure reviewed?
Who reviewed it?
Why was it reviewed?
What has changed since the previous review?
Does the procedure still reflect actual operations?
Have risks changed?
Have technology or supplier dependencies changed?
Have incidents or audit findings identified weaknesses?
Is the procedure actually being followed?
Is the procedure effective?
What changes were required?
Who approved the changes?
Were the changes communicated?
When will the procedure next be reviewed?
Final Principle
A procedure review is not simply a document-date exercise. A meaningful review confirms that the procedure still reflects the organization’s risks, technology, responsibilities, requirements, and actual operating practices—and that any necessary changes are approved, communicated, implemented, and evidenced.