A policy says what; a procedure says how

2026-08-04T00:00:00-06:00

Many organizations own a shelf of security documents and still cannot answer a plain question about any one of them: is this telling someone what to achieve, or telling them how to do it? The distinction sounds academic until an assessment, a staff departure, or a new hire makes it expensive.

The division of labor

A policy states what the organization will do and why it matters. It should make sense to someone who does not administer the systems it governs.

It also has to state its scope: which people and which systems have to meet it. People means employees, but usually also contractors, temporary staff, and vendor personnel with access. Systems means the ones the organization runs and the ones it merely pays for. A requirement with no stated scope cannot be complied with or checked, because nobody can say what falls under it.

Scope is where policies fail quietly. "All employees" leaves out the contractors who often hold the most access. "All company systems" leaves out the ones the company does not own but depends on. The scope statement also sets the size of the inventory the organization needs in order to check its own compliance.

A procedure states how the work is done: the steps, the role that performs them, the tool involved, what the work produces, who checks it, and where the result is recorded. It should be specific enough that a competent new employee can follow it without being shown.

The same requirement, split

Consider phishing-resistant multifactor authentication.

The policy is one or two sentences: remote access to all systems working with sensitive data requires phishing-resistant multifactor authentication. Coverage is verified regularly, and exceptions are approved, compensated, and time-limited.

The procedures are everything that sentence assumes: which authentication methods are permitted and which are switched off; how a new employee enrolls a security key, and what happens to the temporary credential used to do it; how the identity administrator produces the monthly enrollment report; who compares it against the current roster of people who should have access; where that comparison is filed; what happens when an account turns up without an enrolled method; how an exception is requested, what it has to contain, and who approves it.

None of that detail belongs in the policy. All of it has to exist somewhere.

Systems the organization does not run

The split matters most where the organization does not own the computer. A cloud service or an external service provider holding company sensitive data is in scope, and the organization can configure only what the provider chose to expose.

The policy does not change: the requirement follows the data, not the question of who racks the hardware. The procedure changes considerably, because the mechanisms available are contractual as much as technical. The requirement has to appear in the agreement, the provider has to be asked what it actually supports, and the answer has to be verified rather than assumed.

That check is worth doing early. Plenty of providers are absorbed in their own product and have given little thought to what their customers are obliged to meet. A provider that cannot support phishing-resistant authentication, or supports it only on a plan the organization is not buying, is a finding to discover during selection rather than during an assessment.

Providers describe the division in a responsibility matrix: which controls the provider operates, which the customer operates, and which are shared. That document is where the organization's own procedure has to start, because it determines what is left to write a procedure about. A control the matrix marks as shared is not a control that is finished.

Why separating them is practical, not tidy

Four consequences show up in ordinary operation.

Approval and change rate. A policy is approved by someone with authority to commit the organization. A procedure changes when a vendor rearranges a settings page. Merge them and one of two things happens: trivial operational changes queue up for executive approval, or the document quietly stops matching reality because nobody wants to trigger the approval cycle.

Audience. An executive, a customer, or an assessor reads the policy to learn what the organization has committed to. The person doing the work reads the procedure. A document serving both audiences usually serves neither: too much detail to approve, too little to follow.

Handover. Turnover is where the distinction stops being a documentation question and starts costing money. An administrator leaving with a written procedure hands over a document. One leaving without hands over a conversation, and whatever gets forgotten in it leaves with them.

The bill arrives twice. First on the way out, in the scramble to capture what one person turned out to be the only one who knew, conducted during a notice period against someone whose attention has already moved on. Then on the way in, because a new hire with nothing to follow has to be taught by whoever knows the work—which means taking an experienced person off their own tasks, for every hire, with a result that varies according to who did the teaching and what they happened to remember that day. Written procedures turn all of that into reading.

Evidence. A policy makes a claim about coverage. The procedure is what produces the artifact that supports the claim, and it is the procedure that names the report, the schedule, and the file it lands in. Without that, the policy asserts something nobody can demonstrate.

The line is wide and gray

Where a given statement belongs depends on the organization. A twelve-person firm may reasonably keep one short document; a twelve-hundred-person one that tried would produce something no one could approve or follow.

A workable rule of thumb: if a sentence would have to be rewritten because the organization changed vendors, reorganized a department, or upgraded a product, it is procedure. A policy that names a particular identity provider has to go back for re-approval when the organization switches to a different one, even though the underlying requirement never changed.

The same test applies to named individuals. Policies assign responsibility to roles, because people change jobs and the requirement does not.

Checking frequency sits squarely on the line, and reasonable organizations put it on either side. How often compliance is verified is a real commitment: an assessor or a customer reads it as one, and a cadence stated in the policy cannot be quietly relaxed by whoever finds the check inconvenient. Stated in the procedure instead, it can be tightened after a bad finding without waiting on a re-approval cycle.

A workable compromise states a floor in the policy—verification happens at least annually—and lets the procedure set the working cadence above it. What does not work is leaving the frequency in neither document, which is the usual arrangement and the reason so many checks turn out to have last happened whenever someone last thought of it.

Two familiar failure modes

A policy with no procedure is an intention nobody is obliged to act on. This is the usual result of buying a template document set. It reads well, covers every heading an assessor might name, and when someone asks how a requirement is actually met, the answer lives in one administrator's memory or does not exist.

A procedure with no policy is a habit that changes when its author leaves. The work may be done well, but nothing states the requirement, so there is no basis for saying that a deviation is wrong, and no way to tell whether the practice still reflects a decision anyone made.

Link them to each other

Splitting the documents creates a navigation problem, and the fix is unglamorous: each policy statement should link to the procedures that carry it out, and each procedure should name the policy it serves. Often that is more than one. A procedure for reviewing account access may answer to an access control policy and to a personnel security policy at the same time, and it should cite both.

The organization gets the first benefit. Cross-references are how anyone discovers that a requirement has no procedure at all: a policy statement with nothing to link to is the first failure mode above, found before an assessor finds it.

The second benefit arrives on assessment day. An assessor working a control follows the policy to the procedure to the evidence. Where those links exist, that path takes minutes and the conversation moves on. Where they do not, the assessor asks, someone goes looking, and the organization spends its assessment hours demonstrating that it can find things rather than demonstrating that it is secure. Assessment time is not free, and neither is the impression left by an organization that cannot navigate its own documentation.

A test worth running

Take one requirement that matters. Hand the procedure to a competent person who has not done the job and see whether they can do the work. Hand the policy to an executive who administers nothing and see whether they can tell what the organization has committed to. If both hold, the pair is doing its job.

Neither document is paperwork for its own sake. Together they are what lets the work survive a resignation, an audit, and a change of vendor.

Kenneth Ingham Consulting writes and reviews security policies and procedures, and sorting out which statement belongs in which document is usually where that work starts.

Kenneth Ingham Consulting, LLC