Apache Airflow pipelines that process ePHI under HIPAA

No. Airflow is open-source software and cannot perform your risk analysis under the administrative safeguards in 45 CFR 164.308. The risk analysis must identify where ePHI is created, received, maintained or transmitted, including every DAG, connection, task log, XCom value and metadata database table that touches it, and then manage the risks you find. Your compliance or security team owns that work, with input from the engineers who write and operate the DAGs. NIST SP 800-66 Rev. 2 describes the activities in more depth and is a useful reference, though HHS treats it as informational rather than binding. Ask for the risk analysis scope in writing before any build starts, and keep it current as pipelines change.

Your organization does, and the platform cannot do it for you. The Security Rule expects workforce members who use or administer ePHI systems to be trained on security policies and procedures, and that training has to match how your team works with Airflow: who can write DAGs, who can trigger or clear runs, how secrets are handled and how suspected incidents are reported. DeployOpen can help prepare runbooks and access procedures that training can reference, but the training program, attendance records and refresher schedule remain your responsibility. Plan for training for DAG authors, operators and anyone with access to task logs.

The organization that controls the hardware, facility or cloud account carries the physical safeguards in 45 CFR 164.310. Airflow runs on servers, virtual machines or Kubernetes nodes that you or your hosting provider operate, so facility access controls, workstation and device security, and media disposal for disks that hold logs or database backups all sit outside the software. Confirm with your hosting provider which physical and environmental controls it supplies and how it documents them. Your own evidence should show who can reach the hosts and how decommissioned storage is wiped.

Yes, when a vendor creates, receives, maintains or transmits ePHI on your behalf. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to the covered entity. A cloud or colocation provider that stores Airflow metadata, logs or backups containing ePHI typically falls into this category, and so does an implementation partner that can access those systems. Ask your legal or compliance team to confirm whether each vendor's role triggers the requirement, and keep signed agreements with the evidence you collect for audits.

Airflow logs can help you detect and investigate an incident, but the reporting obligation and the decision about what counts as a breach belong to your organization or, where you are a business associate, to the contract with the covered entity. The business associate contract must require reporting of security incidents, including breaches of unsecured PHI, so the notification path, timing and content should be defined before an event occurs. Build an incident procedure that covers DAG code changes, exposed connection credentials, unexpected task log access and metadata database compromise, and test it with the teams that would run it. Confirm the notification terms with your counsel rather than relying on any technical setting.

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation (HHS FAQ 2003). Airflow is Apache-2.0 licensed open-source software with no certification of its own for HIPAA, and DeployOpen does not issue audit reports, attestations or certifications. Independent assessors may review your evidence for a third-party assurance program, but that is a separate decision. Your obligation is to meet the Security Rule and to be able to show how you did so.

Not yet. HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898, RIN 0945-AA22), with comments due March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rule under Long-Term Actions with final action projected for July 2027. The current rule in 45 CFR Part 164 Subpart C still governs. Plan your Airflow controls against the current text, and review them when a final rule is published, since proposed changes could affect areas such as encryption, asset inventory and recovery planning.

Many teams can, provided they have people who understand both the Security Rule and Airflow's internals. The work includes mapping ePHI flows, configuring audit logs, encrypting connections and log shipping, restricting task log access, setting up a secrets backend, and writing the procedures and evidence that an assessor would sample. Cost and duration depend on how many pipelines touch ePHI, how many environments exist, how mature your identity and logging stack is, and whether you need outside security testing. DeployOpen plans and implements these controls under a written, fixed scope if you want a partner, and it does not issue the compliance conclusion itself. Ask any partner to state in writing which tasks it performs and which remain yours.

The effort depends mainly on the number of DAGs, the source and destination systems they touch, where task and audit logs must go, and which identity provider staff will use. Each DAG that reads or writes ePHI needs its data flow mapped, its connections reviewed for encryption in transit, and its logs classified. Source systems multiply the work because each one needs its own connection, credentials and access rule. Log destinations matter because audit evidence must be shipped and retained outside the scheduler. The identity provider sets how role mapping and access reviews are built. Ask any partner to size the work against these four drivers in a written scope before agreeing a price or timeline.

Yes, an internal team can run it alone if it has the skills and time, but the skills need to cover more than Airflow itself. The team needs people who can operate the scheduler, metadata database, executors and secrets backend, people who can review DAG code for ePHI handling, and someone who can read the HIPAA Security Rule controls for audit logging, access and transmission security. Most teams find the gap in access reviews, log retention and documented risk decisions rather than in the scheduler. A useful test is whether your team can show, for a sample pipeline, who changed it, who ran it, where its logs went and how the encryption was verified. If any of those answers depend on one person, the work is not yet ready to hand to auditors.

A partner needs three things before design work can start. First, your architecture decisions: which executor, where the metadata database runs, how DAGs are delivered and where logs are stored. Second, access to the systems involved, including the cloud or data center accounts, source databases, identity provider and any existing log platform, granted under your own change process. Third, a named risk owner who can accept or reject residual risk on your behalf and sign off on documented exceptions for addressable implementation specifications. Without that person, technical decisions stall at the first compliance question. Your compliance or privacy lead should also confirm which pipelines actually carry ePHI, because the scope of the work follows from that list.

No. There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private certifications. Those certifications also do not prevent HHS from later finding a violation. Covered entities and business associates must comply with the Security Rule in 45 CFR Part 164 Subpart C, and the Office for Civil Rights checks compliance through complaints, compliance reviews and audits. Vendors and consultants who offer a HIPAA certificate for a platform are describing a third-party assessment or attestation, which is a different thing. Ask any provider to name exactly what was tested, by whom, against which criteria and for what period. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications.

Penalties are set per violation within tiers based on the level of culpability, and each tier has an annual calendar-year cap. For penalties assessed on or after January 28, 2026, the inflation-adjusted amount under 45 CFR 102.3 (published at 91 FR 3666) ranges from $145 per violation where the entity did not know of the violation, up to $2,190,294 per violation for uncorrected willful neglect. The calendar-year cap for identical provisions is also $2,190,294. The number of violations, the tier, whether the problem was corrected, and the entity's own documented efforts all shape the outcome. Because penalties apply per violation, weak logging or access controls across many pipelines can add up quickly. Confirm the current figures against the eCFR text before relying on them, since they are adjusted for inflation.

Ask for a quote that follows from a written scope, not a rate card. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Give the partner your DAG inventory with ePHI flags, the source and destination systems, the executor and deployment target, the identity provider, the log destinations and your retention rules. Ask the quote to separate one-time build work from recurring items such as upgrades, patching, access reviews and evidence collection. Ask which items are excluded, who provides the infrastructure and licenses, and what happens if the inventory changes during the build. Ongoing support, upgrades and continuous testing are available as retainers, so ask for those as separate lines.

Confirm four things first. Confirm that audit logs from Airflow capture who triggered, cleared or changed runs and DAGs, and that they are shipped off the scheduler to a store you control. Confirm that task logs, which can contain ePHI in output or error messages, have restricted read access that matches your need-to-know rules. Confirm that connections to databases, object storage and log platforms use encrypted transport, and that the settings are verified in your environment rather than assumed from defaults. Confirm where secrets are stored and who can read them. Airflow 3 uses the Simple auth manager by default, so an identity integration and role model should be planned before production use. Check the current Airflow production guide and your own configuration to verify each point, as the exact options depend on your version and providers.