Compliance, Frameworks & Regulations
Overview of the most important security frameworks, regulations, and standards you'll encounter in security engineering interviews and on the job. Each section answers: what is it, why it exists, what it requires, and what interviewers ask about it.
NIST Cybersecurity Framework (CSF)
Current versionCSF 2.0 (released February 2024) Published by: NIST (National Institute of Standards and Technology, USA) Mandatory?: No — voluntary for most; effectively required for federal agencies and their contractors
What it is
A risk-based framework for managing cybersecurity risk. Originally aimed at critical infrastructure, now widely adopted across all sectors globally. CSF 2.0 added a new Govern function.
Six Functions (CSF 2.0)
| Function | What it covers |
|---|---|
| Govern (GV) | NEW in 2.0: organizational context, roles, risk management strategy, policies |
| Identify (ID) | Asset management, risk assessment, supply chain risk |
| Protect (PR) | Access control, awareness training, data security, platform security |
| Detect (DE) | Continuous monitoring, anomaly detection, adverse event analysis |
| Respond (RS) | Incident response planning, communication, mitigation |
| Recover (RC) | Recovery planning, improvements, communication after incident |
Why it matters in interviews
- Provides a common vocabulary for discussing security posture
- "How does your security program map to the NIST CSF?" is a common question at senior levels
- Helps frame your incident response/detection answers: "In the Detect phase, we use..."
NIST SP 800-53
Current versionRev 5 (2020) Full name: Security and Privacy Controls for Information Systems and Organizations
What it is
A comprehensive catalog of security and privacy controls. Think of it as an encyclopedia of security requirements — over 1,000 controls across 20 control families.
Key Control Families
| Family | Code | Examples |
|---|---|---|
| Access Control | AC | Least privilege, account management, remote access |
| Audit & Accountability | AU | Audit logging, log retention, review |
| Configuration Management | CM | Baseline config, change control |
| Identification & Authentication | IA | MFA, password complexity, PKI |
| Incident Response | IR | IR plan, testing, handling, reporting |
| System & Communications Protection | SC | TLS, boundary protection, cryptography |
| Supply Chain Risk Management | SR | NEW in Rev 5 — supply chain controls |
Who uses it
- US federal agencies (mandatory)
- Companies seeking FedRAMP authorization (cloud providers)
- Defense contractors (often required)
- Any organization wanting a comprehensive controls baseline
Interview relevance
- Understanding 800-53 shows you know controls-based thinking: "This maps to AC-6 (Least Privilege)" or "IR-4 (Incident Handling) requires this playbook"
- Often referenced in cloud security assessments
NIST SP 800-61 (Incident Response)
Full nameComputer Security Incident Handling Guide (Rev 2)
What it is
The authoritative guide for building an incident response capability. Defines the IR lifecycle:
Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident ActivityKey concepts
- Incident vs event: an event is any observable occurrence; an incident is an event that violates policy or threatens security
- Incident severity categories: functional impact (data integrity, availability), information impact (data classification affected)
- Evidence collection and chain of custody
- Communication: when to involve legal, management, law enforcement, external parties
SOC 2
Published byAICPA (American Institute of CPAs) Mandatory?: No — but de facto required for SaaS companies selling to enterprises
What it is
An auditing standard for service organizations (SaaS companies, cloud providers) that evaluates controls related to the five Trust Service Criteria (TSC):
| Criterion | What it covers |
|---|---|
| Security | Protecting system resources against unauthorized access (required) |
| Availability | System is available for operation as committed |
| Processing Integrity | System processing is complete, valid, accurate, timely |
| Confidentiality | Information designated as confidential is protected |
| Privacy | Personal information is collected, used, retained, and disclosed properly |
Type I vs Type II
point-in-time — "controls are suitably designed as of date X"
period-of-time (usually 6-12 months) — "controls operated effectively over the period" — this is what enterprise customers actually want
Memory hookType I is a photo, Type II is a video. Type I proves your controls look right on one day (designed properly). Type II proves they actually worked over months (operating effectively) — the auditor pulls evidence across the whole period, e.g. "show me every access review for the last 9 months." Mnemonic: I = instant (a snapshot), II = time (a track record). Enterprises want Type II because anyone can pass inspection for a day; Type II shows the controls run continuously. Also remember SOC 2 is a report, not a pass/fail certificate — it's an auditor's attestation against the Trust Service Criteria, of which only Security ("Common Criteria") is mandatory; the other four are opt-in based on what you commit to customers.
Why it matters
A SOC 2 Type II report is what enterprise customers ask for in security questionnaires. Having it means: a third-party auditor verified your security controls work.
Common controls testedaccess reviews, change management, encryption at rest/transit, vulnerability management, incident response, log retention.
ISO 27001
Published byISO (International Organization for Standardization) Mandatory?: No — but required in many EU/UK/global enterprise deals and supply chains
What it is
An international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).
Structure
organizational context, leadership, planning, support, operation, performance evaluation, improvement
93 controls across 4 themes: Organizational, People, Physical, Technological
third-party audit by an accredited certification body → ISO 27001 certificate (valid 3 years, annual surveillance audits)
ISO 27001 vs SOC 2
| ISO 27001 | SOC 2 | |
|---|---|---|
| Scope | ISMS (process + controls) | Controls for specific services |
| Geography | Global (especially EU/UK/Asia) | Primarily US |
| Output | Certificate | Audit report |
| Focus | Management system | Control effectiveness |
Memory hookISO 27001 certifies the factory, SOC 2 inspects the products. ISO 27001 is about having a working management system (an ISMS — the process for how you manage risk continuously), and you get a certificate. SOC 2 is about whether your specific controls actually operate, and you get a report an auditor wrote that customers read. Geography rule of thumb: ISO = the global/EU answer, SOC 2 = the US answer — many companies end up doing both because different customers ask for different ones. Mnemonic: ISO = system + certificate (global); SOC 2 = controls + report (US).
PCI-DSS
Full namePayment Card Industry Data Security Standard Current version: PCI-DSS v4.0 (2022) Mandatory?: Yes — for any organization that stores, processes, or transmits cardholder data
What it is
12 requirements for protecting cardholder data (credit/debit card numbers). Enforced by card brands (Visa, Mastercard) through merchant agreements. Non-compliance → fines, increased transaction fees, loss of ability to accept cards.
12 Requirements (grouped)
Build and maintain a secure network
- Install and maintain network security controls (firewalls)
- Apply secure configurations to all system components
Protect account data3. Protect stored account data (encryption, masking of PAN) 4. Protect cardholder data in transit (TLS, no WEP)
Maintain a vulnerability management program5. Protect against malicious software (AV) 6. Develop and maintain secure systems (patching, secure dev)
Implement strong access control7. Restrict access on need-to-know 8. Identify and authenticate access 9. Restrict physical access
Monitor and test networks10. Log and monitor all access to system components 11. Test security of systems regularly (pen tests, ASV scans)
Maintain an information security policy12. Support information security with organizational policies and programs
Key concepts for interviews
scope of PCI assessment — minimize CDE to reduce compliance burden
replace PANs with tokens; tokens are useless outside the payment processor → reduces CDE scope dramatically
Self-Assessment Questionnaire (smaller merchants) vs Report on Compliance (larger merchants, requires QSA)
customized implementation option (risk-based alternative controls), evolved MFA requirements, new software security requirements
GDPR
Full nameGeneral Data Protection Regulation Jurisdiction: European Union + EEA; applies to any company processing EU residents' data regardless of where the company is located Effective: May 25, 2018 Penalties: Up to €20M or 4% of global annual revenue (whichever higher)
Core Principles
data must be processed lawfully; users must know how their data is used
data collected for one purpose can't be used for a different purpose
collect only what you need
keep data accurate and up to date
don't keep data longer than necessary
protect data appropriately (encryption, access controls)
organizations must demonstrate compliance
Rights of Data Subjects
| Right | Description |
|---|---|
| Right of access | User can request a copy of their data |
| Right to rectification | Correct inaccurate data |
| Right to erasure ("right to be forgotten") | Delete data in certain circumstances |
| Right to portability | Receive data in machine-readable format |
| Right to object | Object to processing for direct marketing |
| Right to restrict processing | Pause processing while dispute is resolved |
Technical Requirements for Engineers
72 hours to notify supervisory authority; "without undue delay" to data subjects if high risk
security controls baked in from the start, not bolted on
required before processing high-risk data
required when sharing data with processors (cloud providers, SaaS tools)
strongly recommended; can reduce obligations in breach scenarios
CCPA
Full nameCalifornia Consumer Privacy Act (+ CPRA amendment, effective 2023) Jurisdiction: California, USA — applies to businesses processing CA residents' data above certain thresholds Comparison to GDPR: narrower rights, lower penalties, more opt-out focused (vs GDPR's opt-in)
Key Rights
- Right to know what personal information is collected
- Right to delete personal information
- Right to opt out of sale or sharing of personal information
- Right to non-discrimination for exercising rights
Technical implication
"Do Not Sell My Personal Information" opt-out mechanism must be implemented in UI and data pipelines.
HIPAA
Full nameHealth Insurance Portability and Accountability Act Jurisdiction: USA — healthcare providers, health plans, healthcare clearinghouses, and their business associates Protected data: Protected Health Information (PHI) — any individually identifiable health information
Key Rules
standards for use/disclosure of PHI
administrative, physical, and technical safeguards for electronic PHI (ePHI)
notify affected individuals within 60 days; HHS if > 500 individuals
Technical Safeguards (Security Rule)
- Unique user identification (no shared accounts)
- Emergency access procedure
- Automatic logoff
- Encryption and decryption of ePHI
- Audit controls (hardware, software, procedural)
FedRAMP
Full nameFederal Risk and Authorization Management Program Jurisdiction: USA — cloud service providers selling to US federal agencies Based on: NIST SP 800-53 Rev 5 controls, tailored for cloud
What it is
A standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services used by federal agencies.
Authorization Levels
| Level | Based on | Example workloads |
|---|---|---|
| Low | 125 controls | Public-facing, no sensitive data |
| Moderate | 325 controls | PII, some sensitive data (most agencies) |
| High | 421 controls | Law enforcement, emergency services, financial |
Getting FedRAMP authorized is expensive (18+ months, $1M+) and is essentially the price of entry for selling to the US federal government.
CIS Benchmarks
Published byCenter for Internet Security What they are: Consensus-based configuration guidelines for operating systems, cloud services, containers, databases, browsers, etc.
Key benchmarks for security engineers:
- CIS Benchmark for Ubuntu Linux
- CIS Benchmark for AWS Foundations
- CIS Benchmark for Kubernetes
- CIS Benchmark for Docker
- CIS Benchmark for macOS
Two implementation levels
recommended minimum security settings that don't significantly impact functionality
defense in depth; may reduce functionality; for high-security environments
Free PDFs available at cisecurity.org. Used as the baseline for many hardening scripts and cloud Security Hub findings.
Framework Comparison Table
| Framework | Type | Mandatory? | Scope | Key output |
|---|---|---|---|---|
| NIST CSF 2.0 | Risk management | Voluntary / fed required | Organization-wide | Risk posture |
| NIST 800-53 | Control catalog | Fed mandatory | Systems/programs | Control baseline |
| NIST 800-61 | IR guidance | Voluntary | IR capability | Playbooks |
| SOC 2 | Audit standard | Voluntary / de facto | Service operations | Audit report |
| ISO 27001 | Management system | Voluntary | ISMS | Certificate |
| PCI-DSS | Industry standard | Mandatory (card data) | Cardholder data env | Compliance report |
| GDPR | Regulation | Mandatory (EU residents) | Personal data | Legal compliance |
| CCPA | Regulation | Mandatory (CA residents) | Personal data | Legal compliance |
| HIPAA | Regulation | Mandatory (health data) | PHI | Legal compliance |
| FedRAMP | Authorization | Mandatory (US federal) | Cloud services | Authorization to Operate |
| CIS Benchmarks | Config guidelines | Voluntary | System configuration | Hardened config |
Interview Questions
Both assess a service organization's controls against the Trust Service Criteria, but over different timeframes. Type I is point-in-time — the auditor attests that the controls are suitably designed as of a specific date, essentially a snapshot. Type II covers a period, usually six to twelve months, and tests that the controls actually operated effectively throughout — the auditor samples evidence across the whole window, like every access review and change record over those months. Enterprises want Type II because designing a control well on one day proves little; Type II shows it runs continuously. I'd also note SOC 2 produces an auditor's report, not a pass/fail certificate, and only the Security criterion is mandatory — availability, confidentiality, processing integrity, and privacy are included based on what you commit to customers.
The headline obligation is the 72-hour notification: if the breach is likely to result in a risk to individuals' rights and freedoms, you must notify the relevant supervisory authority within 72 hours of becoming aware, and if it's a high risk, also notify the affected individuals without undue delay. The notification has to describe the nature of the breach, the categories and approximate number of people and records affected, the likely consequences, and the measures taken. Beyond notification, you must document the breach internally regardless of whether it's reportable, so the clock and the documentation start immediately on detection — which is exactly why incident response and forensics readiness matter. Whether you're the controller or a processor changes who notifies whom: a processor must notify its controller without undue delay, and the controller notifies the authority.
Define the cardholder data environment — identify everywhere card data is stored, processed, or transmitted, and everything connected to it, because PCI scope is all of that plus connected systems. The single most valuable move is to minimize scope: the less of your environment that touches card data, the smaller and cheaper the assessment, so I'd look at whether we can avoid handling card data at all by outsourcing to a compliant payment processor and tokenization, keeping raw PANs out of our systems entirely. Then segment the network so the cardholder data environment is isolated from the rest, which keeps unrelated systems out of scope. So the first step is data-flow mapping to establish scope, immediately followed by scope reduction through outsourcing and segmentation, before assessing controls against the twelve requirements.
They operate at different altitudes. The Cybersecurity Framework is the high-level, voluntary, outcome-oriented model organized around its core functions — Govern, Identify, Protect, Detect, Respond, Recover — and it's meant to be readable by executives and applicable to any organization. NIST 800-53 is the detailed control catalog: hundreds of specific security and privacy controls used for US federal systems and underpinning FedRAMP. So CSF tells you what outcomes to aim for and gives a common language for risk, while 800-53 provides the specific controls you implement to achieve them — CSF even maps its subcategories to 800-53 controls. In short, CSF is the strategic framework, 800-53 is the implementation control set it can reference.
A Data Protection Impact Assessment is a GDPR process for evaluating and mitigating the privacy risks of a processing activity before you start it. It's required when processing is likely to result in a high risk to individuals' rights and freedoms — for example large-scale processing of special-category data, systematic monitoring of public areas, or extensive profiling and automated decision-making with significant effects. The DPIA documents the processing, assesses necessity and proportionality, identifies risks to data subjects, and defines mitigations; if significant residual risk remains, you must consult the supervisory authority before proceeding. Practically it's how privacy-by-design becomes concrete — you do the risk analysis up front rather than after a regulator asks. For an engineer it often means being pulled in to describe data flows and the technical safeguards.
FedRAMP is the standardized authorization for cloud services used by US federal agencies, built on NIST 800-53 controls, with Low, Moderate, and High baselines — Moderate being the common one, covering a few hundred controls. The path: you implement the Moderate control baseline, document everything in a System Security Plan, and engage an accredited third-party assessor, a 3PAO, to independently test the controls and produce a security assessment report. Then you pursue an authorization either through a sponsoring agency that grants an Authority to Operate, or via the FedRAMP program office. After authorization, it's not done — there's continuous monitoring, with ongoing scanning, monthly reporting, and annual assessments. It's a heavy, months-to-over-a-year effort, which is why teams plan for the documentation and continuous-monitoring burden, not just the initial control implementation.