Auditing Documented operating procedures is the technical verification of formal instructions governing information processing activities. The Primary Implementation Requirement mandates granular, step-by-step documentation for all operational tasks, yielding the Business Benefit of consistent security performance, reduced human error, and improved resilience during technical incidents or system failures.
Table of contents
- 1. Operational Procedure Inventory Formalised
- 2. Procedural Technical Specificity Validated
- 3. Information Security Step Integration Verified
- 4. Document Availability for Relevant Personnel Confirmed
- 5. Procedural Change Management Evidence Identified
- 6. Backup and Restoration Playbooks Present
- 7. Monitoring and Logging Operational Standards Documented
- 8. Emergency and Out-of-Hours Procedures Validated
- 9. Third-Party Service Interaction Procedures Confirmed
- 10. Periodic Procedural Review Records Verified
1. Operational Procedure Inventory Formalised
Verification Criteria: A master index or register identifies all operational tasks requiring documented procedures, specifically those related to system administration and information processing.
Required Evidence: Master Document Index (MDI) or Standard Operating Procedure (SOP) Register within the Document Management System.
Pass/Fail Test: If critical operational tasks (e.g. user account provisioning) exist without a corresponding entry in the document inventory, mark as Non-Compliant.
2. Procedural Technical Specificity Validated
Verification Criteria: Documented procedures contain granular, step-by-step instructions (including CLI commands, UI navigation paths, or script names) rather than high-level policy statements.
Required Evidence: Sampled technical SOPs for system backup, server hardening, or firewall configuration changes.
Pass/Fail Test: If the operating procedures only describe “what” should be achieved without detailing the “how” for technical implementation, mark as Non-Compliant.
3. Information Security Step Integration Verified
Verification Criteria: Mandatory security checkpoints, such as integrity checks, cryptographic verification, or secondary approvals, are embedded directly within the operational workflows.
Required Evidence: Annotated operating procedures highlighting integrated security controls and verification stages.
Pass/Fail Test: If a procedure describes a technical operation that intentionally bypasses or omits a mandatory security control defined in the Information Security Policy, mark as Non-Compliant.
4. Document Availability for Relevant Personnel Confirmed
Verification Criteria: Procedures are accessible to all intended users at the point of need, while access is restricted for those with no operational requirement.
Required Evidence: Permissions report for the SOP repository (e.g. SharePoint or Confluence) showing alignment with the “Need-to-Know” principle.
Pass/Fail Test: If an operational administrator cannot access the required technical instructions to perform their role during an audit walkthrough, mark as Non-Compliant.
5. Procedural Change Management Evidence Identified
Verification Criteria: Updates to operating procedures follow a formal review and approval process to ensure technical accuracy and security alignment.
Required Evidence: Document version history logs or Change Request tickets linked to specific SOP modifications.
Pass/Fail Test: If a procedure has been modified in production without a recorded approval from the designated Process Owner or Security Lead, mark as Non-Compliant.
6. Backup and Restoration Playbooks Present
Verification Criteria: Specific operating procedures are documented for the execution of backup cycles and the technical restoration of data from archives.
Required Evidence: Backup Schedule documentation and step-by-step Data Restoration Playbooks.
Pass/Fail Test: If the organisation relies on “legacy knowledge” or unwritten administrator experience to perform a data restore rather than a documented procedure, mark as Non-Compliant.
7. Monitoring and Logging Operational Standards Documented
Verification Criteria: Procedures define the specific events to be monitored, the threshold for alerts, and the subsequent manual response required by operations staff.
Required Evidence: Security Operations Centre (SOC) Manual or System Monitoring Standard Operating Procedures.
Pass/Fail Test: If logs are being collected but no procedure exists to define how staff must respond to a “Critical” system alert, mark as Non-Compliant.
8. Emergency and Out-of-Hours Procedures Validated
Verification Criteria: Operational instructions exist for handling system failures or security events during non-standard hours or emergency conditions.
Required Evidence: On-call rotation manuals or Emergency System Handover procedures.
Pass/Fail Test: If a technical incident occurring at 3 AM has no documented out-of-hours response or escalation path, mark as Non-Compliant.
9. Third-Party Service Interaction Procedures Confirmed
Verification Criteria: Procedures define the requirements for interacting with vendor support, including the secure exchange of diagnostic data and remote access granting.
Required Evidence: Vendor Management SOP or External Support Escalation Matrix.
Pass/Fail Test: If there is no documented procedure for authenticating a third-party engineer before granting them privileged system access, mark as Non-Compliant.
10. Periodic Procedural Review Records Verified
Verification Criteria: Operating procedures are reviewed for technical accuracy and relevance at least annually or following significant architectural changes.
Required Evidence: Document review logs or timestamped “Verified” status updates within the Document Management System.
Pass/Fail Test: If an operating procedure describes a technical interface or system version that has been decommissioned for over six months, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Documented SOPs | GRC platform identifies that a “Policy.pdf” is uploaded to the control. | The auditor must verify the file contains technical “how-to” steps, not just high-level management “intent”. |
| User Availability | SaaS tool shows the file is “Shared” globally. | Verify “Need-to-Know”. If a standard user can read admin-only restoration playbooks, the control fails on confidentiality. |
| Technical Accuracy | Tool flags the document as “Current” based on the upload date. | The auditor must witness an administrator follow the SOP. If the UI has changed and the SOP has not, the control is ineffective. |
| Approval Workflow | GRC tool records a “Manager Approval” click on a dashboard. | Verify the technical competence of the approver. Did they verify CLI commands or simply “rubber stamp” the document? |
| Training Alignment | Tool shows “User A” watched a training video. | Compare the video content to the SOP. If the training describes a different process than the documented procedure, it is non-compliant. |
| Emergency Steps | SaaS tool identifies an “Incident Plan” exists. | The auditor must verify that procedures are accessible offline. If the cloud is down, can staff reach the procedures needed to fix it? |
| Version Control | Tool identifies multiple versions in the history. | Check for “Shadow SOPs”. Verify that staff are not using local Desktop copies of outdated procedures instead of the GRC version. |

