Compliance Frameworks

PCI-DSS, HIPAA, GDPR, and Other Regulations

TL;DR

Compliance frameworks establish minimum security and privacy requirements. PCI-DSS applies to credit card processors (encryption, network segmentation). HIPAA applies to healthcare (patient privacy, breach notification). GDPR applies to personal data of EU residents (consent, data portability, right to erasure). SOC 2 applies to service providers handling customer data. Compliance isn't just legal—it aligns with security best practices.

Learning Objectives

• Understand scope and applicability of major frameworks
• Map security controls to compliance requirements
• Assess compliance gaps and remediation
• Implement continuous compliance monitoring
• Document compliance for audits

Compliance Frameworks Overview

PCI-DSS (Payment Card Industry Data Security Standard)

Applies To: Merchants, processors, and service providers handling credit cards

Key Requirements:

1. Install and maintain firewall configuration
2. Do not use vendor-supplied defaults
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems
7. Restrict access by business need-to-know
8. Identify and authenticate access
9. Restrict physical access to cardholder data
10. Track and monitor access
11. Regularly test security systems
12. Maintain information security policy

Current Version: PCI-DSS 4.0 (2024)

HIPAA (Health Insurance Portability and Accountability Act)

Applies To: Healthcare providers, health plans, healthcare clearinghouses

Key Requirements:

• Privacy Rule: Control how PHI (Protected Health Information) is used/disclosed
• Security Rule: Safeguards for electronic PHI (encryption, access controls, audit logs)
• Breach Notification Rule: Notify individuals if PHI is compromised

Technical Safeguards:

• Access controls and authentication
• Audit controls and logging
• Data integrity controls
• Encryption and decryption
• Transmission security

GDPR (General Data Protection Regulation)

Applies To: Organizations processing data of EU residents (even if not in EU)

Key Principles:

• Lawfulness: Legal basis for processing (consent, contract, legal obligation, etc.)
• Purpose Limitation: Data used only for stated purpose
• Data Minimization: Collect only necessary data
• Accuracy: Keep data accurate and up-to-date
• Storage Limitation: Don't keep longer than necessary
• Confidentiality: Protect via encryption, access controls
• Integrity: Prevent unauthorized modification

Rights:

• Right to access (can request all their data)
• Right to rectification (correct inaccurate data)
• Right to erasure (delete their data - "right to be forgotten")
• Right to restrict processing
• Right to data portability (get data in portable format)
• Right to object to processing

Penalties: Up to EUR 20,000,000 or 4% of global revenue (whichever is higher)

SOC 2 (Service Organization Control)

Applies To: Service providers (cloud, SaaS, hosting, etc.)

Trust Service Criteria:

• Security: Systems protected against unauthorized access
• Availability: Systems available for operation and use
• Processing Integrity: Complete, accurate, and timely processing
• Confidentiality: Information protected from disclosure
• Privacy: Personal information collected, used, and retained appropriately

Audit Types:

• Type I: Point-in-time assessment
• Type II: Assessment over minimum 6-month period

ISO 27001/27002

Standard: International standard for information security management

Scope: 14 domains covering organizational, people, and technical controls

Common in: EU, international organizations, regulated industries

Practical Example

Compliance Mapping

Requirement: "Encrypt all cardholder data at rest" (PCI-DSS 3.4)

Controls:
  - Storage encryption (AES-256)
  - Key management (HSM, external KMS)
  - Key rotation (annually)
  - Access controls to decryption keys

Implementation:
  Database:
    Technology: PostgreSQL + pgcrypto
    Encryption: AES-256
    Keys: Stored in AWS KMS
    Rotation: Annual

  Backup:
    Technology: S3 with server-side encryption
    Encryption: AES-256
    Keys: AWS managed keys
    Rotation: Automatic

  Evidence:
    - Documentation of encryption implementation
    - Key management procedures
    - Test of decryption
    - Audit logs of key access

Audit:
  - Annual PCI assessment
  - Validate encryption in place
  - Verify keys not hardcoded
  - Test key rotation process

Compliance vs. Security

Not Synonymous:

