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

Objective 5.1 in this course covers security governance. The previous lesson took the structures and roles; this one takes the document hierarchy from CompTIA's scope note, and it is the applied lab for 5.1 — because a policy is something you can write and be graded on.

Why this matters

These four words are used interchangeably in ordinary speech and are examined as four distinct things. The exam will describe a document and ask what it is, or ask which of the four 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 genuinely useful. Most organisations with a "security policy" problem actually have a level problem — technical specifics buried in a policy nobody can change, or a mandatory requirement written as a guideline nobody has to follow.

The lesson

The hierarchy, and the one word that makes an answer wrong

From the top:

• 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. It is mandatory.
• Standard — a specific, measurable requirement that supports a policy. It says what specifically: the minimum TLS version, the required password length, the approved encryption algorithms. Also mandatory, and it changes more often than the policy above it.
• Procedure — step-by-step instructions for carrying something out. It says how, and it is written so that someone who has not done it before can follow it. Mandatory where it applies.
• Guideline — recommended practice. It says what is advisable, and it is optional. Guidelines exist for situations too varied to mandate.

The word in the heading is optional. If an exam option describes something as a guideline and the scenario requires compliance, that option is wrong — and conversely, if the scenario describes advice with discretion, "policy" is the wrong label.

A worked set for one requirement:

• Policy: "All 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 type X, generate a CSR with these parameters, submit it to the internal CA, install as follows, verify with this command."
• Guideline: "Where a service supports it, prefer TLS 1.3 for improved performance and forward secrecy."

Notice what changes at each level. The policy could have been written ten years ago and still be right. The standard will change when TLS 1.2 is deprecated. 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.

Acceptable use, information security, business continuity, disaster recovery

The policies CompTIA names, each with what it is actually for:

• Acceptable use policy (AUP) — what staff may and may not do with company systems, data and networks: personal use, prohibited activity, monitoring consent, and the consequences. Its underrated function is legal: it is what establishes that monitoring is expected and that a given action was unauthorised, which matters in a disciplinary case or a prosecution. Signed at onboarding and re-acknowledged periodically.
• Information security policy — the overarching statement of the security programme: scope, objectives, roles, risk approach, and the commitment from management. It is the document that everything else hangs from.
• Business continuity policy — the commitment to maintain essential functions during disruption, and who is responsible. The plan is separate; the policy establishes the requirement.
• Disaster recovery policy — the commitment to restore technology services, with the requirement that RTOs and RPOs are defined and tested.
• Incident response policy — defines what an incident is, who declares one, who has authority to act, and the obligation to report. The authority clause is the important part: it is what lets a responder take a production system offline at 3am without waiting for a manager.
• Software development lifecycle (SDLC) policy — security requirements in development: review, testing, separation of environments, and what may reach production.
• Change management policy — from Domain 1, and it belongs in this list.

Standards: password, access control, physical security, encryption

Standards are where the specifics live, and CompTIA names four families:

• Password standard — minimum length, screening against breached lists, MFA requirements, rules for privileged and service accounts, lockout thresholds. Written against the current guidance from Domain 4's MFA lesson, not habit.
• Access control standard — the model in use (RBAC, ABAC), how access is requested and approved, recertification frequency, and the rules for privileged access.
• Physical security standard — zones and their controls, badge issuance and revocation, visitor handling, and requirements for server rooms.
• Encryption standard — approved algorithms and key lengths, where encryption is required, key management and rotation, and what is prohibited. This is the document that says MD5 and SHA-1 are not acceptable for signatures, which makes the Domain 1 material enforceable.

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

Procedures: change management, onboarding, offboarding, playbooks

The procedures CompTIA names are the ones where inconsistency costs most:

• Change management procedure — the mechanics of the Domain 1 process: how a request is raised, what it must contain, who approves, how emergency changes work, and how they are recorded afterwards.
• Onboarding procedure — identity created from the authoritative source, role-based access granted, equipment issued and recorded in the inventory, policies acknowledged, training assigned.
• Offboarding procedure — the Domain 4 leaver case, written down: access revoked at notification, all systems covered including SaaS outside SSO and keys the person created, equipment returned, data transferred to a new owner, and mailbox handled. The value of writing it down is completeness — offboarding fails by forgetting one system, and a checklist is what stops that.
• Playbooks — step-by-step response to a specific incident type: ransomware, BEC, credential compromise, data exfiltration. A playbook is what makes response consistent regardless of who is on shift, and it is the thing that gets automated in the 4.7 lesson.

A procedure's test is the heading of the 4.8 lesson applied here: can someone follow it at 3am, tired, under pressure, without the person who wrote it? If it assumes knowledge that is not in the document, it will fail exactly when it matters.

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

To close, the discriminator stated plainly, because it is the most reliably examined thing in this objective.

Guidelines are optional. They are recommendations for situations where mandating one answer would be wrong — varied environments, evolving practice, matters of judgement. They are genuinely useful: they capture expertise without creating a compliance 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 a guideline has already demonstrably failed to change behaviour;
• and a control that regulation requires cannot be expressed as a guideline at all.

The related trap is the reverse: putting something in a policy that should be a standard. A policy naming a specific product or algorithm means every technical change requires senior approval, which is how organisations end up running deprecated cryptography for two years because nobody wanted to reopen the policy.

Policy says what must be true. Standard says what specifically. Procedure says how. Guideline says what is advisable, and nobody has to.

What to take into the exam

• Policy (what and why) → standard (what specifically) → procedure (how) → guideline (advice, optional).
• Only guidelines are optional; the other three are mandatory and auditable.
• A standard must be measurable — if you cannot write a check for it, it is still a policy sentence.
• Keep algorithms and versions out of policies and in standards, so they can change without board approval.
• The AUP's underrated role is establishing that monitoring is expected and an action was unauthorised.
• The IR policy's authority clause is what lets a responder act without waiting for approval.