How do we separate what belongs in a policy, a standard and a procedure?

Start

You have requirements and need to place them

Policies that carry settings, steps and advice become long, go out of date quickly and need top-level approval for every small change. The fix is to put each kind of content in the tier made for it. The tiers exist because they are approved and reviewed at different levels.

• Then: Give each document one tier, stated on its first page

Step

Give each document one tier, stated on its first page

Each document is a policy, standard, procedure or guideline, never a mix, and its title ends with that word. The top policy is approved by the board or its equivalent: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management. Other policies go to executive management. In the pack's defaults, standards and procedures go to the Head of Information Security, and policies and standards are reviewed every 12 months, procedures and guidelines every 24.

• Then: Test one sentence at a time

Step

Test one sentence at a time

Work sentence by sentence, because one draft can mix content from several tiers. The pack gives a quick test for each sentence. The questions below apply it in one order that works; move each sentence to the first tier that fits.

• Then: Does it explain background, threats or history?

Decision

Does it explain background, threats or history?

Explanations of why a threat matters, how an incident happened or what a regulation says are useful, but nobody can comply with them. They make a policy longer without adding a single requirement.

• Yes: Move it to training or a guideline
• No: Must anyone follow it?

Outcome

Move it to training or a guideline

Keep at most one sentence of it in the policy's Purpose section. If the Purpose runs past five lines, it is doing the work of a guideline. Threat statistics and history belong in awareness material.

Decision

Must anyone follow it?

A policy, standard or procedure must be followed. A guideline is recommended practice, and nobody is non-compliant for ignoring it. If you are unsure whether something is mandatory, treat it as mandatory and let the owner decide when the draft is checked.

• No: it is advice: Guideline: recommend it, with no 'must'
• Yes, or not known: Does it say how a task is done, or who does which step?

Outcome

Guideline: recommend it, with no 'must'

For example: "When working in a public place, sit where your screen cannot be overlooked." A guideline may not contain a 'must' statement. If something has to be done, it belongs in a standard or a procedure.

Decision

Does it say how a task is done, or who does which step?

Steps, forms, tools and who presses which button are procedure material. The pack's test: if it says who clicks what, it belongs in a procedure.

• Yes: Procedure: write the steps by named role
• No: Would it change when a product, setting or number changes?

Outcome

Procedure: write the steps by named role

For example: "To grant access: 1. The line manager raises a request. 2. The system owner approves." In the policy, keep only a pointer: "following the X Procedure". The people who run a procedure are trained on it; staff do not acknowledge it one by one.

• Then: Name each document's parent on its first page

Decision

Would it change when a product, setting or number changes?

A setting, a number or a product that could change within the year is standard material. Password length, time-outs and patch deadlines are examples. Nobody outside IT can judge them, and they would force top-level approval of every adjustment. If you cannot tell, treat the answer as yes.

• Yes, or not known: Is the figure central to what the policy promises?
• No: Policy: state it as a commitment

Decision

Is the figure central to what the policy promises?

Some deadlines are commitments management should approve. "A leaver's access is disabled by the end of their last working day" can stay in a policy. A technical value, such as a password length or a time-out, cannot.

• Yes: Policy: state it as a commitment
• No, or not known: Standard: set the measurable requirement

Outcome

Standard: set the measurable requirement

For example: "Passwords are at least 14 characters" or "Critical patches are applied within 14 calendar days." In the policy, keep the commitment and point to the standard: "to the standard set in the X Standard".

• Then: Name each document's parent on its first page

Outcome

Policy: state it as a commitment

A commitment the organisation must keep, whoever is in post, such as "Every administrator account must use multi-factor authentication." Keep the policy short: the pack's default is at most 4 pages of body. If a draft runs over, move settings, then steps, then explanations, then examples down a tier.

• Then: Name each document's parent on its first page

Step

Name each document's parent on its first page

Every document below the Policy tier names its parent document on its first page. That makes the chain visible from any page, and shows which policy each standard or procedure puts into effect.

• Then: Does a lower tier contradict the tier above it?

Decision

Does a lower tier contradict the tier above it?

A lower tier may add detail. It may never contradict the tier above. Check for it whenever a standard or procedure is drafted or revised.

• Yes: Follow the higher tier; correct the lower document
• No: Each tier holds only its own kind of content

Outcome

Follow the higher tier; correct the lower document

Where a standard and its policy disagree, the policy applies until the standard is corrected. Correct it through review. If the correction changes a 'must' statement or a value people work to, it is a material change.

Outcome

Each tier holds only its own kind of content

The policy stays short and stable, so fewer changes need top-level approval. Standards and procedures change with the technology, approved at the level that can judge them. Record each document with its tier on your register.