Policies, standards, procedures and guidelines, and why the difference is examinable

Why this matters

Most people arriving at SecurityX have spent their careers on the technical side, and the first instinct is to treat the documentation objective as the boring part to be skimmed. That instinct costs marks, because CAS-005 does not ask you to write a policy. It asks you to place a described problem in the right document, and those questions are unusually decidable: the scenario tells you whether the thing is mandatory, whether it names a technology, and whether it describes a sequence of steps. Each of those signals maps to exactly one document type.

There is a practical reason too, and it survives the exam. A great deal of security work fails not because the control was wrong but because it was written in the wrong place — a specific TLS version mandated inside a policy that requires board approval to change, so it is still mandating TLS 1.0 four years later. Knowing which document a rule belongs in is what stops that.

This is the first lesson of the course because everything in domain 1 hangs off it. A risk register records decisions against a policy. An auditor tests procedures against standards. A framework is adopted by a policy. Get the hierarchy straight now and the rest of the domain is arithmetic.

The lesson

The four document types, what each binds, and who approves it

The hierarchy runs from the most abstract and hardest to change, to the most specific and easiest.

• Policy. A statement of intent and requirement, owned by senior management and approved at board or executive level. It says what must be true and why, and it deliberately contains no technology. "All organisational data must be protected in transit and at rest commensurate with its classification" is a policy statement. It is mandatory, it is short, and changing it is a governance act.
• Standard. The mandatory specifics that make a policy achievable. Standards name versions, algorithms, configurations and thresholds. "Data in transit must use TLS 1.2 or higher with approved cipher suites" is a standard. It is mandatory, it is owned by a technical authority rather than the board, and it is expected to change as technology moves.
• Procedure. The ordered steps for performing a task so that the standard is met. "To issue a server certificate: raise a request, validate the hostname against the CMDB, generate the CSR with a 3072-bit key..." is a procedure. It is mandatory for the people performing that task, and it is owned by the team that does the work.
• Guideline. Recommended practice. It helps someone make a good decision where a mandate would be inappropriate or impossible to enforce. "Where a service supports it, prefer certificate lifetimes of 90 days or less" is a guideline. It is not mandatory, and that single property is the most commonly tested fact in this objective.

A fifth term appears in scenarios and is worth naming: a baseline is a defined minimum configuration — often expressed as a standard applied to a platform, such as a hardened build for a server image. Treat it as a standard whose scope is one platform.

The approval level matters because it tells you the cost of change. A policy that has absorbed technical detail has effectively promoted that detail to board-level change control, which is how organisations end up unable to deprecate an algorithm without a governance committee.

Why a standard is mandatory and a guideline is not, and what that changes in an audit

Auditors test compliance against things that are mandatory. That sentence is the whole of the practical difference.

If a control is written in a standard, an auditor can sample systems, compare them to the standard, and record every deviation as a finding. There is no argument to have: the standard said TLS 1.2 minimum, this endpoint negotiates TLS 1.0, that is a non-conformity.

If the same control is written in a guideline, the auditor can observe that the guidance was not followed and cannot raise a non-conformity, because nothing was breached. At most it becomes an observation or an opportunity for improvement.

Three consequences follow, and all three show up in scenarios.

1. Putting a control in a guideline is a decision to not enforce it. That is sometimes exactly right — where local circumstances genuinely vary, a mandate produces either widespread exceptions or quiet non-compliance. But it must be a decision, not an accident of drafting.
2. Moving a rule from guideline to standard is a real change with real cost, because every system now in breach becomes a finding on the day it is published. This is why a standard is usually introduced with a compliance date.
3. An audit finding against a procedure is a different animal. It says the steps were not followed, which points at training, tooling or workload — not at the control's design.

When a question describes an assessor "unable to raise a finding despite observing the practice", it is telling you the requirement lives in a guideline.

Reading a scenario to decide which document a stated gap belongs in

CAS-005 questions in this area are built to be decidable. Work through three signals in order.

Signal one: is it mandatory? If the scenario says staff "should consider" or "are encouraged to", you are in guideline territory. If it says "must", "shall" or "are required to", you are in a policy, standard or procedure.

Signal two: does it name a technology, version, value or threshold? If yes, it is a standard — policies do not name technologies. A requirement to "use AES-256 for stored cardholder data" cannot be a policy statement even though it is mandatory, because it will be wrong the moment the algorithm choice changes.

Signal three: is it a sequence? If the text describes steps performed in order by a named role, it is a procedure, regardless of how technical it is.

That leaves policy as what remains: mandatory, technology-neutral, a statement of requirement and intent. A worked example:

A common trap is a scenario where a very technical rule is currently written in the policy and the question asks what is wrong. The answer is not that the rule is wrong — it is that it is in the wrong document, which makes it impractical to maintain.

Exceptions, compensating controls, and the register that stops both becoming permanent

No organisation meets every standard on every system. The mechanism that keeps that honest is the exception: a recorded, time-limited, approved acknowledgement that a specific system does not meet a specific requirement.

A well-formed exception has five parts, and scenarios test whether one is missing:

• Scope. Exactly which systems, not "the legacy estate".
• The requirement not met, cited to the standard.
• The risk accepted, expressed as impact to confidentiality, integrity or availability — not as "low".
• A compensating control, where one is possible.
• An expiry date and a named owner.

A compensating control is a different control that achieves a comparable reduction in risk when the specified one cannot be implemented. If an embedded system cannot support current TLS, placing it behind a terminating proxy on an isolated segment is a compensating control. Two properties are examinable: it must address the same risk the original control addressed, and it must be documented as a compensation rather than presented as compliance. A compensating control does not make you compliant; it makes the exception defensible.

The exception register is what stops this becoming a way to opt out permanently. Every exception has an expiry; expiry triggers review; review either renews with fresh justification or closes. A register with fifty exceptions all dated four years ago and none expired is itself a finding, and scenarios describe exactly that situation and ask what the governance failure is. The failure is not the exceptions — it is the absence of expiry.

Review cycles: the document nobody has opened in three years is a finding

Every document in the hierarchy carries a review cycle, typically annual for policies and more frequent for standards that track technology. Three things make that more than paperwork.

Documents decay against reality. A procedure written for a system that was migrated eighteen months ago now describes steps nobody can perform. The first person to discover that is usually somebody following it during an incident.

Documents decay against each other. A standard is updated to permit a new platform; the procedure that provisions it is not; the policy still references a classification scheme that was replaced. Reviews are where the hierarchy is re-aligned, and an unreviewed set drifts into mutual contradiction.

An unreviewed document is evidence of an unmanaged control. This is the part that turns up in audit findings. If a control's supporting documentation has not been reviewed within its own stated cycle, the assessor has grounds to doubt that the control is being managed at all, independent of whether the control works.

Practically, the review is triggered by date and by event: a significant change to the estate, a material incident, a new obligation, or a framework update all force an out-of-cycle review. A scenario describing a merger, a new regulation or a major breach and then asking what the governance response is has "out-of-cycle review of the affected documentation" as the answer more often than any specific technical control.