Compliance and Regulatory Requirements¶

← Back to Security Overview

Introduction¶

Regulatory compliance is not optional - it's a legal and business requirement that affects every aspect of software development. Non-compliance can result in significant financial penalties, legal action, reputation damage, and loss of business opportunities. Understanding and implementing compliance requirements from the development phase prevents costly remediation and ensures sustainable business operations.

Section Contents¶

This comprehensive section covers regulatory compliance across three major areas:

Understanding Regulatory Landscape and Standards¶

Navigate the complex world of data protection and industry-specific regulations:

• GDPR Implementation - European Union data protection compliance
• PCI-DSS Compliance - Payment card industry security standards
• HIPAA Requirements - Healthcare data protection
• SOX Controls - Financial reporting system controls
• ISO 27001 ISMS - Information security management
• NIST Cybersecurity Framework - Comprehensive risk management
• African Regional Compliance - Kenya DPA, POPIA, NDPA, and more

Secure Development and Deployment¶

Integrate security and compliance throughout the software development lifecycle:

• Secure SDLC - Security in every development phase
• DevSecOps Integration - Automation and continuous security
• Compliance as Code - Executable compliance requirements
• Audit Trails - Evidence generation and management

Security Scanning and Vulnerability Management¶

Implement comprehensive security testing and vulnerability remediation:

• SAST - Static application security testing
• DAST - Dynamic application security testing
• SCA - Software composition analysis
• Container Security - Image and infrastructure scanning
• Vulnerability Management - Lifecycle and remediation workflows

Core Compliance Principles¶

Quick Navigation by Regulation¶

Compliance Maturity Model¶

Assess your organization's compliance maturity level:

Compliance Implementation Roadmap¶

Phase 1: Assessment¶

Phase 2: Planning¶

Phase 3: Implementation¶

Phase 4: Validation¶

Phase 5: Optimization (Ongoing)¶

Compliance Cost Considerations¶

Budget planning for compliance initiatives:

Key Performance Indicators (KPIs)¶

Track compliance effectiveness with these metrics:

Governance Metrics¶

• Policy review completion rate: Target: 100%
• Training completion rate: Target: >95%
• Audit findings closure rate: Target: 100% within SLA
• Risk assessment currency: Target: <6 months old

Technical Metrics¶

• Security patching SLA compliance: Target: >95%
• Vulnerability remediation time: Target: Within defined SLAs
• Encryption coverage: Target: 100% for sensitive data
• Access review completion: Target: Quarterly

Operational Metrics¶

• Incident response time: Target: <4 hours for critical
• Data subject request fulfillment: Target: <30 days
• Backup success rate: Target: 100%
• System uptime: Target: >99.9%

Common Compliance Pitfalls¶

Getting Started Checklist¶

Use this checklist to begin your compliance journey:

Discovery

• Identify applicable regulations based on industry and geography
• Document current data processing activities
• Identify sensitive data locations and flows
• Assess current security controls

Planning

• Appoint compliance officer or DPO (if required)
• Conduct gap analysis against requirements
• Prioritize compliance initiatives by risk and impact
• Create implementation roadmap with timelines

Quick Wins

• Update privacy policies and notices
• Implement basic access controls and logging
• Establish incident response procedures
• Begin workforce training program

Long-term Implementation

• Deploy technical security controls
• Implement comprehensive audit systems
• Establish ongoing monitoring and reporting
• Prepare for external audits or assessments

Resources and Support¶

Internal Contacts¶

• Compliance Team: Martin or Lewis
• Data Protection Officer: Lewis
• Security Team: Caleb, Stella and Tracy
• Legal: Martin

External Resources¶

• Regulatory authority websites (links in subsections)
• Industry associations and working groups
• Compliance communities and forums
• Professional certifications (ISMS, CIPP, CISSP, CISA)

Understanding Regulatory Landscape and Standards¶

GDPR (General Data Protection Regulation) Compliance¶

Core Principle: Implement privacy-by-design and privacy-by-default principles to protect EU residents' personal data throughout the entire data lifecycle.

Key Requirements Summary¶

1. Lawful Basis for Processing¶

Every data processing activity must have a valid lawful basis under GDPR Article 6:

• Consent: Freely given, specific, informed, and unambiguous
• Contract: Necessary to fulfill contractual obligations
• Legal Obligation: Required by law
• Vital Interests: Protecting someone's life
• Public Task: Performing official functions
• Legitimate Interests: Balanced against data subject rights

2. Data Subject Rights Implementation¶

You must provide mechanisms for users to exercise their rights:

Practical Implementation Approach:

# Example: Data Subject Rights Request Handler (Simplified)
from enum import Enum
from typing import Dict, Any

class DSARType(Enum):
    ACCESS = "access"
    ERASURE = "erasure"
    RECTIFICATION = "rectification"
    PORTABILITY = "portability"

class DSARHandler:
    def __init__(self, user_service, audit_logger):
        self.user_service = user_service
        self.audit_logger = audit_logger

    def handle_request(self, user_id: str, request_type: DSARType) -> Dict[str, Any]:
        """Central handler for all data subject access requests"""

        # Log the request for compliance tracking
        self.audit_logger.log_dsar(user_id, request_type)

        if request_type == DSARType.ACCESS:
            return self._handle_access_request(user_id)
        elif request_type == DSARType.ERASURE:
            return self._handle_erasure_request(user_id)
        elif request_type == DSARType.RECTIFICATION:
            return self._handle_rectification_request(user_id)
        elif request_type == DSARType.PORTABILITY:
            return self._handle_portability_request(user_id)

    def _handle_access_request(self, user_id: str) -> Dict[str, Any]:
        """Compile all personal data we hold about the user"""
        return {
            "profile_data": self.user_service.get_profile(user_id),
            "activity_logs": self.user_service.get_activity(user_id),
            "consent_records": self.user_service.get_consents(user_id),
            "processing_purposes": self.user_service.get_purposes(user_id),
            "data_recipients": ["analytics_provider", "email_service"],
            "retention_periods": {"profile": "account_lifetime", "logs": "90_days"}
        }

    def _handle_erasure_request(self, user_id: str) -> Dict[str, Any]:
        """Delete user data unless legal retention applies"""

        # Check for legal holds
        if self.user_service.has_legal_obligation(user_id):
            return {
                "status": "partial_deletion",
                "retained_data": ["financial_records", "audit_logs"],
                "reason": "legal_retention_requirement"
            }

        # Cascade deletion across all systems
        self.user_service.anonymize_user(user_id)
        return {"status": "completed", "deletion_date": datetime.now()}

3. Consent Management¶

Requirements:

• Must be granular (separate consent for different purposes)
• Must be withdrawable at any time
• Must be documented with timestamp and mechanism
• Cannot be bundled with terms & conditions

Implementation Pattern:

class ConsentManager:
    PURPOSES = {
        "essential": "Service delivery (always required)",
        "analytics": "Usage analytics and improvement",
        "marketing": "Marketing communications",
        "personalization": "Personalized content"
    }

    def collect_consent(self, user_id: str, purposes: list) -> dict:
        """Record granular consent with full audit trail"""
        consent_record = {
            "user_id": user_id,
            "timestamp": datetime.now(),
            "purposes": purposes,
            "consent_method": "explicit_checkbox",
            "ip_address": self.get_request_ip(),
            "user_agent": self.get_user_agent(),
            "version": "consent_form_v2.1"
        }

        # Store in compliance database
        self.db.store_consent(consent_record)

        # Update user permissions
        self.update_processing_permissions(user_id, purposes)

        return consent_record

    def withdraw_consent(self, user_id: str, purpose: str):
        """Allow users to withdraw consent for specific purposes"""
        self.db.record_withdrawal(user_id, purpose, datetime.now())
        self.disable_processing(user_id, purpose)

4. Data Breach Response Protocol¶

Breach Response Workflow:

┌───────────────────┐
│  Breach Detected  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Assess Risk Level │◄── Use breach risk matrix
└─────────┬─────────┘
          │
          ▼
    ┌─────┴───────┐
    │             │
    ▼             ▼
