Policies, standards, procedures, plans and guidelines, and the difference between them

Objective 5.1 asks why governance, risk and compliance documents matter. In practice that means knowing the five kinds of document a security programme is written in, what each one is for, and which kind a given requirement belongs in. This lesson is the applied lab for 5.1, because a policy is something you can write and be graded on.

Why this matters

These five words are used interchangeably in ordinary speech and are examined as five distinct things. The exam will describe a document and ask what it is, or ask which kind a given requirement belongs in. That is free marks for anyone who learned the hierarchy and a coin flip for everyone else.

The distinction is also useful at work. Most "security policy" problems are level problems: technical specifics buried in a policy nobody can change, or a mandatory requirement written as a guideline.

The lesson

The hierarchy first, because every section below hangs from it:

• Policy: a high-level statement of intent and requirement, approved by senior management. It says what must be true and why, and it is deliberately free of technical detail so it survives technology changes. Mandatory.
• Standard: a specific, measurable requirement that supports a policy. It says what specifically: the minimum TLS version, the password length, the approved algorithms. Mandatory, and it changes more often than the policy above it.
• Procedure: step-by-step instructions for carrying something out. It says how. Mandatory where it applies.
• Plan: a coordinated response to a defined situation, such as a disaster. It says who does what, in what order, when it happens, and it usually calls on many procedures.
• Guideline: recommended practice. It says what is advisable, and it is optional.

A worked set for one requirement shows what changes at each level:

• Policy: "Company data must be protected against unauthorised disclosure, in transit and at rest."
• Standard: "Data in transit uses TLS 1.2 or higher with approved cipher suites. Data at rest uses AES-256."
• Procedure: "To request a certificate: raise a ticket of this type, generate a CSR with these parameters, submit it to the internal CA, install it as follows, verify with this command."
• Guideline: "Where a service supports it, prefer TLS 1.3."

The policy could have been written ten years ago and still be right. The standard will change when TLS 1.2 is retired. The procedure changes when the ticketing system does. Putting the algorithm in the policy is the common mistake, because then changing an algorithm needs board approval.

Policies from acceptable use and clean desk to BYOD, data retention and vulnerability disclosure

The policies worth knowing, each with what it is actually for:

• Information security policy: the top document of the programme. Scope, objectives, the risk approach and management's commitment. Everything else hangs from it.
• Acceptable use policy (AUP): what staff may and may not do with company systems, data and networks. Its underrated function is legal: it establishes that monitoring is expected and that a given action was unauthorised, which matters in a disciplinary case. Acknowledged at onboarding and again periodically.
• Clean desk policy: no sensitive papers, unlocked screens, written passwords or unattended removable media left out when you step away. A physical-world control against shoulder surfing, opportunistic theft and the visitor who photographs a whiteboard.
• Bring your own device (BYOD) policy: the conditions under which personal devices may reach company data. Typically enrolment in device management, a minimum OS version, a screen lock, separation of work data from personal data, and what the company may wipe when the person leaves.
• Access control policy: who approves access, on what basis (least privilege, need to know), and how often access is reviewed.
• Incident response policy: what counts as an incident, who may declare one, and who has authority to act. The authority clause is the important part: it lets a responder take a system offline at 3am without waiting for a manager.
• Data classification and retention policy: the classification levels, who assigns them, and how long each kind of record is kept before disposal.
• Data disposal policy: how data and media are destroyed at the end of their life, by classification and media type, and what evidence of destruction is kept.
• Privacy policy: how the organisation collects, uses and protects personal data, often published externally as well as applied internally.
• Vulnerability disclosure policy: how an outside researcher should report a flaw they found, what is in scope, how quickly you will respond, and a commitment not to pursue good-faith reporters. Without one, the researcher who found your bug has no safe way to tell you.

Standards: baselines, passwords, encryption, physical security and RFCs

Standards are where the specifics live:

• Baselines: the required secure configuration for each platform, such as the build every Windows server must match. A baseline is usually derived from a published benchmark, with the organisation's own exceptions recorded.
• Password standard: minimum length, screening against known-breached passwords, where MFA is required, and the rules for privileged and service accounts. Written against current guidance from Domain 4, not habit.
• Encryption standard: approved algorithms and key lengths, where encryption is required, key management, and what is prohibited. This is the document that says MD5 and SHA-1 are not acceptable for signatures, which makes the Domain 1 cryptography enforceable.
• Physical security standard: zones and their controls, badge issue and revocation, visitor handling, and requirements for equipment rooms.
• RFCs: the Requests for Comments published by the IETF, which define how internet protocols work. TLS 1.3, for example, is specified in RFC 8446. An organisation's own standards cite RFCs so that what it builds interoperates and behaves predictably, and a standard that says "conforms to" a given RFC can be tested against it.

The property that makes a standard useful is that it is measurable. "Strong encryption must be used" is a policy sentence; "AES-256 at rest, TLS 1.2 minimum in transit" is a standard, and the second can be audited by a tool. If you cannot write a check for it, it is not yet a standard.

Procedures and runbooks, and the plans for continuity and disaster recovery

A standard operating procedure (SOP) is the documented, repeatable way a routine task is done: provisioning a new starter, rotating a certificate, restoring a file from backup. Its value is consistency: the task is done the same way whoever does it, and nothing is forgotten.

A runbook is a procedure for operating a particular system or handling a particular condition, written so precisely that it can be followed under pressure, and often precise enough to be automated. "Disk on the database server above 90%: run these checks, in this order, then this command." Many runbook steps end up as scripts in the automation work of Domain 4.

A procedure's test: can someone follow it at 3am without the person who wrote it?

Plans sit above procedures. The business continuity plan says how the organisation keeps its essential functions running during a disruption: manual workarounds, alternative locations, who decides. The disaster recovery plan says how technology services are restored afterwards: in what order, to which site, by whom, to meet which recovery objectives. A plan is mostly coordination, and it calls on many procedures. The recovery metrics the plans are built to meet belong to resilience in Domain 3.

Guidelines: benchmarks, advisories, implementation guides and reference architectures

Guidelines are advice from someone with expertise, and the common sources are external:

• Benchmarks: published, consensus configuration recommendations for a platform, such as the CIS Benchmarks. Hundreds of settings, each with a rationale.
• Advisories: notices from a vendor or a government security agency about a vulnerability or an active threat, with recommended actions.
• Implementation guides: a vendor's or standards body's advice on deploying a product or a control securely.
• Reference architectures: published example designs showing how the pieces of a solution fit together securely, which you adapt rather than copy.

The important point is what happens when you adopt one. A benchmark is a guideline while it sits on the publisher's website. The moment your baseline standard says "every server meets this benchmark, with these recorded exceptions", that benchmark's content has become a mandatory standard inside your organisation. The document did not change; its status did.

Why 'guideline' is the word that makes an exam answer wrong

Guidelines are optional. They exist for situations where mandating one answer would be wrong: varied environments, evolving practice, matters of judgement. They capture expertise without creating an obligation nobody can meet.

What makes them an exam trap is that a guideline cannot be enforced or audited for compliance. So:

• if the scenario says staff must do something, it is a policy or a standard, never a guideline;
• if an auditor is checking compliance, they check against policies and standards; a guideline produces no finding;
• if the fix for a recurring problem is "we have a guideline about that", the correct answer is to promote it to a standard, because the guideline has already failed to change behaviour;
• and a control that regulation requires cannot be expressed as a guideline.

The reverse trap is putting into a policy something that belongs in a standard. A policy naming a specific product or algorithm means every technical change needs senior approval, which is how organisations end up running deprecated cryptography for two years.

What to take into the exam

• Policy (what and why), standard (what specifically), procedure (how), plan (coordinated response), guideline (advice, optional).
• Only guidelines are optional; the others are mandatory and auditable.
• A standard must be measurable; baselines and RFCs are standards because something can be tested against them.
• A benchmark or advisory is a guideline until your own standard adopts it.
• BC keeps the business running; DR restores the technology. Both are plans.
• A vulnerability disclosure policy gives outside reporters a safe, defined route to tell you about a flaw.