Terraform vs Manual Cloud Setup: Which Reduces Healthcare Compliance Drift?

A cloud environment can pass a security review on Monday and fall outside its approved configuration by Friday. An engineer may temporarily open a firewall rule to troubleshoot an EHR integration. A new storage service may be deployed without the required encryption settings. Logging may be disabled during testing and never re-enabled. An emergency identity and access management role may remain active long after the incident ends.

Individually, these changes can appear minor. Together, they create healthcare compliance drift: the growing difference between the cloud environment an organization approved and the environment it is actually operating.

So, which approach better controls that risk: Terraform or manual cloud setup?

Terraform generally reduces healthcare compliance drift more effectively than manual configuration, but only when it is implemented as part of a governed DevSecOps operating model. 

Terraform by itself does not create HIPAA compliance. It must be supported by secure state management, version control, policy checks, cloud-native monitoring, change approvals, audit logging, and a controlled process for emergency changes.

What Is Healthcare Compliance Drift?

Compliance drift is an operational term for the gradual movement of infrastructure away from an organization’s approved security, privacy, resilience, and governance baseline.

In a healthcare cloud environment, the approved baseline may specify that:

• Databases containing electronic protected health information are encrypted.
• Storage services block public access.
• Administrative access requires approved identity controls.
• Security logs are enabled and centrally retained.
• Production workloads use private network paths.
• Backups follow approved retention and recovery requirements.
• Only authorized regions, services, machine types, and network routes are used.
• Changes receive security review before production deployment.

Drift occurs when the deployed environment no longer matches those requirements.

Terraform describes infrastructure through configuration files and maintains state that maps those definitions to real cloud resources. 

During a normal Terraform plan, Terraform reads the current settings of managed resources, compares them with the declared configuration, and proposes actions that would return the infrastructure to the desired state. Healthcare teams should think about drift in three related forms.

Configuration Drift

The deployed resource differs from the approved technical baseline. 

Examples include an unencrypted database, an altered network security rule, disabled diagnostic logging, changed backup retention, or a newly public endpoint.

Process Drift

A technically valid change bypasses the organization’s approved review and deployment workflow.

For example, an administrator may add a legitimate interface endpoint directly through the cloud console rather than submitting a pull request. 

The resulting configuration may work correctly, but the approval record, testing evidence, and infrastructure code no longer reflect production.

Evidence Drift

Compliance documentation no longer represents the current environment. An architecture diagram may show private storage while a recently created bucket is public. A control matrix may state that logging is mandatory even though a production account has stopped forwarding audit events.

This is particularly important under HIPAA because regulated entities must conduct an accurate and thorough assessment of risks to the confidentiality, integrity, and availability of all ePHI and implement measures that reduce identified risks to a reasonable and appropriate level. 

HHS also expects required policies, procedures, assessments, and related actions to be documented and periodically updated.

Why Manual Cloud Setup Creates More Drift

Manual setup means engineers create and modify infrastructure through cloud consoles, command-line tools, tickets, scripts, or operational runbooks without a consistently enforced declarative source of truth.

Manual administration is not automatically noncompliant. Experienced engineers can build secure environments manually. The problem is maintaining that consistency as the environment expands.

Different Engineers Make Different Decisions

Cloud consoles expose hundreds of configuration choices. Two engineers following the same architecture document may still select different defaults, naming conventions, network routes, encryption options, logging settings, or access policies.

These differences multiply across development, testing, staging, disaster recovery, and production.

Documentation Falls Behind Production

A runbook describes what an engineer was expected to configure. It does not prove that every setting was selected correctly or remained unchanged.

Screenshots and spreadsheets also become outdated as resources are added, replaced, scaled, or reconfigured.

Emergency Changes Become Permanent

Healthcare operations sometimes require urgent changes. An interface may stop exchanging ADT messages. A telehealth service may lose connectivity. An EHR migration may require temporary vendor access.

The immediate change may be justified. Drift appears when the temporary exception is not reviewed, reverted, or incorporated into the approved configuration after service is restored.

Review Happens After Deployment

