What are the four types of security policies?

What are the four types of security policies?

The four types of security policies are program (organizational) policy, issue-specific policies, system-specific policies, and standards, procedures, and guidelines as the supporting layer. The taxonomy comes from NIST SP 800-12, the US National Institute of Standards and Technology's introduction to information security. Program policy establishes the security program itself, issue-specific policies address one topic each, system-specific policies govern one system each, and the supporting layer turns all of them into enforceable specifics.

The four types, with examples

For a SaaS company, each type maps to documents you would recognize.

Type	Scope	Example for a SaaS company	Who approves
Program policy	The entire organization's security program	Information security policy establishing the program, its owner, and its authority	CEO or board
Issue-specific policy	One topic, across the whole company	Acceptable use, access control, incident response, vendor management	CISO, CTO, or equivalent executive
System-specific policy	One system or environment	Production access policy for the main cloud environment	System owner
Standards, procedures, guidelines	Implements the policies above	Password standard (minimum 12 characters, MFA required); offboarding procedure	Policy owner or security team

The layers are hierarchical. The program policy says security is mandatory and names who runs it. An issue-specific policy says all access follows least privilege. A system-specific policy says who may access production and how. A standard says exactly what a compliant password looks like. Reading top to bottom, each layer answers the question the layer above left open.

Three types or four?

Sources disagree on the count, and the disagreement is worth resolving because both numbers appear in training materials and exam guides.

NIST SP 800-12 formally defines three types of policy: program, issue-specific, and system-specific. It discusses standards, procedures, and guidelines separately, as documents that implement policy rather than policy proper. Later textbooks and certification courses folded that supporting layer in as a fourth type because in practice the documents live together and are managed the same way.

So "three types" and "four types" describe the same structure. If an exam or an auditor asks, the distinction that matters is between the three policy layers, which state management's intent, and the supporting layer, which specifies how that intent is carried out. Policies change rarely and need executive approval; standards and procedures change often and should not need a board meeting to update.

What SOC 2 auditors expect from a policy set

SOC 2 does not mandate this taxonomy or any fixed list of documents. What auditors test is whether your policy set covers the Trust Services Criteria in scope and whether the documents are real: versioned, formally approved by someone with the authority to bind the organization, acknowledged by employees, and reviewed at least once every 12 months.

The common failure is not a missing policy type. It is a complete-looking policy set with no operating history behind it: no approval records, no acknowledgment trail, and a last-reviewed date from two years ago. An auditor treats an unapproved policy as no policy, because a document nobody signed binds nobody.

A practical way to build the set is top-down in the NIST order. Write the program policy first, since every other document inherits its authority. Then write issue-specific policies against the criteria your audit covers. Add system-specific policies only where a system genuinely needs rules of its own, and push everything volatile, such as password parameters and tool configurations, down into standards so routine changes never require re-approving a policy.