What Auditors Actually Check in a CDC Vendor During a HIPAA or SOC 2 Review
Auditors examine encryption, logs, and access controls to verify CDC vendors handle PHI safely.
HIPAA and SOC 2 compliant managed CDC for regulated industries depends on evidence about the replication layer itself. Auditors examine executed agreements, encryption, application-level logs, access controls, failure recovery, and deployment records. Data teams should ask for those same artifacts before procurement so they can find compliance liabilities before PHI enters the pipeline.
Why a HIPAA or SOC 2 auditor treats a CDC vendor as a first-class subject of scrutiny, not a background dependency
Log-based CDC reads inserts, updates, and deletes from operational databases and streams row-level changes to a destination. PostgreSQL exposes those changes through the WAL, MySQL through the binlog, and MongoDB through change streams. This is an event stream. When replicated rows hold PHI, each change passes through the replication infrastructure, so that infrastructure is directly in the data-processing path.
That operational role establishes the regulatory scope. A CDC vendor that creates, receives, maintains, or transmits ePHI on behalf of a covered entity falls within HIPAA’s business associate definition at 45 CFR 160.103. HIPAA’s audit-control standard at 45 C.F.R. § 164.312(b) requires ways to record and examine what happens in systems that hold ePHI. Where every modification must be logged, polling captures row state and leaves the intervening operations unlogged. CDC exposes those operations, but the vendor must still demonstrate controls over its own processing.
SOC 2 Type II adds a time dimension. The AICPA Trust Services Criteria assess whether controls worked as they should throughout an observation window, while the replication pipeline keeps processing data. An auditor therefore cannot stop at the application or warehouse boundary.
How HIPAA and SOC 2 differ in what they demand from a vendor, and where those demands converge for a replication layer
HIPAA is federal law with no certification scheme. A claim of “HIPAA certification” is therefore a procurement warning. The evidence begins with a signed Business Associate Agreement, supported by third-party assurance such as a SOC 2 Type II or HITRUST report. HIPAA also imposes direct liability on business associates after HITECH and requires contractual obligations to flow down to subcontractors.
SOC 2 distinguishes the controls included in the examination. Its five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality, and Privacy, but only Security is required in every audit. For replication, Processing Integrity addresses whether data is processed completely, accurately, and on time. Scope must therefore be read. A Type II report must also show that the controls worked across the observation window, beyond describing which controls were in place.
The frameworks converge on access, encryption, logging, change management, and access recertification, allowing one control matrix to support both reviews. Proposed requirements need a separate label, however. HHS OCR’s 2025 NPRM would remove the required-versus-addressable distinction and make encryption, MFA, audit logging, and access termination mandatory. As of 2026, no final rule has been issued, although auditors increasingly use the proposed standard as a practical baseline.
Business Associate Agreement execution and subprocessor chain are the first artifacts an auditor requests
The contractual gate comes before the technical walkthrough. Under 45 CFR 164.502(e) and 164.504(e), a BAA is a legal requirement. The auditor first asks whether an executed agreement exists, then traces the subcontractors involved in replication. That inquiry commonly reaches the cloud provider hosting the replication instance, whose agreement with the CDC vendor must complete the chain.
A gap in the required BAA chain remains a HIPAA violation regardless of the primary vendor’s controls. Auditors also seek supporting evidence, including penetration test summaries, security questionnaire responses, and third-party reports. These artifacts connect contractual promises to the infrastructure and practices that implement them.
For procurement, the lesson is to establish the chain before any PHI flows. Teams should confirm that the vendor will sign a BAA, obtain its current subprocessor list, and confirm the required executed agreements. The 2025 proposal would also introduce annual technical-safeguard verification and a 24-hour contingency-plan incident-notification timeline in BAAs. Its proposed MFA and encryption standards would apply as Security Rule obligations rather than explicit BAA terms, a distinction that prevents proposed contract requirements from being overstated.
Encryption across the replication path is where auditors look beyond the warehouse
Warehouse encryption covers only one part of the path. The baseline of AES-256 at rest and TLS 1.2 or higher in transit extends to the source connection, replication instance, intermediate staging storage, and endpoint credential store. Transaction logs include sensitive field changes, so a staging layer can expose PHI independently of the destination. Auditors examine its encryption and access controls separately.
Architecture changes how much infrastructure requires that examination. In a pass-through model, the vendor never persists customer data on its own infrastructure, so PHI does not rest there. This directly addresses the procurement question of how to replicate data in real time without storing PHI on third-party vendor infrastructure. It reduces the at-rest encryption surface, but the connections and credential protection still require scrutiny.
Auditors request TLS configurations for source-to-replication and replication-to-destination connections, KMS key policies showing rotation schedules, and confirmation of staging-storage encryption where staging exists. Credential-storage documentation completes that view. Together, these artifacts reveal whether the warehouse’s protections extend across the actual replication path or stop at its endpoint.
Audit logging requirements specific to the CDC layer include immutability, application-level capture, and PHI scope
The source transaction log is not the vendor’s audit log. The vendor reads the WAL or equivalent change stream, but that input on its own does not show what the vendor did at the application layer. For PHI tables, auditors expect per-operation records that identify who acted, what occurred, when it occurred, and from where. Cloud access logs and VPC flow logs do not supply that application-level account.
The vendor’s records must also withstand alteration. Auditors look for append-only logs in tamper-evident storage separate from pipeline operational storage. On AWS, a Log Archive account has WORM protection through S3 Object Lock in Compliance mode. SHA-256 hashing and digital signatures help validate log-file integrity so that later changes can be found.
The practical test is reconstruction of a specific event. An auditor asks whether the logs can show what happened to a particular PHI record at a particular time and whether vendor operators can alter or delete that evidence. Messages that a task started or stopped, or counts of rows in aggregate, cannot answer the first question. A sample entry must expose the table name, operation type, timestamp, and identity authorizing pipeline access, while storage controls substantiate the second answer.
Access control on the replication user and vendor personnel makes least privilege an auditable property
Logging establishes what happened. Access controls establish what was permitted. The source database replication user is a standing privileged identity with continuous access to changes in replicated tables. Auditors examine it as a service account. Its grants must match the declared replication scope and give it no standing administrator privileges or access to tables outside that scope.
Auditors examine RBAC definitions, access-review approvals, prompt offboarding, and MFA for administrative and production access. Quarterly review is common practice for privileged identities, although the AICPA criteria specify no minimum frequency. The replication account therefore belongs in the review process rather than remaining outside it because no person signs in with it.
Operators’ access to replication infrastructure needs its own review and revocation evidence, distinct from the customer database account’s grants. Procurement teams should ask about both and check whether the quarterly review records cover service accounts and human operators. Replication credentials should reside in a secrets manager rather than configuration files or environment variables, with the instance’s IAM role limited to retrieving them at task startup. That restriction also helps keep credentials out of pipeline logs.
Processing integrity under SOC 2 exposes weaknesses in exactly-once delivery and schema evolution
Most CDC pipelines provide at-least-once delivery, which leaves a specific recovery risk. A pipeline can write an event to the target and crash before saving its checkpoint. On restart, it replays the event. Without idempotent destination writes, the replay creates duplicate rows, turning the temporary interruption caused by a checkpoint failure into inaccurate processing.
Idempotent target writes and durable, crash-safe checkpointing must work together to support the delivery guarantee. An auditor can request reconciliation logs comparing source and destination row counts after simulated failure and recovery. The architecture documents explain what should happen, while incident tickets show what happened when recovery paths were used.
Schema evolution creates a different failure mode. Logical replication ships data changes rather than schema changes, so a newly added upstream column can create a downstream mismatch. A pipeline that stops cleanly and alerts makes the problem visible, but one that keeps processing data the wrong way can hide output that is incomplete or wrong. Under PI1, auditors ask for validation logs at pipeline boundaries, schema-change history, and records of how mismatches were found and fixed.
Change management and vendor risk evidence come from Git history and deployment logs
Auditors pull reviewed and approved Git pull requests tied to tickets, then connect them to CI/CD runs containing approver identity, timestamp, and commit SHA. They also examine whether a review gate prevents engineers from deploying directly to production. The test is whether deployment history follows the documented process throughout the observation window.
A gate that is enforced creates evidence as the work is done. A policy without a gate depends on people remembering each required step, creating a gap auditors can test against immutable deployment records. Incident-response history also shows how fast incidents were detected, what was communicated to the covered entity, and what recovery path was recorded. Missing incident records do not establish that no incidents occurred.
The covered entity uses those records when it reviews vendor risk. Drata and Vanta can collect and surface vendor evidence continuously. A SOC 2 Type II report condenses change management, access-control, and availability evidence into an auditor-reviewed document for the observation window. This completes the six-domain evidence package, connecting contractual responsibility and technical safeguards to demonstrated operational discipline.
How should teams evaluate HIPAA and SOC 2 compliant managed CDC before procurement?
The BAA question includes whether the vendor will sign before PHI flows and provide a written subprocessor list with the required agreements. Teams should ask where customer data rests, then examine storage protection, key management, and rotation. These questions establish both contractual responsibility and the architecture that must support it.
Logging and access questions test whether activity can be attributed and constrained. Teams should request sample application-level records tied to PHI tables and documentation of their storage and tamper protections. They should also ask how the service account’s privilege scope is documented and reviewed, where credentials reside, and how vendor personnel access is revoked. Review approvals and the grants in place show how that access is controlled.
Teams should ask what happens during a crash and restart, what reconciliation demonstrates afterward, and how upstream schema changes are detected and handled. For change management, they should request deployment history with approver records and the vendor’s SOC 2 Type II report. Its scope must extend beyond corporate IT to explicitly cover replication infrastructure.
If a vendor cannot show evidence in one domain, the compliance liability remains even when it has strong evidence in others. Covered entities should ask for the Type II report each year and use the broader evidence framework each time they review the vendor. If finalized, the 2025 proposal’s annual business associate verification requirement would make that recurring assessment an explicit obligation.
