| name | compliance-architecture |
| description | Enterprise-grade compliance architecture for SOC 2, HIPAA, GDPR, PCI-DSS. Provides compliance checklists, security controls, audit guidance, and regulatory requirements for serverless and cloud architectures. Activates for compliance, HIPAA, SOC2, SOC 2, GDPR, PCI-DSS, PCI DSS, regulatory, healthcare data, payment card, data protection, audit, security standards, regulated industry, BAA, business associate agreement, DPIA, data protection impact assessment. |
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:
-
Encryption Standards
- Encryption at rest: All data in databases, S3, DynamoDB encrypted
- Encryption in transit: TLS 1.2+ for all API communications
- Key management: Customer-managed keys (KMS, Key Vault, GCP KMS)
- Regular key rotation: Annual minimum or per compliance policy
-
Access Logging and Retention
- CloudTrail (AWS), Activity Log (Azure), Cloud Audit Logs (GCP)
- Minimum retention: 90 days (24 months recommended)
- Centralized log aggregation: ELK Stack, Splunk, or cloud-native
- Immutable audit logs: Write-once storage for compliance evidence
- Real-time alerting on unauthorized access attempts
-
Access Controls
- Least privilege IAM roles and policies
- No wildcard (*) permissions on sensitive resources
- Role-based access control (RBAC) by team/department
- Multi-factor authentication (MFA) for humans
- Service-to-service authentication via temporary credentials
-
Change Management
- Documented change procedures with approval workflow
- Separation of duties: Developers, reviewers, approval authority
- Automated testing in CI/CD before production deployment
- Change logs with timestamps, author, and justification
- Rollback procedures documented and tested
HIPAA Compliance
Healthcare Data Protection Requirements:
-
Business Associate Agreement (BAA)
- Mandatory: Cloud provider must sign BAA before deployment
- Covers: AWS, Azure, GCP, managed services
- Do not use: Generic SaaS platforms without BAA
-
Encryption Requirements
- Encryption at rest: AWS KMS, Azure Key Vault, or GCP KMS
- Customer-managed keys (CMK): Not provider-managed default keys
- Encryption in transit: TLS 1.2+ for all PHI transfers
- Database encryption: All databases holding PHI (RDS, DynamoDB)
- S3/Blob encryption: All healthcare data storage
-
Audit Logging
- CloudTrail/Activity Log: All access to PHI systems
- Application logging: Access, modification, deletion events
- Retention: Minimum 6 years (state laws may require longer)
- Immutable storage: Prevent audit log tampering
-
Network Isolation
- VPC for database and processing: No public endpoints
- Security groups: Whitelist only necessary ports
- NACLs: Network ACLs for additional layer
- Private subnets: Database and sensitive compute resources
- VPN/Bastion for administrative access
-
No Public Endpoints
- API Gateway: Private endpoints, not public
- Lambda: Invoke only from VPC or authenticated clients
- Databases: Private subnets only
- S3: Block public access, bucket policies deny public
GDPR Compliance
European Data Protection Regulations:
-
Data Residency Controls
- EU data: Must reside in EU regions (eu-west-1, eu-central-1)
- Data localization: No automatic replication outside EU
- Backup regions: Only EU-based backup locations
- Processing: Ensure data processors operate in EU
- Documentation: Mapping of data to region/controller
-
Right to Erasure (Data Deletion)
- Deletion capabilities: Systems must support complete data removal
- Orphaned data: Periodic scans for disconnected/abandoned data
- Backup deletion: Timely deletion from backup systems
- Third-party deletion: Data deletion from all processors
- Compliance evidence: Document deletion execution and timing
- Foreign keys: Cascade deletes or documented orphaned records
-
Consent Management
- Consent records: Timestamp and version of every consent
- Granular consent: Separate for marketing, analytics, processing
- Easy withdrawal: Simple mechanisms to withdraw consent
- Documentation: Proof of consent for audits
- Cookie management: Consent before non-essential tracking
-
Data Portability
- Export formats: JSON, CSV, or standard formats
- Completeness: All data subject to export request
- Machine-readable: Structured data in machine-readable format
- Timing: Provide within 30 days of request
- No fees: Free data export (no extraction charges)
-
Privacy by Design
- Data minimization: Collect only necessary data
- Purpose limitation: Use data only for stated purposes
- Retention policies: Delete when no longer needed
- Default privacy: Private by default, not opt-in later
- Impact assessments: DPIA for new processing activities
PCI-DSS Compliance
Payment Card Data Protection (v3.2.1 or later):
-
Tokenization Requirements
- Never store raw card data: PAN, CVV, expiration
- Tokenization service: Stripe, Square, or PCI-compliant provider
- Token storage only: Systems never handle raw card data
- Scope reduction: Tokenization dramatically reduces PCI scope
-
Encryption Requirements
- Encryption at rest: All card data and keys in secure storage
- Encryption in transit: TLS 1.2+ minimum for all payments
- Key management: HSM (Hardware Security Module) recommended
- Key rotation: Annual minimum or per compliance policy
- Test keys: Separate test environment keys
-
Network Segmentation
- Cardholder data environment (CDE): Isolated network segment
- Firewalls: Between CDE and non-CDE systems
- Intrusion detection: IDS monitoring for CDE
- Testing: Regular penetration testing (quarterly minimum)
-
Regular Security Audits
- Quarterly vulnerability scans: External scanning service
- Annual penetration testing: By approved assessor
- Compliance validation: Annual SAQ or audit
- Incident response testing: Test breach response procedures
-
Secure Card Data Handling
- No storage of sensitive authentication data: CVC/CVV, PIN
- No storage of magnetic stripe data after auth
- Transaction logging: All card interactions logged
- 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 during creation
- Cannot be disabled after creation
❌ Missing HTTPS Enforcement
WRONG:
- API Gateway accepting HTTP traffic
- No redirect from HTTP to HTTPS
- Clients can connect via unencrypted channel
CORRECT:
- API Gateway: minimum TLS 1.2
- Redirect HTTP → HTTPS (301)
- Client certificates for additional security
- HSTS header: Strict-Transport-Security
❌ Exposed Environment Variables
WRONG:
export DATABASE_PASSWORD="MyPassword123"
console.log(process.env.DATABASE_PASSWORD) # In logs
CORRECT:
- Use AWS Secrets Manager, Azure Key Vault, GCP Secret Manager
- Inject as secret environment variables (redacted in logs)
- Never log secrets or sensitive configuration
- Rotate secrets annually
❌ Missing Network Isolation
WRONG:
- Lambda in public subnet with NAT
- Database accessible from internet
- No security groups restricting access
CORRECT:
- Lambda in private subnet
- Database in private subnet
- Security groups: Lambda → Database only
- No route to Internet Gateway from database subnet
Production Security Checklist
Before deploying to production, verify all items:
Identity & Access
Secrets Management
Encryption
Network Security
Data Protection
Logging & Monitoring
Deployment & CI/CD
Compliance & Auditing
Testing
When to Request Compliance Architecture
Request my help when:
- User mentions regulated industry (healthcare, finance, payment processing)
- Project involves customer data, personal information, or sensitive records
- Requirements specify SOC 2, HIPAA, GDPR, PCI-DSS, or other compliance
- User asks about security best practices or data protection
- Deployment involves cross-border data transfer
Integration with Security Agent
Coordinate with Security Agent for:
- Detailed threat modeling and risk assessment
- Security architecture review and hardening
- Incident response planning and testing
- Penetration testing coordination
- Vulnerability management processes
Remember: Compliance is not a checkbox exercise - it's about building secure, trustworthy systems that protect user data and meet legal obligations.