With manual setup, security teams often review infrastructure after it exists. By that point, workloads may already contain ePHI, integrations may depend on the configuration, and remediation may require downtime.

Multi-Account and Multi-Cloud Environments Amplify Inconsistency

A control applied manually to one AWS account, Azure subscription, or Google Cloud project may be missed elsewhere. The problem becomes more pronounced when mergers, product teams, external implementation partners, and regional environments follow different operating practices.

The reviewed SERP sources correctly identify issues such as console changes, inconsistent firewall rules, repetitive configuration, identity drift, and missing audit context. 

However, healthcare organizations must go further by connecting those problems to ePHI boundaries, HIPAA documentation, Terraform state security, break-glass access, and formal remediation decisions.

How Terraform Reduces Healthcare Compliance Drift

Terraform changes the cloud operating model from “configure each resource correctly” to “define, review, and repeatedly enforce an approved desired state.”

1. Infrastructure Becomes Reviewable Code

Network rules, storage controls, encryption configuration, logging, identity bindings, databases, clusters, and other resources can be defined in text-based configuration.

The code can be stored in version control, where teams can review:

• Who requested the change
• Which resources will be affected
• Whether a security control is being removed
• Whether the change has clinical or operational impact
• Who approved the deployment
• Which code version produced the current environment

This supports configuration-management practices reflected in NIST SP 800-53 controls such as baseline configuration, configuration change control, configuration settings, and continuous monitoring. NIST guidance is not a substitute for HIPAA requirements, but it provides a useful structure for operating controlled cloud environments.

2. Environments Can Be Reproduced Consistently

A reviewed module can establish standard configurations for ePHI storage, private networking, audit logging, database encryption, backup policies, service identities, and resource tagging.

The same module can then be used across approved environments rather than rebuilding each environment through a series of console clicks.

This does not mean development and production must be identical. It means differences can be deliberate, parameterized, documented, and reviewable.

3. Plans Expose Proposed Changes Before Deployment

A Terraform plan shows what Terraform expects to add, change, replace, or destroy before an apply occurs. This creates an opportunity to identify potentially harmful changes such as:

• Removing database encryption
• Opening a network path to the internet
• Deleting a log destination
• Replacing a production database
• Modifying an identity policy
• Disabling backups
• Moving a resource into an unapproved region

The plan should be reviewed together with policy checks and security context. A technically accurate plan can still implement a poor or noncompliant design.

4. Policy as Code Can Stop Unsafe Changes

Policy engines can evaluate Terraform plans before deployment and block configurations that violate organizational rules.

A healthcare policy library might prohibit:

• Public storage containing ePHI
• Databases without encryption
• Internet-accessible administrative ports
• Unapproved cloud regions
• Resources without data-classification tags
• Disabled audit logging
• Excessive wildcard permissions
• Production resources without backup policies
• Deletion of required security services

HCP Terraform, for example, can enforce Sentinel policies during its run workflow, including mandatory policies that stop a run when a check fails. Google Cloud’s Terraform policy-validation workflow can evaluate Terraform plan data and warn or stop a deployment before it reaches production.

5. Scheduled Plans Can Detect Out-of-Band Changes

If someone changes a Terraform-managed resource through the cloud console, a later plan can reveal the difference between the actual resource and the declared configuration.

HCP Terraform health assessments use non-actionable refresh-only plans to compare real resource settings with infrastructure tracked in the workspace. Teams can then decide whether to restore the code-defined configuration or formally accept and codify the external change.

Terraform vs Manual Cloud Setup

Evaluation Area	Manual Cloud Setup	Governed Terraform Workflow
Configuration consistency	Depends heavily on individual execution	Reusable modules establish repeatable baselines
Pre-deployment review	Often ticket or checklist based	Code, plan, and policy results can be reviewed
Change attribution	Distributed across tickets and cloud logs	Git history, pipeline records, and cloud logs
Drift detection	Usually periodic or incident-driven	Scheduled plans can identify managed-resource drift
Policy enforcement	Engineer follows written requirements	Automated checks can block prohibited configurations
Environment replication	Requires repeated manual work	Approved definitions can be reused
Emergency changes	Easy to make but easy to forget	Break-glass changes can be detected and reconciled
Unmanaged resources	Must be inventoried separately	Still requires cloud-native discovery and monitoring
Operational complexity	Lower initially, higher at scale	Higher implementation effort, stronger long-term control
Compliance evidence	Frequently assembled manually	Evidence can be generated from code and pipelines

