Security Policy vs Standard vs Procedure: What CISM Candidates Must Know

Why This Distinction Matters for CISM

Information Security Governance is the first and heaviest-weighted domain on the CISM exam, and the policy/standard/procedure/guideline hierarchy is one of its foundational concepts. ISACA does not usually ask you to define these terms directly. Instead, it describes a scenario, a document, or a management decision, and asks you to identify which governance artifact is being described, or which one is missing, outdated, or being misused.

Getting this wrong has real consequences beyond the exam. Organizations that blur the line between policies and procedures end up with either toothless policies nobody can enforce, or 40-page "policies" that have to be rewritten every time a tool changes. Understanding the hierarchy is both an exam requirement and a practical governance skill.

Security Policy: The "What" and "Why"

A security policy is a formal, high-level statement of management's intent. It answers why the organization does something and establishes what must happen, without specifying how. Policies are approved by senior management or the board, rarely change (often reviewed annually rather than monthly), and apply broadly across the organization.

Key characteristics of a policy:

• Mandatory. Policies are not optional; violating one is a compliance or disciplinary matter.
• Technology-agnostic. A good policy should still make sense in ten years, regardless of what tools the organization uses.
• Approved at the top. Policies typically require sign-off from the CISO, executive leadership, or the board, often through a security governance committee.
• Brief. Most well-written policies run two to five pages. If a policy document is 40 pages long, it is almost certainly mixing in standards and procedures that belong elsewhere.

Example policy statement: "The organization will classify all information assets and apply protective controls commensurate with their classification and the risk of unauthorized disclosure, modification, or loss." Notice it says nothing about which encryption algorithm, which classification tool, or which labels to use. That specificity belongs at a lower level.

Standard: The Mandatory "How Much"

A standard translates policy intent into specific, measurable, mandatory requirements. Standards answer how much or to what level something must be done. Like policies, standards are mandatory, but they are more granular, more technical, and reviewed more frequently, since they often reference specific technologies or configurations.

Key characteristics of a standard:

• Mandatory and measurable. A standard should be auditable: you can check compliance against it objectively (encrypted or not, patched within 30 days or not).
• Narrower scope than a policy. A single policy might be supported by five or six standards, each covering a different technical domain.
• Reviewed more often. As technology and threats evolve, standards typically get revisited annually or whenever a significant platform change occurs.

Example standard supporting the classification policy above: "Information classified as Confidential must be encrypted at rest using AES-256 or stronger, and encrypted in transit using TLS 1.2 or higher." This is specific enough to audit, but it still does not tell an engineer which menu to click.

Procedure: The Step-by-Step "How"

A procedure is a detailed, sequential set of instructions for carrying out a specific task in a way that satisfies one or more standards. Procedures answer how, exactly. They are written for the person doing the work, not for an executive or an auditor, and they are the document type most likely to need frequent updates as tools and platforms change.

Key characteristics of a procedure:

• Mandatory for the specific task it covers. If a procedure exists for patching production servers, operations staff must follow it, not improvise.
• Operationally specific. Procedures often reference exact tool names, menu paths, command syntax, or ticketing workflows.
• Owned by operational teams. Unlike policies, procedures are typically written and maintained by the team that executes them, with security providing oversight rather than authorship.
• The most frequently revised document type. A procedure written for an on-premises database will need rewriting the day the organization migrates to a cloud-managed instance; the standard it satisfies usually will not need to change at all.

Example procedure supporting the encryption standard above: a numbered, step-by-step document describing exactly how to enable transparent data encryption on the organization's specific database platform, including which service account to use, how to rotate the key, and how to validate the configuration afterward.

Guideline: The Optional Advice

A guideline is the one document type in this hierarchy that is not mandatory. Guidelines offer recommended practices, suggestions, or decision-making frameworks for situations where a single rigid rule would not fit every case. They exist to support judgment, not replace it.

Example guideline: "When selecting a password manager for personal use, employees are encouraged to choose a product that supports multi-factor authentication and has not had a publicly disclosed breach in the past two years." Nobody is disciplined for ignoring this advice, but following it reduces risk.

How the Four Levels Relate

These four document types form a pyramid, narrowing in scope and increasing in operational detail as you move down. Each lower level exists to implement the level above it, and none of them should duplicate content that belongs at another level.

A useful mental model: the policy is the constitution, the standard is the law, the procedure is the regulation that tells an inspector exactly what to check, and the guideline is the advice column nobody is obligated to read. For more on where these documents sit within the broader governance structure, see our guide to CISM Domain 1: Information Security Governance.

A Real Example, End to End

It helps to trace a single requirement through all four levels, since exam scenarios often test exactly this chain.

