ISO 27001 A.5.37: Documented Operating Procedures

Quick Reference: A.5.37 in 60 Seconds

What the Standard Actually Requires

Figure · Process

What A.5.37 asks you to do

ISO 27001:2022 A.5.37 Control Text

ISO 27001:2022 Annex A 5.37 asks organizations to document operating procedures for information processing facilities and make them available to those who need them.

This is one of the shortest and most operationally focused controls in Annex A. The word "shall" makes it mandatory. Two obligations are imposed on the organization:

1. Document operating procedures, the procedures required to operate information processing facilities must be written down.
2. Make them available to relevant personnel, the documented procedures must be accessible to the people who need them to do their jobs.

There is no explicit requirement in ISO 27001:2022 for approval, review, or version control within the control text itself, but these are implied through other ISO 27001 clauses, especially clause 7.5 (Documented information) and clause 8.1 (Operational planning and control). An auditor will not accept a random Word document stored on a local desktop as satisfying A.5.37.

ISO 27002:2022 Implementation Guidance (Section 5.37)

ISO 27002 expands the control into practical guidance:

1. Establish operating procedures for all IT and information processing facilities where deviation from the procedure could adversely affect information security or business operations.
2. Procedures should cover:
   • System start-up, shutdown, and restart operations
   • Software installation, configuration, and hardening
   • Routine maintenance, housekeeping, and monitoring
   • Backup, recovery, and restoration
   • Logging, log review, and incident handling
   • Security device management (firewalls, IDS/IPS, SIEM, AV/EDR)
   • User account provisioning and de-provisioning
   • Patch management and vulnerability remediation
   • Change implementation steps
   • Handling of media, output, and documentation
3. Procedures should be:
   • Accurate and complete
   • Tested where necessary
   • Kept up to date
   • Approved by management or system owners
   • Accessible to personnel who need them
4. Segregation between operational and development environments should be maintained; operating procedures should not inadvertently expose production credentials or configurations.
5. Changes to operating procedures should follow the organization's change management process.

"Shall" vs. "Should" Analysis

What Auditors Actually Check

Why This Control Matters

The Business Risk Narrative

Documented operating procedures are the operational immune system of an organization. Policies tell people what to do; procedures tell them how. But operating procedures tell them exactly how to perform repetitive, critical, or risky tasks so that the outcome is consistent, secure, and independent of who is on duty.

When operating procedures are missing, outdated, or inaccessible, organizations rely on tribal knowledge. The risk is severe:

• Inconsistent execution: Two engineers performing the same backup task may use different commands, different retention settings, or different verification steps.
• Single points of failure: If the one person who knows how to restore the database leaves the organization, the business continuity plan collapses.
• Security misconfigurations: Firewall rules, access controls, and encryption settings are applied inconsistently, creating exploitable gaps.
• Delayed incident response: Without runbooks, responders waste critical minutes figuring out what to do instead of doing it.
• Audit failures: Auditors cannot verify that controls are implemented if the method of implementation exists only in someone's head.

Gartner research indicates that approximately 80% of unplanned downtime is caused by human error, and a significant portion of that error stems from the absence of clear, validated procedures. Forrester studies on operational resilience show that organizations with mature runbook practices recover from incidents up to 60% faster than those without.

Indian Regulatory Context

Indian organizations are subject to a dense web of regulations that implicitly or explicitly require documented operating procedures.

The Digital Personal Data Protection Act, 2023 (DPDP Act)

The DPDP Act requires data fiduciaries to implement reasonable security safeguards to protect personal data. Section 8(5) and the anticipated rules will expect technical and organizational measures. Documented operating procedures are a foundational organizational measure:

• Procedures for data subject rights requests (access, correction, erasure).
• Procedures for breach notification to the Data Protection Board and data principals.
• Procedures for data retention and secure deletion.
• Procedures for consent management and consent withdrawal.
• Procedures for cross-border data transfer controls.

Failure to demonstrate documented procedures can be interpreted as failure to implement reasonable safeguards, attracting penalties up to INR 250 crore for certain breaches.

CERT-In Directions, 2022

The Indian Computer Emergency Response Team (CERT-In) mandates:

• Incident reporting within 6 hours of noticing or being brought to notice of a cyber incident.
• Synchronization of ICT system clocks.
• Maintenance of logs for 180 days within Indian jurisdiction.
• Reporting to CERT-In of certain cyber incidents.

Each of these requirements demands documented operating procedures. Organizations cannot reliably report incidents within 6 hours without a runbook that defines what constitutes a reportable incident, who reports it, and through which channel.

Reserve Bank of India (RBI) Guidelines

Banks, NBFCs, payment system operators, and fintechs regulated by RBI must comply with:

• Master Direction on Information Technology Framework for the NBFC Sector.
• Guidelines on Information Security, Electronic Banking, Technology Risk Management, and Cyber Frauds.
• Master Direction on Cyber Security Framework in Banks.