Terraform Does Not Automatically Create HIPAA Compliance

Terraform is a provisioning and lifecycle-management tool. It does not determine whether an organization has correctly interpreted HIPAA, completed an adequate risk analysis, signed required BAAs, trained its workforce, created incident-response procedures, or tested contingency plans.

HHS allows regulated entities to use cloud services for ePHI when the appropriate BAA is in place, and the organization otherwise complies with the HIPAA Rules. HHS also states that the regulated entity must understand its cloud environment, perform its own risk analysis, and establish suitable risk-management policies.

As of August 2026, the current HIPAA Security Rule remains in effect. The cybersecurity changes announced by HHS in December 2024 remain a proposed rule rather than a finalized replacement. Organizations may use the proposal to understand OCR’s direction, but should not present proposed requirements as current law.

Terraform also has several important limitations.

Terraform Sees What It Manages

Terraform primarily operates on resources declared in its configuration and mapped through its state. A resource created outside Terraform may remain invisible to a workspace until it is discovered and imported or detected through another inventory service.

Existing resources can be imported into Terraform, but import requires both an appropriate resource configuration and a correct state mapping. Importing a resource into state without reconciling its full configuration can result in unexpected changes during the next plan.

Refresh-Only Is Not Drift Remediation

A refresh-only operation updates Terraform state to reflect external changes. It does not restore the real infrastructure or update the Terraform configuration.

Therefore, blindly applying a refresh-only plan can effectively acknowledge the new real-world state without resolving the difference between production and the approved code. 

Teams should first decide whether the external change must be reverted, accepted and codified, or handled as a temporary exception.

ignore_changes Can Hide Important Differences

Terraform’s ignore_changes lifecycle setting allows another process to manage selected resource attributes. This can be useful when responsibility is intentionally shared, but broad use can prevent Terraform from proposing corrections for security-relevant attributes.

Every ignored attribute should have a documented owner, monitoring method, justification, and review date.

Terraform State Is a Security Asset

Terraform state and saved plan files can contain detailed infrastructure metadata and sensitive values. Marking a value as sensitive hides it from normal command output, but does not necessarily prevent it from being stored in state.

Healthcare organizations should use remote state storage, encryption, access controls, state locking, audit logging, and short-lived provider credentials. State files should never be committed to an ordinary Git repository.

The Recommended Healthcare Drift-Control Architecture

Terraform should be one layer within a broader control system.

Layer 1: Approved Terraform Modules

Create controlled modules for common healthcare infrastructure patterns, including:

• Private application networks
• Encrypted relational databases
• Controlled object storage
• Centralized logging
• Backup and recovery policies
• Identity roles
• Container clusters
• Web application firewalls
• Key-management services
• Monitoring and alerting

Modules should provide secure defaults and restrict dangerous options rather than simply wrapping every cloud-provider setting.

Layer 2: Pull-Request-Based Change Control

Production changes should begin with a pull request containing:

• Business and technical justification
• Affected ePHI workflows
• Terraform plan output
• Security and policy results
• Rollback or recovery approach
• Named reviewers
• Approved maintenance window where required

Production apply permissions should be separated from routine code-authoring permissions.

Layer 3: Automated Validation

A typical pipeline should perform the following sequence:

• Format and validate Terraform configuration
• Scan code for prohibited infrastructure patterns
• Generate a Terraform plan
• Convert plan data into machine-readable output
• Evaluate policy-as-code controls
• Require human approval for protected environments
• Apply the reviewed plan
• Store deployment and approval evidence
• Run post-deployment compliance checks

Policy failures should stop production changes unless an authorized, logged exception process exists.

Layer 4: Cloud-Native Continuous Monitoring

Terraform should be paired with the cloud platform’s own configuration, policy, inventory, and audit services.