1. Policy: "The organization will protect the confidentiality, integrity, and availability of customer data in accordance with applicable regulatory requirements."
2. Standard: "All systems storing or processing customer payment data must be segmented from the general corporate network and must comply with the current PCI DSS requirements for that environment."
3. Procedure: "To onboard a new system into the cardholder data environment: submit a change request in ServiceNow, complete the network segmentation checklist, obtain sign-off from the security architecture team, and schedule a vulnerability scan before go-live."
4. Guideline: "When designing new payment workflows, teams are encouraged to minimize the number of systems that touch raw cardholder data, even where full PCI scope reduction is not strictly required."

Notice how the policy never mentions PCI DSS by name, the standard does, the procedure never restates the "why," and the guideline offers advice that goes beyond the mandatory minimum. Each layer does one job. This same pattern applies directly to the work covered in our data classification scheme guide, where classification policy, labeling standards, and handling procedures each sit at a different level of this same hierarchy.

Common Mistakes on the CISM Exam (and in Real Governance Programs)

1. Treating Standards as Policies

A common distractor on the exam describes a highly specific, technical, mandatory requirement and offers "policy" as an answer choice. If the statement specifies a technology, a numeric threshold, or a configuration detail, it is a standard, not a policy, even if the document in question is literally titled "Policy" in a specific organization. ISACA tests the functional definition, not the label on the cover page.

2. Confusing Mandatory Procedures with Optional Guidelines

Just because a procedure gives flexibility in sequencing or tooling does not make it a guideline. A procedure can allow some discretion in execution while still being mandatory in outcome. The determining factor is whether deviation is a violation subject to consequences, not whether every step is rigidly prescribed.

3. Writing Procedures Into Policy Documents

In practice, this is the most common governance failure CISM candidates will encounter on the job. Organizations write detailed technical steps directly into policy documents, which then require board-level re-approval every time a tool changes. The fix is always the same: move the technical detail down into a standard or procedure, and keep the policy limited to intent.

4. Forgetting Who Owns Each Document

Exam scenarios sometimes test ownership and approval authority rather than content. Policies are approved by senior management, often through the body described in our security governance committee guide. Procedures are typically owned and maintained by the operational team performing the work, with security providing review, not authorship.

Building This Hierarchy in Practice

For a CISM holder running or advising a security program, the practical value of this hierarchy is version control and change management discipline. A well-run program keeps these documents in separate repositories or document classes with separate review cadences:

• Policies go through formal governance committee review and board or executive sign-off, and are versioned conservatively.
• Standards are reviewed by security architecture or engineering leadership, typically annually, and whenever a major platform changes.
• Procedures are owned by the teams executing them and updated continuously as tools and processes evolve, with security auditing for continued alignment to the standards they support.
• Guidelines are published and updated more informally, since they carry no compliance weight.

This separation also matters for audits and risk assessments: when a risk appetite shifts (see our risk appetite statement guide), it is usually the standards that need to move first, since they encode the measurable thresholds that translate appetite into enforceable requirements, while the policy's broad intent typically remains unchanged.

Frequently Asked Questions

What is the difference between a security policy and a security standard?

A policy states management's intent at a high level and rarely changes. A standard sets a specific, mandatory, measurable requirement that implements that intent, such as a required encryption algorithm or minimum password length, and is reviewed more frequently as technology evolves.

Is a procedure mandatory or optional?

Mandatory. A procedure describes the required steps to carry out a task in a way that satisfies an organization's standards. The only document type in this hierarchy that is optional is the guideline.

Why does CISM test policy vs standard vs procedure so heavily?

Because the entire structure of a security governance program depends on getting this right. Confusing the levels leads to policies that are too rigid, procedures that lack authority, or governance documents that cannot be audited consistently. ISACA treats this as foundational knowledge for Domain 1 and references it implicitly throughout the other three domains.

Can a guideline ever become mandatory?

Yes, but only by being promoted. If an organization decides a recommended practice should now be required, it needs to be rewritten and formally issued as a standard or procedure, with the appropriate approval and enforcement mechanism attached. Simply treating a guideline as mandatory in practice, without reclassifying it, creates an enforcement gap that auditors will flag.

Who approves security policies versus who approves procedures?

Policies require sign-off from senior management, the CISO, or the board, often via a governance committee, because they represent organizational commitment. Procedures are typically approved and maintained at the operational or team level, since they describe task execution rather than organizational intent, though security often retains review authority to confirm alignment with the standards above them.

What happens if a standard conflicts with the policy it supports?

The policy wins, since standards exist solely to implement policy intent. In practice, a conflict usually signals that the standard was written without re-checking the policy, or that the policy is outdated relative to current risk. Either way, governance teams should treat the conflict as a document review trigger rather than simply picking one to follow.

Related Guides