# Security Operating Procedure: [Procedure name]

> Model template for the written procedures that run IT systems and
> security tasks, supporting ISO/IEC 27001:2022 + Amd 1:2024 Annex A
> control A.5.37 (documented operating procedures: written, controlled
> and reachable by the people who do the work; read the official control
> text for the exact requirement) and the documented information rules
> of clause 7.5. Sections 1 to 3 set the
> rules for deciding which activities need a written procedure, section 4
> is the model procedure layout (purpose, scope, prerequisites, steps,
> verification, rollback, escalation, records), sections 5 to 7 cover
> writing and control, and sections 8 and 9 give two complete worked
> *Example* procedures: user access provisioning and backup verification. Replace every `[bracketed]`
> value and every row marked *Example*.

<!--
Guidance: How to use this template
- Use sections 1 to 3 and 5 to 7 once to set up the procedure register
  and the rules. Then copy the section 4 layout for every new procedure and keep each procedure as its own
  controlled document with its own SOP ID.
- Fill the procedure register (section 3) first: it shows the auditor
  which security activities are covered and which are still to be
  written.
- Main pitfall: procedures written once for the audit that nobody uses.
  Write each procedure with the person who does the task, test it with
  someone who has not done it before, and keep it where the work
  happens (runbook tool, wiki, ticket template).
- For general (non-security) SOPs the library has `ops/sop`. Use this
  template when the procedure operates a security control or an
  information processing facility, so that the control links and the
  evidence fields are in place.