AWS recommends combining infrastructure as code with AWS Config to test and govern configurations. AWS Config conformance packs group rules and remediation actions, while AWS CloudTrail records AWS API activity, including identity, time, source address, request parameters, and response details.

Azure Policy evaluates resources against organizational standards and supports remediation for selected policy effects. Azure Activity Log records subscription-level administrative operations, including resource and role-assignment changes.

Google Cloud supports pre-deployment Terraform policy validation, while Cloud Audit Logs record administrative changes and, when enabled, data access activity.

These tools detect resources and events beyond the scope of a single Terraform state file.

Layer 5: Drift Triage and Remediation

Every drift alert should lead to one of four documented decisions:

1. Revert: Return the resource to the approved Terraform configuration.
2. Codify: Update the configuration because the external change was valid.
3. Import: Bring an approved unmanaged resource under Terraform management.
4. Except: Record a time-limited exception with an owner and expiration date.

Automatic remediation should be reserved for well-understood, low-risk controls. 

Automatically changing routing, identity, encryption, or production database settings without impact analysis can create outages or destroy access to critical clinical systems.

How to Handle Break-Glass Cloud Changes

Healthcare organizations need an emergency path for restoring care delivery, interface processing, patient access, or revenue-cycle operations.

A break-glass procedure should define:

• Who may make an emergency cloud change
• Which identities and roles may be used
• How access is approved and time-limited
• Which audit logs must be preserved
• When security leadership must be notified
• How quickly the change must be reviewed
• Whether Terraform should revert or codify the change
• How the exception is formally closed

The purpose is not to prohibit urgent action. It is to prevent an emergency workaround from becoming an undocumented permanent control failure.

HHS’s audit protocol emphasizes procedures for regularly reviewing information-system activity, including audit logs, access reports, and security-incident records. Cloud audit logs and Terraform reconciliation records should feed that review process rather than exist as isolated engineering data.

When Is Manual Cloud Setup Still Reasonable?

Manual configuration may remain reasonable when:

• Engineers are exploring services in a nonproduction environment with no ePHI.
• A resource is temporary, isolated, and scheduled for deletion.
• A provider does not yet expose the required resource through Terraform.
• An emergency production change follows the approved break-glass process.
• A small legacy environment is being inventoried before Terraform adoption.

Even in these cases, the organization should retain cloud audit logs, document the change, apply security policies, and decide whether the resource should later be imported into Terraform.

Manual setup becomes increasingly difficult to justify when the environment contains ePHI, serves production clinical workflows, spans multiple accounts or subscriptions, changes frequently, or must produce repeatable audit evidence.

Terraform or Manual Setup: The Final Decision

For production U.S. healthcare environments, Terraform is the stronger choice for reducing compliance drift.

It provides a repeatable infrastructure definition, supports pre-deployment review, enables policy enforcement, detects changes to managed resources, and produces better evidence than a process built primarily around cloud-console actions and written runbooks.

However, the winning model is not simply “Terraform instead of engineers.”

It is:

Terraform for desired state, policy as code for preventive controls, cloud-native services for continuous visibility, audit logs for attribution, and human governance for risk decisions.

Organizations that implement only the Terraform code may automate insecure infrastructure. 

Organizations that implement the full operating model can create a defensible, repeatable, and measurable approach to protecting healthcare cloud environments.

Reduce Healthcare Cloud Drift With CapMinds

CapMinds helps healthcare providers, health plans, healthcare SaaS companies, digital health organizations, and HIPAA business associates replace fragile cloud configuration processes with governed Infrastructure as Code.

Our healthcare cloud and DevSecOps services can support:

• AWS, Azure, and Google Cloud infrastructure assessment
• Terraform architecture and module development
• Existing-resource discovery and Terraform adoption
• Secure remote-state and identity design
• Policy-as-code implementation
• HIPAA-aligned cloud control mapping
• CI/CD security gates and approval workflows
• Multi-account and multi-cloud governance
• Drift detection and remediation workflows
• Logging, monitoring, backup, and disaster-recovery automation

Talk to a CapMinds healthcare cloud architect to assess where configuration drift is creating the greatest operational and compliance exposure.

Talk to a Healthcare Cloud Architect