Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we write a policy statement that an auditor can test?

7 decision pointsThe pack behind this answer: Security Policy Management

Add to board memo

The short answer

Recommendation
Write each policy statement so that two people looking at the same evidence would agree whether it was met. One requirement per statement, a named role, "must" or "must not", a result that can be seen or counted, and evidence you can name before you keep it.
Reasoning
The numbered statements are the part of a policy an auditor tests. Soft words such as "should", "where possible" and "endeavour to" leave the reader free to decide, so nobody can be found non-compliant with them. Vague words such as "appropriate", "regularly" and "promptly" describe a judgement, and each reader makes a different one. A statement with two duties cannot record a single result, and a statement with no subject leaves nobody accountable. If you cannot say what you would hand an auditor, the statement will fail its first audit.
Considerations
  • The figure of 8 to 20 statements per policy is the CISO Times policy pack's default. Fewer usually says too little to test; more usually means standard-level detail has crept in. Your own framework may set a different range.
  • Settings and steps can be tested too, but they belong in a standard or a procedure, where they can change without top-level approval. Leave a pointer to them in the policy.
  • If a practice is truly optional, it is not a policy statement. Move it to a guideline, which may not contain a "must". If you are not sure it is optional, write it with "must".
  • Never renumber at a revision. A removed statement keeps its number, marked as withdrawn in that version, so findings, exceptions and training still point to the right text.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartYou are drafting a policy statementDecisionIs it a commitment, not a setting or a step?OutcomeMove it to a standard or procedureDecisionDoes it hold more than one duty?StepSplit it: one requirement per statementDecisionDoes it name who must act?StepStart the statement with a role or groupDecisionDoes it use "must" or "must not"?DecisionIs it truly optional?OutcomeMove it to a guidelineStepRewrite it with "must" or "must not"DecisionCan the result be seen or counted?StepReplace vague words with a result or a frequencyDecisionDo you know the evidence that would show it is met?StepNumber it, and never renumber at a revisionOutcomeTestable: two people would agree from the evidence

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 16 steps.

  1. Start

    You are drafting a policy statement

    The numbered statements are the part of a policy an auditor tests. The test is simple: two people, looking at the same evidence, would agree whether the statement was met. Each check below removes one way a statement fails that test.

    In the pack

  2. Decision

    Is it a commitment, not a setting or a step?

    A policy statement is something the organisation commits to, whoever is in post. A password length, a time-out or a list of steps can be tested too, but it belongs in a standard or procedure, where it can change without top-level approval.

    In the pack

  3. Outcome

    Move it to a standard or procedure

    Leave a pointer in the policy, such as "to the standard set in the Access Control Standard". For example, "Users must use strong passwords" becomes "Users must not share their passwords or other sign-in secrets with anyone, including IT staff", and the length and complexity move to the standard.

    In the pack

    See also

  4. Decision

    Does it hold more than one duty?

    Look for "and" between two different duties. "Users must use strong passwords and protect their accounts" is two requirements. One can be met while the other is not, and an auditor cannot record a single result.

    In the pack

  5. Step

    Split it: one requirement per statement

    Give each duty its own number, so each can be tested, excepted and reported on by itself. An exception or audit finding then cites exactly one statement.

    In the pack

  6. Decision

    Does it name who must act?

    A statement needs a subject an auditor can go and ask: "system owners", "every user", "the Head of IT". "It" and passive forms such as "access will be reviewed" leave nobody accountable.

    In the pack

  7. Step

    Start the statement with a role or group

    Use a role, not a person's name, so the statement survives staff changes. "IT is responsible for ensuring backups are adequate" becomes "The IT Operations Manager must make sure every system in the backup scope has a successful backup at least once every 24 hours."

    In the pack

  8. Decision

    Does it use "must" or "must not"?

    "Should", "may", "where possible", "as appropriate" and "endeavour to" leave the reader free to decide. Nobody can be found non-compliant with them, so an auditor has nothing to test.

    In the pack

  9. Decision

    Is it truly optional?

    Sometimes the soft word is honest: the practice is recommended, and nobody is non-compliant for skipping it. If so, it is not a policy statement. If people are expected to do it, say so with "must".

    In the pack

  10. Outcome

    Move it to a guideline

    A guideline holds recommended practice, and it may not contain a "must". Taking optional advice out of the policy keeps every remaining statement enforceable.

    In the pack

    See also

  11. Step

    Rewrite it with "must" or "must not"

    "The organisation will endeavour to remove leavers' access promptly" becomes "All of a leaver's access must be disabled by the end of their last working day." "Endeavour" and "promptly" cannot fail; a date can.

    In the pack

  12. Decision

    Can the result be seen or counted?

    An auditor needs something to observe: an account, a record, a date. "Adequate", "appropriate", "regularly" and "promptly" describe a judgement, and each reader will make a different one.

    In the pack

  13. Step

    Replace vague words with a result or a frequency

    "Access should be reviewed regularly" becomes "System owners must review who has access to each system holding customer data at least every 6 months, and record the result." That gives a named role, a frequency with its unit and a record to inspect. "Appropriate security measures for remote access" becomes "Every sign-in from outside the office network must use multi-factor authentication."

    In the pack

  14. Decision

    Do you know the evidence that would show it is met?

    Ask what you would hand an auditor to prove the statement is met: a report, a log, a signed record. If there is no answer, the statement will fail its first audit. If you are not sure, rewrite until you are.

    In the pack

  15. Step

    Number it, and never renumber at a revision

    Use a short prefix and a running number, such as ACP-1, ACP-2 for an access control policy. A removed statement keeps its number, marked "Withdrawn in version x.y", so findings, exceptions and training still point to the right text. Aim for 8 to 20 statements: fewer usually says too little to test, more usually means standard-level detail has crept in.

    In the pack

  16. Outcome

    Testable: two people would agree from the evidence

    Keep the rest of the policy as testable as its statements. The Compliance and consequences section says which records are sampled, how often and by whom. The Exceptions section sends every deviation to your exception process by reference, with no second route.

    In the pack

    See also

Practical checklist

  1. Check the statement is a commitment the organisation keeps whoever is in post. Move settings and steps to a standard or procedure.
  2. Split any statement with two different duties, so each has its own number.
  3. Start each statement with a role or group, never a person's name, "it" or the passive.
  4. Use "must" or "must not" for every requirement, or move optional practice to a guideline.
  5. Replace vague words with something that can be seen or counted: a record, a date, or a frequency with its unit.
  6. Name the evidence you would show an auditor. If there is none, rewrite the statement.
  7. Number each statement with a short prefix and a running number.
  8. Make the Compliance and consequences section say which records are sampled, how often and by whom, and point the Exceptions section to your exception process by reference.

Evidence to have ready

  • The approved policy, with numbered "must" statements that each name who acts.
  • For each statement, the record that shows it is met: a report, a log or a signed record, such as dated access reviews or the dates leavers' accounts were disabled.
  • The results of your compliance checks: which records were sampled, when and by whom.
  • The revision history, showing withdrawn statements kept under their original numbers.

Assumptions

  • The statement is going into a policy. Settings, steps and advice belong in standards, procedures and guidelines.
  • Figures shown, such as 8 to 20 statements per policy, are the defaults in the CISO Times policy pack. Your own framework may set different ones.

Not covered here