1. Purpose
The Operating Procedure Register is the master record of documented operating procedures maintained by the organization.
It provides a centralized view of:
- Which procedures exist
- Why each procedure is required
- Who owns each procedure
- Which business or security activity it supports
- Current version and status
- Approval and review dates
- Procedure criticality
- Related risks and controls
- Related systems and processes
- Evidence that procedures are reviewed and maintained
Core Principle
Identify → Register → Assign Ownership → Approve → Operate → Review → Update → Retire
2. Scope
The register may include procedures covering:
- Information security
- IT operations
- Access management
- Change management
- Production deployment
- Vulnerability management
- Patch management
- Backup and recovery
- Disaster recovery
- Incident management
- Logging and monitoring
- Cloud operations
- Network security
- Endpoint security
- Secure development
- Supplier management
- Business continuity
- Information handling
- Compliance monitoring
- Security testing
- Privacy
- Legal and regulatory compliance
- Other operational activities relevant to the ISMS
3. Register Information
| Field | Details |
|---|---|
| Register ID | |
| Register Owner | |
| ISMS Scope | |
| Version | |
| Effective Date | |
| Last Updated | |
| Next Review | |
| Approved By |
4. Operating Procedure Master Register
| Procedure ID | Procedure Name | Process/Area | Owner | Criticality | Version | Status | Effective Date | Next Review | Related Risk/Control |
|---|---|---|---|---|---|---|---|---|---|
Suggested Status Values
- Draft
- Under Review
- Approved
- Active
- Suspended
- Under Revision
- Superseded
- Retired
5. Procedure Identification
Every procedure should have a unique identifier.
Example:
| ID | Procedure |
|---|---|
| SOP-001 | Access Management Procedure |
| SOP-002 | Change Management Procedure |
| SOP-003 | Production Deployment Procedure |
| SOP-004 | Backup & Restore Procedure |
| SOP-005 | Disaster Recovery Procedure |
The organization may use another naming convention provided that procedures can be uniquely identified and traced.
6. Procedure Details
For each procedure, record:
| Field | Details |
|---|---|
| Procedure ID | |
| Procedure Name | |
| Process | |
| Business Function | |
| Security Domain | |
| Procedure Owner | |
| Operational Owner | |
| Approver | |
| Version | |
| Status | |
| Effective Date | |
| Review Date | |
| Criticality | |
| Classification | |
| Location |
7. Procedure Purpose
Document why the procedure exists.
Purpose
The purpose should explain the operational or security outcome the procedure supports.
8. Procedure Scope
Record what the procedure covers.
Scope
Identify:
- Systems
- Processes
- Teams
- Locations
- Information
- Technology
- Third parties
9. Procedure Criticality
Classify procedures according to their importance.
| Criticality | Typical Consideration |
|---|---|
| Low | Limited operational impact |
| Medium | Important operational activity |
| High | Significant security or business impact |
| Critical | Failure could materially affect critical services or security |
Examples of potentially critical procedures:
- Incident Response
- Disaster Recovery
- Access Management
- Backup & Restore
- Production Deployment
The organization’s risk methodology should determine the final classification.
10. Procedure Owner
Each active procedure should have an accountable owner.
Record:
Procedure Owner: __________________
Role: __________________
Department: __________________
Backup Owner: __________________
The owner is responsible for ensuring that the procedure remains:
- Relevant
- Current
- Approved
- Accessible
- Operationally appropriate
- Periodically reviewed
11. Operational Responsibility
The procedure owner and person performing the activity may be different.
| Procedure | Owner | Operational Team |
|---|---|---|
This distinction is useful for ensuring accountability without requiring the procedure owner to personally perform every activity.
12. Approval Information
Record:
| Field | Details |
|---|---|
| Approver | |
| Approval Role | |
| Approval Date | |
| Approval Method | |
| Approval Evidence |
A procedure should not be treated as an approved operating instruction until the required approval has been completed.
13. Version Control
Maintain the current version.
| Procedure ID | Current Version | Previous Version | Change Date | Change Description |
|---|---|---|---|---|
Version numbers may follow a defined convention such as:
- 1.0 — Initial approved version
- 1.1 — Minor change
- 2.0 — Major revision
14. Procedure Status
Use controlled status values.
☐ Draft
☐ Under Review
☐ Approved
☐ Active
☐ Under Revision
☐ Suspended
☐ Superseded
☐ Retired
Only approved/active procedures should normally be used for routine operations.
15. Effective Date
Record when the current version becomes operational.
Effective Date: __________________
Where a procedure replaces an older version, ensure the effective date is clear.
16. Review Frequency
Define an appropriate review frequency.
| Criticality | Example Review Frequency |
|---|---|
| Low | Periodic/risk-based |
| Medium | At least annually or risk-based |
| High | At least annually or after significant change |
| Critical | At least annually and after significant change |
These are example frequencies. The organization’s documented ISMS process should determine the actual requirement.
17. Next Review Date
Each active procedure should have a planned review date.
Next Review Date: __________________
The review should not be considered complete merely because the document was opened or re-approved.
The reviewer should determine whether the procedure remains:
- Accurate
- Applicable
- Effective
- Consistent with current technology
- Consistent with current risks
- Consistent with current requirements
18. Review Trigger
A procedure may require review before its scheduled date following:
☐ Security incident
☐ Major technology change
☐ Process change
☐ New system
☐ New cloud service
☐ New supplier
☐ Regulatory change
☐ Contractual change
☐ Customer requirement
☐ Audit finding
☐ Control weakness
☐ Business continuity event
☐ Significant organizational change
19. Procedure Review Record
| Procedure ID | Review Date | Reviewer | Review Result | Changes Required | Approval |
|---|---|---|---|---|---|
Suggested results:
- No Change Required
- Minor Update Required
- Major Revision Required
- Retire
- Replace
20. Procedure Change Register
Track significant changes.
| Change ID | Procedure ID | Change Description | Reason | Owner | Date | Approval |
|---|---|---|---|---|---|---|
Examples:
- New AWS architecture
- New CI/CD process
- New access model
- New regulatory requirement
- Incident lessons learned
- Audit finding
- New supplier
- New security control
21. Related Risk
Identify risks addressed by the procedure.
| Procedure | Risk ID | Risk Description | Treatment |
|---|---|---|---|
This creates traceability between:
Risk → Control → Procedure → Evidence
22. Related Controls
Record relevant security controls or organizational requirements.
| Procedure | Control/Requirement | Description |
|---|---|---|
Control mapping should reflect the organization’s actual ISMS and Statement of Applicability rather than automatically assigning controls to every procedure.
23. Related Policies
Identify governing policies.
| Procedure | Related Policy |
|---|---|
Examples:
- Information Security Policy
- Access Control Policy
- Cloud Security Policy
- Change Management Policy
- Business Continuity Policy
24. Related Records and Evidence
Identify the records generated by the procedure.
| Procedure | Evidence/Record | Storage Location | Retention |
|---|---|---|---|
Examples:
- Access approvals
- Change records
- Deployment logs
- Backup records
- Incident records
- Security test results
- Review records
25. Related Systems
Record systems involved in executing the procedure.
| Procedure | System/Platform | Purpose |
|---|---|---|
Examples:
- AWS
- GitHub
- Jira
- SIEM
- IAM
- HR system
- Ticketing platform
- Backup platform
26. Procedure Dependencies
Identify other procedures required to perform the activity.
| Procedure | Dependency | Relationship |
|---|---|---|
Example:
Production Deployment Procedure
may depend on:
- Change Management Procedure
- Access Management Procedure
- Backup & Restore Procedure
- Incident Response Procedure
27. Business Process Dependency
Identify the business process supported by the procedure.
| Procedure | Business Process | Criticality |
|---|---|---|
28. Personnel Dependency
Identify whether the procedure depends heavily on a specific person.
☐ No significant dependency
☐ Moderate dependency
☐ High dependency
☐ Single-person dependency
Where significant dependency exists, consider:
- Backup personnel
- Cross-training
- Runbooks
- Knowledge transfer
- Documentation
29. Third-Party Dependency
Record whether execution depends on suppliers.
☐ No
☐ Yes
Supplier
Dependency
Critical supplier dependencies should be aligned with the organization’s supplier and ICT dependency management processes.
30. Cloud Dependency
Identify whether the procedure depends on cloud services.
☐ No
☐ AWS
☐ Azure
☐ Google Cloud
☐ SaaS
☐ Other: __________
Record critical cloud dependencies where relevant.
31. Procedure Accessibility
Confirm that authorized personnel can access the current procedure.
☐ Available
☐ Access restricted appropriately
☐ Current version clearly identified
☐ Obsolete versions controlled
☐ Required personnel can locate it
The procedure should not be difficult to find when it is needed during normal operations or an incident.
32. Procedure Communication
Where appropriate:
☐ Relevant personnel informed
☐ Procedure published
☐ Training completed
☐ Role-specific briefing completed
☐ Changes communicated
Communication should be proportionate to the importance and complexity of the procedure.
33. Procedure Training
Determine whether training is required.
☐ No formal training required
☐ Awareness required
☐ Role-based training required
☐ Practical training required
Training Evidence
34. Procedure Effectiveness
Review whether the procedure actually works in practice.
Consider:
- Are required steps performed?
- Are records generated?
- Are security requirements followed?
- Are exceptions occurring?
- Are incidents occurring?
- Are audit findings recurring?
- Are employees bypassing the procedure?
- Are recovery or response activities successful?
Effectiveness Result
☐ Effective
☐ Partially Effective
☐ Ineffective
☐ Further Assessment Required
35. Compliance Monitoring
Determine whether compliance with the procedure is monitored.
☐ Not applicable
☐ Periodic review
☐ Control testing
☐ Compliance monitoring
☐ Internal audit
☐ Automated monitoring
☐ Management review
36. Procedure Findings
Record issues identified during review.
| Finding ID | Procedure | Finding | Risk | Action | Owner | Due Date |
|---|---|---|---|---|---|---|
37. Procedure Exceptions
Record approved deviations.
| Exception ID | Procedure | Exception | Reason | Risk | Approval | Expiry |
|---|---|---|---|---|---|---|
Exceptions should be managed through the organization’s exception and risk-management process.
38. Procedure Corrective Actions
| Action ID | Procedure | Issue | Corrective Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|
Actions should remain open until appropriate implementation and effectiveness have been verified.
39. Obsolete Procedures
When a procedure is replaced:
☐ New version approved
☐ Old version marked obsolete/superseded
☐ Current version published
☐ Operational teams informed
☐ Obsolete version removed from normal use
☐ Historical record retained where required
40. Procedure Retirement
A procedure may be retired when:
- The related process no longer exists.
- The system has been decommissioned.
- The activity has been outsourced.
- Another procedure replaces it.
- The risk no longer exists.
- Business requirements have changed.
Retirement Record
Procedure: __________________
Reason: __________________
Retirement Date: __________________
Approved By: __________________
Replacement Procedure: __________________
41. Operating Procedure Register Dashboard
Maintain summary metrics.
| Metric | Result |
|---|---|
| Total Procedures | |
| Active Procedures | |
| Draft Procedures | |
| Under Review | |
| Overdue Reviews | |
| Procedures Due Within 30 Days | |
| Procedures Due Within 90 Days | |
| Retired Procedures | |
| High/Critical Procedures | |
| Procedures Without Owner | |
| Procedures Without Approval | |
| Procedures With Open Findings |
42. Review Status Dashboard
| Status | Count |
|---|---|
| Current | |
| Due Soon | |
| Overdue | |
| Under Revision | |
| Retired |
Review Status Definitions
Current: Review is not due.
Due Soon: Review is approaching.
Overdue: Planned review date has passed.
Under Revision: Changes are being developed.
43. Critical Procedure Register
Maintain a separate view of procedures supporting critical operations.
| Procedure ID | Procedure | Critical Process | RTO | Dependency | Owner | Backup Owner |
|---|---|---|---|---|---|---|
Potential examples:
- Incident Response
- Disaster Recovery
- Backup & Restore
- Access Management
- Production Deployment
- Emergency Change
- Security Monitoring
44. Procedure Coverage Assessment
The organization should periodically determine whether important operational activities have appropriate documented procedures.
| Activity | Procedure Exists | Owner | Evidence | Gap |
|---|---|---|---|---|
| Access Management | ||||
| Change Management | ||||
| Production Deployment | ||||
| Backup | ||||
| Disaster Recovery | ||||
| Incident Response | ||||
| Vulnerability Management | ||||
| Supplier Management | ||||
| Security Monitoring |
The absence of a procedure is not automatically a nonconformity. The organization should determine whether documented operating information is necessary based on risk, complexity, personnel dependency, business requirements, and applicable requirements.
45. AWS SaaS Startup Example
A SaaS startup maintains the following operating procedures:
| ID | Procedure | Owner | Criticality | Review |
|---|---|---|---|---|
| SOP-001 | Access Management | IT/Security | High | Annual |
| SOP-002 | Change Management | Engineering | High | Annual |
| SOP-003 | Production Deployment | Engineering | High | Annual |
| SOP-004 | Backup & Restore | IT/DevOps | Critical | Annual |
| SOP-005 | Disaster Recovery | IT/DevOps | Critical | Annual |
| SOP-006 | Incident Response | Security | Critical | Annual |
| SOP-007 | Vulnerability Management | Security | High | Annual |
| SOP-008 | Supplier Management | Procurement/Security | Medium | Annual |
Example Review
The company changes its AWS architecture from EC2 to ECS.
The Operating Procedure Register identifies:
- Production Deployment Procedure
- Cloud Operations Procedure
- Disaster Recovery Procedure
- Backup & Restore Procedure
- Access Management Procedure
as potentially requiring review.
The change is therefore connected to the procedure-review process rather than relying solely on an annual calendar.
Audit Trail
Technology Change → Identify Affected Procedures → Review → Update → Approve → Communicate → Implement → Evidence
46. Startup-Friendly Operating Procedure Model
A startup does not need hundreds of procedures simply to demonstrate documentation.
Start with procedures for activities where failure could materially affect:
- Security
- Customer data
- Production systems
- Availability
- Compliance
- Business continuity
- Critical operations
Core Startup Procedure Set
Security
- Access Management
- Incident Response
- Vulnerability Management
- Security Monitoring
Engineering
- Change Management
- Production Deployment
- Secure Development
Operations
- IT Operations
- Backup & Restore
- Disaster Recovery
Third Parties
- Supplier Management
- Third-Party Access
Review the procedure inventory as the organization grows.
47. Common Mistakes
Avoid:
- Creating procedures without assigning owners.
- Maintaining procedures outside the register.
- Allowing multiple uncontrolled versions.
- Keeping obsolete procedures in active operational locations.
- Failing to track review dates.
- Treating document review as merely changing the date.
- Creating procedures that nobody follows.
- Creating excessive procedures for low-risk activities.
- Failing to update procedures after major technology changes.
- Not linking procedures to operational evidence.
- Not identifying dependencies.
- Having critical procedures without backup owners.
- Failing to review procedure effectiveness.
- Treating documentation itself as proof that the process operates effectively.
48. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Documented Operating Procedures Policy | Defines governance for procedures |
| Operating Procedure Template | Standardizes procedure structure |
| Information Security Policy | Provides overarching security direction |
| Risk Register | Identifies risks requiring treatment |
| Statement of Applicability | Records applicable controls |
| Control Testing Register | Tests control implementation/effectiveness |
| Compliance Monitoring Procedure | Monitors compliance |
| Internal Audit Procedure | Provides independent/internal assurance |
| Corrective Action Tracker | Tracks identified improvements |
| Information Security Exception Register | Tracks approved deviations |
| Document Control Process | Controls versions and records |
| Management Review | Reviews relevant ISMS information |
49. ISO/IEC 27001 Connection
An Operating Procedure Register supports controlled documented information and operational governance within an ISMS.
The organization should determine which procedures and documented information are necessary based on:
- ISMS scope
- Risk assessment
- Risk treatment
- Applicable controls
- Statement of Applicability
- Business requirements
- Technology complexity
- Personnel dependency
- Legal/regulatory requirements
- Customer requirements
- Contractual requirements
The Operating Procedure Register is not itself a universally prescribed ISO/IEC 27001 document. Its value is in providing a controlled inventory and traceability mechanism for procedures that the organization determines are necessary.
50. Audit Evidence Checklist
An auditor should be able to verify:
☐ Procedure inventory exists
☐ Each active procedure has an owner
☐ Procedure status is defined
☐ Current versions are identifiable
☐ Approval is recorded
☐ Review dates are tracked
☐ Overdue reviews are identified
☐ Critical procedures are identified
☐ Procedures are accessible to authorized personnel
☐ Changes are controlled
☐ Obsolete procedures are controlled
☐ Procedure effectiveness is considered
☐ Findings are tracked
☐ Corrective actions are tracked
☐ Procedure dependencies are understood
☐ Evidence demonstrates operational use
51. Final Operating Procedure Audit Trail
For every important operating procedure, the organization should be able to demonstrate:
Why is this procedure required?
Who owns it?
What process does it support?
What risks does it address?
Which systems and teams depend on it?
Who approved it?
Which version is currently active?
When was it last reviewed?
When is the next review due?
What changed since the previous version?
Is the procedure actually being followed?
What evidence demonstrates its operation?
What findings or exceptions exist?
What happens when the procedure is no longer required?
Final Principle
The Operating Procedure Register is not simply a list of documents. It provides the control point between documented procedures and actual operations—ensuring that necessary procedures have owners, remain current, are reviewed when circumstances change, and can be traced to the risks, controls, systems, and evidence they support.