4.2. Policies, Procedures, and Metrics

💡 First Principle: A policy that describes exactly how to configure a firewall will be obsolete the next time that firewall vendor changes its interface — policy has to state what is required and why, leaving how to lower-governance documents that can keep pace with technical change.

⚠️ Common Misconception: Security policies are often expected to be highly technical and detailed. Policy should state what is required and why — mandatory, high-level, and board-endorsed — while standards and procedures, which change far more often, carry the technical how-to detail.

This distinction matters operationally, not just semantically. An organization that rewrites its top-level, board-endorsed policy every time a tool or vendor interface changes is spending scarce governance approval cycles on details that never needed that level of oversight in the first place. Separating the rarely-changing "what and why" from the frequently-changing "how" is what lets a program stay both properly governed and technically current at the same time — and it's exactly this separation that program metrics, covered next, depend on to measure whether the policy layer is actually working in practice.