These guidelines explicitly require documented IT operating procedures, business continuity plans, incident response plans, change management procedures, and vendor management procedures. RBI inspections routinely ask for SOPs and test whether they are followed.

Securities and Exchange Board of India (SEBI)

SEBI's Cyber Security and Cyber Resilience Framework for stock brokers, depository participants, mutual funds, and other regulated entities requires:

• Documented policies and procedures for cyber security.
• Incident response and reporting procedures.
• Business continuity and disaster recovery procedures.
• Vulnerability assessment and penetration testing procedures.
• Two-factor authentication and access control procedures.

Insurance Regulatory and Development Authority of India (IRDAI)

IRDAI guidelines on information and cyber security for insurers require documented procedures for:

• Governance and risk management.
• Data protection and privacy.
• Access control and identity management.
• Incident management and reporting.
• Business continuity management.

Information Technology Act, 2000

Sections 43, 43A, and 66 of the IT Act create liability for negligence in maintaining reasonable security practices. The Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 (the SPDI Rules) require organizations handling sensitive personal data to implement documented security practices and procedures. ISO 27001 is explicitly recognized as an acceptable standard. A.5.37 directly supports compliance with the reasonable security practices requirement.

Industry-Specific Consequences

impact of Non-Compliance with Statistics

• Average impact of IT downtime: USD 5,600 per minute (Gartner).
• Average impact of a data breach in India: INR 17.9 crore (IBM impact of a Data Breach Report 2024).
• Percentage of breaches caused by human error: 74% (Verizon DBIR 2024).
• Organizations with documented incident response plans: Save INR 8.5 crore on average per breach (IBM).
• RBI cyber security penalties on banks: Multiple banks have been fined INR 1 crore to INR 5 crore for deficiencies in IT operations and cyber controls.

Documented operating procedures are not a paper exercise. They are a direct control against operational, financial, and reputational damage.

Scope and Applicability

What This Control Covers

A.5.37 applies to operating procedures, the step-by-step instructions used to operate, administer, maintain, and support information processing facilities. It covers:

• IT infrastructure operations: Servers, networks, storage, cloud platforms, databases, middleware.
• Security operations: SIEM monitoring, firewall administration, EDR/AV management, identity management.
• Application operations: Deployment, rollback, health checks, performance tuning.
• End-user operations: Device provisioning, password resets, software installation, access requests.
• Data operations: Backup, restore, archival, retention, deletion, migration.
• Facility operations: Data center operations, environmental controls, physical access systems.
• Incident and continuity operations: Escalation, containment, recovery, crisis communication.
• Change and release operations: Pre-change checks, implementation steps, post-change validation.
• Vendor and supplier operations: Managed service handoffs, SLA monitoring, access reviews.

What This Control Does Not Cover (But Is Related To)

Who It Applies To

Size-Based Applicability

A.5.37 applies regardless of organization size. The depth and formality of documentation should scale with risk and complexity, not with the presence or absence of the requirement.

Key Definitions and Terminology

Relationship to Other Controls

Upstream Controls

Upstream controls create the governance context within which A.5.37 operates.

Downstream Controls

A.5.37 directly enables the consistent implementation of many operational and technical controls.

Parallel Controls

Detailed Implementation Guidance

Step 0: Establish Governance for Operating Procedures

Before writing a single SOP, define how SOPs will be governed.

Governance decisions to document:

• SOP taxonomy: How will SOPs be categorized? (By system, by function, by risk level, by control mapping?)
• Template standard: One mandatory template for consistency.
• Ownership model: Who authors, reviews, approves, and maintains each SOP?
• Review cadence: Annual for all; quarterly for high-risk; trigger-based for changes and incidents.
• Repository: Central, searchable, access-controlled location.
• Version control: Naming convention, change log, archival rules.
• Training and communication: How are SOPs introduced to staff?
• Compliance monitoring: How is adherence measured?

Recommended governance body:

Step 1: Inventory Systems and Operations That Need SOPs

Start with a SOP coverage inventory. List every information processing facility, system, network, application, and service, then determine whether an operating procedure is required.

Priority rule: If a task is performed repeatedly, is critical to security or availability, or involves more than one person, it needs an SOP.

Step 2: Define the SOP Hierarchy and Taxonomy

A mature organization distinguishes between different levels of operational documentation:

┌─────────────────────────────────────────────────────────────┐
│  LEVEL 1: POLICIES                                          │
│  What we must do and why                                    │
│  Example: Information Security Policy, Access Control Policy│
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 2: PROCEDURES / STANDARDS                            │
│  How we do it at a process level                            │
│  Example: Change Management Procedure, Patch Management Std │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 3: OPERATING PROCEDURES / RUNBOOKS (A.5.37)          │
│  Step-by-step instructions for specific systems or tasks    │
│  Example: AWS EC2 patching runbook, AD password reset SOP   │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LEVEL 4: WORK INSTRUCTIONS / CHECKLISTS                    │
│  Very granular, task-level guidance                         │
│  Example: SSL certificate renewal checklist, onboarding form│
└─────────────────────────────────────────────────────────────┘