- Related templates: `ops/sop`, `compliance/controlled-document`,
  `isms/isms-documented-information-register`, `isms/access-control-policy`,
  `isms/backup-policy`, `isms/backup-restore-test-log`,
  `ops/backup-restore-procedure`, `ops/access-review`,
  `ops/onboarding-checklist`, `isms/offboarding-security-checklist`,
  `ops/change-request`, `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: This block applies to the framework. Each procedure written from the section 4 layout carries its own smaller document control block with its SOP ID, shown in section 4. -->

| Field | Value |
|---|---|
| Document ID | [DOC-ISMS-049] |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@head-of-it-operations] |
| Approvers/reviewers | [@isms-manager], [@ciso] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.37, cl. 7.5); ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD |
| Procedure register location | [Wiki space or document management library] |
| Documented information register | [DOC-ISMS-028] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Owner | [@head-of-it-operations] | [Prepared] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Reviewed] | YYYY-MM-DD |
| CISO | [@ciso] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@head-of-it-operations] | First version with register and two worked procedures |
| 1.1 *(Example)* | YYYY-MM-DD | [@platform-lead] | SOP-SEC-002 updated after the restore test found a missing checksum step |

## Contents

Part 1: Framework

1. Purpose and scope
2. Which activities need a documented procedure
3. Procedure register
4. Model procedure layout

Part 2: Writing and control

5. Writing rules
6. Procedure lifecycle and change control
7. Availability, training and use

Part 3: Worked examples

8. Worked example SOP-SEC-001: user access provisioning
9. Worked example SOP-SEC-002: backup verification

Part 4: Operation

10. Size tiers
11. Records and evidence
12. References

## 1. Purpose and scope

<!-- Guidance: Say which kinds of activity this framework covers. Questions: does it cover only IT operations, or also security operations such as alert triage and key rotation, and facilities tasks such as visitor handling? An auditor checks that the scope matches the activities named in the SoA justification for A.5.37. -->

This framework sets how [Organization name] identifies, writes, approves,
publishes, uses and maintains operating procedures for information
processing facilities and security activities within the ISMS scope
(DOC-ISMS-002). Its aim is that a trained person can perform each
critical task correctly, securely and in the same way every time,
including out of hours and during disruption, and that the organization
can show afterwards that it was done.

It covers procedures for:

- operating systems, platforms, networks and cloud services in scope;
- running security controls (access provisioning, backups, patching,
  key and certificate handling, log review, vulnerability scanning);
- responding to defined security events where a playbook is not enough
  (see `security/soc-playbook` for detection and response playbooks);
- handling information and media (secure transfer, disposal).

It does not replace policies (which say what must be achieved) or
standards (which set required configurations). A procedure says how a
task is carried out, step by step, by whom.

## 2. Which activities need a documented procedure

<!-- Guidance: A.5.37 does not require a procedure for everything. Decide with clear criteria and record the decision. Questions: which tasks are rare but critical? Which are done by many people who must do them the same way? Which have caused incidents? Pitfall: writing procedures for easy daily tasks while the annual key rotation lives in one engineer's memory. -->

Write and control a procedure when at least one criterion applies:

| Code | Criterion | Example activities |
|---|---|---|
| P1 | The activity is performed by several people who must do it the same way | Access provisioning, onboarding of devices |
| P2 | The activity is infrequent and errors are costly | Certificate renewal, key rotation, failover |
| P3 | The activity is needed during disruption or by a stand-in | Restore from backup, emergency access |
| P4 | The activity operates a control named in the SoA or required by contract or law | Backup verification, log review, access review |
| P5 | The activity has caused an incident or nonconformity before | Firewall rule changes after an outage |
| P6 | The activity is handed to a supplier or new team | Managed service onboarding, outsourced support |

Do not write a procedure when the task is fully automated with no human
decision (document the automation in the system design instead), or when
the tool enforces the steps and keeps the record by itself. Record that
decision in the register with the reason.

## 3. Procedure register

<!-- Guidance: One row per procedure, including planned ones. Link each to the control it operates. Questions: does every SoA control marked "Implemented" with a repeatable manual step have a procedure? Is any procedure overdue for review? Pitfall: a register that lists documents that no longer exist. -->

| SOP ID | Procedure | Criteria (section 2) | Controls supported | Owner | Performed by | Version | Last reviewed | Status |
|---|---|---|---|---|---|---|---|---|
| SOP-SEC-001 *(Example)* | User access provisioning | P1, P4 | A.5.15, A.5.16, A.5.18 | [@it-service-lead] | IT service desk | 2.1 | YYYY-MM-DD | Approved |
| SOP-SEC-002 *(Example)* | Backup verification | P2, P3, P4 | A.8.13 | [@platform-lead] | Platform on-call engineer | 1.3 | YYYY-MM-DD | Approved |
| SOP-SEC-003 *(Example)* | TLS certificate renewal | P2, P5 | A.8.24 | [@platform-lead] | Platform engineers | 1.0 | YYYY-MM-DD | Approved |
| SOP-SEC-004 *(Example)* | Security log review | P4 | A.8.15, A.8.16 | [@security-lead] | Security analyst | 0.9 | Not yet | Draft |
| SOP-SEC-005 *(Example)* | Leaver access removal | P1, P4, P5 | A.5.18, A.6.5 | [@it-service-lead] | IT service desk | 1.2 | YYYY-MM-DD | Approved |
| SOP-SEC-006 *(Example)* | Privileged and production access grant | P2, P4 | A.8.2, A.5.18 | [@platform-lead] | Platform lead with security approval | 1.1 | YYYY-MM-DD | Approved |
| [SOP-SEC-NNN] | [procedure] | [codes] | [A.N.N] | [@owner] | [role] | [n.n] | YYYY-MM-DD | [Draft / Approved / Retired] |

## 4. Model procedure layout

<!-- Guidance: Copy this layout for each new procedure. Every heading must be filled or marked "Not applicable" with a reason. Questions to answer for each part are in the right-hand column. Pitfall: leaving out rollback and escalation, which are exactly the parts needed when something goes wrong. -->

| Part | What to write | Questions it answers |
|---|---|---|
| Header | SOP ID, title, version, status, owner, approver, last reviewed, next review, classification, controls supported | Is this the current approved version? Who owns it? |
| 1. Purpose | One or two sentences: what the procedure achieves and which risk it controls | Why does this exist? |
| 2. Scope | Systems, environments, sites and cases covered and not covered | When do I use this, and when another procedure? |
| 3. Roles | Who performs, who approves, who verifies, who is informed | Who may do each step? Is there segregation of duties? |
| 4. Prerequisites | Access, tools, approvals, tickets, time windows, information needed before starting | Can I start? What do I need first? |
| 5. Steps | Numbered imperative steps, one action each, with the expected result | What exactly do I do, and what should I see? |
| 6. Verification | Checks that prove the task succeeded | How do I know it worked? |
| 7. Rollback | How to undo or stop safely if a step fails | What if it goes wrong halfway? |
| 8. Escalation | When to stop and whom to call, with response times | When is this no longer my decision? |
| 9. Records | What evidence to keep, where, for how long | What proves it was done correctly? |
| 10. Related documents | Policies, standards, other procedures, runbooks | Where is the context? |

Procedure header block to copy:

| Field | Value |
|---|---|
| SOP ID | [SOP-SEC-NNN] |
| Title | [Procedure name] |
| Version and status | [n.n, Approved] |
| Owner and approver | [@owner], [@approver] |
| Controls supported | [A.N.N] |
| Last reviewed and next review | YYYY-MM-DD, YYYY-MM-DD |
| Classification | [Internal] |

## 5. Writing rules

<!-- Guidance: Short, testable rules make procedures usable at 3 a.m. Pitfall: long paragraphs that mix the reason for a step with the step itself. -->

1. Start each step with a verb ("Open", "Confirm", "Record") and give
   one action per step.
2. State the expected result for every step that changes something, so
   the operator can notice a failure at once.
3. Name roles, not people, and name the exact system or console.
4. Put warnings before the step they apply to, not after it.
5. Never write secrets, passwords or keys in a procedure. Refer to the
   vault entry or secrets manager path instead.
6. Use the approved terms from the policy set, and the same names as the
   asset inventory (DOC-ISMS-012).
7. Keep commands in code blocks and test them in a non-production
   environment before publishing.
8. Mark decision points clearly with the criteria for each branch.
9. Keep each procedure to one start and one end. Split long branches into
   linked procedures.
10. Test each new or changed procedure with a person who has not done
    the task before, and record the test in the revision history.

## 6. Procedure lifecycle and change control

<!-- Guidance: Procedures are documented information under clause 7.5: they need review, approval, version control and protection against unintended change. Questions: who can edit the live version? How are users told about a change? Pitfall: engineers editing the wiki page directly, so no one can say which version was used during an incident. -->

```mermaid
stateDiagram-v2
  [*] --> Draft
  Draft --> Tested: Dry run by a second person
  Tested --> Draft: Gaps found
  Tested --> InReview: Owner submits
  InReview --> Approved: Approver signs off
  InReview --> Draft: Changes requested
  Approved --> Draft: Change needed
  Approved --> Retired: Activity stops or is automated
  Retired --> [*]
