Compliance & Governance

Enterprise architects must understand compliance requirements and governance frameworks. This knowledge demonstrates business acumen alongside technical expertise.

Compliance Frameworks

Common Standards

Standard	Industry	Key Requirements
SOC 2	SaaS/Tech	Security, availability, confidentiality
HIPAA	Healthcare	PHI protection, audit trails
PCI DSS	Finance	Cardholder data security
GDPR	EU Data	Data privacy, consent, right to erasure
FedRAMP	US Government	Security controls, continuous monitoring
ISO 27001	Global	Information security management

AWS Compliance Programs

AWS maintains compliance certifications that customers can inherit:

Certification	Benefit	Customer Responsibility
SOC 1/2/3	Financial controls audited	Application-level controls
HIPAA	BAA available	PHI handling policies
PCI DSS Level 1	Infrastructure compliant	Application PCI controls
ISO 27001	Security framework	Implement controls
FedRAMP High	Government approved	Customer-side controls

Interview Question: HIPAA Architecture

Q: "Design a HIPAA-compliant architecture for a healthcare application."

A: Layered compliance approach:

HIPAA Architecture
├── Network Layer
│   ├── Private subnets for PHI
│   ├── VPN/Direct Connect only
│   └── No public internet access for PHI
├── Data Layer
│   ├── Encryption at rest (KMS)
│   ├── Encryption in transit (TLS)
│   └── Field-level encryption for SSN, DOB
├── Access Layer
│   ├── Role-based access (IAM)
│   ├── MFA required
│   └── Break-glass procedures logged
├── Audit Layer
│   ├── CloudTrail (all regions)
│   ├── VPC Flow Logs
│   └── Application audit logs
└── Administrative
    ├── BAA with AWS signed
    ├── Employee training documented
    └── Incident response plan

AWS Governance Tools

AWS Organizations

Structure for multi-account governance:

Organization Root
├── Core OU
│   ├── Security Account
│   ├── Logging Account
│   └── Network Account
├── Production OU
│   ├── Prod Account A
│   └── Prod Account B
├── Non-Production OU
│   ├── Dev Account
│   └── Staging Account
└── Sandbox OU
    └── Sandbox Account

Service Control Policies (SCPs)

SCP Type	Purpose	Example
Deny List	Block specific actions	Deny EC2 in non-approved regions
Allow List	Permit only specific	Only allow approved services
Guardrails	Prevent risky changes	Prevent CloudTrail disable

Example: Region Restriction SCP

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

AWS Config

Feature	Use Case
Configuration Recording	Track all resource changes
Conformance Packs	Pre-built compliance rules
Remediation	Auto-fix non-compliant resources
Aggregation	Multi-account compliance view

Interview Question: Governance at Scale

Q: "How would you implement governance for 100+ AWS accounts?"

A: Centralized governance model:

1. AWS Organizations

   • OU structure by environment/business unit
   • SCPs for guardrails
   • Consolidated billing

2. Control Tower

   • Landing zone automation
   • Account factory for provisioning
   • Guardrails (preventive + detective)

3. Centralized Services

   • Security Hub aggregation
   • Config aggregator
   • CloudTrail organization trail

4. Automation

   • Account vending machine
   • Baseline CloudFormation StackSets
   • Automated compliance reporting

Data Governance

Data Classification

Classification	Examples	Controls
Public	Marketing materials	Minimal
Internal	Employee data	Encryption, access control
Confidential	Customer PII	Encryption, audit, DLP
Restricted	Payment data, PHI	All above + additional

Data Residency

Requirement	Implementation
Region restriction	SCPs, AWS Config rules
Cross-border transfer	Legal review, encryption
Data localization	Single-region deployment
Backup location	Same-region backup policies

Data Lifecycle

Creation → Classification → Storage → Use → Archival → Deletion
    ↓           ↓             ↓        ↓        ↓          ↓
Tagging    Auto-classify   Tiering  Access   Glacier   Secure
           (Macie)         (S3)     Logs     (S3)      Delete

Audit and Reporting

Audit Trail Requirements

Log Type	Service	Retention
API Calls	CloudTrail	7 years (compliance)
Network	VPC Flow Logs	1 year
Application	CloudWatch Logs	Per requirement
Database	RDS/Aurora logs	Per requirement

Compliance Reporting

Tool	Function
AWS Artifact	Download compliance reports
Security Hub	Compliance score dashboard
Config	Compliance timeline
Audit Manager	Automated evidence collection

Interview Question: Audit Readiness

Q: "How do you prepare for a SOC 2 audit?"

A: Continuous compliance approach:

1. Evidence Collection (Audit Manager)

   • Automated evidence gathering
   • Control mapping to SOC 2

2. Continuous Monitoring

   • Config rules for each control
   • Security Hub for posture
   • Automated alerting on drift

3. Documentation

   • Architecture diagrams current
   • Runbooks documented
   • Change management logs

4. Pre-Audit

   • Internal assessment
   • Gap remediation
   • Mock audit walkthrough

Cloud Governance Best Practices

Governance Framework

Component	Implementation
Policies	Written, versioned, accessible
Standards	Technical requirements documented
Procedures	Step-by-step runbooks
Guidelines	Best practices, recommendations

Change Management

Request → Review → Approve → Implement → Verify → Close
   ↓        ↓        ↓          ↓          ↓       ↓
Ticket   CAB or   Workflow   CI/CD     Testing  Audit
         Auto-     (SNS)     Pipeline   Checks   Log
         approve

Key Insight: Compliance is not a one-time achievement—it's continuous. Automate compliance checks, evidence collection, and remediation to maintain audit readiness at scale.

Next module: Behavioral and negotiation strategies for architect interviews. :::