What is ISO 27001 Annex A 5.37?
ISO 27001 Annex A 5.37 requires operating procedures for information processing facilities to be documented and made available to personnel who need them.
In simple terms, an organization should not depend entirely on someone’s memory or informal instructions for important security-related activities.
Important operational activities should have clear, documented procedures that explain:
- What needs to be done.
- Who is responsible.
- How it should be done.
- What security requirements must be followed.
- What records or evidence should be created.
- What to do when something goes wrong.
Simple explanation
If an important security-related activity happens regularly, people should know the correct way to perform it — and the organization should document that way of working.
Why is Annex A 5.37 Important?
Organizations often depend on a few experienced employees.
For example:
“Only Rahul knows how to restore the production database.”
This creates a significant operational and security risk.
If Rahul leaves the company or is unavailable during an incident, the organization may not know:
- How to perform the recovery.
- Which credentials are required.
- Which systems need to be restored first.
- Who needs to approve the action.
- How to verify that recovery was successful.
Documented operating procedures reduce this dependency.
They also help ensure that important activities are performed consistently and securely.
Benefits
A good operating procedure can help with:
- Consistent execution.
- Reduced human error.
- Faster onboarding.
- Business continuity.
- Incident response.
- Audit readiness.
- Knowledge transfer.
- Reduced dependency on individuals.
- Better security control operation.
- Repeatable processes.
Simple principle
Important operational activities should not depend on tribal knowledge.
What Does Annex A 5.37 Require?
The organization should determine which operational activities need documented procedures based on their:
- Business needs.
- Information security risks.
- Technology environment.
- Complexity.
- Regulatory requirements.
- Customer requirements.
- Operational dependencies.
The procedures should be:
- Documented.
- Appropriate for the activity.
- Available to people who need them.
- Kept current.
- Protected from unauthorized modification where appropriate.
- Reviewed when processes, technology or risks change.
Not every minor activity requires a lengthy document.
The objective is useful and controlled documentation, not documentation for its own sake.
What is an Operating Procedure?
An operating procedure is a documented description of how a specific activity should be performed.
For example:
Policy
Production changes must be authorized and tested.
Procedure
- Developer creates change request.
- Change is reviewed.
- Testing is completed.
- Authorized person approves deployment.
- Change is deployed.
- Deployment is verified.
- Evidence is retained.
The policy defines the requirement.
The procedure explains how people actually perform the activity.
The evidence demonstrates that the procedure was followed.
Examples of Operating Procedures
Depending on the organization, documented procedures may include:
IT Operations
- User account creation.
- User account modification.
- User account termination.
- Access reviews.
- Privileged access management.
- Password/MFA administration.
- Backup operations.
- Backup restoration.
- System monitoring.
- Log review.
- Vulnerability management.
- Patch management.
Security
- Security incident response.
- Security event triage.
- Evidence collection.
- Security alert handling.
- Vulnerability remediation.
- Security monitoring.
- Security testing.
Development
- Secure software development.
- Code review.
- Security testing.
- Production deployment.
- Emergency changes.
- Release management.
- Vulnerability handling.
Business Continuity
- Disaster recovery.
- System recovery.
- Failover.
- Backup restoration.
- Emergency access.
- Business continuity activation.
Supplier and Cloud Operations
- Cloud account administration.
- Supplier onboarding.
- Supplier security assessment.
- Supplier access management.
- Cloud configuration review.
- Cloud service exit.
What Should an Operating Procedure Contain?
There is no need for every procedure to be identical, but a useful procedure can include:
| Section | What it Covers |
|---|---|
| Purpose | Why the procedure exists |
| Scope | Systems, teams or activities covered |
| Roles | Who performs and approves the activity |
| Preconditions | What must be available before starting |
| Procedure | Step-by-step instructions |
| Security Requirements | Security controls that must be followed |
| Exceptions | What to do when normal steps cannot be followed |
| Escalation | When and how to escalate |
| Records | Evidence that must be retained |
| Review | How often the procedure is reviewed |
| Owner | Person responsible for maintaining it |
| Version | Document version and revision history |
Activities Required to Implement A.5.37
Step 1 — Identify Critical Operational Activities
Start by identifying activities where incorrect execution could create significant security or operational risk.
For example:
- Employee onboarding.
- Employee offboarding.
- Production deployment.
- Backup.
- Restore.
- Access management.
- Incident response.
- Vulnerability remediation.
- Security monitoring.
- Disaster recovery.
Step 2 — Determine Which Activities Need Documentation
Not everything needs a 20-page SOP.
Prioritize activities that are:
- Security-sensitive.
- Performed frequently.
- Business-critical.
- Complex.
- Difficult to perform correctly without instructions.
- Performed by multiple people.
- Required for regulatory or contractual compliance.
- Important during emergencies.
- Dependent on specific technical knowledge.
Step 3 — Assign an Owner
Every important procedure should have an accountable owner.
Example:
| Procedure | Owner |
|---|---|
| Access Management | IT Manager |
| Incident Response | Security Lead |
| Backup & Restore | Infrastructure Lead |
| Secure Deployment | Engineering Lead |
| Vulnerability Management | Security Team |
| Employee Offboarding | HR + IT |
| Disaster Recovery | CTO/IT |
The owner is responsible for keeping the procedure accurate and current.
Step 4 — Document the Actual Process
Document how the activity is actually performed.
Avoid creating a procedure that describes an ideal process that nobody follows.
For example:
Backup Procedure
- Identify systems requiring backup.
- Verify backup schedule.
- Check backup completion.
- Investigate failures.
- Protect backup storage.
- Monitor backup status.
- Perform restoration testing.
- Record test results.
- Escalate recurring failures.
The procedure should be practical enough that another qualified employee can follow it.
Step 5 — Include Security Requirements
The procedure should explain important security considerations.
For example, a production deployment procedure might require:
- Authorized change ticket.
- Code review.
- Security testing where applicable.
- Approval.
- Controlled deployment.
- Logging.
- Rollback capability.
- Post-deployment verification.
Step 6 — Define Evidence
Determine what evidence should be generated.
For example:
| Procedure | Possible Evidence |
|---|---|
| Access Management | Access request/approval |
| Offboarding | Termination checklist |
| Backup | Backup report |
| Restore | Restore test report |
| Change Management | Change ticket |
| Incident Response | Incident record |
| Vulnerability Management | Vulnerability report |
| Security Monitoring | Monitoring logs |
| Disaster Recovery | DR test report |
This makes the procedure useful for both operations and audits.
Step 7 — Make Procedures Available
Personnel who need a procedure should be able to access it.
For example:
- Company knowledge base.
- Document management system.
- GRC platform.
- Controlled SharePoint/Google Drive.
- Internal wiki.
- Secure documentation platform.
Access should be controlled where procedures contain sensitive information.
For example, a document containing privileged recovery information should not necessarily be available to every employee.
Step 8 — Review and Update Procedures
Procedures should be reviewed when:
- Technology changes.
- Systems change.
- Responsibilities change.
- Security incidents occur.
- Audit findings identify weaknesses.
- Regulations or contractual requirements change.
- The business changes.
- A procedure proves ineffective.
- Significant process changes occur.
A periodic review schedule can also be established.
Startup Example
Consider a 40-person SaaS startup.
The company has a small infrastructure team.
Only one engineer currently knows how to restore the production database.
This creates a key-person dependency.
The company creates a Production Database Backup & Restoration Procedure.
The procedure documents:
- When backups are performed.
- Where backups are stored.
- Who can access backups.
- How restoration is initiated.
- Who approves production restoration.
- How the restore environment is prepared.
- How data integrity is checked.
- How the application is reconnected.
- How recovery is validated.
- What evidence must be recorded.
- Who should be contacted if restoration fails.
The procedure is stored in the company’s controlled knowledge repository.
The team then performs a restoration test.
Flow
Document Procedure
↓
Train Relevant Personnel
↓
Perform Activity
↓
Record Evidence
↓
Test
↓
Review
↓
Update Procedure
This is much stronger than simply telling employees:
“We have backups.”
Startup-Focused Quick Summary
A startup does not need hundreds of complicated SOPs.
Start with the activities that could cause significant security or business impact if performed incorrectly.
Priority procedures for a SaaS startup
1. Joiner / Mover / Leaver
2. Access Management
3. Backup & Restore
4. Incident Response
5. Vulnerability Management
6. Change Management
7. Production Deployment
8. Security Monitoring
9. Disaster Recovery
10. Supplier / Cloud Management
Then expand the documentation as the organization grows.
Example Operating Procedure Register
A simple register can be maintained:
| Procedure | Owner | Frequency | Last Review | Next Review | Status |
|---|---|---|---|---|---|
| Access Management | IT | Quarterly | 01-Jul | 01-Oct | Current |
| Backup & Restore | Infrastructure | Quarterly | 15-Jun | 15-Sep | Current |
| Incident Response | Security | Annual / After Incident | 10-May | 10-May | Current |
| Vulnerability Management | Security | Quarterly | 20-Jun | 20-Sep | Current |
| Production Deployment | Engineering | Quarterly | 05-Jul | 05-Oct | Current |
| Disaster Recovery | CTO | Annual | 01-Apr | 01-Apr | Current |
This gives management and auditors visibility into the operating procedures supporting the ISMS.
Example: Access Management Procedure
A simple access management procedure could look like:
1. Access Request
Employee or manager submits access request.
2. Business Justification
The requested access must have a legitimate business requirement.
3. Approval
Appropriate manager/system owner approves the request.
4. Provisioning
IT provisions the required access.
5. Verification
Access is verified against the approved request.
6. Recording
Access request and approval evidence are retained.
7. Periodic Review
Access rights are reviewed periodically.
8. Removal
Access is removed when no longer required.
This procedure supports several other ISO 27001 controls.
Audit Evidence for A.5.37
An auditor may review:
Documented Procedures
- Access Management Procedure.
- Joiner/Mover/Leaver Procedure.
- Backup Procedure.
- Restore Procedure.
- Incident Response Procedure.
- Vulnerability Management Procedure.
- Change Management Procedure.
- Production Deployment Procedure.
- Disaster Recovery Procedure.
- Security Monitoring Procedure.
- Supplier Management Procedure.
Document Control
- Procedure owner.
- Version number.
- Approval.
- Effective date.
- Review date.
- Revision history.
Operational Evidence
- Completed checklists.
- Tickets.
- Logs.
- Backup reports.
- Restore test reports.
- Access requests.
- Change records.
- Incident records.
- Vulnerability reports.
- DR test reports.
Training / Awareness
Where appropriate:
- Training records.
- Procedure acknowledgement.
- Staff competency records.
- Exercise records.
What an Auditor May Ask
About the procedures
“Show me your documented operating procedures.”
“Which procedures are considered critical?”
“How did you determine which activities require documentation?”
About ownership
“Who owns this procedure?”
“Who approves changes to it?”
About actual implementation
“Show me evidence that this procedure is actually being followed.”
“Show me the most recent backup restoration test.”
“Show me an example of a completed access request.”
“Show me a recent production change.”
About maintenance
“When was this procedure last reviewed?”
“What caused the last update?”
“What happens when the underlying technology changes?”
Common Mistakes in Implementing A.5.37
1. Creating procedures only for the audit
A procedure that exists only in a document repository but is not used operationally provides limited value.
2. Procedures are too generic
For example:
“Backups should be performed regularly.”
This does not tell an employee:
- What is backed up?
- How often?
- Where?
- Who checks it?
- What happens if it fails?
- How is restoration tested?
3. Procedures do not match reality
The documented procedure says one thing while employees perform the activity differently.
This can create audit findings.
4. No document owner
Nobody is responsible for maintaining the procedure.
5. Procedures become outdated
Technology changes but the procedure remains unchanged.
For example:
The company moves from one cloud platform to another, but the backup procedure still describes the old platform.
6. Sensitive information is included unnecessarily
Operational procedures should not unnecessarily contain:
- Passwords.
- API secrets.
- Private keys.
- Recovery credentials.
Secrets should be managed using appropriate secure mechanisms.
7. No evidence is generated
A procedure should identify what records should be created when the process is performed.
8. Employees cannot find the procedures
Documentation is not useful if the people who need it cannot locate it.
9. One person knows everything
If only one employee knows how to perform critical operational activities, the organization has a significant knowledge and continuity risk.
Practical Startup Implementation Model
A practical startup model is:
Identify
Identify critical and security-sensitive operational activities.
↓
Prioritize
Focus first on activities with high business or security impact.
↓
Document
Create simple, practical procedures.
↓
Assign
Give each procedure an owner.
↓
Train
Ensure relevant personnel understand the procedure.
↓
Operate
Use the procedure during actual operations.
↓
Evidence
Retain appropriate records.
↓
Test
Test critical procedures where appropriate.
↓
Review
Update procedures when technology, people, risks or processes change.
Policy vs. Procedure vs. Evidence
This distinction is particularly important for A.5.37.
| Type | Example |
|---|---|
| Policy | Access must be controlled according to business need. |
| Standard | Privileged accounts must use MFA. |
| Procedure | Steps for requesting, approving, provisioning and removing access. |
| Work Instruction | Detailed technical instructions for performing a specific task. |
| Evidence | Access request, approval and provisioning record. |
Simple rule
Policy = What and why
Standard = Required security level
Procedure = How
Evidence = Proof that it happened
A.5.37 and Knowledge Transfer
One of the most valuable benefits of A.5.37 for startups is reducing key-person dependency.
Suppose:
“Only the CTO knows how to recover production.”
That is a business continuity risk.
Instead:
Document
→ Train
→ Cross-train
→ Test
→ Improve
The goal is not to eliminate expert knowledge.
The goal is to ensure that critical operations can continue even when a particular person is unavailable.
Relationship with Other ISO 27001 Controls
A.5.37 supports many other controls.
| Control | Relationship |
|---|---|
| A.5.1 | Information security policies provide the requirements that procedures operationalize |
| A.5.15 | Access control procedures explain how access is managed |
| A.5.18 | Access-right procedures support provisioning and review |
| A.5.24 | Incident management preparation requires documented processes |
| A.5.26 | Incident response procedures define operational actions |
| A.5.28 | Evidence collection procedures support incident investigations |
| A.5.29 | Disruption procedures support secure operations during disruption |
| A.5.30 | ICT continuity procedures support recovery |
| A.5.36 | Compliance reviews can verify that procedures are being followed |
| A.8.8 | Vulnerability management procedures support remediation |
| A.8.13 | Backup procedures support information backup |
| A.8.15 | Logging procedures support operational monitoring |
| A.8.32 | Change-management procedures support controlled changes |
Useful Documents for A.5.37
Organizations may create:
- [Insert Draft Document Link] — Documented Operating Procedures Policy
- [Insert Draft Document Link] — Operating Procedure Template
- [Insert Draft Document Link] — IT Operations Procedure
- [Insert Draft Document Link] — Access Management Procedure
- [Insert Draft Document Link] — Joiner, Mover and Leaver Procedure
- [Insert Draft Document Link] — Backup and Restore Procedure
- [Insert Draft Document Link] — Incident Response Procedure
- [Insert Draft Document Link] — Vulnerability Management Procedure
- [Insert Draft Document Link] — Change Management Procedure
- [Insert Draft Document Link] — Production Deployment Procedure
- [Insert Draft Document Link] — Disaster Recovery Procedure
- [Insert Draft Document Link] — Operating Procedure Register
- [Insert Draft Document Link] — Procedure Review Checklist
A.5.37 Audit Readiness Checklist
Before an ISO 27001 audit, ask:
- Have we identified critical information-security-related operational activities?
- Are important operating procedures documented?
- Does each procedure have an owner?
- Are procedures approved where appropriate?
- Are procedures version controlled?
- Are procedures available to relevant personnel?
- Do procedures reflect actual working practices?
- Do procedures define security requirements?
- Do procedures identify required evidence?
- Are critical procedures tested where appropriate?
- Are employees trained or made aware where necessary?
- Are procedures reviewed periodically?
- Are procedures updated after significant changes?
- Are outdated versions controlled?
- Can the organization demonstrate that procedures are actually being followed?
Questions a Startup Should Ask
Before finalizing an operating procedure, ask:
Can another qualified employee follow this document without having to ask the original author what to do?
Does the procedure reflect what we actually do?
Does it clearly identify security requirements?
Does it explain what happens when something goes wrong?
Does it identify the evidence that should be retained?
Has the procedure been tested where appropriate?
If the answer is yes, the procedure is much more likely to be useful both operationally and during an ISO 27001 audit.
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.37 is about making important operations repeatable, understandable and controlled.
A startup should not create documentation simply because an auditor might ask for it.
The real objective is to make sure that critical activities can be performed:
- Consistently
- Securely
- Correctly
- By more than one person where appropriate
- With appropriate evidence
- Even when key employees are unavailable
A practical approach is:
Identify critical activities
↓
Document how they should be performed
↓
Assign ownership
↓
Make procedures available
↓
Use them in daily operations
↓
Generate evidence
↓
Test critical procedures
↓
Review and update
The key question for A.5.37 is:
“If the person who normally performs this important security activity is unavailable tomorrow, do we have a documented and reliable way for another qualified person to perform it securely?”
If the answer is yes, the organization is moving beyond informal knowledge and toward a more mature, repeatable and auditable ISMS.