┌───────┐    ┌─────────┐
│  Low  │    │High/Med │
└───┬───┘    └────┬────┘
    │             │
    │             ▼
    │   ┌──────────────────┐
    │   │ Notify DPA       │ (within 72h)
    │   │ Notify Subjects  │ (if high risk)
    │   └──────────────────┘
    │             │
    └─────────────┼────────►
                  │
                  ▼
         ┌─────────────────┐
         │ Document & Log  │
         │ Implement Fixes │
         └─────────────────┘

Risk Assessment Matrix:

Code Example:

def assess_breach_severity(incident: dict) -> str:
    """Simple scoring system for breach severity"""
    score = 0

    # Volume scoring
    if incident['affected_users'] > 1000: score += 3
    elif incident['affected_users'] > 100: score += 2
    elif incident['affected_users'] > 10: score += 1

    # Data sensitivity
    sensitive_types = {'financial', 'health', 'biometric', 'credentials'}
    if any(t in incident['data_types'] for t in sensitive_types):
        score += 3

    # Mitigation present
    if not incident.get('encryption_enabled', False):
        score += 2

    # Return risk level
    if score >= 7: return "CRITICAL"
    elif score >= 5: return "HIGH"
    elif score >= 3: return "MEDIUM"
    else: return "LOW"

5. Privacy Impact Assessment (PIA)¶

When to Conduct PIAs:

• Processing special category data (health, biometric, etc.)
• Large-scale systematic monitoring
• Automated decision-making with legal effects
• New technologies with privacy implications

Simplified PIA Template:

# pia_template.yaml
project_name: "Customer Analytics Dashboard"
date: "2025-11-10"
assessor: "Jane Developer"

data_processing:
  purposes: ["service_improvement", "personalization"]
  data_categories: ["usage_logs", "preferences", "device_info"]
  data_subjects: ["customers", "employees"]

risk_indicators:
  - large_scale: true              # >5000 users
  - special_category: false
  - automated_decisions: true      # Recommendation engine
  - new_technology: false
  - cross_border: true             # US servers

risk_assessment:
  level: "MEDIUM"
  justification: "Automated recommendations + cross-border transfer"

mitigation_measures:
  - "Implement Standard Contractual Clauses for US transfer"
  - "Provide explanation for automated recommendations"
  - "Allow users to opt-out of personalization"
  - "Regular audits of recommendation algorithm for bias"

dpo_review_required: true
supervisory_authority_consultation: false

6. Cross-Border Data Transfers¶

Transfer Legitimacy Decision Tree:

Is destination country in EU/EEA?
│
├─ YES → Transfer allowed 
│
└─ NO → Has adequacy decision? (UK, Japan, etc.)
    │
    ├─ YES → Transfer allowed 
    │
    └─ NO → Implement safeguards:
        ├─ Standard Contractual Clauses (SCCs)
        ├─ Binding Corporate Rules (BCRs)
        └─ Transfer Impact Assessment (TIA)

Countries with Adequacy Decisions (2025):

Implementation Checklist:

# Transfer validation before sending data
def validate_data_transfer(destination_country: str, data_categories: list) -> dict:
    ADEQUATE_COUNTRIES = {
        'UK', 'JP', 'CH', 'NZ', 'KR', 'IL', 'AR', 'UY', 'CA'
    }

    if destination_country in ADEQUATE_COUNTRIES:
        return {"allowed": True, "mechanism": "adequacy_decision"}

    # Requires additional safeguards
    return {
        "allowed": False,
        "required_actions": [
            "Execute Standard Contractual Clauses with recipient",
            "Conduct Transfer Impact Assessment",
            "Implement additional technical safeguards (encryption)",
            "Document in Records of Processing Activities"
        ]
    }

7. Records of Processing Activities (ROPA)¶

Maintain documentation of all processing activities (Article 30):

Minimum ROPA Fields:

• Purpose of processing
• Categories of data subjects
• Categories of personal data
• Recipients of data
• International transfers
• Retention periods
• Security measures

Example ROPA Entry:

{
  "activity_id": "PROC-2025-001",
  "controller": "YourCompany Ltd",
  "purpose": "Customer order fulfillment",
  "lawful_basis": "contract",
  "data_subjects": ["customers"],
  "data_categories": ["name", "email", "shipping_address", "payment_info"],
  "recipients": ["payment_processor", "shipping_carrier"],
  "transfers": {
    "countries": ["US"],
    "safeguards": "Standard Contractual Clauses"
  },
  "retention": "7 years (tax law requirement)",
  "security_measures": ["encryption_at_rest", "access_controls", "audit_logs"],
  "last_review": "2025-11-10"
}

Quick Implementation Checklist¶

Phase 1: Foundation¶

• Audit all data collection points
• Document lawful basis for each processing activity
• Create ROPA (Records of Processing Activities)
• Appoint Data Protection Officer (if required)
• Update privacy policy with GDPR language

Phase 2: User Rights¶

• Implement data access request handler
• Implement data deletion functionality
• Create data portability export feature
• Build consent management system
• Add consent withdrawal options

Phase 3: Security & Compliance¶

• Establish breach notification procedures
• Create breach response team and contacts
• Implement audit logging for all data access
• Conduct Privacy Impact Assessments
• Review third-party processor agreements

Phase 4: Ongoing (Continuous)¶

• Regular staff training on GDPR
• Quarterly ROPA reviews
• Annual security assessments
• Monitor regulatory guidance updates
• Test DSAR response procedures

Common Pitfalls to Avoid¶

Key Takeaways for Developers¶

Additional Resources¶

• Official GDPR Text
• ICO Developer Guide
• EDPB Guidelines
• GDPR Checklist Tool

PCI-DSS (Payment Card Industry Data Security Standard) Compliance¶

Core Principle: Implement comprehensive payment card data protection through secure network architecture, strong access controls, and continuous monitoring to prevent cardholder data compromise.

Key Guidelines¶

PCI-DSS Requirements Overview¶

Requirements 1 & 2: Build and Maintain Secure Networks¶

Network Segmentation Strategy¶

Objective: Isolate cardholder data environment (CDE) from other network segments to minimize attack surface.

Network Zone Architecture:

┌───────────────────────────────────────────────────┐
│                    INTERNET                       │
└──────────────────┬────────────────────────────────┘
                   │
       ┌───────────▼───────────┐
       │  Edge Firewall (FW1)  │
       └───────────┬───────────┘
                   │
       ┌───────────▼───────────┐
       │     DMZ Zone          │
       │  - Web Servers        │
       │  - Load Balancers     │
       └───────────┬───────────┘
                   │
       ┌───────────▼───────────┐
       │   Internal FW (FW2)   │
       └───────────┬───────────┘
                   │
       ┌───────────▼───────────┐
       │   Internal Network    │
       └───────────┬───────────┘
                   │
       ┌───────────▼───────────┐
       │    CDE Firewall       │
       └───────────┬───────────┘
                   │
    ┌──────────────┴────────────────┐
    │  Cardholder Data Environment  │
    │  - Payment Application Servers│
    │  - Database Servers           │
    │  - Key Management Systems     │
    └───────────────────────────────┘

Firewall Configuration Checklist¶

Default Deny Policy:

• Deny all inbound traffic by default
• Allow only explicitly approved traffic
• Document business justification for each allowed rule
• Review firewall rules quarterly

CDE Protection Rules:

• No direct internet access to CDE
• All connections routed through DMZ
• Restrict outbound connections from CDE
• Implement application-layer filtering where possible

Rule Documentation Format:

# Example firewall rule documentation format
rule_id: FW-CDE-001
name: "Allow HTTPS from DMZ to CDE Web App"
source: DMZ_Web_Servers (10.1.1.0/24)
destination: CDE_App_Servers (10.2.1.0/24)
port: 443/tcp
protocol: HTTPS
action: ALLOW
justification: "Required for payment processing flow"
business_owner: "Payment Systems Team"
approved_by: "Security Team"
review_date: "2025-01-15"
last_reviewed: "2024-10-15"

System Hardening Standards¶

Configuration Management:

1. Use vendor-supplied security configuration guides
2. Remove or disable unnecessary services and protocols
3. Change default passwords and credentials
4. Implement configuration management tools (Ansible, Puppet, Chef)
5. Document all configurations in version control

Common Hardening Tasks:

• Disable unused network protocols (IPv6 if not used, NetBIOS, SMBv1)
• Remove default accounts and sample applications
• Configure security banners for all system access
• Set appropriate file and directory permissions
• Enable system logging and time synchronization

Requirement 3: Protect Cardholder Data¶

Data Classification and Handling¶

What You Can Store vs. What You Cannot:

Data Protection Implementation¶

1. Tokenization (Recommended Approach)

Concept: Replace sensitive card data with non-sensitive tokens.

Implementation Pattern:

User Input → Tokenization Service → Token Storage
    ↓                                      ↑
PAN: 4111111111111111              Token: 9999123456789012
    ↓                                      ↓
Encrypted Storage (Vault)          Application Database
(Outside your application)         (Your application)

Benefits:

• Reduces PCI scope significantly
• Simplifies compliance
• Minimizes breach impact
• Third-party solutions available (Stripe, Braintree, etc.)

Developer Checklist:

• Use third-party tokenization when possible
• Never log or display full PAN
• Implement token-to-PAN mapping only when required
• Restrict detokenization to authorized systems only

2. Data Masking

Display Standards: - Show first 6 and last 4 digits: 411111******1111 - Or last 4 digits only: ************1111 - Mask in all logs, error messages, and screen displays

Code Implementation Pattern:

def mask_pan(card_number: str) -> str:
    """Mask PAN for display purposes"""
    if not card_number or len(card_number) < 13:
        return "****"

    # Remove any spaces or dashes
    clean_pan = card_number.replace(" ", "").replace("-", "")

    # Return first 6 and last 4
    if len(clean_pan) >= 10:
        return f"{clean_pan[:6]}{'*' * (len(clean_pan) - 10)}{clean_pan[-4:]}"

    # Return only last 4 if shorter
    return f"{'*' * (len(clean_pan) - 4)}{clean_pan[-4:]}"

# Usage in application
masked_card = mask_pan(user_card_number)
logger.info(f"Processing payment for card {masked_card}")

3. Encryption at Rest

Encryption Requirements:

• Use strong cryptography: AES-256 or RSA 2048-bit minimum
• Implement proper key management
• Encrypt entire databases or file systems containing cardholder data
• Use industry-tested and accepted algorithms

Configuration Example (PostgreSQL):