```

| Event | Action | Who |
|---|---|---|
| New activity meets a criterion in section 2 | Add to register, write draft | Activity owner |
| System change alters steps | Update the procedure in the same change request (`ops/change-request`) | Change owner |
| Incident or audit finding involves the procedure | Review and update within [30] days | Procedure owner |
| Scheduled review | Review at least every [12] months, or [6] months for P2 and P3 procedures | Procedure owner |
| Procedure no longer needed | Retire, keep the last version as a record | Procedure owner |

The ISMS manager checks the register every quarter for overdue reviews
and reports the count in the ISMS performance report (DOC-ISMS-081).

## 7. Availability, training and use

<!-- Guidance: Under A.5.37 a written procedure only helps if the person doing the task can reach it at the moment they need it. Questions: can the on-call engineer reach the procedure if the wiki is down? Is each operator trained before working alone? Pitfall: the only copy of the restore procedure stored on the system that needs restoring. -->

- Publish approved procedures in [the runbook tool or wiki], with read
  access for every role that performs them and edit access for owners
  only.
- Keep an offline copy of every P3 procedure (needed during disruption)
  outside the primary environment, for example an encrypted export
  stored with the ICT readiness plan (DOC-ISMS-047).
- Link procedures from the ticket templates or alerts that start them,
  so operators open the right version from the task itself.
- Train each operator before they perform a procedure alone, and record
  the training in the competence and training matrix (DOC-ISMS-026).
- Operators who find an error stop, follow the escalation step and
  report the error to the owner. Deviations are recorded in the ticket.

## 8. Worked example SOP-SEC-001: user access provisioning

<!-- Guidance: This complete example shows the expected level of detail. Adapt the systems, roles and limits to your environment. An auditor will sample tickets and check that each step left the record listed in part 9. -->

| Field | Value |
|---|---|
| SOP ID | SOP-SEC-001 *(Example)* |
| Title | User access provisioning |
| Version and status | 2.1, Approved |
| Owner and approver | [@it-service-lead], [@isms-manager] |
| Controls supported | A.5.15 access control rules, A.5.16 identity lifecycle management, A.5.18 access rights provisioning and review |
| Last reviewed and next review | YYYY-MM-DD, YYYY-MM-DD |
| Classification | Internal |

**1. Purpose.** Grant new or changed access to business systems only
when it is approved and matches the role, so that people get the access
they need and no more (access control policy, DOC-ISMS-041).

**2. Scope.** Covers joiners, movers and temporary access to systems
connected to the identity provider. Not covered: privileged and
production administrative access (procedure SOP-SEC-006, privileged
access) and leavers (SOP-SEC-005).

**3. Roles.**

| Role | Responsibility |
|---|---|
| Requester (line manager) | Raises the request with the role and business reason |
| Approver (system owner) | Approves access beyond the role baseline |
| Operator (IT service desk) | Performs the steps below |
| Verifier (second service desk member) | Checks a weekly sample of completed requests |

The operator may not approve their own request or a request for
themselves (segregation of duties).

**4. Prerequisites.**

- An access request ticket with requester, user, role, systems, start
  date and, for temporary access, an end date.
- For joiners: HR record showing a signed contract and completed
  screening (`isms/personnel-screening-procedure`).
- Operator account with the identity administration role.

**5. Steps.**

| Step | Action | Expected result |
|---|---|---|
| 5.1 | Open the ticket and confirm the requester is the user's line manager in the HR system | Requester matches the HR record |
| 5.2 | Compare requested access with the role baseline in the access matrix | Each item marked "in baseline" or "extra" |
| 5.3 | For any "extra" item, assign the ticket to the system owner for approval and wait | Approval recorded in the ticket, or request rejected |
| 5.4 | For joiners, confirm the HR record shows screening complete | Screening status "complete" with date |
| 5.5 | Create or update the identity in the identity provider with the role group | User appears in the role group |
| 5.6 | Add approved extra groups. For temporary access, set the expiry date on the group membership | Groups and expiry shown on the user profile |
| 5.7 | Enforce multi-factor authentication enrolment at first sign-in | User status "MFA enrolment required" |
| 5.8 | Send the activation link to the user's manager, never the password | Manager confirms receipt in the ticket |
| 5.9 | Attach a screenshot or export of the final group membership to the ticket and resolve it | Ticket resolved with evidence |

**6. Verification.** The operator checks that the user's groups equal
the approved list. Each week the verifier samples [5] resolved tickets
and checks approval, groups and expiry. Results are logged in the
ticket queue report.

**7. Rollback.** If wrong access was granted, remove the extra groups
at once, record what was removed and when, and inform the system owner.
If the wrong person received access, treat it as a security event and
report it (`isms/security-event-reporting-procedure`).

**8. Escalation.** Stop and escalate to the IT service lead when the
requester is not the line manager, approval is missing after [2]
working days, or the request includes privileged or production access.
Escalate to the security team at once when access may already have been
misused.

**9. Records.** The ticket with approval, the group membership export
and the weekly verification report. Kept in the service desk tool for
[3] years.

**10. Related documents.** Access control policy (DOC-ISMS-041),
onboarding checklist (`ops/onboarding-checklist`), access review
(`ops/access-review`), offboarding checklist (DOC-ISMS-053).

Worked figures *(Example)* for one month at Quillmere Analytics Ltd: 18
access tickets, 14 within the role baseline and 4 with extra items
(14 + 4 = 18). All 4 extra items had system owner approval. The weekly
samples covered 20 tickets in 4 weeks, more than the 18 raised, because
2 tickets from the previous month were included; no exceptions found.

## 9. Worked example SOP-SEC-002: backup verification

<!-- Guidance: A second complete example for a technical control that runs on a schedule. It shows decision points and a measured result. An auditor will compare the records with the backup policy and the restore test log. -->

| Field | Value |
|---|---|
| SOP ID | SOP-SEC-002 *(Example)* |
| Title | Backup verification |
| Version and status | 1.3, Approved |
| Owner and approver | [@platform-lead], [@head-of-it-operations] |
| Controls supported | A.8.13 information backup |
| Last reviewed and next review | YYYY-MM-DD, YYYY-MM-DD |
| Classification | Internal |

**1. Purpose.** Prove every week that backups required by the backup
policy (DOC-ISMS-061) completed, are protected from change and can be
restored with the data age and restore time the backup policy requires.

**2. Scope.** Covers the production databases, object storage and
configuration repositories listed in the backup policy. Not covered:
full disaster recovery tests (ICT readiness plan, DOC-ISMS-047) and
end-user laptops (synchronised to the collaboration suite).

**3. Roles.**

| Role | Responsibility |
|---|---|
| Operator (platform on-call engineer) | Performs the weekly steps |
| Owner (platform lead) | Reviews results, owns failures |
| Data owner | Confirms restored data is usable for the monthly sample |

**4. Prerequisites.**

- Read access to the backup console and the backup job report.
- Access to the isolated restore environment (no network route to
  production).
- The current list of protected data sets from the backup policy.

**5. Steps.**

| Step | Action | Expected result |
|---|---|---|
| 5.1 | Export the backup job report for the last 7 days | Report lists every protected data set |
| 5.2 | Check that every data set has a successful backup each day as scheduled | No missing or failed jobs |
| 5.3 | Decision: if any job failed or is missing, go to step 5.4. Otherwise go to step 5.5 | Branch recorded in the ticket |
| 5.4 | Rerun the failed job, confirm success, and open an incident if two consecutive runs failed | Job successful or incident opened |
| 5.5 | Confirm the immutability or retention lock is active on the latest backup of each data set | Lock status "enabled" with expiry beyond the retention period |
| 5.6 | Restore one data set, chosen in rotation, into the isolated restore environment | Restore job completes |
| 5.7 | Compare record counts and a checksum of a reference table with the source at backup time | Counts and checksum match |
| 5.8 | Record the time from start of restore to usable data, and the age of the restored data | Both values recorded |
| 5.9 | Delete the restored copy from the isolated environment | Environment empty |
| 5.10 | Enter the results in the backup and restore test log (DOC-ISMS-071) and close the ticket | Log entry with ticket link |

**6. Verification.** The restored data is no older than the backup
interval set in the backup policy for that data set, and the counts and
checksum match. Shorter recovery point objectives met by replication or
point-in-time recovery are tested under the ICT readiness plan
(DOC-ISMS-047), not here. Once a month the data owner
opens the restored copy before deletion (step 5.9) and confirms it is
usable.

**7. Rollback.** The procedure does not change production. If a restore
is started in the wrong environment, cancel it, confirm that no
production resource was overwritten and report a security event.

**8. Escalation.** Escalate to the platform lead within [4] hours when
two consecutive backups of one data set fail, when a lock is not active,
or when restored data does not match. Escalate to the ICT recovery
manager when the restored data is older than the backup interval.

**9. Records.** Weekly ticket, job report export and the log entry in
DOC-ISMS-071. Kept for [3] years.

**10. Related documents.** Backup policy (DOC-ISMS-061), backup and
restore procedure (`ops/backup-restore-procedure`), ICT readiness plan
(DOC-ISMS-047).

Worked figures *(Example)* for one quarter (13 weeks) at Quillmere
Analytics Ltd: 4 protected data sets with daily backups gave 364
scheduled jobs (4 x 7 x 13). 361 succeeded on the first run and 3 failed
(361 + 3 = 364); all 3 succeeded on rerun, so no incident was opened.
First-run success rate: 361 of 364, or 99.2%. 13 restore samples were
performed, one per week; 12 matched in full and 1 restore of the
customer database data set failed the checksum comparison because the
reference table changed during the backup window (12 + 1 = 13). It was
escalated, the job was moved outside the batch window and the next
restore of that data set matched.

## 10. Size tiers

<!-- Guidance: The number and depth of procedures grows with size and complexity. Show what is realistic for your tier. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Number of security procedures *(Example)* | About 12, mostly cloud operations and access | About 40, including colocation and managed service operations | Over 150, with group procedures plus site procedures for plants and OT |
| Where they live | Runbook pages in the engineering wiki, linked from alerts | Document management system plus runbook tool | Integrated management system document control shared with ISO 9001 and ISO 22301 procedures |
| Ownership | Head of Engineering Operations owns most; engineers own their runbooks | Service owners per platform, reviewed by the 3-person security team | Site IT and OT leads own site procedures; the security office owns group procedures |
| Testing | Dry run by a second engineer | Dry run plus quarterly sample check by the security team | Dry run, site audits and checks during internal audit |
| Languages | English | English | English plus the local languages of the 4 countries, with one master version |

## 11. Records and evidence

<!-- Guidance: List the records that prove procedures exist, are available and are followed. Link each in the control evidence matrix (`isms/control-evidence-matrix`). Auditors sample the register, two or three procedures and the records each procedure produces. -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Procedure register (section 3) | Procedures are identified for the activities that need them | ISMS manager | This document | Current plus 3 years of history |
| Approved procedures with revision history | Procedures are controlled (cl. 7.5) | Procedure owners | Runbook tool or document system | Current plus superseded versions for 3 years |
| Dry-run and test records | Procedures work as written | Procedure owners | Revision history, tickets | 3 years |
| Operator training records | People are competent to use them | Line managers | Training matrix (DOC-ISMS-026) | Employment plus 3 years |
| Execution records (tickets, logs, test log entries) | Procedures are followed | Operators | Ticketing tool, DOC-ISMS-071 | As set per procedure |
| Review evidence and quarterly overdue report | Procedures are maintained | ISMS manager | ISMS performance report (DOC-ISMS-081) | 3 years |

Set final retention in the documented information register
(DOC-ISMS-028).

## 12. References

<!-- Guidance: Cite editions exactly; read the official text for A.5.37 and clause 7.5 before deciding what to document. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024, information security management systems, requirements | 2022, Amd 1 published 2024-02-23 | A.5.37, cl. 7.5, and the controls operated by the worked examples |
| ISO/IEC 27002:2022, information security controls | 2022 | Guidance on documented operating procedures |

Official pages: ISO/IEC 27001 https://www.iso.org/standard/82875.html,
Amd 1 https://www.iso.org/standard/88435.html, ISO/IEC 27002
https://www.iso.org/standard/75652.html.

Related templates: `ops/sop`, `compliance/controlled-document`,
`isms/isms-documented-information-register`,
`isms/access-control-policy`, `isms/backup-policy`,
`isms/backup-restore-test-log`, `ops/backup-restore-procedure`,
`ops/onboarding-checklist`, `ops/access-review`,
`isms/offboarding-security-checklist`, `isms/personnel-screening-procedure`,
`isms/security-event-reporting-procedure`, `security/soc-playbook`,
`ops/change-request`, `isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 (including Amd 1:2024) Annex A
control A.5.37 and clause 7.5 on documented information. The framework,
model layout, writing rules and the two worked procedures are original
wording. ISO/IEC text is not reproduced: control numbers are given with
short descriptive labels written for this template, not the official
titles or control text. ISO and IEC standards are copyrighted; obtain
the official standards from ISO or your national standards body before
relying on this template. Check the current edition and amendments
before use. This is a documentation format, not certification advice.
Template licence: MIT.