• Compliance = Meeting specific regulatory requirements
• Security = Protecting against threats

Overlap:

• Many compliance requirements align with security best practices
• Compliance baseline often less stringent than security needs
• Mature organizations exceed compliance minimums

Risk: Meeting compliance minimums doesn't guarantee security

When to Use / When Not to Use

Compliance Best Practices

1. Understand which frameworks apply to your organization
2. Map controls to requirements explicitly
3. Implement controls as security improvements (not just compliance)
4. Document evidence for audits
5. Regular compliance assessments
6. Continuous monitoring of compliance
7. External audits by qualified assessors
8. Exceed minimums for security advantage

Common Mistakes

1. Implementing only compliance minimums
2. No documentation of control implementation
3. One-time compliance assessment (no monitoring)
4. Compliance team siloed from security team
5. No understanding of specific requirements
6. Compliance theater (looks compliant on surface)
7. No risk assessment beyond compliance
8. Assuming compliance = secure

Design Review Checklist

• Which frameworks apply to your organization?
• Scope clearly documented (data types, systems, geography)?
• Legal review completed?
• Third-party assessments planned?
• Required controls identified?
• Controls mapped to existing security measures?
• Gaps documented and remediation planned?
• Controls implemented with proper documentation?
• Evidence collected for each control?
• Audit logs maintained per requirements?
• Testing of controls documented?
• Remediation of findings tracked?
• Monitoring automated where possible?
• Regular compliance assessments scheduled?
• Changes reviewed for compliance impact?
• Training on compliance requirements?

Compliance Scenarios and Responses

Scenario 1: GDPR Right to Erasure

class GDPRComplianceService:
    def erase_user_data(self, user_id: str):
        """User requests to be forgotten (right to erasure)"""

        # Find all personal data
        user_data = {
            'accounts': self.db.query("SELECT * FROM accounts WHERE user_id = ?", user_id),
            'orders': self.db.query("SELECT * FROM orders WHERE user_id = ?", user_id),
            'emails': self.email_service.get_sent_to_user(user_id),
            'logs': self.audit_log.get_user_activity(user_id),
            'analytics': self.analytics.get_user_events(user_id),
        }

        # Some data must be kept (for legal/tax reasons)
        retention_exceptions = {
            'orders': True,  # Keep for tax records (7 years)
            'payments': True,  # Keep for regulatory (PCI requirement)
            'logs': True,  # Keep for audit (immutable)
        }

        # Erase what we can
        for data_type, records in user_data.items():
            if data_type not in retention_exceptions:
                for record in records:
                    self.db.delete(record)

        # Anonymize what we must keep
        if 'orders' in user_data:
            for order in user_data['orders']:
                # Replace with dummy data
                self.db.update(
                    "UPDATE orders SET customer_name = 'ANONYMIZED' WHERE id = ?",
                    order.id
                )

        # Log the erasure (audit trail)
        self.audit_log.log(
            action='USER_ERASURE_REQUESTED',
            user_id=user_id,
            timestamp=datetime.now(),
            data_erased=list(user_data.keys()),
            exceptions=retention_exceptions
        )

        return {
            'erased_categories': [k for k in user_data if k not in retention_exceptions],
            'retained_for_legal': list(retention_exceptions.keys()),
            'timestamp': datetime.now()
        }

Scenario 2: HIPAA Breach Notification