Recommended SOP categories for an Indian tech company:

1. Identity and Access Management SOPs
2. Network and Infrastructure SOPs
3. Cloud and Platform SOPs
4. Security Operations SOPs
5. Data Management SOPs
6. Application Operations SOPs
7. Endpoint and Device SOPs
8. Incident and Continuity SOPs
9. Vendor and Supplier SOPs
10. Physical and Facilities SOPs
11. Compliance and Audit SOPs

Step 3: Adopt a Standard SOP Template

A standard template ensures every SOP contains the same essential elements. See Section 9 for the full template.

Minimum required fields:

• SOP title and unique ID
• Version number and effective date
• Approval signatures
• Purpose and scope
• Roles and responsibilities
• Prerequisites and dependencies
• Step-by-step instructions
• Expected outcomes / verification
• Rollback or error handling
• Related documents
• Review history

Step 4: Author SOPs with Operational Detail

Good SOPs are written by the people who do the work, reviewed by peers, and approved by system owners. They must be specific enough to be executed by a qualified substitute.

Writing principles:

• Use imperative verbs: "Run," "Verify," "Restart," "Escalate."
• Include exact commands, menu paths, or URLs where possible.
• Include expected outputs or screenshots for verification.
• State decision points clearly with "If X, then Y; else Z."
• Include safety checks: backups, approvals, notifications.
• Avoid assumptions; define acronyms and prerequisites.
• Keep runbooks concise; use appendices for reference data.

Example: Backup Verification SOP Excerpt

SOP-NET-007: Daily Database Backup Verification

1. Log in to the backup management console at https://backup.company.local.
2. Navigate to Jobs > Database > Production.
3. Verify that the job "PROD-DB-FULL" shows status Completed for the previous night.
4. If status is Failed or Warning, open incident INC-BKP-001 and notify the DBA on-call.
5. Select the completed job and click Verify to initiate an integrity check.
6. Wait for verification to complete. Expected result: "Integrity check passed."
7. If verification fails, immediately quarantine the backup set and initiate a retry.
8. Document the result in the Backup Verification Log (sheet: Daily).

Step 5: Review, Approve, and Publish

Every SOP must pass through a controlled lifecycle:

DRAFT → TECHNICAL REVIEW → SECURITY REVIEW → APPROVAL → PUBLISH → COMMUNICATE → TRAIN → PERIODIC REVIEW

Step 6: Make SOPs Available

SOPs must be available to personnel who need them. Availability means:

• Findable: Searchable by system name, task, keyword, or control mapping.
• Accessible: Available during normal operations and incidents, including from alternate locations if primary systems are down.
• Readable: Available in a language and format understood by the personnel.
• Current: Only the latest approved version is visible for routine use.
• Protected: Access controlled so unauthorized personnel cannot misuse operational details (e.g., credentials, network diagrams).

Availability channels:

• Central intranet wiki or knowledge base (primary)
• ITSM tool attachment (linked to relevant service or configuration item)
• Document management system (SharePoint, Confluence, Documentum)
• Offline copies for business continuity scenarios (secure USB, printed binders in secure location)
• Mobile-accessible versions for on-call engineers

Step 7: Train Personnel and Verify Competence

Training ensures that SOPs are not just available but understood and followed.

Step 8: Monitor, Review, and Improve

SOPs are living documents. Establish a review rhythm:

Implementation by Organization Size

For Startups and Small Organizations (10-50 employees)

• Use a simple wiki (Notion, Confluence, or GitBook).
• Start with 10-15 critical SOPs: backup, restore, onboarding, offboarding, firewall change, incident escalation, patching, access request.
• Combine author, reviewer, and approver roles where appropriate, but maintain independence for high-risk SOPs.
• Review quarterly for the first year to mature quickly.

For Mid-Sized Organizations (50-500 employees)

• Implement an ITSM tool (ServiceNow, Freshservice, Jira Service Management).
• Link SOPs to configuration items in the CMDB.
• Introduce formal RACI ownership.
• Begin automated monitoring of SOP review status and training completion.

For Large and Enterprise Organizations (500+ employees)

• Deploy a dedicated knowledge management or GRC platform.
• Federate SOP ownership to business units with central governance.
• Automate SOP compliance checks where possible.
• Integrate SOP execution with SOAR playbooks and ITSM workflows.
• Maintain business unit or geography-specific variations with clear mapping to the master SOP.

SOPs for Cloud and DevOps Environments

Cloud and DevOps environments introduce unique operating procedure challenges: ephemeral infrastructure, infrastructure-as-code (IaC), continuous deployment, and shared responsibility models. A.5.37 applies equally here, but the form of documentation must adapt.

Key principles for cloud and DevOps SOPs:

