CompTIA Security+ SY0-801 Policies, Standards, Procedures and Guidelines

Governance documents form a hierarchy in which each level answers a different question: a policy says what the organization intends and who is accountable, a standard says what specific, measurable requirement must be met, a procedure says how to carry out a task step by step, and a guideline offers recommended practice that is not mandatory. Policies, standards and procedures are mandatory; guidelines are advisory.

Three practical rules follow from this structure:

• Policies stay technology-neutral. A policy that names products, versions or settings goes out of date every time technology changes. Intent, scope and accountability belong in the policy; anything that names a version or value belongs lower down.
• Changes flow down, not up. When a lower-level document's requirement changes (for example, a standard raises the minimum certificate key size), the higher-level intent usually stays as it was, while the documents and settings that put the old requirement into practice, such as certificate-request steps and templates, are what need updating.
• Authority decides mandatory versus advisory. An organization can only mandate what it controls. For assets outside its control, such as a contractor's own office network or a customer's computer, it can only recommend, so what it publishes there is guidance.

Authority flows from the top: standards and procedures carry weight only because a policy endorsed by leadership requires them and names who enforces them.

Guidelines are advisory documents, usually from outside the organization, that inform how it designs, configures and protects systems; Security+ names four kinds, and each serves a different moment in a system's life.

The order matters in a project: a reference architecture comes first (design what is needed), procurement selects products against it, and the chosen vendor's implementation guide then governs deployment. Each guideline answers a different question: what should we build (reference architecture), how do we deploy this product (implementation guide), how do we harden this platform (benchmark) and what do we do about this flaw (advisory).

Do not confuse an advisory with a vulnerability disclosure policy. An advisory flows outward: a vendor tells customers about a flaw it already knows about. A disclosure policy invites reports inward: it tells outside researchers how to report flaws they find (see the vulnerability disclosure section below).

A standard turns a policy's intent into specific, mandatory requirements that can be measured and audited; it says what must be achieved, not the step-by-step method of achieving it.

• Security baseline: the hardened starting configuration that every system of one type must have (for example, every database host: unneeded services disabled, logging switched on, default accounts removed). Because it is written down, it is both the build template and the yardstick: scanners compare running systems with it and flag configuration drift. Organizations often derive their baselines from industry benchmarks, but the baseline is the organization's own mandatory requirement.
• Password standard: the enforceable rules for credentials, such as minimum length, how passwords are stored, lockout and reuse rules, and when multifactor authentication is required. Wording decides the category: "should" language is advice, while "must" language that systems are configured to enforce is a standard.
• Physical security standard: requirements for facilities such as lock and door specifications for equipment rooms, badge-reader coverage of restricted areas and lighting of entrances. It defines outcomes an auditor can verify at any location; the exact steps local staff follow belong in procedures.
• Encryption standard: approved algorithms, key lengths, protocol versions and key-management rules (for example, minimum key sizes and which cipher suites are allowed).
• Request for Comments (RFC): the document series published by the Internet Engineering Task Force (IETF) and related bodies. Standards-track RFCs define how a protocol's messages and behaviour must work; TLS 1.3, for example, is specified in RFC 8446, and RFC 8996 formally deprecated TLS 1.0 and 1.1. Software from different developers that follows the same RFC can talk to each other, which is why protocol work starts from the RFC rather than from one vendor's documentation.

Procedures are the step-by-step instructions that carry out policies and standards; Security+ distinguishes the standard operating procedure (SOP), written for people performing a routine process, from the runbook, written for a specific technical task and often executed by automation.

An SOP does not replace the policy behind it: the policy sets the rule, and the SOP is how that rule is applied every time. Likewise, a runbook is not a recovery plan: a disaster recovery plan sets priorities and order of restoration, and runbooks hold the exact steps for individual technical actions within it. When engineers improvise commands from memory each time the same alert fires, that gap is what a runbook fills.

A business continuity (BC) plan answers how critical services continue while normal people, places or systems are unavailable, while a disaster recovery (DR) plan restores IT systems, data and infrastructure after a disaster; continuity is about the business carrying on, recovery is about getting the technology back.

DR is often described as a subset of, or companion to, BC: a single event such as a destructive malware attack can trigger all three plans at once, each governing different activities: stopping the attacker is incident response, serving customers meanwhile is continuity, and bringing systems back is recovery. Resilience mechanisms such as backup types, recovery sites and recovery objectives belong to objective 3.4, and the incident response process itself to objective 4.7; here you need to know which document governs which activity.

The information security policy is the top-level, leadership-approved document that states the organization's security objectives, assigns responsibility and authority (for example, to the CISO) and commits the organization to protecting its information; every other security policy, standard and procedure derives its authority from it.

It is deliberately high-level: it names no products or settings, so it rarely needs to change when technology does. Because it is the root of the program's authority, it is the first document to create or fix when the program lacks an executive mandate. The subject-specific policies (user conduct, data handling, incident response and the rest) sit beneath it, each governing one area.

