Policies, standards, and procedures

The idea

A policy states organizational intent and requirements. A standard specifies mandatory details, such as minimum configurations. A procedure explains how a task is carried out. Guidelines provide recommended practice. Clear documents identify scope, owners, exceptions, and review dates. They should fit actual systems and roles. A policy that cannot be implemented or verified creates ambiguity rather than reliable assurance.

In practice

An access policy requires least privilege; a standard defines approval and review requirements; a procedure explains how an owner requests and removes access.

A common misunderstanding

Writing a policy is not evidence that everyone follows it or that its intended control works.

Check your understanding

How should an exception be handled?

Think it through: Through an approved, documented process with scope, justification, owner, compensating controls, and expiry or review.

Direction, requirements, and execution serve different readers

A policy states organizational intent and authority. A standard makes required rules more specific. A procedure describes how somebody performs a task in a particular environment. These records work together, but combining them indiscriminately can make maintenance difficult. A policy that embeds every product-specific click path may become obsolete whenever the interface changes.

For account security, policy might require controlled access and accountable ownership. A supporting standard could define approved authentication and review requirements. A procedure could explain how staff request access, how an approver evaluates it, and how an operator records the change. The organization should define its own document hierarchy consistently rather than assume every framework uses identical labels.

A fictional rule without a workflow

An academy publishes a policy saying all privileged access must be approved. Operators still receive informal chat requests because nobody has defined who can approve them or where evidence belongs. A practical procedure resolves the handoff and recording problem. The team then checks a sample of completed requests to see whether the rule operates in practice.

Exceptions also need a route. When a legacy system cannot satisfy a standard, quietly ignoring the requirement hides the risk. An explicit exception records the affected scope, reason, compensating measures, accountable owner, and review point. Approval should come from someone with the appropriate authority.

Test a document hierarchy

Write one policy statement, one supporting standard, and one procedure step for a fictional backup service. Ask whether each statement belongs at the chosen level. Then change the backup product and identify which document should require revision. A well-separated hierarchy preserves stable organizational direction while allowing operational instructions to evolve with the environment.

Keep exploring

• Security governance
• Compliance evidence
• Least privilege