1. SOP the process, not just the server. In auto-scaling environments, document the pipeline and configuration rather than individual instance steps.
2. Version control SOPs alongside code. Store runbooks in Git repositories so they evolve with the systems they describe.
3. Automate the deterministic parts. Use CI/CD pipelines, Ansible playbooks, Terraform plans, and Kubernetes manifests to enforce SOPs.
4. Document exceptions and escalations. Automated systems fail; SOPs must describe how humans intervene.
5. Maintain runbooks for incident scenarios. Cloud outages, region failures, and service degradation require pre-defined response runbooks.

Cloud-specific SOP examples:

SOP Automation and Infrastructure as Code

Automation does not eliminate the need for SOPs; it changes their focus. Automated SOPs must be documented, version-controlled, reviewed, and tested just like manual ones.

SOP automation maturity stages:

Documentation requirements for automated SOPs:

• Design rationale and decision logic
• Input parameters, preconditions, and constraints
• Output and success criteria
• Error handling and escalation paths
• Maintenance and ownership
• Audit logs and evidence of execution

Example: Automated Patch Deployment SOP

SOP-CLO-012: Automated OS Patch Deployment via Ansible

1. Patch candidate list is generated by vulnerability scanner every Tuesday.
2. Ansible playbook PATCH-OS-001 reads the candidate list from the shared drive.
3. Playbook executes in staging environment (SOP-CLO-012-STAGING).
4. Automated tests verify application functionality post-patch.
5. If tests pass, change request CHG-PATCH-### is auto-created for CAB approval.
6. Upon CAB approval, playbook executes in production during maintenance window.
7. Results are logged to the Patch Management Log.
8. Failures trigger incident INC-PATCH-### and notify on-call engineer.

Automation must be paired with human-readable SOPs so that operations teams can understand, audit, and intervene when needed.

Tools, Technologies, and Solutions

Categories of Tools

Vendor Comparison Matrix

Tool Selection Guidance

Policy and Procedure Templates

Operating Procedures Policy (Level 2)

OPERATING PROCEDURES POLICY
[Organization Name]
Version: 1.0
Approved by: [CISO / IT Director]
Date: [Date]
Review Date: [Date + 12 months]
Classification: Internal

---

1. PURPOSE

This policy establishes the requirements for documenting, maintaining, and 
making available operating procedures for information processing facilities 
and IT services in accordance with ISO 27001:2022 Annex A 5.37.

2. SCOPE

This policy applies to all employees, contractors, vendors, and managed service 
providers who operate, administer, support, or maintain [Organization Name]'s 
information processing facilities, systems, networks, applications, and services.

3. POLICY STATEMENTS

3.1 All operating procedures required for the secure and reliable operation 
    of information processing facilities shall be documented.

3.2 Documented operating procedures shall be made available to all personnel 
    who need them to perform their duties.

3.3 Operating procedures shall be accurate, complete, reviewed, approved, 
    version-controlled, and protected against unauthorized modification.

3.4 Each operating procedure shall have a designated owner responsible for 
    its accuracy, review, and currency.

3.5 Operating procedures shall be reviewed at planned intervals, after 
    significant changes, and after incidents that reveal gaps.

3.6 Personnel shall be trained on the operating procedures applicable to 
    their role.

3.7 Deviations from operating procedures shall be documented, justified, 
    and approved.

4. ROLES AND RESPONSIBILITIES

- CISO: Overall governance of the operating procedures program.
- IT Director: Ensures resources and accountability for IT operations SOPs.
- System Owners: Approve SOPs for systems under their ownership.
- SOP Authors: Draft and update SOPs.
- SOP Administrator: Maintains repository, tracks reviews, archives versions.
- All Operational Staff: Follow documented procedures and report issues.

5. COMPLIANCE

Failure to follow documented operating procedures may result in disciplinary 
action, particularly where such failure leads to security incidents, downtime, 
or non-compliance with regulatory obligations.

6. RELATED DOCUMENTS

- Information Security Policy (A.5.1)
- Change Management Procedure (A.8.32)
- Incident Response Plan (A.5.24-A.5.26)
- Documented Information Control Procedure (ISO 27001 clause 7.5)
- SOP Master Index

7. REVIEW

This policy is reviewed annually and when significant changes occur.

Standard Operating Procedure Template (Level 3)

STANDARD OPERATING PROCEDURE

