--- question: "What are the four types of security policies?" title: "What Are the Four Types of Security Policies" seoTitle: "4 Types of Security Policies Explained" summary: "The four types of security policies are program (organizational) policy, issue-specific policies, system-specific policies, and the supporting layer of standards, procedures, and guidelines. The taxonomy descends from NIST SP 800-12, which formally defines the first three as policy types; many sources therefore count three types and treat standards, procedures, and guidelines as supporting documents rather than a fourth type. A program policy sets the mandate for the whole security program, issue-specific policies address one topic such as acceptable use or incident response, system-specific policies govern one system such as production access, and standards and procedures translate all of them into enforceable specifics." publishedAt: "2026-08-22" keywords: - "four types of security policies" - "types of information security policies" - "NIST SP 800-12 policy types" - "security policies for SOC 2" pillar: "SOC 2 Policies and Documentation" faqs: - question: "What are the 3 types of security policies?" answer: "The three types are program (organizational) policy, issue-specific policies, and system-specific policies. This is the formal taxonomy from NIST SP 800-12. Sources that count four add standards, procedures, and guidelines as a fourth category, but NIST treats those as supporting documents that implement policy rather than policy itself. Both counts describe the same structure." - question: "Which policies are required for SOC 2?" answer: "SOC 2 does not publish a fixed list, but auditors expect a policy set covering the Trust Services Criteria you are being audited against. In practice that means an overarching information security policy plus issue-specific policies such as access control, acceptable use, incident response, change management, vendor management, data classification, and business continuity. What matters to the auditor is that each policy is versioned, formally approved, and acknowledged by the people it binds." - question: "Who should approve security policies?" answer: "The program policy should be approved at the executive level, typically the CEO or the board, because it assigns authority and budget. Issue-specific policies are usually approved by the executive who owns the risk, such as a CISO or CTO. System-specific policies can be approved by the owner of that system. Approval by someone without authority over the people bound by the policy is a finding auditors do raise." - question: "How do you write a simple security policy?" answer: "State five things, ideally on a single page: the scope (who and what it covers), the rule itself, who owns the policy, how exceptions are requested and approved, and how often it is reviewed. Then have someone with real authority approve it, give it a version number, and collect acknowledgment from the people it binds. Length is not the goal; a one-page policy that was approved and read outperforms a twenty-page document nobody signed." - question: "What is an example of an email policy?" answer: "An email policy is a classic issue-specific policy. A typical one for a SaaS company states that company mail is for business use, lists prohibited content such as sharing credentials or customer data with unauthorized parties, requires suspected phishing to be reported to a named channel, sets a retention period, and restricts auto-forwarding to personal accounts. It is approved by the executive who owns communications or security risk and acknowledged by all staff." - question: "What is a policy management system?" answer: "A policy management system is software that stores policies with version history, routes them through an approval workflow, and tracks acknowledgment, so you can show exactly who approved and who read each version of each document. That record is what an auditor asks for when testing policy controls. Small teams sometimes cover the same ground with a document repository and a spreadsheet, which works until the acknowledgment trail becomes too tedious to maintain by hand." --- ## 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.