A security policy says what must be true (“MFA is required”, “client data stays in the EU”). Security procedures say how staff do it on Tuesday afternoon: which screens to open, who approves, what to log, and what to do when it fails.
What are security procedures?
Security procedures are written, repeatable instructions for protecting information and systems. A usable procedure has:
- A name and type (access, incident, physical, backup, vendor)
- Scope (which systems, teams, or clients)
- Steps in order
- Responsible parties (named roles, not a dead email alias)
- Evidence (tickets, screenshots, vault items)
- A review date so the runbook does not describe retired tools
They exist so the first hour of an incident is not spent hunting Confluence.
Typical security procedures
- Account provisioning and offboarding
- Granting vault or folder access
- Reporting a lost laptop or phished mailbox
- Incident response (contain, notify, recover)
- Backup restore tests
- Handling of identity documents and NDAs
- Password and MFA exceptions
For MSP-oriented policy structure, see our IT security policy template for MSPs. Procedures sit underneath that policy.
Policy vs procedure vs control
| Policy | Procedure | Control | |
|---|---|---|---|
| Asks | What is required? | How do we do it? | Is it actually happening? |
| Example | MFA on all vault users | Steps to enrol an authenticator app | Admin report: % of users with MFA |
Auditors ask for procedures because they prove the policy is operational.
Where to keep them
Wiki pages go stale and are often readable by the whole company. Sensitive runbooks (break-glass, incident comms) belong in an encrypted digital vault with permissions for security and the people who must execute the steps.
Hypervault includes a Security procedures template: procedure name, type, department, steps, owners, review date, and attachments.
Store related secrets (admin logins, emergency contacts) as linked vault items—not in the same open wiki as the marketing site copy.
