Opening Framing
Unlike voluntary frameworks, regulations carry legal force. Non-compliance can result in significant fines, legal liability, loss of business licenses, and even criminal penalties. For security professionals, understanding the regulatory landscape is essential—not just to avoid penalties, but to properly advise the business on obligations and to design compliant security programs efficiently.
Regulations vary by industry (healthcare, financial services, retail), by geography (US federal, state, EU, global), and by data type (personal data, payment data, health information). Many organizations face multiple overlapping regulations, requiring careful coordination to meet all requirements without duplicative effort. The regulatory landscape continues to expand, with new privacy laws and cybersecurity requirements emerging regularly.
This week covers major regulatory frameworks including PCI DSS, HIPAA, GDPR, CCPA, and industry-specific requirements. You'll learn to navigate complex regulatory environments and build compliance programs that satisfy multiple requirements.
Key insight: Understand the "why" behind regulations—it helps you implement controls that satisfy the intent, not just the letter.
1) Regulatory Landscape Overview
Understanding how regulations are structured helps navigate the compliance landscape:
Regulatory Framework:
TYPES OF REGULATIONS:
┌─────────────────────────────────────────────────────────────┐
│ Industry-Specific Regulations: │
│ - PCI DSS (payment cards) │
│ - HIPAA (healthcare) │
│ - GLBA (financial services) │
│ - FERPA (education) │
│ - NERC CIP (energy/utilities) │
│ │
│ Data Protection/Privacy Regulations: │
│ - GDPR (EU) │
│ - CCPA/CPRA (California) │
│ - LGPD (Brazil) │
│ - PIPEDA (Canada) │
│ - Various US state privacy laws │
│ │
│ Cybersecurity Regulations: │
│ - NY DFS Cybersecurity (financial services in NY) │
│ - CMMC (US defense contractors) │
│ - NIS2 Directive (EU critical infrastructure) │
│ - SEC Cybersecurity Rules (public companies) │
│ │
│ Government/Contract Requirements: │
│ - FedRAMP (US federal cloud) │
│ - FISMA (US federal systems) │
│ - StateRAMP (US state government) │
└─────────────────────────────────────────────────────────────┘
DETERMINING APPLICABILITY:
┌─────────────────────────────────────────────────────────────┐
│ Key Questions: │
│ │
│ What data do you handle? │
│ - Payment card data → PCI DSS │
│ - Protected health information → HIPAA │
│ - Personal data of EU residents → GDPR │
│ - Personal data of CA residents → CCPA │
│ │
│ What industry are you in? │
│ - Healthcare → HIPAA │
│ - Financial services → GLBA, SOX, state regulations │
│ - Education → FERPA │
│ - Energy → NERC CIP │
│ │
│ Where do you operate? │
│ - EU presence → GDPR │
│ - New York financial → NY DFS │
│ - California customers → CCPA │
│ │
│ Who are your customers? │
│ - US Federal government → FedRAMP, FISMA │
│ - Defense contractors → CMMC │
│ - Public companies → SEC requirements │
└─────────────────────────────────────────────────────────────┘
REGULATORY ENFORCEMENT:
┌─────────────────────────────────────────────────────────────┐
│ Regulation │ Enforcer │ Max Penalties │
├─────────────┼───────────────────────┼───────────────────────┤
│ PCI DSS │ Card brands (indirect)│ $100K/month + lose │
│ │ │ ability to process │
├─────────────┼───────────────────────┼───────────────────────┤
│ HIPAA │ HHS OCR │ $1.5M/year per │
│ │ │ violation category │
├─────────────┼───────────────────────┼───────────────────────┤
│ GDPR │ Data Protection │ €20M or 4% global │
│ │ Authorities │ revenue │
├─────────────┼───────────────────────┼───────────────────────┤
│ CCPA │ CA Attorney General │ $7,500 per intentional│
│ │ │ violation │
├─────────────┼───────────────────────┼───────────────────────┤
│ GLBA │ FTC, OCC, others │ $100K per violation │
├─────────────┼───────────────────────┼───────────────────────┤
│ SOX │ SEC │ Criminal penalties, │
│ │ │ up to 20 years prison │
└─────────────┴───────────────────────┴───────────────────────┘
Key insight: Start by understanding what data you have and where it flows—that determines which regulations apply.
2) PCI DSS
PCI DSS applies to any organization that stores, processes, or transmits payment card data:
PCI DSS Overview:
WHAT IS PCI DSS:
┌─────────────────────────────────────────────────────────────┐
│ - Payment Card Industry Data Security Standard │
│ - Developed by PCI Security Standards Council │
│ - Founded by Visa, Mastercard, Amex, Discover, JCB │
│ - Currently version 4.0 (mandatory March 2025) │
│ - Applies to anyone handling cardholder data │
│ │
│ Cardholder Data (CHD): │
│ - Primary Account Number (PAN) │
│ - Cardholder name │
│ - Expiration date │
│ - Service code │
│ │
│ Sensitive Authentication Data (SAD): │
│ - Full track data (never store after authorization) │
│ - CVV/CVC (never store after authorization) │
│ - PIN/PIN block (never store after authorization) │
└─────────────────────────────────────────────────────────────┘
PCI DSS REQUIREMENTS (12 Requirements, 6 Goals):
┌─────────────────────────────────────────────────────────────┐
│ Goal 1: Build and Maintain a Secure Network │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 1: Install and maintain network security controls │ │
│ │ Req 2: Apply secure configurations to all components │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Goal 2: Protect Account Data │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 3: Protect stored account data │ │
│ │ Req 4: Protect cardholder data during transmission │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Goal 3: Maintain a Vulnerability Management Program │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 5: Protect systems from malicious software │ │
│ │ Req 6: Develop and maintain secure systems/software │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Goal 4: Implement Strong Access Control │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 7: Restrict access by business need to know │ │
│ │ Req 8: Identify users and authenticate access │ │
│ │ Req 9: Restrict physical access to cardholder data │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Goal 5: Regularly Monitor and Test Networks │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 10: Log and monitor access to system components │ │
│ │ Req 11: Test security of systems and networks regularly │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ Goal 6: Maintain an Information Security Policy │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Req 12: Support information security with policies │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
PCI DSS Compliance Levels:
PCI DSS Validation Levels:
MERCHANT LEVELS (Visa definitions):
┌─────────────────────────────────────────────────────────────┐
│ Level 1: >6 million transactions/year │
│ - Annual on-site assessment by QSA (Qualified Security │
│ Assessor) │
│ - Quarterly network scan by ASV (Approved Scanning Vendor) │
│ - Report on Compliance (ROC) │
│ - Attestation of Compliance (AOC) │
│ │
│ Level 2: 1-6 million transactions/year │
│ - Annual Self-Assessment Questionnaire (SAQ) │
│ - Quarterly ASV scan │
│ - AOC │
│ - May require on-site assessment per acquirer │
│ │
│ Level 3: 20,000-1 million e-commerce transactions/year │
│ - Annual SAQ │
│ - Quarterly ASV scan │
│ - AOC │
│ │
│ Level 4: <20,000 e-commerce or <1 million total/year │
│ - Annual SAQ │
│ - Quarterly ASV scan (if applicable) │
│ - AOC │
│ - Requirements may vary by acquirer │
└─────────────────────────────────────────────────────────────┘
SELF-ASSESSMENT QUESTIONNAIRES (SAQs):
┌─────────────────────────────────────────────────────────────┐
│ SAQ A: Card-not-present, fully outsourced (22 questions) │
│ - No electronic cardholder data storage/processing │
│ - All payment processing outsourced to PCI-compliant third │
│ party │
│ - Example: E-commerce using hosted payment page │
│ │
│ SAQ A-EP: E-commerce, partial outsource (191 questions) │
│ - Website that redirects to third-party payment page │
│ - Website could impact transaction security │
│ │
│ SAQ B: Imprint or standalone terminal (41 questions) │
│ - Imprint machines only, or │
│ - Standalone dial-out terminals (no internet) │
│ │
│ SAQ C: Payment application systems (160 questions) │
│ - Payment application connected to internet │
│ - No electronic cardholder data storage │
│ │
│ SAQ C-VT: Virtual terminals (79 questions) │
│ - Web-based virtual terminal only │
│ - No electronic cardholder data storage │
│ │
│ SAQ D: All others (329 questions - full requirements) │
│ - Any environment not fitting above categories │
│ - Most comprehensive assessment │
└─────────────────────────────────────────────────────────────┘
SCOPE REDUCTION STRATEGIES:
┌─────────────────────────────────────────────────────────────┐
│ 1. Tokenization │
│ - Replace PAN with non-sensitive token │
│ - Token has no value if stolen │
│ - Reduces systems in scope │
│ │
│ 2. Point-to-Point Encryption (P2PE) │
│ - Encrypt at point of interaction │
│ - Data never decrypted in your environment │
│ - Significant scope reduction │
│ │
│ 3. Network Segmentation │
│ - Isolate cardholder data environment │
│ - Reduce number of systems in scope │
│ - Must be validated by QSA │
│ │
│ 4. Outsourcing │
│ - Use PCI-compliant service providers │
│ - Payment processors, hosting providers │
│ - Still responsible for vendor management │
└─────────────────────────────────────────────────────────────┘
Key insight: Reduce scope first—don't store card data you don't need, and use tokenization/P2PE to minimize what's in scope.
3) HIPAA
HIPAA protects health information and applies broadly to healthcare and related organizations:
HIPAA Overview:
WHAT IS HIPAA:
┌─────────────────────────────────────────────────────────────┐
│ Health Insurance Portability and Accountability Act (1996) │
│ - US federal law │
│ - Protects Protected Health Information (PHI) │
│ - Enforced by HHS Office for Civil Rights (OCR) │
│ │
│ PHI = Individually identifiable health information: │
│ - Health condition (past, present, future) │
│ - Healthcare services provided │
│ - Payment for healthcare │
│ - Plus identifiers (name, SSN, DOB, address, etc.) │
│ │
│ ePHI = PHI in electronic form │
└─────────────────────────────────────────────────────────────┘
WHO MUST COMPLY:
┌─────────────────────────────────────────────────────────────┐
│ Covered Entities: │
│ - Healthcare providers (doctors, hospitals, clinics) │
│ - Health plans (insurers, HMOs, Medicare) │
│ - Healthcare clearinghouses │
│ │
│ Business Associates: │
│ - Anyone who creates, receives, maintains, or transmits │
│ PHI on behalf of a covered entity │
│ - Examples: cloud providers, billing services, consultants, │
│ lawyers, IT support │
│ │
│ Business Associate Agreements (BAAs): │
│ - Required contract between covered entity and BA │
│ - Specifies permitted uses of PHI │
│ - Requires BA to implement safeguards │
│ - No BAA = violation for both parties │
└─────────────────────────────────────────────────────────────┘
HIPAA RULES:
┌─────────────────────────────────────────────────────────────┐
│ Privacy Rule: │
│ - Protects all PHI (paper, electronic, oral) │
│ - Limits use and disclosure of PHI │
│ - Patient rights (access, amendment, accounting) │
│ - Minimum necessary standard │
│ - Notice of Privacy Practices │
│ │
│ Security Rule: │
│ - Applies specifically to ePHI │
│ - Administrative safeguards │
│ - Physical safeguards │
│ - Technical safeguards │
│ - Requires risk analysis │
│ │
│ Breach Notification Rule: │
│ - Notify affected individuals within 60 days │
│ - Notify HHS (timing depends on breach size) │
│ - Notify media if breach affects 500+ in a state │
│ - Document all breaches │
│ │
│ Enforcement Rule: │
│ - Investigation procedures │
│ - Penalty structure │
│ - Compliance reviews │
└─────────────────────────────────────────────────────────────┘
HIPAA Security Rule Requirements:
HIPAA Security Rule Safeguards:
ADMINISTRATIVE SAFEGUARDS (§164.308):
┌─────────────────────────────────────────────────────────────┐
│ Security Management Process (Required): │
│ - Risk analysis (Required) │
│ - Risk management (Required) │
│ - Sanction policy (Required) │
│ - Information system activity review (Required) │
│ │
│ Assigned Security Responsibility (Required): │
│ - Designate security official │
│ │
│ Workforce Security (Addressable): │
│ - Authorization/supervision │
│ - Workforce clearance │
│ - Termination procedures │
│ │
│ Information Access Management (Required): │
│ - Access authorization │
│ - Access establishment/modification │
│ │
│ Security Awareness Training (Addressable): │
│ - Security reminders │
│ - Malicious software protection │
│ - Log-in monitoring │
│ - Password management │
│ │
│ Security Incident Procedures (Required): │
│ - Response and reporting │
│ │
│ Contingency Plan (Required): │
│ - Data backup (Required) │
│ - Disaster recovery (Required) │
│ - Emergency mode operations (Required) │
│ - Testing and revision (Addressable) │
│ - Applications and data criticality (Addressable) │
│ │
│ Evaluation (Required): │
│ - Periodic technical and non-technical evaluation │
│ │
│ Business Associate Contracts (Required if applicable): │
│ - Written contracts/arrangements │
└─────────────────────────────────────────────────────────────┘
PHYSICAL SAFEGUARDS (§164.310):
┌─────────────────────────────────────────────────────────────┐
│ Facility Access Controls (Addressable): │
│ - Contingency operations │
│ - Facility security plan │
│ - Access control and validation │
│ - Maintenance records │
│ │
│ Workstation Use (Required): │
│ - Proper use of workstations │
│ │
│ Workstation Security (Required): │
│ - Physical safeguards for workstations │
│ │
│ Device and Media Controls (Required): │
│ - Disposal (Required) │
│ - Media re-use (Required) │
│ - Accountability (Addressable) │
│ - Data backup and storage (Addressable) │
└─────────────────────────────────────────────────────────────┘
TECHNICAL SAFEGUARDS (§164.312):
┌─────────────────────────────────────────────────────────────┐
│ Access Control (Required): │
│ - Unique user identification (Required) │
│ - Emergency access procedure (Required) │
│ - Automatic logoff (Addressable) │
│ - Encryption and decryption (Addressable) │
│ │
│ Audit Controls (Required): │
│ - Hardware, software, procedural mechanisms │
│ │
│ Integrity (Addressable): │
│ - Mechanism to authenticate ePHI │
│ │
│ Person or Entity Authentication (Required): │
│ - Verify identity of person/entity seeking access │
│ │
│ Transmission Security (Addressable): │
│ - Integrity controls │
│ - Encryption │
└─────────────────────────────────────────────────────────────┘
Note: "Addressable" doesn't mean optional—it means you must
implement or document why an alternative is appropriate
Key insight: HIPAA requires a documented risk analysis as the foundation—everything else flows from understanding your risks.
4) GDPR
GDPR is the EU's comprehensive data protection regulation with global reach:
GDPR Overview:
WHAT IS GDPR:
┌─────────────────────────────────────────────────────────────┐
│ General Data Protection Regulation (EU 2016/679) │
│ - Effective May 25, 2018 │
│ - Applies to personal data of EU residents │
│ - Extraterritorial scope (applies outside EU) │
│ - Significant fines (up to 4% global revenue) │
│ │
│ Personal Data = Any information relating to identified or │
│ identifiable natural person ("data subject") │
│ │
│ Special Categories (sensitive data): │
│ - Racial/ethnic origin │
│ - Political opinions │
│ - Religious/philosophical beliefs │
│ - Trade union membership │
│ - Genetic/biometric data │
│ - Health data │
│ - Sex life/sexual orientation │
└─────────────────────────────────────────────────────────────┘
WHEN GDPR APPLIES:
┌─────────────────────────────────────────────────────────────┐
│ Establishment Test: │
│ - Organization established in EU │
│ - Processing in context of EU establishment activities │
│ │
│ Targeting Test (even if not established in EU): │
│ - Offering goods/services to EU residents │
│ (even if free) │
│ - Monitoring behavior of EU residents │
│ │
│ Examples of when GDPR applies: │
│ - US company selling to EU customers │
│ - US company with EU employees │
│ - US company tracking EU website visitors │
│ - US company processing data for EU client │
└─────────────────────────────────────────────────────────────┘
KEY PRINCIPLES (Article 5):
┌─────────────────────────────────────────────────────────────┐
│ 1. Lawfulness, Fairness, Transparency │
│ - Legal basis for processing │
│ - Fair to data subjects │
│ - Clear about what you're doing │
│ │
│ 2. Purpose Limitation │
│ - Collect for specified, explicit, legitimate purposes │
│ - Don't use for incompatible purposes later │
│ │
│ 3. Data Minimization │
│ - Only collect what's necessary │
│ - Adequate, relevant, limited to purpose │
│ │
│ 4. Accuracy │
│ - Keep data accurate and up to date │
│ - Erase or rectify inaccurate data │
│ │
│ 5. Storage Limitation │
│ - Don't keep longer than necessary │
│ - Define retention periods │
│ │
│ 6. Integrity and Confidentiality │
│ - Appropriate security measures │
│ - Protect against unauthorized processing │
│ - Protect against accidental loss │
│ │
│ 7. Accountability │
│ - Controller responsible for compliance │
│ - Must be able to demonstrate compliance │
└─────────────────────────────────────────────────────────────┘
GDPR Requirements:
GDPR Key Requirements:
LEGAL BASES FOR PROCESSING (Article 6):
┌─────────────────────────────────────────────────────────────┐
│ Must have at least one: │
│ │
│ 1. Consent │
│ - Freely given, specific, informed, unambiguous │
│ - Can be withdrawn at any time │
│ │
│ 2. Contract │
│ - Necessary for contract with data subject │
│ - Or pre-contractual steps at their request │
│ │
│ 3. Legal Obligation │
│ - Required by law │
│ │
│ 4. Vital Interests │
│ - Protect someone's life │
│ │
│ 5. Public Task │
│ - Public interest or official authority │
│ │
│ 6. Legitimate Interests │
│ - Legitimate interest of controller or third party │
│ - Balanced against data subject's rights │
│ - Not available to public authorities │
└─────────────────────────────────────────────────────────────┘
DATA SUBJECT RIGHTS:
┌─────────────────────────────────────────────────────────────┐
│ Right to be Informed (Articles 13-14) │
│ - Privacy notice at collection │
│ - Information about processing │
│ │
│ Right of Access (Article 15) │
│ - Confirm if data is being processed │
│ - Copy of personal data │
│ - Information about processing │
│ │
│ Right to Rectification (Article 16) │
│ - Correct inaccurate data │
│ - Complete incomplete data │
│ │
│ Right to Erasure/"Right to be Forgotten" (Article 17) │
│ - Delete data in certain circumstances │
│ - Not absolute—exceptions apply │
│ │
│ Right to Restrict Processing (Article 18) │
│ - Limit processing in certain circumstances │
│ │
│ Right to Data Portability (Article 20) │
│ - Receive data in structured, machine-readable format │
│ - Transmit to another controller │
│ │
│ Right to Object (Article 21) │
│ - Object to processing for direct marketing (absolute) │
│ - Object to processing based on legitimate interests │
│ │
│ Rights Related to Automated Decision-Making (Article 22) │
│ - Not be subject to purely automated decisions │
│ - Including profiling with legal/significant effects │
└─────────────────────────────────────────────────────────────┘
SECURITY REQUIREMENTS (Article 32):
┌─────────────────────────────────────────────────────────────┐
│ Appropriate technical and organizational measures: │
│ │
│ - Pseudonymization and encryption │
│ - Confidentiality, integrity, availability, resilience │
│ - Ability to restore availability after incident │
│ - Process for regular testing and evaluation │
│ │
│ Consider: │
│ - State of the art │
│ - Cost of implementation │
│ - Nature, scope, context, purpose of processing │
│ - Risk to rights and freedoms │
└─────────────────────────────────────────────────────────────┘
BREACH NOTIFICATION (Articles 33-34):
┌─────────────────────────────────────────────────────────────┐
│ To Supervisory Authority (Article 33): │
│ - Within 72 hours of becoming aware │
│ - Unless unlikely to result in risk to rights/freedoms │
│ - Include: nature, categories, numbers, likely consequences,│
│ measures taken │
│ │
│ To Data Subjects (Article 34): │
│ - When high risk to rights and freedoms │
│ - Without undue delay │
│ - Clear and plain language │
│ - Not required if: encryption makes data unintelligible, │
│ measures eliminate risk, disproportionate effort │
└─────────────────────────────────────────────────────────────┘
DATA PROTECTION OFFICER (Articles 37-39):
┌─────────────────────────────────────────────────────────────┐
│ Required when: │
│ - Public authority or body │
│ - Core activities require regular, systematic monitoring │
│ of data subjects on large scale │
│ - Core activities involve large-scale processing of │
│ special categories or criminal data │
│ │
│ DPO responsibilities: │
│ - Inform and advise on obligations │
│ - Monitor compliance │
│ - Advise on DPIAs │
│ - Cooperate with supervisory authority │
│ - Contact point for supervisory authority │
└─────────────────────────────────────────────────────────────┘
Key insight: GDPR is about demonstrating accountability— you must be able to prove compliance, not just claim it.
5) US Privacy Laws and Other Regulations
The US privacy landscape is fragmented with multiple state and sector-specific laws:
US Privacy Landscape:
CCPA/CPRA (California):
┌─────────────────────────────────────────────────────────────┐
│ California Consumer Privacy Act (2020) + California Privacy │
│ Rights Act amendments (2023) │
│ │
│ Applies to businesses that: │
│ - Have $25M+ annual gross revenue, OR │
│ - Buy/sell/share 100,000+ consumers' data, OR │
│ - Derive 50%+ revenue from selling/sharing data │
│ AND do business in California or handle CA residents' data │
│ │
│ Consumer Rights: │
│ - Know what personal info is collected │
│ - Know if personal info is sold/shared │
│ - Say no to sale/sharing │
│ - Access personal information │
│ - Request deletion │
│ - Correct inaccurate information (CPRA) │
│ - Limit use of sensitive personal information (CPRA) │
│ - Non-discrimination for exercising rights │
│ │
│ Key Requirements: │
│ - Privacy policy disclosures │
│ - "Do Not Sell/Share My Personal Information" link │
│ - Honor opt-out requests │
│ - Respond to consumer requests within 45 days │
│ - Reasonable security measures │
└─────────────────────────────────────────────────────────────┘
OTHER US STATE PRIVACY LAWS:
┌─────────────────────────────────────────────────────────────┐
│ Virginia (VCDPA) - Effective 2023 │
│ Colorado (CPA) - Effective 2023 │
│ Connecticut (CTDPA) - Effective 2023 │
│ Utah (UCPA) - Effective 2023 │
│ Iowa (ICDPA) - Effective 2025 │
│ Indiana (INPA) - Effective 2026 │
│ Tennessee (TIPA) - Effective 2025 │
│ Montana (MTCPA) - Effective 2024 │
│ Texas (TDPSA) - Effective 2024 │
│ Oregon (OCPA) - Effective 2024 │
│ Delaware (DPDPA) - Effective 2025 │
│ ...more states passing laws regularly │
│ │
│ Common themes: │
│ - Consumer rights (access, delete, correct) │
│ - Opt-out of sale/targeted advertising │
│ - Privacy notice requirements │
│ - Data protection assessments for high-risk processing │
│ │
│ Key differences: │
│ - Applicability thresholds vary │
│ - Private right of action (varies) │
│ - Cure periods (varies) │
│ - Sensitive data definitions │
└─────────────────────────────────────────────────────────────┘
GLBA (Financial Services):
┌─────────────────────────────────────────────────────────────┐
│ Gramm-Leach-Bliley Act │
│ │
│ Applies to: Financial institutions (broadly defined) │
│ - Banks, credit unions, securities firms │
│ - Insurance companies │
│ - Financial advisors, tax preparers │
│ - Certain retailers that offer credit │
│ │
│ Key Rules: │
│ - Financial Privacy Rule: Notice requirements │
│ - Safeguards Rule: Security program required │
│ (recently updated with specific requirements) │
│ - Pretexting Protection: Prohibit fraudulent access │
│ │
│ Updated Safeguards Rule (2023) requires: │
│ - Designated qualified individual │
│ - Written risk assessment │
│ - Access controls │
│ - Encryption │
│ - MFA for accessing customer info │
│ - Secure development practices │
│ - Vendor oversight │
│ - Annual penetration testing │
│ - Incident response plan │
│ - Board reporting │
└─────────────────────────────────────────────────────────────┘
MANAGING MULTI-REGULATORY COMPLIANCE:
┌─────────────────────────────────────────────────────────────┐
│ Strategy: Unified Control Framework │
│ │
│ 1. Inventory all applicable regulations │
│ 2. Map requirements to common controls │
│ 3. Implement to highest standard │
│ 4. Document once, satisfy multiple requirements │
│ 5. Track regulatory changes │
│ │
│ Example Mapping: │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Control: Encryption at Rest │ │
│ │ - PCI DSS 3.5.1: Protect stored cardholder data │ │
│ │ - HIPAA 164.312(a)(2)(iv): Encryption (addressable) │ │
│ │ - GDPR Article 32: Pseudonymization and encryption │ │
│ │ - CCPA 1798.150: Reasonable security │ │
│ │ │ │
│ │ Implementation: AES-256 encryption for all sensitive │ │
│ │ data at rest satisfies all four requirements │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Key insight: The US privacy landscape is complex and growing. Design for the strictest requirements and you'll likely satisfy most.
Real-World Context
Case Study: GDPR Enforcement - British Airways
In 2018, British Airways suffered a data breach affecting approximately 500,000 customers. Attackers compromised the website and mobile app, skimming payment card details and personal information. The UK Information Commissioner's Office (ICO) initially proposed a £183 million fine (reduced to £20 million due to COVID-19 economic impact). Key findings: BA failed to implement appropriate security measures including MFA, limiting access, and testing. The case demonstrated that GDPR enforcement is real and that "appropriate security" is judged against what was reasonably available, not just what was convenient.
Case Study: HIPAA Breach - Anthem
In 2015, Anthem Inc. discovered a breach affecting nearly 79 million individuals—one of the largest healthcare breaches in history. Attackers used spear-phishing to gain credentials and accessed a database containing names, dates of birth, Social Security numbers, and healthcare IDs. HHS OCR settled with Anthem for $16 million—the largest HIPAA settlement at the time. Contributing factors included failure to implement enterprise-wide risk analysis, inadequate access controls, and insufficient monitoring. The case highlighted that HIPAA's risk analysis requirement is foundational—without understanding your risks, you can't implement appropriate safeguards.
Regulatory Compliance Quick Reference:
Regulatory Compliance Checklist:
GENERAL APPROACH:
□ Inventory all applicable regulations
□ Identify what data triggers each regulation
□ Map requirements across regulations
□ Implement unified control framework
□ Monitor regulatory changes
PCI DSS:
□ Determine merchant level
□ Define cardholder data environment
□ Implement scope reduction (tokenization, P2PE)
□ Segment network appropriately
□ Complete appropriate SAQ or engage QSA
□ Quarterly ASV scans
□ Annual validation
HIPAA:
□ Identify if covered entity or business associate
□ Execute BAAs with all business associates
□ Conduct documented risk analysis
□ Implement Security Rule safeguards
□ Train workforce
□ Establish breach notification procedures
□ Annual evaluation
GDPR:
□ Determine if GDPR applies (establishment or targeting)
□ Identify legal basis for each processing activity
□ Create/update privacy notices
□ Implement data subject rights processes
□ Conduct DPIAs for high-risk processing
□ Appoint DPO if required
□ Document processing activities (Article 30)
□ Implement appropriate security (Article 32)
□ Establish breach notification procedures
US PRIVACY LAWS:
□ Determine which state laws apply
□ Update privacy policy
□ Implement consumer rights processes
□ Provide opt-out mechanisms
□ Implement reasonable security
Regulatory compliance is ongoing, not one-time. Regulations change, and your compliance posture must evolve.
Metrics Deep Dive: Compliance Evidence
Compliance programs need measurable evidence to prove control effectiveness and exception management.
Compliance Metrics:
- Control coverage rate by regulation
- Open audit findings by severity
- Mean time to close compliance gaps
- Exception count and average age
- DPIA completion rate for high-risk processing
- % of vendors with current compliance attestations
Reporting Guidance:
Track evidence freshness and exception aging. Old
exceptions are a leading indicator of compliance risk.
Guided Lab: Regulatory Mapping
In this lab, you'll analyze regulatory requirements and create a unified compliance approach.
Lab Scenario:
- Healthcare technology company
- Cloud-based patient portal
- Processes credit cards for co-pays
- EU customers (expanding market)
- California-based with nationwide customers
Exercise Steps:
- Identify all applicable regulations
- Document data types and flows
- Map overlapping requirements
- Identify gaps in current controls
- Create unified control framework
- Develop compliance roadmap
- Design evidence collection approach
Reflection Questions:
- How did you handle conflicting requirements?
- What controls satisfy multiple regulations?
- How would you prioritize compliance efforts?
Week Outcome Check
By the end of this week, you should be able to:
- Determine which regulations apply to an organization
- Explain PCI DSS requirements and compliance levels
- Describe HIPAA rules and safeguard requirements
- Apply GDPR principles and understand data subject rights
- Navigate the US state privacy law landscape
- Map requirements across multiple regulations
- Create unified compliance frameworks
- Develop multi-regulation compliance strategies
🎯 Hands-On Labs (Free & Essential)
Navigate complex regulatory requirements with practical compliance implementation exercises.
💳 PCI DSS Compliance Lab
What you'll do: Implement PCI DSS requirements—scope cardholder data
environment, apply controls, prepare for QSA assessment.
Why it matters: PCI DSS is mandatory for any organization handling payment
cards.
Time estimate: 3-4 hours
🏥 HIPAA Compliance Exercise
What you'll do: Apply HIPAA Security Rule—conduct risk analysis, implement
safeguards, document policies and procedures.
Why it matters: HIPAA protects healthcare information—violations carry
severe penalties.
Time estimate: 2-3 hours
🌍 GDPR Privacy Compliance
What you'll do: Implement GDPR requirements—conduct data mapping, establish
lawful basis, implement privacy rights processes.
Why it matters: GDPR applies extraterritorially—any EU data requires
compliance.
Time estimate: 3-4 hours
📊 Compliance Metrics Scorecard
What you'll do: Build a compliance metrics scorecard with evidence freshness,
exceptions, and audit closure rates.
Why it matters: Leadership needs concise compliance signals, not raw
findings.
Time estimate: 1-2 hours
💡 Lab Strategy: Map requirements across regulations—many controls satisfy multiple regulations simultaneously.
Resources
Lab
Complete the following lab exercises to practice regulatory compliance concepts.