Security Policies and Procedures: Governance Hierarchy and Risk
Hierarchy of governance documents
Questions reward knowing which document does what:
- Policy - leadership's high-level, mandatory statement of intent ("access is granted on least privilege"). Rarely changes.
- Standard - mandatory, specific, measurable requirement supporting a policy (AES-256 for data at rest).
- Procedure - step-by-step instructions for a task (how to onboard a user).
- Guideline - recommended but not mandatory.
- Baseline - minimum configuration applied uniformly to a system type.
Named policies to recognize: Acceptable Use (AUP), BYOD, data classification and handling, retention, authentication/password, remote access, incident response, business continuity/disaster recovery, and third-party risk.
Risk vocabulary: asset, threat, vulnerability, likelihood, impact, risk appetite/tolerance, and the four treatments - mitigate, transfer (insurance), avoid, accept. Residual risk is what remains after controls.
Due care vs due diligence: due diligence is the ongoing investigation and verification; due care is acting reasonably on what you learned. Questions swap them.
Data classification (public, internal, confidential, restricted) drives handling, encryption, and retention; labeling enforces it.
Change management requires request, risk/impact assessment, approval, testing, scheduled implementation, rollback plan, and documentation. Emergency changes still get reviewed afterward.
Awareness vs training: awareness is broad and periodic (phishing simulations, posters); training builds role-specific skill.
Worked example: an analyst adds a new log source to the SIEM. That follows the existing logging standard and goes through change management for an approval record - it is not a new policy, and the procedure only describes the steps.
Rule of thumb: "how" = procedure, "what must be true" = standard, "we shall" = policy.