Two documents on a company intranet both talk about passwords. One says "Passwords used as the only sign-in factor must be at least 15 characters." The other says "Consider a passphrase of four or more random words." An auditor can write a finding against the first and not the second, and that difference is what this lesson is about.
On the CompTIA Security+ SY0-801 exam this sits under objective 5.1, which expects you to explain why governance documents matter to a security program. This lesson places standards, procedures and guidelines beneath policy, covers the specific kinds the objective lists, from baselines and RFCs to runbooks and reference architectures, shows all four document types written for one topic, and teaches you to identify a document from its wording.
Each document type answers a different question beneath the policy
Policies, covered in the previous lesson, state what the organization requires and why. The documents beneath them make that intent usable:
| Document | Answers | Mandatory? | Typical wording | Usually approved by |
|---|---|---|---|---|
| Policy | What and why | Yes | "must", broad intent | Senior leadership |
| Standard | Exactly what, how much | Yes | "must" plus a value, version or product | CISO or security team |
| Procedure | How, step by step | Yes, when doing the task | Numbered steps, commands | Process or system owner |
| Guideline | What's recommended | No | "should", "consider" | Subject matter experts |
Each layer takes its authority from the one above. A standard that can't be traced to a policy has no mandate behind it, and a procedure that contradicts a standard is wrong even if it works. Guidelines come last because they bind no one; they help people make good choices where the rules leave room for judgment.
The layers also change at different speeds. A policy might go years without a meaningful edit. A standard changes when technology or threats change, such as when an old protocol version is retired. A procedure changes whenever the tool or the process does. Splitting documents this way means a new firewall product forces a rewrite of a few procedures, not a trip back to the board.
Standards turn a policy into mandatory, measurable requirements
A standard states the specific, mandatory requirements that satisfy a policy. Its defining feature is that compliance can be tested: a system either meets it or it doesn't. Standards can be written internally or adopted from outside bodies such as NIST, ISO, the PCI Security Standards Council or the IETF. The objective names five kinds.
Password standards set rules for length, composition, reuse, lockout and changes. A standard that follows current NIST guidance in SP 800-63B might require at least 15 characters for a password used as the only factor and 8 when it's paired with MFA, screen new passwords against lists of breached ones, and drop forced periodic changes while requiring a change whenever there is evidence of compromise. Password management in practice is covered in the identity and access management section.
Encryption standards name approved algorithms, key lengths and protocol versions, for example:
- Data at rest: AES-256.
- Data in transit: TLS 1.2 minimum, TLS 1.3 preferred; SSL and TLS 1.0 and 1.1 disabled.
- Keys: RSA 2048-bit minimum, 3072-bit for long-lived keys, or ECC P-256 and above.
- Hashing: SHA-256 or stronger; MD5 and SHA-1 not permitted for security purposes.
Physical security standards make facility rules specific: server rooms open with a badge plus a PIN, visitors are signed in, badged and escorted, cameras cover every entrance with footage kept for 90 days, and a data center door held open longer than 30 seconds raises an alarm.
A baseline is a standard for the configuration of one type of system, such as Windows 11 workstations or RHEL 9 web servers. It lists every required setting, and every system of that type is built to it and scanned against it. How baselines are built and enforced is covered in the hardening section.
The fifth kind, the RFC, comes from outside the organization entirely.