Security Operating Procedure Template (ISO/IEC 27001 A.5.37)

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.

Document control

Approvals

Revision history

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

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

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

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

4. Model procedure layout

Procedure header block to copy:

5. Writing rules

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

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

• 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

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.

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.

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

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.

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.

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

11. Records and evidence

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

12. References

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.