Policies, Procedures, and Guidelines

The document hierarchy

CISM treats security documentation as a strict hierarchy, and the exam relies on you knowing which document does what and who approves it. From top to bottom:

The single most tested distinction: a policy is mandatory but high-level and technology-agnostic, expressing management's intent and risk appetite; it must be approved by senior management to carry authority and changes rarely. A standard makes the policy specific and measurable. A procedure explains how to do it. A guideline is optional. If a question asks which document states that something must happen (intent), it is the policy; which states how to do it, the procedure; which is recommended, the guideline.

Why senior-management approval matters

A policy without senior-management sponsorship is unenforceable and is a frequent wrong-state in scenarios. ISACA's view is that the board or executive management owns and approves the policy, giving the ISM the authority to enforce it. If a scenario shows the security team drafting and approving its own policy with no executive sign-off, the correct fix is to obtain senior-management approval and sponsorship — not to add technical controls.

Enforcement, exceptions, and review

Documents are only effective if they are enforced and maintained. A complete policy framework includes:

• Enforcement and consequences. Tie violations to HR and disciplinary processes; an unenforced policy is a paper control.
• A formal exception process. When a business unit cannot meet a standard, it requests a documented, risk-assessed, time-bound exception approved by the risk owner — never an informal verbal waiver.
• Periodic review. Review policies on a schedule (commonly annually) and after major changes — new regulation, reorganization, or significant incident — so they stay current.
• Awareness and acknowledgment. Users must be trained and must acknowledge the policy; otherwise enforcement is unfair and weak.

How the documents fit together in practice

The hierarchy is meant to flow downward without gaps. A single acceptable use policy says "company information must be protected according to its classification" (intent). A supporting standard says "Confidential data at rest is encrypted with AES-256" (specific, measurable). A baseline says "servers are hardened to the CIS Benchmark" (minimum config). A procedure says "to encrypt a new database, do steps 1–7" (how-to). A guideline says "consider classifying ambiguous data at the higher level when unsure" (advice).

The exam exploits the seams: if a control objective exists in policy but no standard or procedure operationalizes it, the program has a documentation gap, and the fix is to write the missing lower-tier document, not to rewrite the policy.

Avoiding policy sprawl and overlap

A mature framework keeps the policy set small and durable while allowing standards and procedures to change with technology. Too many overlapping or contradictory policies is itself a finding — staff cannot follow rules they cannot find or that conflict. CISM favors a concise, consistent set with clear ownership, version control, and effective dates over volume. Each document should name its owner, approval authority, review cadence, and the population it applies to. When two documents conflict, the higher tier (policy) wins, and the conflict is escalated to be resolved rather than left for users to interpret.

Worked scenario and traps

Scenario: auditors find that staff routinely bypass a security standard with informal manager permission. The CISM-correct response is to implement a formal, risk-assessed exception process owned by the risk owner, not to delete the standard or punish individuals first. Another common trap presents a brand-new technology-specific rule and asks where it belongs; if it dictates a mandatory configuration it is a standard or baseline, not a policy — policies stay technology-agnostic so they survive technology changes and do not need board re-approval every time a product is swapped.

A further trap shows a policy that has not been reviewed in five years; the correct action is to trigger the scheduled review and update it for current regulation and risk, because a stale policy quietly loses authority. Finally, remember that writing more documents does not improve security unless they are approved by the right authority, communicated, acknowledged, enforced, and reviewed; the management lifecycle around the document matters as much as its content.

Communication, awareness, and measuring compliance

A document only changes behavior if people know it exists. The ISM pairs every significant policy with awareness training and a recorded acknowledgment, so the workforce understands the rule and the enterprise can demonstrate due diligence if a violation occurs. Tailor delivery to the audience — concise reminders for general staff, deeper standards training for administrators handling Restricted data. The program should also measure policy compliance: rates of acknowledgment, exception volume and aging, and audit findings tied to specific documents reveal whether a policy is working or quietly ignored.

A high exception rate against one standard is a signal that the standard may be unrealistic and should be revisited, not that enforcement should simply intensify. By closing the loop from authoring through communication, enforcement, measurement, and review, the policy framework becomes a living governance instrument that translates senior management's intent into consistent, demonstrable behavior across the enterprise — which is precisely what the exam means when it calls policies the foundation of the security program.