The incident response policy establishes the incident response capability: what counts as a security incident, which incidents must be reported and to whom, the response team's membership and authority (for example, whether responders may seize a device or suspend a senior manager's account), and obligations for escalation and external notification. It separates cleanly from the documents beneath it:

A playbook cannot grant itself powers: it assumes the authority the policy has already given.

Three Security+ policies govern how individual users behave: the bring your own device (BYOD) policy sets the conditions for personal devices to access company data, the acceptable use policy (AUP) defines permitted use of company systems, and the clean desk policy keeps sensitive material and credentials out of sight when unattended.

The distinguishing question is ownership and setting: a personal device accessing company data points to BYOD; how people may use company equipment points to the AUP; what is left lying around in the workspace points to clean desk. Policies that mention monitoring or personal information can look alike; ask whether the document governs the behaviour of people using company systems or the handling of data about people the organization collects it from.

Four policies govern data across its life: data classification decides how sensitive each type of data is and how it must be handled, data retention decides how long each type of record is kept, data disposal decides how it is destroyed when it is no longer needed, and the privacy policy decides what personal data is collected and what it may be used for.

Classification usually comes first: until data is labeled, the organization cannot apply sensitivity-appropriate handling, meaningful access rules or the right disposal strength, so a backup set holding both public brochures and payroll files gets a single protection level for everything. Retention and disposal work as a pair: retention sets when data must go, disposal sets how it is made unrecoverable. A retention policy needs an end as well as a start: records held past their required period add breach exposure and legal discovery cost without adding value.

A privacy policy is the reference point for any new use of personal data: if data was gathered for one purpose (such as warranty registration), reusing it for another (such as training an analytics model) must be checked against what the privacy policy states. How long that data may be kept after a customer leaves is still a retention question. Sanitization techniques and destruction certificates are covered in objective 4.2, and privacy legislation and data subject rights in the compliance objective.

The access control policy defines how access to systems and data is requested, approved, granted, reviewed and removed, and the vulnerability disclosure policy (VDP) tells outside researchers how to report security flaws they find, what they may test and what protection they have.

Access control policy

A typical access control policy sets out: least privilege and need-to-know; who must approve access requests (often the data or system owner); how often owners recertify (review and re-approve) existing access; what happens when someone changes role (old permissions removed, new ones requested) or leaves; and requirements for privileged accounts. Contractor accounts that stay active after a contract ends, or privileged rights nobody has reviewed in years, point to a missing or unenforced access control policy. The policy sets the rules; an SOP makes the provisioning and removal steps happen consistently. Sensitivity labels inform access decisions, but the rules for requesting, approving, reviewing and removing access live in the access control policy.

Vulnerability disclosure policy

A VDP gives outside parties a sanctioned path to report flaws. It typically states:

• Scope: which systems may be tested and which may not;
• Rules of engagement: permitted and forbidden testing methods (for example, no denial of service, no accessing other users' data);
• How to report: a contact channel, often advertised in a security.txt file defined by RFC 9116;
• Safe harbor: a commitment not to pursue legal action against researchers who act in good faith and follow the policy;
• What happens next: acknowledgement, coordination and disclosure timelines.

A bug bounty usually sits on top of a VDP; an organization that wants reports but will not pay publishes a VDP. A VDP is also different from an internal vulnerability management policy, which governs how the organization's own teams scan, prioritize and patch weaknesses; the VDP faces outward, to people outside the organization. Bug bounty mechanics as a vulnerability-discovery method belong to objective 4.3.

To pick the right governance artifact, identify what is actually missing (authority, a measurable requirement, consistent steps, advice, a design, or a rule about one subject) and match it to the document whose job is exactly that.

1. Is the problem authority or accountability? Nobody senior approved anything, or nobody is responsible: a policy (the information security policy at the top, or the subject policy, such as incident response, for authority within one area).
2. Is it a requirement that must be measurable and auditable? A standard (baseline, password, encryption, physical security). If the need is the authoritative specification of an internet protocol, that is an RFC. If the requirement only suggests, it is a guideline.
3. Is it inconsistency in how a task is performed? A procedure: an SOP for recurring people-driven processes, a runbook for exact technical actions tied to an alert or task, especially automated ones.
4. Is it advice from outside? A guideline: benchmark for hardening, advisory for one flaw, reference architecture for design before purchase, implementation guide for deploying a chosen product.
5. Is it about surviving a disruption? BC plan for keeping the business running, DR plan for restoring IT.
6. Is it about a specific subject? Match the subject: personal devices (BYOD), use of company systems (AUP), the workspace (clean desk), sensitivity (classification), how long (retention), how destroyed (disposal), who gets access (access control), outside reports (vulnerability disclosure), personal data use (privacy).

Many real problems need two artifacts at once, such as a policy to grant authority plus a standard or SOP to make it concrete. Keep the levels separate: put intent and authority in the policy, the measurable values in the standard, and the steps in the procedure.