SOP ID: [SOP-XXX-###]
Title: [Clear, action-oriented title]
Category: [e.g., Identity Management, Network Operations, Security Operations]
System/Service: [Name of system or service]
Owner: [Name and role]
Author: [Name]
Reviewers: [Names and roles]
Approved by: [Name and title]
Classification: [Internal / Confidential / Restricted]
Version: [X.Y]
Effective Date: [YYYY-MM-DD]
Next Review Date: [YYYY-MM-DD]
ISO 27001 Mapping: [e.g., A.5.37, A.8.13, A.8.32]

---

1. PURPOSE

Brief statement of what this SOP accomplishes and why it exists.

2. SCOPE

Who must follow this SOP and under what circumstances.

3. DEFINITIONS

Key terms, acronyms, and abbreviations used in this SOP.

4. ROLES AND RESPONSIBILITIES

| Role | Responsibility |
|---|---|
| [Role 1] | [Responsibility] |
| [Role 2] | [Responsibility] |

5. PREREQUISITES

- Access requirements (accounts, groups, permissions)
- Tools or systems needed
- Pre-conditions (e.g., maintenance window, backup completed)
- Related approvals or tickets

6. PROCEDURE

6.1 [Step 1]
    [Detailed instruction]
    [Expected result]

6.2 [Step 2]
    [Detailed instruction]
    [Expected result]

6.3 [Decision point or conditional step]
    IF [condition]
       THEN [action]
    ELSE [alternative action]

7. VERIFICATION

How to confirm the procedure was completed correctly.

8. ROLLBACK / ERROR HANDLING

Steps to take if the procedure fails or produces unexpected results.

9. RELATED DOCUMENTS

- [Linked policy]
- [Linked procedure]
- [Linked runbook]
- [Linked checklist]

10. REVISION HISTORY

| Version | Date | Author | Description of Change | Approved By |
|---|---|---|---|---|
| 1.0 | YYYY-MM-DD | [Name] | Initial release | [Name] |
| 1.1 | YYYY-MM-DD | [Name] | [Description] | [Name] |

11. APPROVAL SIGNATURES

| Name | Role | Signature | Date |
|---|---|---|---|
| [Name] | [Role] | _______________ | [Date] |
| [Name] | [Role] | _______________ | [Date] |

Sample SOP: Privileged Account Access Request and Provisioning

SOP ID: SOP-IAM-003
Title: Privileged Account Access Request and Provisioning
Owner: Identity and Access Management Lead
Version: 2.1
Effective Date: 2026-01-15
Next Review Date: 2027-01-15

1. PURPOSE
To standardize the request, approval, provisioning, and review of privileged 
access to [Organization Name]'s critical systems.

2. SCOPE
All requests for privileged access to production systems, databases, network 
devices, cloud consoles, security tools, and backup systems.

3. PREREQUISITES
- Requester has a valid business justification.
- Requester's manager has approved the request.
- Security team has reviewed the risk.

4. PROCEDURE
4.1 Requester submits a ticket in the ITSM portal using form "Privileged Access Request."
4.2 Manager reviews and approves the request within 24 hours.
4.3 Security team performs risk review and approves within 48 hours.
4.4 IAM team provisions access using the principle of least privilege.
4.5 MFA is enforced on the privileged account.
4.6 Access is logged in the Privileged Access Log.
4.7 Requester and manager are notified of provisioning.
4.8 Access is reviewed quarterly by the system owner.

5. VERIFICATION
Confirm the account exists in the Privileged Access Register with:
- Requester name
- Approved by
- Systems granted
- MFA status = Enabled
- Review date set

6. ROLLBACK
If access was granted in error, revoke within 2 hours and notify requester, 
manager, and security team.

Sample SOP: Firewall Rule Change

SOP-NET-005: Perimeter Firewall Rule Change
Owner: Network Security Lead
Version: 1.4
Effective Date: 2026-02-01
Next Review Date: 2027-02-01

1. PURPOSE
To standardize the request, risk assessment, implementation, and verification of 
perimeter firewall rule changes.

2. SCOPE
All changes to perimeter firewall rules, including additions, modifications, and deletions.

3. PREREQUISITES
- Firewall change request ticket with business justification.
- Security review approval for high-risk rules.
- Current firewall configuration backup.
- Maintenance window for production changes.

4. PROCEDURE
4.1 Review the change request and verify source IP, destination IP, port, protocol, and purpose.
4.2 Assess whether the rule aligns with the principle of least privilege.
4.3 Search existing rules to avoid duplication.
4.4 Create the rule in the firewall management interface with a descriptive name and ticket reference.
4.5 Set an expiration date for temporary rules (maximum 30 days).
4.6 Implement the change during the approved maintenance window.
4.7 Verify connectivity using test cases documented in the ticket.
4.8 Confirm no unintended traffic is permitted using firewall logs.
4.9 Update the Firewall Rule Register.

5. VERIFICATION
- Rule appears in the active rulebase.
- Required traffic passes; denied traffic remains blocked.
- No new high-severity alerts in the SIEM.

6. ROLLBACK
If the change causes issues, revert to the backup configuration and notify the requester and security team.

Sample SOP: Security Incident Escalation

SOP-SEC-011: Security Incident Escalation and Initial Triage
Owner: SOC Manager
Version: 2.0
Effective Date: 2026-03-15
Next Review Date: 2027-03-15

1. PURPOSE
To ensure security events are triaged, classified, and escalated consistently.

2. SCOPE
All security events detected by SIEM, EDR, threat intelligence, or manual reporting.

3. PROCEDURE
3.1 SOC analyst receives alert or report.
3.2 Analyst reviews alert context: source, target, severity, timestamp.
3.3 Determine if the event is a false positive, true positive, or requires escalation.
3.4 For true positives, classify as Low, Medium, High, or Critical using the Incident Classification Matrix.
3.5 For High/Critical incidents, page the on-call incident responder within 15 minutes.
3.6 Create incident record in ITSM and link related alerts.
3.7 Preserve evidence: screenshots, logs, memory dumps as applicable.
3.8 Communicate initial assessment to stakeholders per the Incident Communication Plan.

4. VERIFICATION
- Incident record exists with correct classification.
- On-call responder acknowledged within SLA.
- Evidence chain of custody initiated.

5. ROLLBACK
Not applicable for triage; escalation cannot be undone. If misclassified, update incident record and notify stakeholders.

Sample SOP: New Employee Endpoint Provisioning

SOP-END-003: Laptop Provisioning and Hardening for New Employees
Owner: IT Support Manager
Version: 1.6
Effective Date: 2026-01-20
Next Review Date: 2027-01-20

1. PURPOSE
To ensure all employee laptops are provisioned securely and consistently.

2. SCOPE
All corporate-owned and BYOD-enrolled laptops for employees and contractors.

3. PREREQUISITES
- Approved onboarding request in HR system.
- Hardware asset tag assigned.
- Golden image available and updated within last 30 days.

4. PROCEDURE
4.1 Verify employee details and role-based software requirements.
4.2 Image the laptop using the approved golden image.
4.3 Apply role-based configuration via MDM.
4.4 Enroll device in endpoint protection (EDR/AV).
4.5 Enable disk encryption and verify activation.
4.6 Install required applications from approved software catalog.
4.7 Configure VPN and MFA.
4.8 Update asset inventory with serial number, asset tag, and assigned user.
4.9 Hand over device to employee with security briefing.

5. VERIFICATION
- Device appears in MDM and EDR consoles.
- Encryption status shows "Enabled."
- Asset inventory updated.
- Employee signed acceptable use acknowledgment.

6. ROLLBACK
If the device is found non-compliant, quarantine it and re-image.

Risk Assessment and Treatment

Risk Scenarios Related to A.5.37

Risk Treatment Plan

Audit and Compliance Checklist

25 Audit Questions for A.5.37

Metrics and KPIs

15 KPIs for A.5.37 Maturity

Sample KPI Dashboard

SOP GOVERNANCE DASHBOARD — JUNE 2026

┌─────────────────────────────────────────────────────────────┐
│ OVERALL MATURITY: LEVEL 3 (DEFINED)                         │
├─────────────────────────────────────────────────────────────┤
│ SOP Coverage Rate          94% ████████████████████░░       │
│ Review On-Time Rate        97% █████████████████████░       │
│ Training Completion        99% ██████████████████████       │
│ Runbook Test Pass Rate    100% ██████████████████████       │
│ SOP-Related Incidents         1 (target <2)                 │
├─────────────────────────────────────────────────────────────┤
│ ACTIONS REQUIRED                                            │
│ • SOP missing for new Kubernetes cluster → Owner: Cloud Lead│
│ • 2 SOPs due for review in July → Owners notified           │
└─────────────────────────────────────────────────────────────┘

Common Pitfalls / Audit Failures & How to Avoid Them

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: Indian NBFC, Database Recovery Failure During RBI Inspection

Organization: A mid-sized non-banking financial company (NBFC) in Mumbai with 400 employees and INR 800 crore assets under management.

Challenge: During a routine RBI IT inspection, the NBFC was asked to demonstrate recovery of its core banking database from backup. The DBA who had performed backups for five years had recently resigned. The remaining team attempted the restore using a partially documented procedure saved on the ex-employee's laptop. The restore failed because:

• The backup procedure did not document the encryption passphrase rotation performed six months earlier.
• The recovery runbook referenced a decommissioned backup server.
• No one else had tested a full restore in over two years.

The NBFC could not recover the database within the inspection window. RBI issued a cyber security deficiency letter, restricted certain digital onboarding activities, and imposed a penalty of INR 1.5 crore.

Solution: The NBFC engaged Singahi to rebuild its operating procedures discipline.

• Conducted a SOP coverage assessment across all 38 critical systems.
• Developed runbooks for backup, restore, failover, and DR for the core banking platform, databases, and network devices.
• Implemented a central SOP repository in SharePoint with version control and role-based access.
• Linked SOP reviews to the change advisory board (CAB) process.
• Conducted quarterly restore tests with documented results.
• Trained all operations staff and recorded competencies.
• Added SOP clauses to all MSP contracts.

Results:

• SOP coverage increased from 42% to 98% within 4 months.
• Database restore time reduced from undefined/failed to 45 minutes (RTO: 2 hours).
• Zero SOP-related findings in the subsequent RBI inspection.
• Staff confidence improved; no single points of failure for critical operations.
• The NBFC successfully renewed its ISO 27001 certification with no major nonconformities.

Illustrative Scenario 2: Indian SaaS Startup, Outage from Undocumented Deployment Process

Organization: A Bengaluru-based SaaS startup providing HR tech solutions to 200 enterprise customers.

Challenge: The startup had experienced rapid growth. Deployments were performed by a senior DevOps engineer who "knew the steps." During a Friday evening release, the engineer was on leave. A junior engineer attempted the deployment using informal notes shared over Slack. The deployment:

• Skipped the database migration pre-check.
• Deployed the new code to all nodes simultaneously instead of a canary rollout.
• Did not roll back when health checks began failing.

The result was a 4.5-hour outage, affecting 150 customers. The startup faced SLA penalties, negative social media attention, and a churn risk from three enterprise accounts representing 20% of revenue.

Solution: The startup implemented a documented operating procedures program focused on DevOps and platform operations.

• Created deployment runbooks with step-by-step commands, canary rollout rules, and rollback triggers.
• Integrated SOPs into the CI/CD pipeline so that key checklist items had to be acknowledged before release.
• Built an on-call runbook repository in Confluence, integrated with PagerDuty.
• Implemented runbook automation using Ansible for repetitive tasks.
• Introduced deployment drills every two weeks in a staging environment.

Results:

• Deployment-related outages reduced by 85% in six months.
• Mean time to recover (MTTR) improved from 4.5 hours to 18 minutes.
• The startup achieved SOC 2 Type II certification on the first attempt.
• Enterprise customer retention improved; two of the at-risk accounts renewed early.
• The DevOps team could scale without relying on a single individual.

Multi-Framework Mapping

Mapping Commentary

• SOC 2: A.5.37 directly supports CC6.1, CC7.2, and CC8.1 by ensuring that access controls, monitoring, and changes are performed through documented procedures. SOC 2 auditors routinely ask for runbooks and evidence that they are followed.
• PCI DSS: Requirements 2.2 (configuration standards) and 6.5 (change control) require documented procedures. Payment environments must have runbooks for firewall management, patching, access provisioning, and incident response.
• NIST 800-53: Controls CM-3, CM-6, IR-4, MA-2, SA-8, and SI-4 all depend on documented operating procedures. Federal contractors and agencies mapping to NIST will find A.5.37 foundational.
• CIS Controls: Controls 4, 7, 8, 17, and 18 require documented, repeatable processes. CIS Implementation Groups expect increasing formality of SOPs at higher maturity levels.
• COBIT 2019: BAI03, BAI06, DSS01, DSS02, DSS04, DSS05, and APO12 all reference the need for documented procedures, controlled operations, and managed change.
• GDPR / DPDP Act 2023: Security of processing and breach notification require documented operational steps. The DPDP Act's reasonable safeguards obligation is best demonstrated through SOPs for data handling, access control, and breach response.

Implementation Roadmap

Phase 1: Foundation (Weeks 1–2)

Phase 2: Core SOP Development (Weeks 3–6)

Phase 3: Integration and Automation (Weeks 7–10)

Phase 4: Maturity and Continuous Improvement (Weeks 11–12 and Ongoing)

12-Week Timeline Summary

Week:  1  2  3  4  5  6  7  8  9  10 11 12
       ├──────┤
       Foundation
              ├──────────────────┤
              Core SOP Development
                                 ├──────────────────┤
                                 Integration + Automation
                                                    ├──────┤
                                                    Maturity + Review

FAQ

Q1: Does every single IT task need a documented procedure?

No. A.5.37 requires operating procedures for tasks performed on information processing facilities where the absence of documentation could affect security or operations. Routine, low-risk tasks may be covered by general work instructions or training. Critical, complex, or repeatable tasks must be documented.

Q2: What is the difference between a procedure and an operating procedure?

In the ISO 27001 context, a procedure often refers to a process-level document (e.g., Change Management Procedure under A.8.32). An operating procedure is a more granular, task-level document that tells an operator how to perform a specific function on a specific system (e.g., "How to add a firewall rule on Palo Alto X").

Q3: How often must operating procedures be reviewed?

ISO 27001 does not specify a frequency for A.5.37 itself, but clause 7.5 requires documented information to be reviewed and updated as needed. Best practice is annual review for all SOPs, quarterly for high-risk SOPs, and trigger-based review after changes, incidents, or regulatory updates.

Q4: Can operating procedures be stored in Confluence or a wiki?

Yes, provided the platform meets the requirements of clause 7.5: access control, version control, backup, searchability, and protection from unauthorized modification. A wiki is often the preferred modern repository.

Q5: Do vendors and managed service providers need to maintain SOPs?

Yes, if they operate information processing facilities on your behalf. The SOP requirement flows down through contracts and SLAs. You should review and retain copies of vendor SOPs for critical services.

Q6: What should we do if operators are not following documented procedures?

First, investigate why: Is the SOP outdated? Is it inaccessible? Is training lacking? Or is it a discipline issue? Address root causes through SOP updates, training, tooling, or enforcement. Document deviations and use them as improvement inputs.

Q7: Are screenshots and commands required in SOPs?

Screenshots and exact commands are highly recommended for complex tasks, especially those performed infrequently or under pressure (e.g., disaster recovery). They reduce ambiguity and error. However, avoid embedding credentials or secrets.

Q8: How do we protect SOPs that contain sensitive operational details?

Restrict access based on role and need-to-know. Use a vault for credentials. Mark sensitive SOPs as "Restricted." Log access and changes. Avoid distributing SOPs via email or uncontrolled shared drives.

Q9: What is the role of automation in A.5.37?

Automation reduces reliance on manual procedures and can enforce consistency. However, even automated processes need documented runbooks for design, maintenance, exception handling, and audit. Automation complements but does not replace A.5.37.

Q10: How does A.5.37 relate to business continuity?

A.5.37 ensures that day-to-day operations are documented, while business continuity procedures (A.5.29, A.5.30) ensure operations can continue during disruption. Recovery runbooks are a bridge between the two: they are operating procedures for crisis scenarios.

Q11: Should SOPs be written in English only?

English is typically the working language for ISO 27001 documentation and audits. However, if operational staff are more proficient in Hindi or a regional language, provide translated versions or visual aids to ensure comprehension. The master SOP should remain in English for audit consistency, with localized versions as supplementary documents.

Q12: How do we handle emergency situations where there is no time to follow the SOP?

Emergency deviations are allowed when necessary to prevent greater harm. The response should still be governed by a pre-defined emergency response runbook. After the emergency, document the deviation, the justification, the actions taken, and any lessons learned. Update the SOP if the emergency revealed a gap.

Q13: Can we use videos instead of written SOPs?

Videos can supplement written SOPs, especially for complex physical tasks or visual workflows. However, videos are harder to version-control and search. Best practice is to maintain a written SOP as the authoritative document and use video as a training aid.

Q14: Who should pay for SOP development, IT or the business unit?

SOP development is a shared overhead. IT typically funds technical SOPs, while business units fund process-specific SOPs. The CISO or ISMS budget may cover governance, training, and audit support. Allocate overhead based on system ownership and risk.

Q15: How do we prevent SOPs from becoming shelfware?

Integrate SOPs into daily workflows: link them in ITSM tickets, require acknowledgment in the LMS, observe compliance during audits, and update them based on real incidents. If an SOP is never used, question whether it is needed or whether the process has changed.

References and Further Reading

Standards

• ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection, Information security management systems, Requirements.
• ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection, Information security controls.
• ISO/IEC 27003:2017, Information security management system implementation guidance.
• ISO/IEC 27005:2022, Information security risk management.

Indian Regulations and Guidelines

• Digital Personal Data Protection Act, 2023 (DPDP Act).
• Information Technology Act, 2000.
• Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011.
• CERT-In Directions, 2022 (Cyber Security Directions).
• Reserve Bank of India, Master Direction on Information Technology Framework for the NBFC Sector.
• Reserve Bank of India, Cyber Security Framework in Banks.
• SEBI, Cyber Security and Cyber Resilience Framework for Stock Brokers/Depository Participants.
• IRDAI, Guidelines on Information and Cyber Security for Insurers.

Industry Frameworks

• NIST Special Publication 800-53, Revision 5, Security and Privacy Controls for Information Systems and Organizations.
• CIS Controls, Version 8.
• COBIT 2019 Framework.
• SOC 2 Trust Services Criteria (TSC) 2017.
• PCI DSS Version 4.0.

Additional Reading

• NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems.
• ITIL 4 Practice Guides, Service Configuration Management, Incident Management, Change Enablement.
• Gartner research on IT operational resilience and runbook automation.
• IBM impact of a Data Breach Report 2024.
• Verizon Data Breach Investigations Report 2024.
• ISACA, COBIT 2019 Framework: Introduction and Methodology.
• SANS Institute, Runbook and Playbook Development for Incident Response.
• AWS Well-Architected Framework, Operational Excellence Pillar.
• Microsoft Azure Well-Architected Framework, Operational Excellence.
• Google Cloud, DevOps and SRE Best Practices.
• ISO/IEC 27007:2020, Guidelines for information security management systems auditing.
• ISO/IEC 27017:2015, Code of practice for information security controls based on ISO/IEC 27002 for cloud services.
• Reserve Bank of India, Master Circular on Customer Protection, Limiting Liability of Customers in Unauthorized Electronic Banking Transactions.
• SEBI, Master Circular on Cyber Security and Cyber Resilience Framework.

This guide was prepared by Singahi. For implementation support, audit readiness, or ISO 27001 certification services, contact us at /.