High-level management directives that set security expectations and requirements.
A policy is a high-level management directive that sets security expectations and intent. It sits at the top of the document hierarchy: policy says what and why, standards say how strictly (mandatory specifics), procedures give step-by-step instructions, and guidelines offer advisory recommendations. Policies are approved by leadership, give the program its authority, and are reviewed at least annually.
Step-by-step instructions for performing a specific task in a repeatable way.
A procedure is the step-by-step, repeatable instruction for carrying out a task — the operational “how” beneath a policy and its standards. Procedures are mandatory (unlike advisory guidelines), which is a favorite exam distinction. Well-written procedures deliver consistency under pressure, accelerate onboarding and training, and provide the evidence auditors look for that a control is actually performed the same way every time.
Mandatory rules that implement a policy — e.g., minimum password length, approved cipher suites.
A standard is a mandatory rule that translates broad policy intent into specific, measurable requirements — minimum password length, approved cipher suites, required baseline configurations. Standards are what make a policy auditable: “protect data in transit” (policy) becomes “TLS 1.2 or higher with approved ciphers” (standard). Because they’re mandatory, deviations require a formal exception, unlike advisory guidelines.
Recommended, non-mandatory practices that help implement policy.
In the policy hierarchy, a guideline is the only advisory tier — recommended practice that helps people implement policy, but where deviation is not itself a violation. That makes guidelines useful for emerging or fast-changing areas where a firm standard would be premature or quickly outdated. Contrast with standards and procedures, which are mandatory.
A structured set of controls and processes used to organize a security program.
A framework is a structured catalog of controls and processes that organizes a security program so teams don’t start from a blank page. Common choices serve different purposes: NIST CSF for risk-based program structure, NIST SP 800-53 for a deep control catalog, ISO 27001 for a certifiable ISMS, and CIS Controls for a prioritized quick-start. Beyond structure, a shared framework gives auditors and leadership a common vocabulary.
The U.S. National Institute of Standards and Technology — publishes widely used security frameworks.
NIST publishes the most widely adopted U.S. security guidance. The Cybersecurity Framework (CSF) organizes a program around its six functions — Govern, Identify, Protect, Detect, Respond, Recover (Govern was added in CSF 2.0). Key Special Publications include SP 800-53 (control catalog), 800-61 (incident handling), and 800-207 (zero-trust architecture); though U.S.-origin, they’re referenced globally.
The International Organization for Standardization — publishes ISO/IEC 27001, the global ISMS standard.
ISO/IEC 27001 is the international standard for an Information Security Management System (ISMS) — a risk-based, process-driven program rather than a fixed checklist. 27001 contains the certifiable requirements; its companion 27002 is the detailed control catalog you draw from. Certification is granted by an accredited external auditor and maintained on a roughly three-year cycle with annual surveillance audits.
PCI DSS — security requirements for organizations that store, process, or transmit cardholder data.
PCI DSS is a contractual standard (not a law) imposed by the card brands on anyone who stores, processes, or transmits cardholder data. Merchant levels 1–4 scale validation rigor by annual transaction volume — level 1 requires an on-site assessment, lower levels a self-assessment questionnaire. The cheapest path to compliance is scope reduction: tokenization and network segmentation keep card data out of most systems, shrinking what must be assessed.
EU General Data Protection Regulation — privacy rights for EU data subjects with global reach.
GDPR grants EU data subjects rights over their personal data — access, rectification, erasure (“right to be forgotten”), and portability — and requires a lawful basis to process it. It applies extraterritorially to any organization handling EU residents’ data, regardless of where the org is based. Teeth come from a 72-hour breach-notification requirement and fines up to the greater of €20M or 4% of global annual revenue.
U.S. law requiring privacy and security safeguards for protected health information.
HIPAA protects U.S. health information (PHI) through several rules: the Privacy Rule governs use and disclosure, the Security Rule mandates administrative, physical, and technical safeguards for electronic PHI, and the Breach Notification Rule sets disclosure obligations. Business Associate Agreements (BAAs) extend these duties down the chain to any vendor — cloud host, billing service — that touches PHI on a covered entity’s behalf.
Sarbanes-Oxley Act — U.S. law requiring internal controls over financial reporting for public companies.
Sarbanes-Oxley (SOX) requires U.S. public companies to maintain and attest to internal controls over financial reporting, enacted after the Enron/WorldCom scandals. The security-relevant work is IT General Controls (ITGCs) — access management, change management, and operations — because they protect the integrity of the systems that produce financial statements. Annual external-auditor testing of these controls backs management’s required attestation.
Independent review of controls against a standard or framework to assess effectiveness.
An audit is an independent review of controls against a standard or framework, and independence is what gives it credibility. Internal audits drive improvement and self-correction; external audits drive attestation and certification (SOC 2, ISO 27001). Audits test both design effectiveness (is the control well-conceived?) and operating effectiveness (did it actually work over the period?).