How Zero-Data-Retention CDC Architecture Satisfies HIPAA Business Associate and SOC 2 Scope Requirements

Zero-data-retention change data capture (CDC) can support HIPAA and SOC 2 requirements by streaming database changes to a warehouse without persisting payloads in middleware. This architecture removes an intermediate ePHI storage layer and its associated controls, but it does not eliminate Business Associate Agreement obligations or place the pipeline outside SOC 2 scope.

Why the location of data in a CDC pipeline determines compliance scope

A staging database, durable message queue, or cache gives replicated data another place to rest. That copy needs protection independently of the source database and destination warehouse, even if the pipeline deletes it shortly afterward. Temporary storage is still a storage layer. Operational logs can create the same problem when they record payloads rather than metadata, turning a diagnostic system into another repository of sensitive data.

The distinction becomes consequential when those payloads contain electronic protected health information, or ePHI. Persisting them introduces HIPAA safeguards for data at rest and adds systems for SOC 2 boundary assessment. A passthrough pipeline instead keeps data only in memory while it processes it and streams it forward without writing an intermediate copy. The source and destination still retain their data. What changes is whether the integration path adds another store, with its own access, retention, backup, and disposal obligations.

How log-based CDC reads data without ever writing it to middleware storage

Log-based CDC reads committed changes from the database’s own record of activity rather than creating a middleware database to track them. In traditional relational databases, the engine already writes the transaction log so it can recover from a crash. CDC reads that record and sends the changes on. The read mechanism permits a passthrough architecture, although a particular implementation can still add persistence after reading the log.

PostgreSQL logical decoding reads committed changes from the write-ahead log, or WAL, in commit order without writing to the source tables. It supports capturing deletes and old row values and delivering changes directly to a consumer. Replication slots still need active operational management. An inactive or lagging slot can cause WAL to accumulate in pg_wal, so engineers must monitor pg_replication_slots for active = false and set max_slot_wal_keep_size to prevent disk exhaustion.

Failover adds a separate slot-lifecycle concern. On PostgreSQL 17 and later, logical slots survive failover when created with the failover option and when the standby has sync_replication_slots, hot_standby_feedback, and primary_slot_name, identifying a physical replication slot, configured. On PostgreSQL 16 and earlier, logical slots do not survive failover. The operational assessment therefore needs to cover how slots are managed. The absence of middleware storage does not remove source-side replication requirements.

MongoDB Change Streams reads from the oplog and requires a replica set or sharded cluster. A standalone MongoDB instance has no oplog and cannot stream changes through this mechanism. DynamoDB Streams has a different storage boundary. It is a separate, opt-in feature that captures an ordered log of item-level modifications and retains records for up to 24 hours. A consumer that forwards those events immediately adds no persistence of its own, but that does not make the source stream retention-free.

What makes a vendor a HIPAA Business Associate, and what removes that trigger

Zero data retention does not remove Business Associate status when a vendor handles ePHI on behalf of a covered entity. Transient in-memory processing can still qualify as handling PHI. The trigger is the service’s involvement in creating, receiving, maintaining, or transmitting PHI, regardless of whether the vendor calls itself middleware or keeps a durable copy. Processing, transforming, or routing ePHI therefore cannot be treated as outside HIPAA merely because the operation is brief.

A Business Associate Agreement, or BAA, must be signed before the third-party integration service handles any ePHI. It specifies permitted uses, required safeguards, and breach notification responsibilities. Architecture and contract answer different questions here. Zero data retention describes whether the pipeline persists payloads, while the BAA governs the vendor’s obligations across its handling of PHI. HHS has issued fines for missing BAAs, with inadequate safeguards and improper disclosures creating separate penalty exposure.

The contractual simplification comes from removing obligations attached to an intermediate PHI store. Negotiation can focus on TLS encryption, infrastructure access controls, and incident notification rather than middleware payload retention, backup encryption, and data disposal. The subcontractor chain can shrink as well. A sync-and-cache design may involve a database host, cache provider, logging service, and backup vendor handling persisted PHI, each bringing safeguards and BAA coverage into the review. Passthrough removes those storage-specific relationships only where they genuinely do not exist, not where another service still handles ePHI in transit.

How the 2026 HIPAA Security Rule changes the cost of having a storage layer in the pipeline

The regulatory distinction in 2026 is between existing requirements and proposed changes. The proposed HIPAA Security Rule remained unfinalized as of late 2026, with a final rule targeted for July 2027. Its stricter provisions are therefore not current mandates on that basis. The proposal would remove the addressable-versus-required distinction across implementation specifications, making it clearer which controls are needed when more ePHI infrastructure is added.

The proposed controls discussed here include MFA when workforce members use interactive access to ePHI, AES-256 or equivalent encryption at rest, vulnerability scanning at least every 6 months, and a 72-hour recovery time objective that has been tested. Limited MFA exceptions exist for non-person entities in the proposal. These requirements should not be described as finalized. For a storage-heavy pipeline, however, they illustrate the prospective cost of adding a queue, staging database, or cache that holds ePHI and must be covered by the relevant safeguards and evidence.

