A procedure is a documented set of step-by-step instructions that shows how to perform a recurring operational or control activity in a consistent way.
In security and compliance programs, procedures sit below policies and standards. An information security policy states what must be true. A standard sets measurable baselines. A procedure (sometimes called a runbook or work instruction) explains how people and systems carry out the work: which tickets to open, which screens to use, who approves, and what to retain as evidence.
In simple terms, a procedure answers:
- What exact steps should someone follow for this activity?
- Who performs each step, and who approves or reviews?
- What dated outputs prove the procedure was followed during the audit period?
This page defines the document type. It is related to policies, standards, and processes, but those words are not interchangeable.
Why Procedures Matter
Policies without procedures leave teams guessing. Tribal knowledge works until a key person is out, a tool changes, or an auditor asks how a control actually runs.
Procedures matter because:
- They make control operation repeatable across people and shifts.
- They reduce "hero" dependency and onboarding time.
- They create a shared reference for exceptions when someone must deviate (exception management).
- They help map day-to-day work to controls and audit evidence.
- Auditors and customers often ask how you perform activities such as access provisioning, change deployment, incident response, or backup restore tests.
A short, current procedure that matches reality beats a long unread document that no longer matches the tools in use.
Policy vs Procedure vs Process vs Standard
Keep the hierarchy clear so updates stay maintainable.
| Document / concept | Primary job | Typical change cadence | Example |
|---|---|---|---|
| Policy | State principles, scope, roles, and mandatory expectations | Annual or major org/risk change | "Production access requires unique accounts and MFA where supported" |
| Standard | Set measurable baselines that implement policy | As technology baselines evolve | "MFA required for all remote VPN and cloud console access" |
| Procedure / runbook | Step-by-step how to perform the work | As tools and teams change | "How to request production access in Okta and Jira" |
| Process | End-to-end flow of activities and handoffs (may span procedures) | When operating model changes | "Joiner-mover-leaver access lifecycle from HR ticket to IdP disable" |
Policy says what must be true. Standards say how strong the baseline is. Procedures say how to do the work. Process describes the broader flow those procedures sit inside. Confusing these layers produces either a bloated policy that is never updated or orphan procedures with no governing requirement.
What a Useful Procedure Typically Includes
Content varies by activity, but strong procedures usually cover:
- Purpose and scope. Which systems, environments, and roles the steps apply to.
- Roles. Who executes, who approves, who is consulted or informed.
- Prerequisites. Access needed, tools, and related policies or standards.
- Ordered steps. Concrete actions with system names where helpful (for example Okta, Jira, AWS, GitHub).
- Decision points. When to escalate, when an exception is required, and emergency paths.
- Evidence outputs. What to retain (ticket IDs, screenshots with dates, exports, approvals).
- Revision control. Version, effective date, owner, and last review.
Avoid burying product-specific click paths inside the top-level information security policy. Keep volatile how-to detail in procedures that can change when the UI changes.
Examples by Control Area
Illustrative only:
| Control area | Procedure example | Evidence the procedure often produces |
|---|---|---|
| Access / logical access | Provision and deprovision workforce accounts | Tickets, IdP logs, access review samples |
| Change management | Promote a production change with required reviews | PR links, approvals, deploy records |
| Incident management | Triage, contain, communicate, and close an incident | Incident tickets, timelines, post-incident notes |
| Backup / recovery | Run a restore test and record results | Test tickets, restore success logs, dates |
| Vendor onboarding | Complete security review before production data sharing | Questionnaire, risk rating, approval |
These themes connect to live pages such as logical access, change management, incident management, and monitoring.
Evidence Themes Auditors May Expect
Illustrative artifacts. Not a mandatory universal checklist:
| Activity | Example evidence to retain |
|---|---|
| Procedure existence | Current controlled copy with version and owner |
| Operation | Tickets or system records showing the steps were followed |
| Approvals | Named approvers and timestamps where the procedure requires them |
| Exceptions | Documented deviations with expiry and residual risk |
| Review | Periodic procedure review notes when your program requires them |
| Training / familiarity | Role onboarding that points people to the right runbooks |
Prefer systems of record over reconstructed narratives. See evidence collection and What Is SOC 2 Evidence?.
Framework Notes
SOC 2
SOC 2 programs commonly examine whether controls are not only designed but operated consistently. Procedures help show how activities are supposed to run; tickets and system logs show they ran. Auditors may walk through a procedure and sample instances across the audit period. Treat procedures as common practice for operating controls, not as a verbatim AICPA quote. Related: SOC 2 Trust Services Criteria Explained and SOC 2 Type 1 vs Type 2.
ISO 27001
ISO 27001-oriented programs typically emphasize documented processes and controlled document information for information security activities. Procedures are a common way teams implement policy requirements in day-to-day operations. See ISO 27001 and control mapping.
Common Failures
Watch for these patterns:
- Procedures that describe tools the company no longer uses (control drift)
- Policy text stuffed with click-by-click steps that go stale quickly
- Shadow runbooks in personal notes that differ from the controlled copy
- Missing owners, so nobody updates the procedure when the stack changes
- Emergency paths with no later documentation or exception record
- Procedures that require evidence no system actually produces
- Assuming a procedure document alone proves Type 2 operation without sample instances
These failures create findings and slow incident response when people need accurate steps under pressure.
Continuous Compliance Bridge
Procedures decay when products, vendors, and teams change. Continuous compliance means reviewing critical runbooks on a cadence, tying them to live tickets, and retaining operation evidence all year. See also AuditFlo's continuous compliance resource and how to prepare for a SOC 2 audit.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for operational artifacts that procedures produce, such as tickets, approvals, and related exports from connected systems.
The focus is organizing dated proof across common systems such as GitHub, Jira, Okta, AWS, and Google Workspace so procedure-backed control claims can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the operating procedures your organization defines. It does not author your runbooks for you, does not issue SOC 2 reports, does not certify compliance, and does not replace auditors.
To see the workflow for your stack, request a demo.
Key Takeaway
A procedure is the step-by-step how-to that implements policy and standards in daily work. It differs from a policy (what must be true), a standard (how strong the baseline is), and a process (the broader end-to-end flow). Keep procedures current, owned, and tied to evidence outputs, and sample real instances across the audit period when proving Type 2 operation.