Quick Answer: A good cybersecurity procedure tells a named role exactly how to perform a control, how often, with which tools and what record to keep. Write one procedure per control or activity, tie it to the standard it satisfies, and make every step produce evidence. Procedures that meet those tests are the ones assessors accept.
A procedure is the "how" of a security program. Policies state management intent, standards set measurable requirements, and procedures describe the repeatable steps that put those requirements into practice. If a standard says privileged accounts are reviewed quarterly, the procedure explains who pulls the account list, where it comes from, what the reviewer checks and where the signed review is stored.
The policies vs standards vs controls vs procedures guide explains how the document types relate.
Every procedure should include at the very least:
Start each step with an action verb, keep it to one action, and name the role that performs it. "The system administrator exports the list of privileged accounts from the directory" is testable. "Accounts are reviewed as needed" is not. Where a step requires judgment, state the decision criteria so two people would reach the same outcome.
Avoid copying tool screenshots into the procedure unless they are stable. Menus change often, and an out-of-date screenshot makes the whole document look stale. Reference the tool and the outcome instead, and keep click-by-click detail in a separate work instruction if staff need it.
Most rejected procedures fail for the same few reasons:
Fixing these is usually faster than writing from scratch. Walk through each procedure with the person who performs it, correct the steps, and add the evidence output.
Map each procedure to a control, and each control to your standards. ComplianceForge uses the Hierarchical Cybersecurity Governance Framework to connect policies, control objectives, standards, guidelines, controls, risks, procedures and metrics, so a small team can keep procedures short while a large enterprise adds owners and detail without rewriting the structure.
If you would rather edit than start from a blank page, ComplianceForge's editable procedures templates, including the SCF-based procedures, are written at the control level and map to the Secure Controls Framework, so each procedure already points to the requirement it supports.
A policy states management intent, such as requiring access to be reviewed. A procedure describes the specific steps a named role follows to meet that requirement, how often, and what record it produces.
Detailed enough that a qualified person who has never done the task could follow it and produce the same result. If a step depends on judgment, say who makes the decision and what criteria they use.
Yes. Assessors typically compare written procedures with what staff describe in interviews and with the records the process produces. A procedure nobody follows usually creates a finding.
Usually not. Policies change rarely and need executive approval, while procedures change whenever tools or teams change. Keeping them separate makes updates faster and approvals simpler.