-- Enable transparent data encryption for PCI-compliant columns
CREATE TABLE payments (
    id SERIAL PRIMARY KEY,
    transaction_id VARCHAR(50) NOT NULL,
    encrypted_pan BYTEA NOT NULL,  -- Encrypted PAN
    token VARCHAR(20) NOT NULL,     -- Tokenized reference
    amount DECIMAL(10,2) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

-- Application handles encryption/decryption with proper key management

Key Management Essentials:

• Store encryption keys separately from encrypted data
• Implement key rotation policies (annually minimum)
• Use hardware security modules (HSMs) for production keys
• Restrict key access to minimal necessary personnel
• Maintain dual control and split knowledge for keys

Requirement 4: Encrypt Transmission of Cardholder Data¶

Secure Transmission Standards¶

TLS/SSL Configuration

Minimum Requirements:

• TLS 1.2 or higher (TLS 1.3 preferred)
• Strong cipher suites only
• Valid, non-expired certificates from trusted CA
• Proper certificate validation

Approved Cipher Suites:

# Prioritized list (strongest first)
TLS_AES_256_GCM_SHA384                    # TLS 1.3
TLS_AES_128_GCM_SHA256                    # TLS 1.3
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384     # TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256     # TLS 1.2
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384       # TLS 1.2

Web Server Configuration (Nginx Example):

# PCI-DSS compliant SSL configuration
server {
    listen 443 ssl http2;
    server_name payment.example.com;

    # TLS Protocol versions
    ssl_protocols TLSv1.2 TLSv1.3;

    # Strong cipher suites
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS - Force HTTPS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Certificate configuration
    ssl_certificate /etc/ssl/certs/payment.crt;
    ssl_certificate_key /etc/ssl/private/payment.key;

    # Additional security headers
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
}

API Security for Payment Transmission¶

Authentication Patterns:

1. OAuth 2.0 with PKCE - For user-initiated transactions
2. Mutual TLS (mTLS) - For server-to-server communication
3. API Keys + TLS - Minimum standard, use with IP whitelisting

Request Signing for Integrity:

# Example: HMAC-SHA256 request signing
import hmac
import hashlib
import json
from datetime import datetime

def sign_payment_request(payload: dict, secret_key: str) -> dict:
    """Sign payment API request for integrity verification"""

    # Add timestamp for replay protection
    payload['timestamp'] = datetime.utcnow().isoformat()

    # Create canonical string
    canonical_string = json.dumps(payload, sort_keys=True)

    # Generate signature
    signature = hmac.new(
        secret_key.encode(),
        canonical_string.encode(),
        hashlib.sha256
    ).hexdigest()

    # Add signature to request
    payload['signature'] = signature

    return payload

# Usage
payment_data = {
    'amount': 99.99,
    'currency': 'USD',
    'token': '9999123456789012'
}

signed_request = sign_payment_request(payment_data, API_SECRET_KEY)

Requirements 5 & 6: Vulnerability Management¶

Vulnerability Scanning Schedule¶

Patch Management Process¶

Patch Classification and Timeline:

┌───────────────────────────────────────────────────────┐
│ CRITICAL Severity (CVSS 9.0-10.0)                   │
│ Timeline: Apply within 24-48 hours                  │
│ Examples: Remote code execution, SQL injection      │
└───────────────────────────────────────────────────────┘
                        ↓
┌───────────────────────────────────────────────────────┐
│ HIGH Severity (CVSS 7.0-8.9)                        │
│ Timeline: Apply within 7 days                       │
│ Examples: Authentication bypass, XSS                │
└───────────────────────────────────────────────────────┘
                        ↓
┌───────────────────────────────────────────────────────┐
│ MEDIUM Severity (CVSS 4.0-6.9)                      │
│ Timeline: Apply within 30 days                      │
│ Examples: Information disclosure, denial of service │
└───────────────────────────────────────────────────────┘
                        ↓
┌───────────────────────────────────────────────────────┐
│ LOW Severity (CVSS 0.1-3.9)                         │
│ Timeline: Apply within 90 days                      │
│ Examples: Minor configuration issues                │
└───────────────────────────────────────────────────────┘

Monthly Patch Workflow:

Secure Development Practices¶

OWASP Top 10 Protection Checklist:

A01: Broken Access Control

• Implement role-based access control (RBAC)
• Deny by default
• Validate authorization on server-side
• Disable directory listing

A02: Cryptographic Failures

• Use TLS for all data in transit
• Encrypt sensitive data at rest
• Use current encryption standards
• Avoid deprecated algorithms

A03: Injection

• Use parameterized queries/prepared statements
• Validate and sanitize all inputs
• Use ORM frameworks properly
• Apply principle of least privilege for database accounts

Code Review Checklist (PCI-Specific):

## Pre-Commit Security Checklist

### Data Handling
- [ ] No hard-coded credentials or API keys
- [ ] Sensitive data encrypted before storage
- [ ] No prohibited data (CVV, full track data) stored
- [ ] All PAN instances properly masked in logs

### Input Validation
- [ ] All user inputs validated and sanitized
- [ ] SQL injection protection implemented
- [ ] XSS protection in place
- [ ] File upload restrictions enforced

### Authentication & Authorization
- [ ] Strong password requirements enforced
- [ ] Multi-factor authentication available
- [ ] Session management secure
- [ ] Authorization checks on all endpoints

### Logging & Monitoring
- [ ] Security events logged
- [ ] No sensitive data in logs
- [ ] Log integrity protected
- [ ] Alerting configured for anomalies

Requirements 7 & 8: Access Control¶

Role-Based Access Control (RBAC)¶

Role Definition Matrix:

Access Control Implementation:

Environment Variable Pattern:

# .env.example (never commit actual credentials)
# Production credentials stored in secure vault

# Database Access
DB_HOST=localhost
DB_PORT=5432
DB_NAME=payments
DB_USER=app_user
DB_PASSWORD=<retrieve-from-vault>

# API Keys
PAYMENT_GATEWAY_API_KEY=<retrieve-from-vault>
ENCRYPTION_KEY=<retrieve-from-vault>

# Access tokens expire after 1 hour
JWT_SECRET=<retrieve-from-vault>
JWT_EXPIRY=3600

Secret Management Options:

• AWS Secrets Manager / AWS Systems Manager Parameter Store
• Azure Key Vault
• HashiCorp Vault
• Google Cloud Secret Manager
• Kubernetes Secrets (with encryption at rest)

Authentication Requirements¶

Password Policy:

• Minimum 12 characters (15+ recommended)
• Complexity: uppercase, lowercase, numbers, special characters
• No common dictionary words
• Cannot reuse last 4 passwords
• Change every 90 days (or use MFA with longer periods)
• Account lockout after 6 failed attempts

Multi-Factor Authentication (MFA):

• Required for all access to CDE
• Required for remote network access
• Required for administrative functions
• Options: TOTP apps, hardware tokens, biometrics

Requirements 10 & 11: Monitoring and Testing¶

Logging Requirements¶

What to Log:

Security Events:

• All authentication attempts (success and failure)
• All access to cardholder data
• All privileged actions
• All access to audit trails
• Invalid logical access attempts
• Changes to authentication mechanisms
• Initialization, stopping, or pausing of logs
• Creation and deletion of system-level objects

Required Log Fields:

{
  "timestamp": "2025-11-10T14:32:15.123Z",
  "event_type": "authentication",
  "result": "failure",
  "user_id": "john.doe@company.com",
  "source_ip": "192.168.1.100",
  "resource_accessed": "/api/payments",
  "action_taken": "login_attempt",
  "outcome": "account_locked",
  "session_id": "abc123xyz789",
  "user_agent": "Mozilla/5.0..."
}

Log Management:

Centralized Logging Architecture:

Application Servers → Log Shipper (Filebeat/Fluentd)
                            ↓
              Centralized Log Storage (ELK Stack)
                            ↓
        ┌──────────────────┴──────────────────┐
        ↓                                      ↓
  SIEM Analysis                         Compliance Reporting
  (Splunk/Elastic)                     (Quarterly Reviews)
        ↓                                      ↓
  Alert Generation                      Audit Evidence

Log Retention:

• Store logs for at least 3 months immediately available
• Archive logs for at least 1 year for analysis
• Protect log integrity (write-once storage or signing)

Continuous Monitoring¶

Automated Alerting Rules:

# Example alert configuration
alerts:
  - name: "Multiple Failed Logins"
    condition: "failed_logins > 5 in 10 minutes"
    severity: HIGH
    action: ["email_security_team", "lock_account"]

  - name: "Unusual Data Access Pattern"
    condition: "cardholder_data_access > 100 records in 1 hour"
    severity: CRITICAL
    action: ["page_security_oncall", "suspend_session"]

  - name: "Database Schema Change"
    condition: "DDL statements on production"
    severity: MEDIUM
    action: ["email_dba_team", "log_change"]

  - name: "Privilege Escalation Attempt"
    condition: "unauthorized_admin_access"
    severity: CRITICAL
    action: ["immediate_alert", "block_ip", "start_incident"]

Requirement 12: Security Policies¶

Essential Policies and Procedures¶

Information Security Policy Structure:

1. Purpose and Scope
2. Roles and Responsibilities
3. Risk Assessment Methodology
4. Security Controls
5. Incident Response Procedures
6. Annual Review Process

Developer-Specific Procedures:

Pre-Production Checklist:

## PCI-DSS Pre-Production Deployment Checklist

### Code Review
- [ ] Security code review completed
- [ ] Automated security scans passed
- [ ] No hard-coded credentials present
- [ ] Input validation implemented

### Testing
- [ ] Unit tests passed (>80% coverage)
- [ ] Integration tests passed
- [ ] Security testing completed
- [ ] Penetration testing if required

### Configuration
- [ ] Production secrets configured in vault
- [ ] TLS certificates valid and current
- [ ] Firewall rules reviewed and approved
- [ ] Monitoring and alerting enabled

### Documentation
- [ ] Architecture diagrams updated
- [ ] Runbook created/updated
- [ ] Change management ticket approved
- [ ] Rollback plan documented

### Compliance
- [ ] PCI-DSS impact assessment completed
- [ ] Data flow diagrams updated if needed
- [ ] Security policy compliance verified
- [ ] Audit trail requirements met

Incident Response Plan¶

Incident Classification¶

Response Workflow¶

Detection → Containment → Investigation → Remediation → Post-Mortem
    ↓            ↓              ↓               ↓              ↓
  Alert      Isolate       Root Cause      Deploy Fix     Document
  Team       System        Analysis        & Test         Lessons

Quick Reference: Common Developer Scenarios¶

Scenario 1: Displaying Cardholder Data¶

Question: User wants to see their saved card.

Solution:

# CORRECT: Show masked PAN only
display_card = {
    'last_four': '1111',
    'brand': 'visa',
    'expiry': '12/25'
}

# WRONG: Never display full PAN
# full_pan = '4111111111111111'  # Don't do this

Scenario 2: Logging Payment Transactions¶

Question: Need to log payment details for debugging.

Solution:

# CORRECT: Log transaction ID and masked data
logger.info(
    "Payment processed",
    extra={
        'transaction_id': 'txn_abc123',
        'masked_pan': '411111******1111',
        'amount': 99.99,
        'status': 'success'
    }
)

# WRONG: Don't log sensitive data
# logger.info(f"Payment: {full_pan} {cvv}")  # Never log this

Scenario 3: API Integration with Payment Gateway¶

Question: How to securely send card data to processor?

Solution:

// CORRECT: Use tokenization
const token = await paymentGateway.createToken({
  number: cardNumber,  // PAN never hits your server
  exp_month: expMonth,
  exp_year: expYear
});

// Store only the token
await database.save({ token: token.id, last_four: '1111' });

// WRONG: Sending raw card data to your backend
// fetch('/api/payment', { body: { pan: cardNumber } })  // Don't do this

Compliance Maintenance Schedule¶

Daily:

• Review security alerts
• Monitor access logs
• Verify backup completion

Weekly:

• Review firewall logs
• Update vulnerability tracking
• Team security standup

Monthly:

• Patch management cycle
• Review user access rights
• Security training module

Quarterly:

• Vulnerability scans (internal & external)
• Firewall rule review
• Policy review and updates
• Management review meeting

Annually:

• Full PCI-DSS assessment
• Penetration testing
• Security awareness training (all staff)
• Disaster recovery test
• Risk assessment update

Additional Resources¶

Internal Resources¶

• Security Team: Caleb, Stella and Tracy
• Incident Response Playbook: Incident Response Procedure
• Security Training Portal: Request Janet access to Udemy

External Resources¶

• PCI Security Standards Council
• OWASP
• NIST Cybersecurity Framework
• CWE/SANS Top 25

Contact Information¶

• Security Team: Caleb, Stella and Tracy
• Compliance Officer: Martin or Lewis
• 24/7 Security Hotline: +254 20 513 2100

HIPAA (Health Insurance Portability and Accountability Act) Compliance¶

Core Principle: Protect electronic protected health information (ePHI) through comprehensive administrative, physical, and technical safeguards while ensuring healthcare data privacy and security.

Key Guidelines¶

HIPAA Safeguards Framework¶

Implementation Approach¶

1. PHI Identification and Classification¶

Before implementing controls, identify what constitutes PHI in your systems:

PHI Categories to Track:

• Patient identifiers (names, addresses, SSNs, MRNs)
• Medical records and treatment information
• Billing and insurance data
• Demographic information
• Biometric data and photographs

Data Classification Matrix:

Implementation Checklist:

• Document all systems that create, receive, maintain, or transmit ePHI
• Map data flows showing where PHI moves through your infrastructure
• Apply appropriate classification labels in databases and file systems
• Implement automated PHI detection tools for repositories and logs

2. Access Control Implementation¶

Minimum Necessary Principle: Grant users only the PHI access required for their specific job function.

Role-Based Access Control (RBAC) Structure:

# Example: Access Control Configuration
roles:
  physician:
    phi_access: full
    allowed_operations: [read, write, update]
    data_scope: assigned_patients
    additional_permissions:
      - view_medical_history
      - order_medications
      - update_diagnoses

  nurse:
    phi_access: treatment_related
    allowed_operations: [read, write]
    data_scope: ward_patients
    additional_permissions:
      - update_vitals
      - view_care_plans
      - document_treatments

  billing_staff:
    phi_access: billing_only
    allowed_operations: [read]
    data_scope: financial_data
    additional_permissions:
      - view_insurance_info
      - process_claims
      - access_procedure_codes

  researcher:
    phi_access: limited_dataset
    allowed_operations: [read]
    data_scope: approved_studies
    requires_consent: true
    additional_permissions:
      - export_deidentified_data

access_controls:
  authentication:
    method: multi_factor
    password_policy:
      min_length: 12
      complexity: high
      rotation_days: 90
    session_timeout_minutes: 15
    failed_attempts_lockout: 5

  authorization:
    enforce_minimum_necessary: true
    break_glass_emergency_access: true
    supervisory_approval_required:
      - cross_department_access
      - bulk_data_export
      - administrative_overrides

Access Control Validation:

Implement pre-access checks before allowing PHI access:

1. User Authentication - Verify identity through MFA
2. Role Verification - Confirm user has appropriate role assignment
3. Patient Relationship - Validate treatment relationship or legitimate purpose
4. Emergency Override - Log and review break-glass access scenarios
5. Consent Validation - Check patient consent for special uses (research, marketing)

3. Comprehensive Audit Logging¶

What to Log:

Every PHI access must be logged with sufficient detail for compliance audits:

Minimum Audit Log Fields:

{
  "timestamp": "2025-11-07T14:23:45Z",
  "event_type": "phi_access",
  "user_id": "dr_smith_001",
  "user_role": "physician",
  "patient_id": "patient_12345",
  "phi_category": "medical_records",
  "access_purpose": "treatment",
  "data_accessed": ["diagnoses", "medications", "lab_results"],
  "operation": "read",
  "ip_address": "192.168.1.100",
  "session_id": "session_abc123",
  "application": "ehr_system",
  "location": "emergency_department",
  "success": true,
  "justification": "Emergency care for chest pain complaint"
}

Audit Log Monitoring:

Implement automated monitoring for:

Alert Thresholds:

• More than 50 patient records accessed in 1 hour → Flag for review
• Access from 3+ different IP addresses in 24 hours → Geographic anomaly alert
• Failed login attempts (5 consecutive) → Account lockout + security notification
• Off-hours access (10 PM - 6 AM) → Manager notification
• Access to VIP/sensitive records → Real-time alert to privacy officer

Audit Log Retention:

• Maintain audit logs for minimum 6 years (HIPAA requirement)
• Implement tamper-proof logging (write-once, append-only storage)
• Regular log backup with encryption
• Periodic log analysis and compliance reporting

4. Data Encryption Standards¶

Encryption at Rest:

# Database Encryption Configuration
database:
  encryption:
    algorithm: AES-256-GCM
    key_management: AWS_KMS  # or Azure Key Vault, HashiCorp Vault
    transparent_data_encryption: enabled
    backup_encryption: enabled

  field_level_encryption:  # For highly sensitive fields
    enabled: true
    fields:
      - ssn
      - credit_card_number
      - bank_account
    encryption_keys: rotated_annually

# File Storage Encryption
file_storage:
  medical_images:
    encryption: AES-256
    storage_class: encrypted_standard

  documents:
    encryption: enabled
    format_preserved: true  # Maintain file readability

Encryption in Transit:

# Transport Layer Security Configuration
tls:
  minimum_version: "1.2"
  preferred_version: "1.3"
  cipher_suites:
    - TLS_AES_256_GCM_SHA384
    - TLS_CHACHA20_POLY1305_SHA256
    - TLS_AES_128_GCM_SHA256

api_endpoints:
  phi_endpoints:
    require_tls: true
    mutual_tls: recommended  # For B2B integrations
    certificate_pinning: enabled

internal_services:
  service_mesh_encryption: enabled  # mTLS for microservices
  vpn_required: true  # For remote access

Key Management Best Practices:

• Use dedicated key management services (KMS, HSM)
• Rotate encryption keys annually minimum
• Implement key hierarchy (master keys, data encryption keys)
• Maintain key backup and recovery procedures
• Audit all key access and usage
• Separate key management responsibilities (split knowledge)

5. Business Associate Management¶

Business Associate Agreement (BAA) Requirements:

Before sharing PHI with third-party vendors, ensure a signed BAA that includes:

Core BAA Provisions:

Business Associate Risk Assessment:

Evaluate vendors before engagement:

Vendor Management Checklist:

• Conduct pre-engagement security assessment
• Execute comprehensive BAA before PHI sharing
• Validate security certifications (SOC 2, HITRUST)
• Review and approve data processing locations
• Establish incident notification procedures
• Schedule annual compliance reviews
• Monitor vendor security advisories and updates
• Maintain vendor inventory with risk classifications

6. Breach Response and Notification¶

Incident Classification:

Not all security events are breaches. Use the 4-Factor Risk Assessment per 45 CFR 164.402:

Factor 1: Nature and Extent of PHI Involved

• What types of PHI? (SSN, medical diagnoses, financial data)
• How many individuals affected?
• How much data per individual?

Factor 2: Unauthorized Person

• Who accessed the PHI?
• Malicious insider vs. inadvertent employee vs. external attacker
• Likelihood of criminal use

Factor 3: Was PHI Actually Acquired/Viewed?

• Was PHI viewed or just accessible?
• Evidence of actual data exfiltration?
• Forensic analysis findings

Factor 4: Risk Mitigation

• What safeguards were in place? (encryption, access controls)
• What mitigation steps were taken immediately?
• Effectiveness of containment measures

Breach Determination Matrix:

Breach Notification Timeline:

72-Hour Timeline:

Incident Response Procedure:

Phase 1: Detection & Containment

1. Detect and verify the incident
2. Activate incident response team
3. Contain the incident (isolate systems, revoke access)
4. Preserve evidence (logs, forensic images)

Phase 2: Assessment

1. Conduct 4-factor risk assessment
2. Determine breach status
3. Identify affected individuals and PHI types
4. Document findings and decision rationale

Phase 3: Notification (if breach)

1. Notify affected individuals (written notice)
2. Notify HHS (electronic submission if 500+)
3. Notify media (if 500+ in same jurisdiction)
4. Notify business associates (if involved)

Phase 4: Post-Incident (Ongoing)

1. Conduct post-mortem analysis
2. Implement corrective actions
3. Update policies and procedures
4. Provide additional staff training

7. Data De-identification Methods¶

Safe Harbor Method (18 Identifiers):

Remove all of the following identifiers:

Special Handling for Dates:

• Birth dates: For individuals 89+, use age group "90+" and remove specific dates
• Other dates: Retain year only (e.g., "2024" instead of "2024-03-15")
• Exception: Dates may be retained if aggregated into time periods (e.g., decades)

Safe Harbor Implementation Example:

def apply_safe_harbor_deidentification(patient_record):
    """
    Apply HIPAA Safe Harbor de-identification method
    """
    deidentified = {}

    # Remove direct identifiers
    excluded_fields = [
        'name', 'address', 'city', 'zip_code', 'phone', 
        'email', 'ssn', 'mrn', 'account_number'
    ]

    for field, value in patient_record.items():
        if field not in excluded_fields:
            deidentified[field] = value

    # Handle dates - keep year only
    if 'birth_date' in patient_record:
        birth_year = patient_record['birth_date'].year
        age = calculate_age(patient_record['birth_date'])

        if age >= 89:
            deidentified['age_group'] = '90+'
        else:
            deidentified['birth_year'] = birth_year

    # Generalize geographic data - keep state only
    if 'state' in patient_record:
        deidentified['state'] = patient_record['state']

    # Add de-identification metadata
    deidentified['_deidentified'] = True
    deidentified['_method'] = 'safe_harbor'
    deidentified['_date'] = datetime.now().isoformat()

    return deidentified

Expert Determination Method:

Alternative to Safe Harbor - requires statistical expertise to ensure re-identification risk is very small.

Techniques Include:

• Statistical disclosure control
• Data perturbation (adding calibrated noise)
• Generalization (broader categories)
• Suppression (removing outliers)
• k-anonymity principles (each record indistinguishable from k-1 others)

When to Use Expert Determination:

• Need to retain more granular data than Safe Harbor allows
• Research requiring dates beyond year
• Small population studies where Safe Harbor may destroy utility
• Advanced analytics requiring statistical precision

8. Employee Training Program¶

Training Requirements by Role:

Training Content Areas:

1. HIPAA Foundations (All Staff)

• What is PHI and how to identify it
• Patient rights (access, amendment, accounting)
• Minimum necessary standard
• Permitted uses and disclosures
• Consequences of violations

2. Security Awareness (All Staff)

• Password security and MFA
• Phishing and social engineering
• Device security (laptops, mobile devices)
• Secure email and communication
• Incident reporting procedures
• Remote work security

3. Role-Specific Training

• Clinical: Documentation standards, consent management, disclosure scenarios
• Administrative: Policy enforcement, sanctions, workforce management
• Technical: System hardening, vulnerability management, encryption implementation
• Leadership: Risk assessment, breach response, compliance oversight

Training Delivery Methods:

• Online modules with assessments (convenient, trackable)
• In-person workshops (interactive, scenario-based)
• Simulation exercises (breach response, social engineering)
• Just-in-time training (contextual help within applications)
• Onboarding programs (new hire orientation)

Competency Validation:

Training Compliance Tracking:

Maintain records including:

• Training completion dates and scores
• Training content version
• Training method and instructor
• Certificate of completion
• Renewal due dates
• Remediation plans for non-completion

Implementation Roadmap¶

Phase 1: Assessment & Planning

• Conduct comprehensive PHI inventory
• Document data flows and system architecture
• Perform gap analysis against HIPAA requirements
• Identify high-risk areas requiring immediate attention
• Develop implementation project plan

Phase 2: Technical Safeguards

• Implement encryption for PHI at rest and in transit
• Deploy access control systems with RBAC
• Configure comprehensive audit logging
• Set up automated monitoring and alerting
• Implement authentication mechanisms (MFA)

Phase 3: Administrative Safeguards

• Develop and document security policies
• Establish business associate management program
• Create incident response procedures
• Implement workforce training program
• Conduct initial risk assessment

Phase 4: Physical Safeguards

• Implement facility access controls
• Secure workstations and devices
• Establish media disposal procedures
• Configure environmental controls

Phase 5: Testing & Validation

• Conduct security testing and vulnerability assessments
• Perform breach simulation exercises
• Validate audit logging completeness
• Test incident response procedures
• Review and remediate findings

Phase 6: Training & Go-Live

• Deliver role-based HIPAA training
• Validate workforce competency
• Launch compliance monitoring program
• Establish ongoing governance processes
• Document compliance status and evidence

Compliance Monitoring & Continuous Improvement¶

Ongoing Compliance Activities:

Monthly:

• Review access logs for unusual patterns
• Monitor security alerts and incidents
• Update business associate inventory
• Track training compliance rates

Quarterly:

• Conduct internal compliance audits
• Review and update risk assessments
• Analyze incident trends and root causes
• Update policies based on lessons learned

Annually:

• Comprehensive security risk assessment
• Business associate agreement reviews
• Workforce training renewal
• External security audit (recommended)
• Executive compliance report

Key Performance Indicators (KPIs):

Common Pitfalls to Avoid¶

Additional Resources¶

Regulatory Guidance:

• HHS Office for Civil Rights (OCR): https://www.hhs.gov/hipaa
• HIPAA Security Rule: 45 CFR Part 164, Subpart C
• HIPAA Privacy Rule: 45 CFR Part 164, Subpart E
• Breach Notification Rule: 45 CFR Part 164, Subpart D

Industry Frameworks:

• HITRUST CSF (Common Security Framework)
• NIST Cybersecurity Framework
• NIST 800-66: Implementing HIPAA Security Rule

Professional Organizations:

• American Health Information Management Association (AHIMA)
• Healthcare Information and Management Systems Society (HIMSS)
• International Association of Privacy Professionals (IAPP)

SOX (Sarbanes-Oxley Act) Compliance for IT Systems¶

Core Principle: Implement controls over financial reporting systems to ensure accuracy, completeness, and reliability of financial data through proper IT governance and change management.

Key Requirements¶

1. IT General Controls (ITGCs)¶

Establish fundamental controls across all systems that support financial reporting:

• Change Management: All modifications to financial systems require documented approval
• Access Controls: Restrict system access based on job responsibilities
• Computer Operations: Monitor system performance and maintain operational logs
• System Documentation: Maintain current documentation of all financial systems

2. Change Management Process¶

Every change to systems handling financial data must follow this workflow:

Request → Review → Approval → Implementation → Verification → Documentation

Required Documentation for Each Change:

• Change ticket ID (e.g., CHG-123456)
• Business justification
• Risk assessment
• Approval from authorized manager
• Test results
• Deployment evidence
• Rollback plan

Git Commit Standards for Financial Systems:

git commit -m "CHG-123456: Update tax calculation logic

Business-Justification: Implement new tax rates for FY2025
Approved-By: Jane Smith (Finance Manager)
Tested-By: QA Team - Test Plan TP-789
SOX-Impact: Yes - Financial Calculation
Risk-Level: Medium"

3. Segregation of Duties (SOD)¶

Prevent conflicts of interest by separating responsibilities:

Implementation Example:

# team-roles.yml - Role assignment configuration
roles:
  alice:
    - developer
    - change_requester

  bob_manager:
    - change_approver
    - access_reviewer

  charlie:
    - production_deployer
    - release_manager

# Automated SOD validation in CI/CD
segregation_rules:
  - requester != approver
  - developer != production_deployer
  - no_self_approval: true

4. Access Controls and Privilege Management¶

Principle: Just-in-Time Access

• Grant elevated privileges only when needed
• Limit access duration (typically 2-4 hours)
• Require business justification
• Log all privileged actions

Access Review Schedule:

• Quarterly: Review all user access rights
• Immediately: Revoke access for terminated employees
• Annually: Recertify all system administrators

Example Access Request:

Privileged Access Request Form
═══════════════════════════
Requester: john.doe@company.com
System: Production Financial Database
Access Type: Read-only query access
Duration: 4 hours
Justification: Debug month-end closing issue (Ticket: INC-54321)
Approved By: [Finance Manager]
Access Granted: 2025-01-15 14:00 UTC
Access Expires: 2025-01-15 18:00 UTC

5. Audit Logging Requirements¶

What to Log:

• All database queries on financial data
• System configuration changes
• User authentication events
• Privileged access usage
• Failed access attempts
• Data exports and transfers

Log Retention:

• Minimum 7 years for SOX compliance
• Store logs in immutable storage
• Implement tamper-detection mechanisms

Structured Logging Example:

{
  "timestamp": "2025-01-15T14:23:45Z",
  "event_type": "data_access",
  "user": "john.doe",
  "action": "SELECT",
  "resource": "financial_transactions",
  "system": "prod_finance_db",
  "change_ticket": "CHG-123456",
  "ip_address": "10.0.1.45",
  "result": "success",
  "records_affected": 1247
}

6. Backup and Recovery¶

Requirements:

• Daily backups of all financial system data
• Offsite storage in geographically separate location
• Quarterly restoration tests with documented results
• Define RTO/RPO for each financial system

Backup Verification Checklist:

• Backup completed successfully
• Backup integrity verified (checksums match)
• Backup accessible from recovery location
• Restoration tested within last 90 days
• Documentation updated

7. Control Testing and Monitoring¶

Testing Frequency:

Automated Control Validation Script:

# sox_control_validator.py - Run daily via cron
def validate_sox_controls():
    checks = {
        'unapproved_changes': check_pending_changes(),
        'sod_violations': check_role_conflicts(),
        'expired_access': check_access_expiry(),
        'missing_logs': check_log_completeness(),
        'backup_status': check_recent_backups()
    }

    failures = [k for k, v in checks.items() if not v]

    if failures:
        alert_compliance_team(failures)
        return False
    return True

8. CI/CD Integration for Financial Systems¶

Pre-Deployment Checklist (Automated):

# .gitlab-ci.yml - SOX-controlled pipeline
financial_system_checks:
  script:
    - verify_change_ticket_exists
    - verify_manager_approval
    - verify_code_review_completed
    - verify_test_coverage > 80%
    - verify_security_scan_passed
    - verify_segregation_of_duties
  only:
    - production
  when: manual  # Requires explicit approval

9. Common Audit Findings (And How to Avoid Them)¶

10. Emergency Change Procedures¶

When immediate changes are necessary:

1. Implement the change to resolve the incident
2. Document the emergency in incident ticket
3. Notify compliance team within 24 hours
4. Obtain retroactive approval within 48 hours
5. Complete full change documentation within 72 hours
6. Review in next compliance meeting

Emergency Change Template:

Emergency Change Notification
═══════════════════════════════
Change ID: EMRG-2025-001
Implemented: 2025-01-15 02:30 UTC
Incident: INC-54321 - Payment processing failure
Change Made: Updated database connection timeout
Implemented By: on-call engineer (alice)
Business Impact: $2M in pending transactions
Retroactive Approval: [PENDING - Manager notified]

SOX Compliance Quick Reference Card¶

Before Making Any Change:

• Create change ticket
• Document business justification
• Get manager approval
• Complete code review
• Pass all tests
• Verify SOD compliance

After Deploying Change:

• Verify deployment success
• Document deployment evidence
• Update system documentation
• Archive change records

Monthly Responsibilities:

• Review audit logs
• Verify backup integrity
• Check for SOD violations

Quarterly Responsibilities:

• Access rights review
• Test backup restoration
• Update system documentation
• Control effectiveness testing

ISO 27001 Information Security Management System (ISMS)¶

Core Principle: Establish, implement, maintain, and continuously improve an information security management system based on systematic risk assessment and treatment.

Understanding ISO 27001 Structure¶

ISO 27001 is organized into 14 control domains with 114 specific controls. Not all controls apply to every organization - select controls based on your risk assessment.

Risk-Based Approach¶

Risk Assessment → Risk Treatment → Control Selection → Implementation → Review
       ↑                                                                   ↓
       └────────────────────── Continuous Improvement ──────────────────────┘

Key Control Domains¶

A.5 Information Security Policies¶

Purpose: Provide management direction and support for information security

Implementation:

• Document organization-wide security policy
• Define roles and responsibilities
• Establish policy review schedule (annually minimum)
• Ensure management approval and communication

Practical Example:

# Information Security Policy v2.1

## Purpose
Protect the confidentiality, integrity, and availability of company and customer information.

## Scope
All employees, contractors, systems, and data

## Key Principles
1. Security is everyone's responsibility
2. Follow principle of least privilege
3. Protect customer data as our own
4. Report security concerns immediately

## Responsibilities
- **Employees**: Follow security policies, complete training
- **Managers**: Enforce policies, conduct access reviews
- **Security Team**: Monitor, respond to incidents
- **Executive**: Provide resources, approve exceptions

Approved by: [CEO Signature]
Next Review: January 2026

A.6 Organization of Information Security¶

Purpose: Establish management framework for security

Key Activities:

• Define security roles (CISO, Security Champions, DPO)
• Establish security governance structure
• Create incident response team
• Define communication channels

A.8 Asset Management¶

Purpose: Identify and protect organizational assets

Asset Classification:

Asset Inventory Template:

asset_inventory:
  - id: AST-001
    name: Customer Database
    type: Database
    classification: Confidential
    owner: data-team@company.com
    location: AWS RDS us-east-1
    data_types: [PII, financial]
    backup_frequency: hourly
    last_reviewed: 2025-01-15

A.9 Access Control¶

Purpose: Limit access to information and systems

Access Control Policy:

1. Identification: Unique user IDs for all users
2. Authentication: Multi-factor authentication for sensitive systems
3. Authorization: Role-based access control (RBAC)
4. Accountability: Log all access activities

Access Request Workflow:

Employee Request → Manager Approval → Security Review → Provisioning → Quarterly Review

A.10 Cryptography¶

Purpose: Protect information confidentiality and integrity

Encryption Standards:

• Data at Rest: AES-256
• Data in Transit: TLS 1.3+
• Password Hashing: bcrypt or Argon2
• API Authentication: JWT with RSA-256 or HMAC-SHA256

Key Management:

• Store encryption keys separately from encrypted data
• Rotate keys annually (or per data breach)
• Use hardware security modules (HSM) for production keys
• Document key lifecycle (generation → usage → rotation → destruction)

A.12 Operations Security¶

Purpose: Ensure correct and secure system operations

Operational Procedures:

Change Management Integration:

# Simplified change management check
def can_deploy_change(change_request):
    required_checks = [
        change_request.has_risk_assessment(),
        change_request.has_approval(),
        change_request.has_rollback_plan(),
        change_request.passed_security_scan()
    ]
    return all(required_checks)

A.13 Communications Security¶

Purpose: Secure information in networks and systems

Network Security Requirements:

• Segment networks (DMZ, internal, management)
• Encrypt all external communications
• Implement intrusion detection/prevention
• Monitor network traffic for anomalies

Secure Communication Guidelines:

• Use company-approved communication tools only
• Encrypt sensitive data before sending
• Verify recipient before sharing confidential info
• Avoid discussing sensitive topics in public spaces

A.14 System Acquisition, Development and Maintenance¶

Purpose: Ensure security is built into systems

Secure Development Lifecycle:

Requirements → Design → Development → Testing → Deployment → Maintenance
    ↓            ↓           ↓           ↓          ↓           ↓
 Security    Threat     Secure      Security   Secure     Vulnerability
Requirements Modeling   Coding      Testing    Config      Management

Security Requirements Checklist:

• Input validation on all user inputs
• Output encoding to prevent XSS
• Parameterized queries to prevent SQL injection
• Authentication and session management
• Proper error handling (no sensitive info in errors)
• Security logging and monitoring

A.16 Information Security Incident Management¶

Purpose: Ensure consistent and effective approach to incidents

Incident Severity Levels:

Incident Response Workflow:

Detection → Triage → Containment → Eradication → Recovery → Lessons Learned

A.17 Business Continuity Management¶

Purpose: Maintain operations during disruptions

Business Impact Analysis:

• Identify critical business processes
• Determine maximum tolerable downtime
• Define recovery priorities
• Test continuity plans annually

A.18 Compliance¶

Purpose: Avoid breaches of legal or regulatory requirements

Compliance Obligations:

• Identify applicable regulations (GDPR, PCI-DSS, HIPAA, etc.)
• Document compliance requirements
• Assign compliance responsibilities
• Conduct regular compliance assessments
• Maintain evidence of compliance

Implementation Roadmap¶

Phase 1: Foundation

• Define scope of ISMS
• Conduct initial risk assessment
• Develop security policies
• Create asset inventory

Phase 2: Control Implementation

• Implement priority controls
• Deploy technical security measures
• Train staff on policies
• Establish incident response procedures

Phase 3: Monitoring and Review

• Conduct internal audits
• Perform management reviews
• Address non-conformities
• Prepare for certification audit

NIST Cybersecurity Framework Implementation¶

Core Principle: Implement comprehensive cybersecurity risk management through five core functions: Identify, Protect, Detect, Respond, and Recover.

Framework Overview¶

┌────────────────────────────────────────────────────────────┐
│                    NIST CSF Five Functions                 │
├─────────────┬──────────────┬──────────┬──────────┬─────────┤
│  IDENTIFY   │   PROTECT    │  DETECT  │ RESPOND  │ RECOVER │
│             │              │          │          │         │
│ Asset Mgmt  │ Access Ctrl  │ Anomaly  │ Response │ Recover │
│ Risk Assess │ Awareness    │ Alerts   │ Comms    │ Planning│
│ Governance  │ Data Sec     │ Monitor  │ Analysis │ Improve │
└─────────────┴──────────────┴──────────┴──────────┴─────────┘

1. IDENTIFY¶

Purpose: Develop understanding of cybersecurity risks to systems, people, assets, data, and capabilities

Asset Management (ID.AM)¶

Know what you're protecting

Create an Asset Inventory:

## Critical Asset Register

### Application Servers
- **prod-web-01**: Production web application (AWS EC2)
  - Criticality: High
  - Data: Customer transactions
  - Owner: Platform Team
  - Last assessed: 2025-01-15

### Databases
- **prod-db-main**: Customer database (AWS RDS)
  - Criticality: Critical
  - Data: PII, financial records
  - Owner: Data Team
  - Backup: Hourly

### Data Assets
- **customer_data**: Personal and financial information
  - Classification: Restricted
  - Location: Encrypted database
  - Retention: 7 years

Risk Assessment (ID.RA)¶

Understand your threats and vulnerabilities

Simple Risk Matrix:

Risk Assessment Template:

risk_assessment:
  threat: Unauthorized database access
  vulnerability: Weak password policy
  asset: Customer database
  likelihood: Medium
  impact: High
  risk_level: High
  mitigation:
    - Implement MFA
    - Enforce strong password policy
    - Monitor failed login attempts
  owner: Security Team
  due_date: 2025-02-28

Risk Management Strategy (ID.RM)¶

Decide how to handle risks

2. PROTECT¶

Purpose: Implement safeguards to ensure delivery of critical services

Access Control (PR.AC)¶

Control who accesses what

Identity and Access Management:

User Authentication → Role Assignment → Permission Grants → Access Logging

Practical Implementation:

# rbac-policy.yml
roles:
  developer:
    permissions:
      - read:code
      - write:code
      - read:dev-environment
    mfa_required: false

  senior_developer:
    inherits: developer
    permissions:
      - deploy:staging
      - read:production-logs
    mfa_required: true

  platform_engineer:
    permissions:
      - deploy:production
      - manage:infrastructure
      - read:sensitive-data
    mfa_required: true
    approval_required: true

Data Security (PR.DS)¶

Protect information at rest and in transit

Data Protection Checklist:

• Encrypt sensitive data at rest (AES-256)
• Encrypt all network traffic (TLS 1.3+)
• Implement data loss prevention (DLP)
• Classify and label data
• Secure data deletion procedures
• Regular data backup verification

Environment Variable Management:

# Bad Practice
DATABASE_URL="postgres://user:password@localhost/db"

# Good Practice
# Store in secret management system
# Reference via: $(vault kv get secret/database/url)

# Development: Use .env files (not committed)
# Production: Use AWS Secrets Manager, HashiCorp Vault, etc.

Security Awareness Training (PR.AT)¶

Educate users and stakeholders

Training Program:

• New Hire: Security orientation (Day 1)
• Annual: Refresher training (mandatory)
• Phishing Simulations: Quarterly
• Incident Response Drills: Bi-annually
• Security Champions: Monthly workshops

3. DETECT¶

Purpose: Identify occurrence of cybersecurity events

Continuous Monitoring (DE.CM)¶

Watch for anomalies and unauthorized activities

What to Monitor:

Monitoring Dashboard Setup:

# monitoring-config.yml
alerts:
  - name: suspicious_login_activity
    condition: failed_logins > 5 within 10m
    severity: high
    action: 
      - alert_security_team
      - temporary_account_lock

  - name: data_exfiltration_detected
    condition: outbound_traffic > baseline * 3
    severity: critical
    action:
      - alert_security_team
      - page_on_call_engineer
      - initiate_incident_response

Security Event Analysis (DE.AE)¶

Understand what's happening

Log Aggregation Example:

Application Logs → Log Collector → SIEM → Analysis → Alerts
     ↓                                         ↓
   (JSON)                              (Automated Response)

Structured Logging for Security Events:

{
  "timestamp": "2025-01-15T14:30:00Z",
  "severity": "WARNING",
  "event_type": "authentication_failure",
  "user_id": "user@example.com",
  "ip_address": "203.0.113.45",
  "user_agent": "Mozilla/5.0...",
  "failure_reason": "invalid_password",
  "attempt_count": 3,
  "account_locked": false
}

4. RESPOND¶

Purpose: Take action regarding detected cybersecurity incidents

Response Planning (RS.RP)¶

Have a plan before incidents occur

Incident Response Team Structure:

Incident Commander (Decision authority)
    ├── Technical Lead (Containment & recovery)
    ├── Communications Lead (Internal & external comms)
    ├── Legal Representative (Compliance & legal)
    └── Business Representative (Business impact assessment)

Incident Response Playbook:

1. Phishing Email Incident

### Detection
- User reports suspicious email
- Security team analyzes email headers/links

### Containment
- Block sender domain
- Remove email from all mailboxes
- Revoke compromised credentials (if clicked)

### Recovery
- Password reset for affected users
- Scan systems for malware
- Monitor for further activity

### Lessons Learned
- Update email filters
- Additional phishing awareness training

2. Suspicious Database Access

### Detection
- Monitoring alerts on unusual query patterns
- Data export activity outside business hours

### Containment
- Suspend suspicious user account
- Block IP address
- Preserve logs for forensics

### Investigation
- Review access logs
- Interview account owner
- Check for data exfiltration

### Recovery
- Revoke compromised credentials
- Strengthen access controls
- Notify affected parties if data compromised

Communications (RS.CO)¶

Keep stakeholders informed

Communication Matrix:

5. RECOVER¶

Purpose: Restore capabilities or services impaired by cybersecurity incidents

Recovery Planning (RC.RP)¶

Plan for business continuity

Recovery Time Objectives (RTO) by System:

Recovery Procedure Template:

## System Recovery: Production Database

### Prerequisites
- [ ] Incident contained and threat eliminated
- [ ] Backup verified and accessible
- [ ] Restoration environment prepared
- [ ] Stakeholders notified

### Recovery Steps
1. Verify backup integrity (checksum validation)
2. Restore database to recovery environment
3. Validate data integrity and completeness
4. Test application connectivity
5. Switch traffic to recovered system
6. Monitor for 24 hours

### Validation Criteria
- All critical data present
- Application functions normally
- Performance within acceptable range
- No recurring security issues

### Rollback Plan
If recovery fails: [Document fallback procedures]

Improvements (RC.IM)¶

Learn from incidents

Post-Incident Review Template:

## Incident Post-Mortem: [Incident ID]

### Incident Summary
- **Date**: 2025-01-15
- **Duration**: 3 hours
- **Severity**: High
- **Impact**: Payment processing delayed

### Timeline
- 14:00 - Incident detected
- 14:15 - Incident commander assigned
- 14:30 - Issue contained
- 15:45 - Service restored
- 17:00 - All-clear given

### What Went Well
- Detection within 5 minutes
- Clear communication
- Effective containment

### What Needs Improvement
- Backup restoration took longer than expected
- Documentation outdated
- Monitoring gaps identified

### Action Items
- [ ] Update backup procedures (Owner: Ops Team, Due: 2025-02-01)
- [ ] Refresh documentation (Owner: Platform Team, Due: 2025-01-30)
- [ ] Implement additional monitoring (Owner: Security, Due: 2025-02-15)

NIST CSF Implementation Tiers¶

Choose your target maturity level:

Quick Implementation Checklist¶

Foundation¶

• Identify critical assets
• Conduct initial risk assessment
• Establish incident response team
• Set up basic monitoring