Policies, standards, procedures and guidelines

A security program speaks through its documents. Policies state what leadership requires; standards make those requirements specific; procedures tell people how to carry them out; guidelines offer advice. Sub-domain 1.6 of the CISSP outline asks you to develop, document and implement security policy, standards, procedures and guidelines. Getting the hierarchy right matters: documents that are too vague cannot be enforced, and documents that are too detailed at the wrong level become obsolete the moment technology changes.

The document hierarchy

Policies are high-level statements of management intent, approved by senior leadership. They are mandatory, they say what must be achieved and why, and they change rarely. An information security policy might state that information must be classified and protected according to its sensitivity, and that access must follow least privilege.

Standards are mandatory requirements that support policies by specifying uniform technologies, settings or methods. They say what specifically must be done. A password standard might require multi-factor authentication for all remote access and a minimum passphrase length; an encryption standard might name approved algorithms and key lengths. Standards change more often than policies, as technology evolves.

Baselines are a kind of standard that defines a minimum level of security for a type of system, often as a configuration checklist. Examples include the Center for Internet Security (CIS) Benchmarks and government configuration baselines. A baseline lets an organization say 'every Windows server must meet this configuration' and test against it automatically.

Procedures are mandatory step-by-step instructions for performing a task in a way that complies with policies and standards: how to create a user account, how to handle a lost laptop report, how to restore from backup. They are detailed and change whenever the underlying process or tool changes.

Guidelines are recommendations and best-practice advice. They are not mandatory; they help people make good decisions where flexibility is appropriate, such as guidance on choosing memorable passphrases or on securing a home office.

Types of policy

Policies themselves come in levels. An organizational or program policy, sometimes called the master security policy, establishes the security program, assigns responsibilities, states management's commitment and defines how compliance is enforced. Issue-specific policies address particular topics such as acceptable use, email, remote work, bring your own device, social media or artificial intelligence tools. System-specific policies set rules for a particular system or application, such as who may approve changes to the payroll system and which security settings it must have.

Policies can also be classified by purpose. Regulatory policies ensure compliance with laws and regulations; advisory policies describe expected behavior and the consequences of non-compliance; informative policies educate about a topic without being enforceable. Acceptable use policies are a good example of an advisory policy that every user signs or acknowledges.

What a good policy contains

Most organizations use a consistent template so that policies are easy to read and audit. Typical sections include:

• Purpose: why the policy exists and what risk it addresses.
• Scope: who and what the policy covers, including contractors and third parties if relevant.
• Policy statements: the requirements themselves, written clearly and concisely.
• Roles and responsibilities: who owns the policy, who implements it and who must follow it.
• Compliance and exceptions: how compliance is measured, how exceptions are requested and approved, and consequences of violations.
• References and definitions: related standards, procedures and laws, and key terms.
• Document control: version, approval date, owner and next review date.

Policies should be technology-neutral where possible. A policy that requires 'multi-factor authentication for remote access' will survive several product changes; one that names a specific vendor will not. Put the technical detail in standards and procedures, which are easier to update.

Developing and approving documents

Good policies are developed with the people who must follow them. A typical process starts with identifying the need, often from a risk assessment, a new law or an audit finding. The security team drafts the policy with input from legal, privacy, human resources, IT and the affected business units. Stakeholders review it for feasibility and clarity. Senior management or the governance committee approves it, which gives it authority. Then the organization communicates it, trains people, implements supporting standards and procedures, and monitors compliance.

Every document needs an owner and a review cycle. Policies are commonly reviewed at least annually and whenever significant changes occur, such as a reorganization, a major incident, a new regulation or a new technology. Standards and procedures should be reviewed whenever the underlying technology or process changes. Version control and a central, searchable repository help people find the current version and help auditors see the history.

Exceptions and enforcement

No policy fits every situation. A legacy system may be unable to support modern encryption; a research team may need administrative rights for specialized software. A formal exception process allows the organization to accept such deviations knowingly. An exception request should state the requirement, the reason it cannot be met, the risk, any compensating controls, the risk owner who accepts it and an expiry date. Exceptions should be reviewed regularly, not granted forever.

Enforcement must be consistent. If senior leaders ignore a policy without consequences, staff will too. Organizations use technical enforcement where possible, such as configuration management that blocks non-compliant settings, and monitoring and audits elsewhere. Consequences for violations should be stated in the policy and applied fairly, usually through human resources processes.

Making policies work in practice

Policies succeed when people understand them and can follow them. Write in plain language, keep documents short, explain the reasons behind rules, and make the right behavior the easy behavior. A clean-desk policy works better when people have lockable drawers; a password policy works better with a password manager provided. Awareness training (Lesson 12) and onboarding are the main channels for communicating policy, and attestation, in which people confirm they have read and understood key policies, creates a record of acknowledgment.

In the United States, federal agencies follow requirements from FISMA, OMB circulars such as A-130 and NIST publications, and must document policies for each SP 800-53 control family (the '-1' control in each family, such as AC-1 for access control, requires policy and procedures). Private organizations often align their policy sets with ISO 27001, the NIST CSF or sector rules such as the GLBA Safeguards Rule, which requires a written information security program.

A sample policy set

Organizations differ, but many security policy sets include a similar core. A master information security policy establishes the program, roles and enforcement. Beneath it, issue-specific policies cover acceptable use, data classification and handling, access control, password and authentication, encryption, remote work and mobile devices, email and internet use, incident response, business continuity, vendor management, change management, logging and monitoring, physical security and, increasingly, the use of artificial intelligence tools. Each issue-specific policy is supported by standards and procedures owned by the teams that operate the controls.

Smaller organizations should resist the temptation to copy a large template set wholesale. Twenty policies that no one reads protect less than six clear ones that people follow. A practical approach is to start with the policies required by law, contracts and the most significant risks, write them in plain language, and add more as the program matures. Each new policy should answer a real need identified by risk assessment, an obligation or an incident.

Measuring policy effectiveness

Policies should be measured like any other control. Useful indicators include the percentage of staff who have acknowledged key policies, the number of open exceptions and how many are past their expiry date, audit findings related to policy non-compliance, the share of systems compliant with configuration baselines, and the time taken to update policies after a relevant change in law or technology. A rising number of exceptions in one area often signals that a standard is unrealistic and needs revision, or that a business need has changed. Treating policy as a living part of the program, rather than a binder on a shelf, keeps it aligned with how the organization actually works.

Policy work also connects directly to the rest of Domain 1. Governance (Lesson 2) gives policies their authority; legal and regulatory requirements (Lessons 4 to 6) supply many of their contents; risk assessment (Lesson 11) decides which risks they must address; and awareness programs (Lesson 12) make sure people know and follow them. A policy that cannot be traced to a risk, an obligation or a management decision should be questioned, and a significant risk with no supporting policy is a gap. Keeping that traceability visible, for example by linking each policy to the risks and requirements it addresses in the governance, risk and compliance tool, makes reviews faster and helps auditors understand why each document exists.

Done well, the policy framework becomes the shared rulebook that lets a whole organization act consistently, even when the security team is not in the room.