compliance-architecture

Compliance Architecture Expert

I'm a specialist in enterprise compliance architecture across regulated industries. I help you design systems that meet regulatory requirements while maintaining operational efficiency.

When to Use This Skill

Ask me when you need help with:

• SOC 2 Type II compliance for SaaS applications
• HIPAA compliance for healthcare data systems
• GDPR compliance for European data protection
• PCI-DSS compliance for payment card processing
• Security architecture for regulated industries
• Audit preparation and evidence collection
• Compliance validation for serverless/cloud deployments

My Expertise

SOC 2 Type II Compliance

Core Requirements for Serverless:

1. Encryption Standards
2. Encryption at rest: All data in databases, S3, DynamoDB encrypted
3. Encryption in transit: TLS 1.2+ for all API communications
4. Key management: Customer-managed keys (KMS, Key Vault, GCP KMS)
5. Regular key rotation: Annual minimum or per compliance policy

1. Access Logging and Retention
2. CloudTrail (AWS), Activity Log (Azure), Cloud Audit Logs (GCP)
3. Minimum retention: 90 days (24 months recommended)
4. Centralized log aggregation: ELK Stack, Splunk, or cloud-native
5. Immutable audit logs: Write-once storage for compliance evidence
6. Real-time alerting on unauthorized access attempts

1. Access Controls
2. Least privilege IAM roles and policies
3. No wildcard (*) permissions on sensitive resources
4. Role-based access control (RBAC) by team/department
5. Multi-factor authentication (MFA) for humans
6. Service-to-service authentication via temporary credentials

1. Change Management
2. Documented change procedures with approval workflow
3. Separation of duties: Developers, reviewers, approval authority
4. Automated testing in CI/CD before production deployment
5. Change logs with timestamps, author, and justification
6. Rollback procedures documented and tested

HIPAA Compliance

Healthcare Data Protection Requirements:

1. Business Associate Agreement (BAA)
2. Mandatory: Cloud provider must sign BAA before deployment
3. Covers: AWS, Azure, GCP, managed services
4. Do not use: Generic SaaS platforms without BAA

1. Encryption Requirements
2. Encryption at rest: AWS KMS, Azure Key Vault, or GCP KMS
3. Customer-managed keys (CMK): Not provider-managed default keys
4. Encryption in transit: TLS 1.2+ for all PHI transfers
5. Database encryption: All databases holding PHI (RDS, DynamoDB)
6. S3/Blob encryption: All healthcare data storage

1. Audit Logging
2. CloudTrail/Activity Log: All access to PHI systems
3. Application logging: Access, modification, deletion events
4. Retention: Minimum 6 years (state laws may require longer)
5. Immutable storage: Prevent audit log tampering

1. Network Isolation
2. VPC for database and processing: No public endpoints
3. Security groups: Whitelist only necessary ports
4. NACLs: Network ACLs for additional layer
5. Private subnets: Database and sensitive compute resources
6. VPN/Bastion for administrative access

1. No Public Endpoints
2. API Gateway: Private endpoints, not public
3. Lambda: Invoke only from VPC or authenticated clients
4. Databases: Private subnets only
5. S3: Block public access, bucket policies deny public

GDPR Compliance

European Data Protection Regulations:

1. Data Residency Controls
2. EU data: Must reside in EU regions (eu-west-1, eu-central-1)
3. Data localization: No automatic replication outside EU
4. Backup regions: Only EU-based backup locations
5. Processing: Ensure data processors operate in EU
6. Documentation: Mapping of data to region/controller

1. Right to Erasure (Data Deletion)
2. Deletion capabilities: Systems must support complete data removal
3. Orphaned data: Periodic scans for disconnected/abandoned data
4. Backup deletion: Timely deletion from backup systems
5. Third-party deletion: Data deletion from all processors
6. Compliance evidence: Document deletion execution and timing
7. Foreign keys: Cascade deletes or documented orphaned records

1. Consent Management
2. Consent records: Timestamp and version of every consent
3. Granular consent: Separate for marketing, analytics, processing
4. Easy withdrawal: Simple mechanisms to withdraw consent
5. Documentation: Proof of consent for audits
6. Cookie management: Consent before non-essential tracking

1. Data Portability
2. Export formats: JSON, CSV, or standard formats
3. Completeness: All data subject to export request
4. Machine-readable: Structured data in machine-readable format
5. Timing: Provide within 30 days of request
6. No fees: Free data export (no extraction charges)

1. Privacy by Design
2. Data minimization: Collect only necessary data
3. Purpose limitation: Use data only for stated purposes
4. Retention policies: Delete when no longer needed
5. Default privacy: Private by default, not opt-in later
6. Impact assessments: DPIA for new processing activities

PCI-DSS Compliance

Payment Card Data Protection (v3.2.1 or later):

1. Tokenization Requirements
2. Never store raw card data: PAN, CVV, expiration
3. Tokenization service: Stripe, Square, or PCI-compliant provider
4. Token storage only: Systems never handle raw card data
5. Scope reduction: Tokenization dramatically reduces PCI scope

1. Encryption Requirements
2. Encryption at rest: All card data and keys in secure storage
3. Encryption in transit: TLS 1.2+ minimum for all payments
4. Key management: HSM (Hardware Security Module) recommended
5. Key rotation: Annual minimum or per compliance policy
6. Test keys: Separate test environment keys

1. Network Segmentation
2. Cardholder data environment (CDE): Isolated network segment
3. Firewalls: Between CDE and non-CDE systems
4. Intrusion detection: IDS monitoring for CDE
5. Testing: Regular penetration testing (quarterly minimum)

1. Regular Security Audits
2. Quarterly vulnerability scans: External scanning service
3. Annual penetration testing: By approved assessor
4. Compliance validation: Annual SAQ or audit
5. Incident response testing: Test breach response procedures

1. Secure Card Data Handling
2. No storage of sensitive authentication data: CVC/CVV, PIN
3. No storage of magnetic stripe data after auth
4. Transaction logging: All card interactions logged
5. Access controls: Minimize people accessing card data

Security Misconfiguration Warnings

Common Serverless Security Issues:

❌ Public S3 Buckets

WRONG:
- S3 bucket with public read access
- "Block public access" disabled
- Bucket policy allows s3:GetObject to "*"

CORRECT:
- Block public access: enabled
- Bucket policy: Only CloudFront, VPC endpoints, specific IAM roles
- Encryption: enabled with customer-managed keys

❌ Overly Permissive IAM Policies

WRONG:
{
  "Effect": "Allow",
  "Action": "s3:*",           # WILDCARD ACTION
  "Resource": "*"             # WILDCARD RESOURCE
}

CORRECT:
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::specific-bucket/specific-prefix/*",
  "Condition": {
    "IpAddress": {"aws:SourceIp": "10.0.0.0/8"}
  }
}

❌ Hardcoded Secrets

WRONG:
const apiKey = "sk_test_123456789abcdef";  // In code or env vars

CORRECT:
// AWS
const secret = await secretsManager.getSecretValue('api-key');

// Azure
const credential = new DefaultAzureCredential();
const client = new SecretClient(vaultUrl, credential);

// GCP
const [version] = await client.accessSecretVersion({name: secretName});

❌ Unencrypted Databases

WRONG:
- RDS without encryption
- DynamoDB without encryption
- DocumentDB without encryption

CORRECT:
- All databases encrypted at rest
- Customer-managed keys in KMS
- Encryption enabled durin