Regulatory Compliance Frameworks#

Regulatory compliance translates legal requirements into technical controls. Understanding which regulations apply to your system and mapping them to infrastructure and application design is a core engineering responsibility in regulated industries.

This guide covers four major frameworks and their practical implications for software architecture. These are not exhaustive compliance guides — they map the most impactful technical controls for each framework.

HIPAA (Health Insurance Portability and Accountability Act)#

HIPAA applies to organizations handling Protected Health Information (PHI) — any data that can identify a patient and relates to their health condition, treatment, or payment.

Who It Applies To#

• Covered entities: Healthcare providers, health plans, healthcare clearinghouses.
• Business associates: Any organization that handles PHI on behalf of a covered entity (cloud providers, SaaS vendors, contractors).

If your system touches PHI, HIPAA applies to you. This includes storing, processing, transmitting, or even logging PHI.

Technical Controls#

Encryption:

PHI at rest → AES-256 encryption (mandatory in practice)
PHI in transit → TLS 1.2+ (mandatory)
Encryption keys → Separate from encrypted data, managed via KMS
Backup encryption → Same standard as primary storage

HIPAA does not technically mandate encryption — it calls it an “addressable” safeguard. In practice, not encrypting PHI requires a documented risk assessment explaining why encryption is not reasonable. No auditor accepts that argument. Encrypt everything.

Access controls:

# Role-based access to PHI
roles:
  clinician:
    - read: patient_records (assigned patients only)
    - write: clinical_notes
  billing:
    - read: billing_records
    - read: patient_demographics (no clinical data)
  admin:
    - read: audit_logs
    - manage: user_accounts
  developer:
    - access: NONE to production PHI

• Unique user identification — no shared accounts.
• Automatic logoff — sessions timeout after inactivity.
• Emergency access — break-glass procedures with audit trail.
• Minimum necessary — access only the PHI needed for the specific task.

Audit logging:

Every access to PHI must be logged:

{
  "timestamp": "2026-02-21T14:23:01Z",
  "user_id": "clinician-456",
  "action": "read",
  "resource": "patient_record",
  "resource_id": "patient-789",
  "ip_address": "10.0.1.50",
  "result": "success",
  "justification": "assigned_care_team"
}

Retain audit logs for a minimum of 6 years. Store logs in tamper-evident storage (write-once, append-only). Monitor for anomalous access patterns.

Infrastructure:

Production Environment (PHI)
├── Isolated VPC / network segment
├── No developer access to production data
├── Database encryption (AES-256, KMS-managed keys)
├── TLS termination at load balancer
├── mTLS between internal services
├── Audit logging on all data access
├── Automatic backup encryption
└── BAA (Business Associate Agreement) with all vendors

The BAA is critical. Every cloud provider, SaaS tool, and third-party service that could access PHI must have a signed BAA. AWS, Azure, and GCP all offer HIPAA BAAs, but you must explicitly enable them and configure services according to their HIPAA guidance.

De-Identification#

HIPAA allows use of health data without restrictions if it is properly de-identified. Two methods:

• Expert determination: A statistician certifies the risk of identification is very small.
• Safe harbor: Remove 18 specific identifiers (name, dates, SSN, zip code beyond first 3 digits, etc.).

De-identified data is not PHI. This enables analytics, ML training, and research without HIPAA constraints.

FedRAMP (Federal Risk and Authorization Management Program)#

FedRAMP standardizes security assessment and authorization for cloud services used by US federal agencies. If you sell cloud services to the federal government, you need FedRAMP authorization.

Impact Levels#

Most commercial cloud services target FedRAMP Moderate.

Key Technical Controls (NIST 800-53)#

FedRAMP maps to NIST SP 800-53 controls. The most impactful for infrastructure:

AC (Access Control):

AC-2: Account Management
  - Automated account provisioning/deprovisioning via SSO (SCIM)
  - Disable inactive accounts after 90 days
  - Review all accounts quarterly

AC-6: Least Privilege
  - Role-based access with documented justifications
  - Privileged access via just-in-time (JIT) elevation
  - Separate admin accounts from daily-use accounts

AC-17: Remote Access
  - MFA on all remote access
  - Encrypted tunnels (VPN or zero-trust proxy)
  - Session recording for privileged access

AU (Audit and Accountability):

AU-2: Audit Events
  - Authentication successes and failures
  - Privilege escalation
  - Data access and modification
  - System configuration changes
  - All administrative actions

AU-6: Audit Review
  - Automated analysis of audit logs
  - Alert on anomalous patterns
  - Weekly human review of flagged events

AU-9: Protection of Audit Information
  - Write-once storage (S3 Object Lock, immutable blob storage)
  - Separate access controls from operational systems
  - Encrypt audit logs at rest and in transit

SC (System and Communications Protection):

SC-8: Transmission Confidentiality
  - TLS 1.2+ on all connections (FIPS-approved cipher suites)
  - mTLS between internal services

SC-13: Cryptographic Protection
  - FIPS 140-2/140-3 validated modules (see FIPS article)

SC-28: Protection of Information at Rest
  - AES-256 encryption for all data stores
  - KMS-managed keys with automatic rotation