The proposed 2025 NPRM would also require real-time recording of activity in relevant electronic information systems, without enumerating every specific log category in the regulatory text. Tamper-evident, immutable logs are recommended, but every detail of how they are set up is not already required. Security documentation has a separate retention requirement. The six-year minimum under 45 CFR § 164.316(b)(2)(i) should not be conflated with a blanket retention rule for every operational log.

Without middleware payload storage, there is no additional at-rest ePHI repository to encrypt, back up, and recover. Those storage obligations remain with the source and destination. The pipeline’s compute, identities, and operational controls still need to be assessed, including the scanning and access safeguards that apply to them. The architectural advantage is avoiding a new storage tier while remaining subject to proposed controls applicable to in-memory processing.

How zero-data-retention CDC architecture collapses SOC 2 audit scope

SOC 2 scope covers the production system that delivers the service, including systems that process, store, or transmit customer data or help meet service commitments. An active CDC pipeline meets that test even when it keeps no data. It remains inside the relevant system boundary. Zero data retention narrows the system description by removing intermediate payload stores, rather than excluding the processor that connects source and destination.

That boundary can include production compute, storage, queues, secrets managers, source control, CI/CD, the identity provider, and monitoring and logging systems. When a middleware database is removed, those supporting components stay in place. It does remove one distinct control surface. Auditors can assess the pipeline’s access controls and encryption in transit without also examining the access, backup, retention, and disposal controls of a nonexistent intermediate payload repository.

Under the inclusive method, vendor controls become part of the system description. Under the carve-out method, vendor services are identified but their controls are excluded, while the customer’s monitoring controls remain included. Neither method makes vendor oversight optional by implication. A vendor with no persistent payload store simply has fewer storage-specific controls to include or carve out.

SOC 2 Type II also needs evidence from across the observation period, which is usually several months to a year. The logs used as evidence must cover that period and the fieldwork window, and tamper-evident archives must back them up. Passthrough removes intermediate data-store access logs while retaining pipeline administrative logs. Access management, logging, change control, vendor oversight, and incident response can produce evidence useful to both SOC 2 and HIPAA programs. That overlap does not make a SOC 2 report HIPAA certification or a replacement for a BAA.

What "in-scope but passthrough" means in practice for access controls, encryption, and logging

TLS encryption is still needed on the connections from the source database to the pipeline and from the pipeline to the warehouse. Infrastructure access also remains a control obligation. The relevant permissions include who can configure replication slots, change pipeline settings, or view operational logs. Incident notification procedures must cover the pipeline as part of the PHI handling chain, even when the service has no stored payloads to investigate.

Administrative logging is still needed to record configuration changes, authentication events, and when the pipeline starts and stops. None of these requires recording replicated row contents. That separation is central to the retention claim. Error logs that contain payloads would create the very store of data that the architecture claims to avoid.

What disappears is the need to encrypt payloads at rest in a middleware store that does not exist. Backup encryption and tested recovery procedures for that store disappear with it, as do its PHI retention schedules and disposal procedures. The same boundary applies to infrastructure-specific controls. If no middleware database or cache is deployed, there is none to scan, but the rest of the pipeline infrastructure still needs the security controls that apply to it. BAA obligations for a storage subprocessor likewise end only when that storage service no longer handles PHI.

This distinction also separates payload retention from evidence retention. The vendor may still need administrative audit trails to show how it controlled access and handled incidents over the required period. Those records must be assessed for their contents, because calling a record “metadata” does not establish that it excludes payload data.

How to evaluate a CDC vendor's zero-data-retention claim before signing a BAA

Buyers need to check that the claimed data path stays storage-free when it runs, even if the contract promises to delete data eventually. Does the pipeline write to a staging table, message queue, object store, or cache between reading the source log and writing the destination? If it does, what retention period and at-rest encryption apply? Can the vendor provide a deployment architecture diagram showing the complete path with no persistent intermediate payload storage?

Do error logs, latency metrics, and audit trails capture payload data or only metadata such as table names, row counts, and timestamps? Which subprocessors handle data in transit, and have BAAs been executed with each? The answers should reflect how the proposed service will be set up. A general zero-retention statement leaves open whether a specific logging integration or subprocessor brings another party into the handling of PHI.

Failure handling is the next place to test. How does the service handle schema evolution, and does a schema change cause payloads to be buffered while the destination schema is updated? Do exactly-once delivery guarantees require events to be kept in durable storage during recovery? A pipeline that writes events to disk and deletes them after acknowledgment still creates transient at-rest ePHI. Buyers should seek evidence that schema evolution, recovery, and delivery guarantees work without disk-backed payload buffering rather than infer that property from normal streaming behavior.

Contractual and audit evidence must then describe the same implementation. Buyers should confirm that the BAA covers the specific services and configuration they will use before any ePHI flows. They should also request the vendor’s SOC 2 Type II report and compare its system description with the claimed passthrough architecture, including how intermediate stores are treated. The decision rests on that alignment. A defensible zero-data-retention claim connects the actual data path, the BAA’s safeguards, and the audit boundary without treating any one of them as a substitute for the others.