class HIPAABreachResponse:
    def handle_breach(self, breach_details: Dict):
        """Respond to healthcare data breach (within 60 days)"""

        affected_users = self.identify_affected_patients(breach_details)

        # Notification timeline (HIPAA requirement)
        # - Individual notification: within 60 days
        # - Regulatory: within 60 days if > 500 people
        # - Media: within 60 days if > 500 in same jurisdiction

        for user in affected_users:
            # 1. Send notification letter
            notification = self.breach_notification_service.send(
                user_id=user.id,
                breach_description=breach_details['description'],
                affected_data=breach_details['data_types'],
                mitigation_steps='Offer 2 years of credit monitoring',
                steps_user_should_take='Monitor accounts, credit freeze',
                contact_info='privacy@healthcare.com'
            )

            # 2. Offer credit monitoring (usual mitigation)
            self.credit_monitoring_service.enroll(user.id, years=2)

            # 3. Document notification
            self.breach_log.record(
                user_id=user.id,
                notification_date=datetime.now(),
                notification_method='email',
                status='sent'
            )

        # 3. Regulatory notification
        if len(affected_users) > 500:
            self.hhs.notify_breach(
                covered_entity='Healthcare Org',
                breach_date=breach_details['discovered_date'],
                affected_count=len(affected_users),
                brief_description=breach_details['description'],
                corrective_action=breach_details['remediation']
            )

        # 4. Post-breach investigation
        investigation = self.investigate_breach(
            how_breach_occurred=breach_details['cause'],
            whether_unauthorized_access_occurred=breach_details['accessed'],
            whether_harm_likely=len(affected_users) > 10,  # Threshold
            extent_of_unauthorized_disclosure='SSN, DOB, medical records'
        )

        return {
            'affected_count': len(affected_users),
            'notifications_sent': len(affected_users),
            'regulatory_notification_sent': len(affected_users) > 500,
            'investigation': investigation
        }

Scenario 3: PCI-DSS Quarterly Compliance Scans

PCI-DSS Compliance Schedule:

Monthly:
  - Review access logs (who accessed card data?)
  - Monitor for unusual network activity
  - Check password policies (complexity, rotation)
  - Verify firewall rules unchanged

Quarterly:
  - External vulnerability scan (Qualified Security Assessor)
    * Scan all systems for known vulnerabilities
    * Scan web apps for OWASP Top 10
    * Generate report with findings
  - Internal penetration test (simulate attacker)
  - Review access controls (least privilege)
  - Audit configuration changes

Annually:
  - Full PCI-DSS assessment (SAQ D)
    * Document security posture
    * Map controls to PCI requirements
    * Third-party assessment by Qualified Security Assessor
    * Final certification (valid for 1 year)
  - Network segmentation validation
    * Verify cardholder data isolated
    * Test firewall rules (can't bypass)
  - Disaster recovery drill

Failure Response:
  - Non-compliant finding → 30 days to remediate
  - Critical finding (e.g., unencrypted card data) → immediate action
  - Repeated failures → escalate to payment processor
  - Worst case: Deactivate payment processing, heavy fines

Compliance Maturity Model

Level 1: Chaotic
  - No awareness of compliance requirements
  - No processes, ad-hoc patches
  - Audits are surprises (always fail)
  - Cost: Cheap initially, expensive penalties after breach

Level 2: Aware
  - Compliance requirements documented
  - Basic processes exist (but manual, inconsistent)
  - Annual audits, frequent failures
  - Cost: Medium (audit prep, periodic fixes)

Level 3: Structured
  - Compliance integrated into dev/ops
  - Automated checks in CI/CD
  - Regular assessments, most findings remediated
  - Consistent passing audits
  - Cost: Medium (tooling, training)

Level 4: Optimized
  - Compliance by design (not afterthought)
  - Continuous monitoring, real-time remediation
  - Proactive threat hunting
  - Exceed compliance minimums (real security)
  - Cost: High upfront, medium ongoing, low risk

Building a Compliance Program

1. Understand applicable frameworks (PCI, HIPAA, GDPR, SOC 2, etc.)
2. Document scope (What data? Which systems? What users?)
3. Map controls (What controls satisfy each requirement?)
4. Implement controls (Code, processes, monitoring)
5. Assess compliance (Internal audit, third-party assessment)
6. Remediate gaps (Fix non-compliance findings)
7. Monitor continuously (Don't fall back to non-compliant state)
8. Train teams (Everyone knows requirements, responsibilities)

One Takeaway

Compliance frameworks provide useful baselines for security maturity. Exceed minimums and integrate security and compliance teams to prevent organizational silos and ensure actual security, not just compliance appearance. Compliance is a journey, not a destination.

References

• PCI-DSS Requirements ↗
• HIPAA Security Rule ↗
• GDPR Regulation ↗
• ISO 27001 Standard ↗
• SOC 2 Attestations ↗