SC-7: Boundary Protection
  - Network segmentation between tiers
  - WAF on public endpoints
  - IDS/IPS on network boundaries

CM (Configuration Management):

CM-2: Baseline Configuration
  - Infrastructure as code (Terraform, CloudFormation)
  - Immutable infrastructure (no manual changes)
  - Configuration drift detection

CM-6: Configuration Settings
  - CIS benchmark compliance (automated scanning)
  - Hardened OS images (no unnecessary packages)
  - Documented deviations with risk acceptance

Continuous Monitoring (ConMon)#

FedRAMP requires ongoing monitoring, not just point-in-time assessment:

• Monthly vulnerability scans of all systems.
• Annual penetration testing.
• Continuous inventory of all assets.
• Monthly POA&M (Plan of Action and Milestones) updates for known issues.
• Significant change reporting within 30 days.

ITAR (International Traffic in Arms Regulations)#

ITAR controls the export of defense-related articles, services, and technical data. It is administered by the US State Department’s Directorate of Defense Trade Controls (DDTC).

What It Means for Infrastructure#

• US persons only. Only US citizens, permanent residents, or protected persons can access ITAR-controlled data. This includes cloud operations staff, customer support, and developers.
• US-only infrastructure. ITAR data must be stored and processed on infrastructure located within the United States, managed by US persons.
• No foreign access. Cloud providers must guarantee that no non-US-person employee can access the data, even for support or maintenance.

Cloud Options for ITAR#

Standard commercial cloud regions (even us-east-1) are not sufficient for ITAR because non-US-person employees may have operational access.

Technical Controls#

Data Access:
  - US-person verification on all accounts with data access
  - Separation of ITAR and non-ITAR workloads
  - No shared databases or storage between ITAR and commercial

Network:
  - ITAR workloads in isolated VPC/network
  - No peering with non-ITAR networks
  - All traffic encrypted (FIPS-validated TLS)

Audit:
  - Log all access to ITAR data
  - Include accessor nationality verification in audit trail
  - Retain logs per DDTC requirements

Export Controls:
  - Prevent data export to non-US destinations
  - Block cross-region replication to non-US regions
  - Monitor and alert on any data egress

SOX (Sarbanes-Oxley Act)#

SOX applies to publicly traded companies and focuses on financial reporting integrity. Section 404 requires internal controls over financial reporting, which includes the IT systems that process financial data.

IT Controls for SOX#

SOX does not prescribe specific technical controls. It requires that controls exist to ensure financial data integrity, and that those controls are auditable. In practice:

Change management:

Requirements:
  - All changes to financial systems go through documented approval
  - Separation of duties: developer cannot approve their own change
  - Production deployments require change ticket with approval chain
  - Rollback procedures documented and tested

Implementation:
  - GitOps with PR approval requirements (minimum 2 reviewers)
  - Protected branches on main/production
  - Automated deployment pipelines (no manual production access)
  - Change tickets linked to commits and deployments

Access controls:

Requirements:
  - Segregation of duties between development and operations
  - No developer access to production financial databases
  - Quarterly access reviews with documented evidence
  - Privileged access tracked and time-limited

Implementation:
  - Separate IAM roles for dev, staging, production
  - Break-glass procedures for production access (logged, time-limited)
  - Automated access reviews via identity provider reports
  - JIT access for production debugging (auto-revoke after 4 hours)

Audit trail:

Requirements:
  - All changes to financial data must be traceable
  - Who changed what, when, and why
  - Immutable audit logs (cannot be altered or deleted)

Implementation:
  - Database-level audit logging (all INSERT, UPDATE, DELETE on financial tables)
  - Application-level audit events for business operations
  - Write-once log storage (S3 Object Lock, Azure immutable blob)
  - Log retention: 7 years minimum

Data integrity:

Requirements:
  - Financial data must be accurate and complete
  - Reconciliation between systems must be automated
  - Errors must be detected and corrected promptly

Implementation:
  - Input validation at every system boundary
  - Automated reconciliation jobs (daily, with alerts on discrepancies)
  - Checksums on financial data transfers between systems
  - Database constraints (NOT NULL, CHECK, foreign keys) on financial tables

Cross-Framework Control Mapping#

Many controls satisfy multiple frameworks simultaneously:

Implementing the strictest version of each control often satisfies all applicable frameworks. Design for the most restrictive regulation first and relax for less restrictive contexts.

Common Mistakes#

1. Treating compliance as a checklist rather than architecture. Compliance controls should be baked into the system design, not bolted on before an audit. Retrofitting is expensive and fragile.
2. Not signing BAAs with all data processors. For HIPAA, every vendor touching PHI needs a BAA. Forgetting a logging service or analytics tool that receives PHI creates a compliance gap.
3. Using commercial cloud regions for ITAR. Standard AWS/Azure/GCP regions do not meet ITAR access control requirements. Use GovCloud or equivalent government regions.
4. Implementing SOX controls only on the financial application. SOX covers the entire chain: infrastructure, databases, CI/CD pipelines, monitoring systems. If a developer can push to production without approval, the change management control fails regardless of application-level controls.
5. Not testing controls continuously. An audit finding that controls existed 12 months ago but were disabled 6 months ago is a failure. Automated compliance scanning (daily or continuous) catches drift before auditors do.