← All posts

Cloud · August 14, 2025 · intSignal Cloud Team

Cloud Compliance: Mapping SOC 2 and HIPAA to Your Architecture

The shared responsibility line moves when the framework does

Every cloud provider publishes a shared responsibility model, and most teams can recite the headline: the provider secures the cloud, you secure what you put in it. What the diagram never shows is where that line sits for compliance. An auditor does not accept "AWS handles that" as a control. They ask for your evidence, mapped to your scope, for the systems that touch regulated data.

The provider gives you a compliant substrate — a data center, a hypervisor, a managed database engine that can be encrypted. Turning that capability into a control is your job. A managed key service exists; whether your snapshots use it is a configuration you own. Audit logging is available; whether it is enabled in every region, retained long enough, and actually reviewed is on you. SOC 2 and HIPAA both live almost entirely on your side of the line, and both come down to the same handful of configuration domains.

Translating controls into cloud configuration

Frameworks are written in the language of policy. Your cloud is configured in the language of resources. The work of cloud compliance is the translation between them. Five domains carry most of the weight for both SOC 2's Common Criteria and the HIPAA Security Rule.

  • Encryption. Data at rest encrypted with managed keys, key rotation enabled, and TLS enforced in transit. For HIPAA this is the addressable encryption specification you almost always implement rather than document a reason not to; for SOC 2 it maps to confidentiality criteria. In practice: no unencrypted volumes, buckets, snapshots, or database instances, and no plaintext internal traffic.
  • Access. Least-privilege IAM, mandatory MFA, no long-lived root or access keys, and quarterly access reviews that are documented and acted on. This single domain generates more audit exceptions than any other.
  • Logging. Centralized, tamper-resistant audit trails (CloudTrail, Azure Activity Logs, GCP Cloud Audit Logs) enabled in every region and account, with retention that covers your audit window — 90 days hot at a minimum, a year is safer, and HIPAA guidance points to six years for some records.
  • Backup and recovery. Immutable, tested backups with defined RPO/RTO. An untested backup is not a control; auditors ask for restore evidence, not just a backup job that reports success.
  • Change management. Every production change flows through version control and review, with an approval trail. Pull request approvals and CI/CD logs are the artifacts that satisfy this, which is why change management and IaC end up tightly coupled.

Cloud compliance checklist mapping encryption, access, logging, backup, and change management controls to configuration evidence Figure: each framework requirement resolves to a concrete cloud setting and a timestamped artifact that proves it ran — the mapping is the real deliverable.

The point of the mapping exercise is that a requirement written as prose — "the entity restricts logical access" — resolves to a specific, checkable setting: this IAM policy, this MFA enforcement flag, this access review ticket. Once every requirement points at a resource and an artifact, compliance stops being a narrative and becomes something you can measure continuously.

Continuous compliance with CSPM and IaC guardrails

The old model was an annual scramble: freeze changes, screenshot consoles, assemble a binder, pass the audit, then drift for eleven months until the next one. Cloud moves too fast for that. Environments change hourly, and a "let me just open this port to test" becomes a permanent finding nobody remembers creating. Continuous compliance replaces the scramble with two mechanisms that run all the time.

Cloud Security Posture Management reads your control plane through provider APIs and evaluates every resource against a baseline — CIS Benchmarks, provider best practices, and framework mappings for SOC 2 and HIPAA. The same scan that finds a public bucket rolls that finding up into both the security queue and the compliance report. Because it is agentless and continuous, drift surfaces in minutes rather than at the next fieldwork. Our Cloud Security Posture Management practice tunes the baseline to your architecture so the queue reflects real risk instead of ten thousand undifferentiated "medium" findings.

Infrastructure as code guardrails stop the misconfiguration before it ships. Detection alone is a treadmill; the durable fix is to push it left:

  1. Fix the code, not the resource. Correct the Terraform module or Bicep template so the desired state is compliant. A console toggle gets reverted by the next deploy.
  2. Policy as code in CI. Run Checkov, tfsec, or Open Policy Agent on every pull request so an unencrypted volume or a public ACL is blocked before merge.
  3. Preventive guardrails at the org level. AWS Service Control Policies, Azure Policy, and GCP Organization Policy make whole classes of violation impossible — deny public bucket ACLs org-wide, require encryption, block root key creation.
  4. Auto-remediation for the safe cases. For high-confidence, low-blast-radius issues, an automated workflow reverts the change and opens a ticket in seconds.

Wiring these into how infrastructure is provisioned is a core part of how we run cloud infrastructure for regulated clients. The measure of success is that the number of findings reaching production keeps falling cycle over cycle, and CSPM becomes the safety net rather than the front line.

Evidence collection and audit automation

SOC 2 Type II and HIPAA assessments are, at bottom, evidence exercises. The auditor picks samples across your window and asks you to prove the control ran on the dates they chose. The teams that pass without pain are the ones collecting evidence continuously instead of reconstructing it under deadline.

A good rule: if a control cannot produce a timestamped artifact on demand, it is not audit-ready. Map each artifact to its source and let the pipeline emit it:

  • Access: provisioning and deprovisioning tickets, quarterly access review sign-offs, MFA enforcement configuration, privileged-account inventory.
  • Change management: pull requests with approvals and CI/CD logs showing review before production.
  • Monitoring: log retention proof, alert samples with response timestamps, and incident tickets with post-incident notes.
  • Vulnerability and patch: scan results, remediation tickets, and evidence you met your own SLA.
  • Encryption and backup: key configuration, encryption status reports, and successful restore tests.

Modern compliance-automation platforms integrate directly with your cloud, IdP, ticketing, and code repositories to pull most of this automatically and map it to the relevant criteria as work happens. That turns fieldwork from a month of screenshotting into a review of an already-assembled evidence set. The governance layer that keeps criteria, mappings, and exceptions current is what our security and compliance service is built to run between audits, not just during them.

Multi-framework overlap: measure once, report many

The reason continuous compliance pays off is that frameworks overlap heavily at the control level even when their language differs. Encryption, access control, logging, and incident response appear in nearly every regime. The underlying cloud settings are identical; only the mapping and the report change.

  • SOC 2 Common Criteria, the HIPAA Security Rule, PCI DSS 4.0, ISO 27001, and NIST 800-53 all demand access control, audit logging, encryption, and change management.
  • One well-instrumented CSPM scan can satisfy the security team, the SOC 2 auditor, and the HIPAA assessor simultaneously.
  • A single access-review process, run quarterly with documented sign-off, serves every framework you carry.

The practical strategy is to build to the strictest applicable control once, then use crosswalk mappings — many are published by CIS and the frameworks themselves — to produce each report from the same evidence. A team subject to both SOC 2 and HIPAA should not run two programs; it should run one control set mapped two ways. That is where the effort of doing the translation carefully at the start returns compounding value, because every new framework becomes a mapping exercise rather than a fresh build.

Where to start

If you are not certain which of your cloud resources are unencrypted, publicly reachable, or over-privileged right now, that uncertainty is itself the first finding. A focused posture assessment across your accounts will surface the exposed resources and the control gaps in days, mapped to SOC 2 and HIPAA, and hand you an IaC-ready remediation plan instead of a spreadsheet nobody will finish.

intSignal maps your frameworks to concrete cloud configuration, stands up the CSPM and IaC guardrails that keep you compliant continuously, and automates the evidence pipeline so audits become a review rather than a fire drill. Talk to our cloud team and we will scope the controls, size the gaps, and get your architecture audit-ready across every framework you carry.