Security Policy, Standards and Compliance

• Distinguish policy, standard, guideline, procedure and control
• Map common frameworks (NIST CSF, ISO 27001, SOC 2) to controls
• Explain evidence-based compliance and its ongoing nature

• Customers, regulators and enterprise buyers ask for certification; 'we have NIST 800-53-aligned controls with SOC 2 report' is a sales answer.
• Policies create the enforcement basis: controls, reviews and incident-response authority all trace to policy.
• Incident response runs smoother when roles, thresholds and reporting are policy-before-the-event.
• Evidence-based compliance protects the org and the engineers: documented decisions are defensible.

The health code is the framework you must meet. Standard operating recipes make it concrete. The inspector doesn't trust 'trust me' — she checks thermometers and the temperature log. Same shape: policies, standards, and the logs that prove you followed them.

• Leadership approves policy (intent). Teams convert to standards/procedures. Controls implement, and evidence (logs, reviews, access lists) documents the implementation.
• A selected framework (NIST CSF, ISO 27001, SOC 2 Type II) defines control sets; a gap assessment finds what's missing.
• Controls are implemented with engineering (MFA, logging, backups) + process (reviews, plans).
• An auditor tests design (is the control present?) and operating effectiveness (evidence over a period).
• Continuous compliance: controls drift; monitoring (configuration scanning, access reviews) catches that before the audit window.

• A SaaS pursuing SOC 2 implements the 'access control' family: MFA, least privilege, quarterly access reviews, and evidence exported from its IdP and cloud audit logs.
• A fintech being PCI DSS-scoped never stores PANs — the scope boundary is drawn so the control surface stays small.
• A company maps NIST CSF PR.IP (info protection) to encryption standards, then automates config drift checks to keep evidence green.

• Start with the business: choose frameworks/regulations customers actually demand.
• Encode controls in automation (config-as-policy, IaC scanning) so evidence is continuous, not annual.
• Keep evidence suck-able: logs, reviews and access lists in one place an auditor can query.
• Treat exceptions as tracked risks with owners and dates, not silent 'we do it differently'.

• Writing policies nobody reads and controls nobody runs — audit theater.
• Re-scoping for compliance rather than security: 'we avoid scope' can mean 'we avoid controls'.
• Certifying once and letting drift win the next 11 months.
• Policies too vague to enforce or too specific to maintain (no owners, no review dates).

• An audit finding usually means missing evidence, not missing control — create the evidence trail first.
• When 'compliance OK' meets 'incident happened', the gap is usually operating effectiveness, not design.
• Map each control to its evidence source; if no source exists, the control is documentary.

• GDPR/CCPA are directly enforceable with fines; engineering must build data lifecycle controls (right-to-delete, retention).
• Compliance frameworks are a floor, not a ceiling — an audited company can still be breached; keep security beyond the minimum.