Why Apache NiFi fits hospital data integration
A hospital integration team usually runs HL7 v2 feeds from the EHR, lab results flowing to clinical systems, and extracts landing in an analytics platform, often through a mix of interface engine rules, scripts and point-to-point jobs nobody fully documents. Apache NiFi addresses this with one visual flow model: each feed is parsed, routed and transformed in a graph that can be read, tested and changed, and its provenance records show where every message came from, what happened to it and where it went. Because NiFi is self-hosted, the flows, the message content and the keys that protect them stay in infrastructure the organization controls, such as its own data center or a cloud tenancy it governs. For interface engineers, the change is mostly in how work is organized. Parsing and routing rules sit in processors and controller services that can be versioned, parameterized per environment and promoted through a registry, so a change to an ADT or ORU route is reviewed like code rather than edited on a live server. For security teams, the questions move to the deployment: TLS on every listener, an authentication provider that matches the workforce directory, and a cluster that does not bind its UI beyond the loopback interface until it is configured. For compliance leads, provenance becomes the main audit artifact, but it only helps if retention, access to the provenance repository and the handling of message content are defined before go-live. NiFi is licensed under Apache-2.0 and has no paid edition from the Apache Software Foundation, so the project itself carries no license fee. The cost sits in design, build, hardening and operation: clinical interface analysis, HIPAA-aligned controls around ePHI, cluster sizing and the staff who run the platform. Ask any partner to price those components separately, and confirm which of them will recur after launch, such as upgrades and on-call support.
Which HIPAA Security Rule requirements shape a NiFi healthcare build
This table maps the HIPAA Security Rule requirements that most affect a NiFi design to the build decisions they drive. Read each row as a design input: the requirement, where it sits in the rule, and what it means for the NiFi cluster, flows and documentation. The main takeaway is that most of these requirements are met by configuration choices made early, and the addressable specifications need written decisions that an assessor can review.
| Requirement | Source | What it means for the NiFi build |
|---|---|---|
| Unique user identification | 45 CFR 164.312(a)(2)(i), required | Each engineer and service operator needs an individual identity in NiFi. Use LDAP, OpenID Connect or SAML 2.0 rather than shared accounts, and confirm how the single-user provider is restricted outside of break-glass use. |
| Emergency access procedure | 45 CFR 164.312(a)(2)(ii), required | Define a documented, tested way to reach flows during an identity provider outage, such as a tightly controlled administrative account held under dual control. Record when it is used. |
| Automatic logoff | 45 CFR 164.312(a)(2)(iii), addressable | Set the NiFi UI session timeout to a value your risk analysis supports. Document the chosen value and the reasoning, since the specification is addressable. |
| Encryption and decryption | 45 CFR 164.312(a)(2)(iv), addressable | Decide whether flow content containing ePHI is encrypted at rest in the content, provenance and flow repositories, and how sensitive parameters are protected. Record the decision and any equivalent measure. |
| Transmission security (integrity and encryption in transit) | 45 CFR 164.312(c)(1) and (e)(1), with encryption addressable under 164.312(e)(2)(ii) | Enable TLS for the NiFi UI, cluster node communication, site-to-site transfers and every connection to EHR, lab and analytics endpoints. Do not bind to a non-loopback address without a security configuration in place. |
| Audit controls | 45 CFR 164.312(b) | Provenance records show what data moved, when and through which processor. Decide retention, protect the repositories from unauthorized change, and confirm that authentication and authorization events are also logged for review. |
| Business associate contracts | 45 CFR 164.314(a)(2)(i) | If a partner operates or accesses the NiFi environment and handles ePHI, the contract must require Security Rule compliance, flow terms to subcontractors and incident reporting. Scope access to the partner in the authorization policies. |
| Addressable versus required specifications | 45 CFR 164.306(d) and Appendix A to Subpart C | Required specifications must be implemented. For each addressable one, record whether it is reasonable and appropriate for your NiFi environment and, if not, the equivalent alternative measure. Keep these records with the design documents. |
Which NiFi modules and settings matter for health data
A healthcare NiFi deployment is shaped by a few components: the HL7 parsing and routing path, the controller services that reach EHRs, labs and analytics, how credentials and TLS are handled, who can change which flows, and how flow versions are kept. Each card names the decision it drives and what your team must confirm in its own environment before build starts.
HL7 v2 parsing and routing
The HL7 v2 processors in the NiFi 2 component documentation decide how ADT, ORU and ORM messages are read, validated and split before they reach downstream systems. Decide early whether routing keys on message type, sending facility or a specific segment, and whether malformed messages go to a quarantine path. Confirm the exact processor names and versions in the NiFi 2 component documentation for your build, and test them against sample messages from each source system.
Controller services for clinical endpoints
Database and HTTP controller services hold the connections to EHR databases, lab interfaces and analytics platforms, so each one is a shared, long-lived dependency. Decide which process groups may use which services, and size connection pools for the peak load of your interface feeds. Confirm each target's authentication method, TLS requirements and failover behavior with its owner before you build the connection.
Parameter contexts and sensitive values
Parameter contexts keep hostnames, endpoints and environment-specific settings outside the flow, and sensitive parameters hold database passwords and API tokens. Plan one parameter context per environment, and decide who can view or change sensitive values. The NiFi 2 variable registry scope was replaced by an ENVIRONMENT scope, so confirm which values move between environments and how your secret store feeds them.
TLS and authentication providers
NiFi supports single-user, LDAP, OpenID Connect, SAML 2.0 and X.509 client certificate authentication, and the Kerberos provider is deprecated. Choose the provider that matches your workforce identity source, and make sure NiFi is not left on its default loopback binding in a shared network. Confirm your certificate authority, certificate rotation process and who holds administrative access before go-live, because access to ePHI flows depends on it.
Authorization policies per process group
NiFi authorization policies set who can view, modify, operate and transfer data in each process group, and they are the main control that separates interfaces for different clinical systems. Map roles to the teams that own each interface, and keep provenance and data viewing rights narrower than flow editing rights. Confirm with your privacy and security leads which people may view message content, since provenance can expose ePHI.
Flow Registry Client for Git versioning
NiFi 2 includes Flow Registry Clients for GitHub and GitLab, which store flow versions in a Git repository so that every change to an interface has a commit, a reviewer and a rollback point. Decide whether your repository is self-hosted, how branches map to promotion stages, and how approvals are recorded. NiFi Registry is deprecated and planned for removal in NiFi 3.0, so confirm that a Git-based client fits your change management process before you adopt it.
Choosing a network and identity model by data source
Traffic between the EHR, the laboratory information system and NiFi usually stays inside the hospital network or a segmented clinical zone. The NiFi node should sit in a dedicated integration segment with narrow routes to the HL7 v2 interfaces it needs, and nowhere else. Because NiFi binds to 127.0.0.1 when no security configuration is provided, the node must be deliberately configured to listen on an internal interface before any clinical staff or other services can reach its UI or API. Authentication for administrators should come from the hospital's identity provider, while machine sources are usually restricted by network rules and, where supported, by client certificates.
- Node placement: A dedicated integration segment between clinical systems and the analytics side, with no direct path from workstations to the NiFi UI.
- Binding: Explicit listener addresses and ports for the UI, the cluster protocol and each inbound listener, so nothing defaults to loopback or to all interfaces.
- Administrator access: Sign-in through an enterprise provider such as LDAP or OpenID Connect, with separate roles for flow designers and operators.
- Source authentication: Firewall rules limiting each interface to known EHR and lab hosts, plus X.509 client certificates where the sending system can present them.
- Who has access: Integration staff and the security team only, with the reason for each route recorded.
Confirm with the network and security teams which VLANs, firewall rules and certificate authority apply to clinical traffic, and whether the clinical engineering group must approve any change to an interface.
Analytics destinations such as a cloud data warehouse, object store or lakehouse are usually reached over an outbound path from the NiFi node. The main decision is whether NiFi runs in the hospital data center or in a cloud account the hospital controls, and whether the write path to analytics is private or crosses the public internet. The NiFi UI should not be published to the internet even when the data destination is in the cloud. Credentials for the destination should be stored as sensitive parameters and scoped to the minimum write permissions, not shared administrator keys.
- Node placement: In the same cloud account and private subnet as the destination where possible, with no inbound route from the internet to the UI or cluster ports.
- Binding: UI and cluster listeners on private addresses only, with any load balancer reachable from the hospital network alone.
- Administrator access: The same enterprise identity provider used on premises, so one joiner and leaver process covers both environments.
- Destination access: A dedicated service identity with write-only permissions to the target dataset, and a private endpoint or VPN where the platform offers one.
- Data scope: Only de-identified or minimum-necessary fields leave the clinical zone, with the mapping decision documented.
Confirm with the cloud and security teams how the destination is reached, whether egress is logged, and which encryption keys protect the stored data. Ask the analytics owner which fields are permitted under the hospital's privacy policy.
Reference labs and regional health information exchanges exchange data across organizational boundaries, and the trust model changes accordingly. NiFi should not accept connections from a partner directly into the clinical network. A safer pattern places an inbound listener in a demilitarized zone or a partner-facing segment, with a controlled handoff to the internal flow. Partner identities should be individually issued and revocable, and the partner should have no access to the NiFi UI, flow definitions or provenance data. Expectations for data exchange, incident reporting and security controls are normally set in a written agreement, so the technical design should match what that agreement requires.
- Node placement: A partner-facing segment or DMZ node that receives data and forwards it on, separate from the internal processing node.
- Binding: Listeners bound only to the partner-facing interface, with the UI and cluster protocol kept off that segment.
- Partner authentication: Mutual TLS with a certificate per partner, issued by an authority the hospital controls, with revocation tested.
- Partner access: Submit-only access to the agreed endpoint, with no login to NiFi and no visibility into other partners' data.
- Contract alignment: Incident notification and data handling terms reflected in the flow design, including how a partner's breach is detected and escalated.
Confirm with the security team and legal or privacy office which partner agreements apply, what certificate lifecycle the partners can support, and who approves a new partner connection before it is enabled.
Using provenance as an audit trail and where it stops
NiFi records provenance for every FlowFile it touches, creating events such as receive, route, attribute change, content modification, send and drop. For a healthcare flow, each event lets you answer who or what moved a given HL7 v2 message, when it moved, and through which processors and connections it passed. That is useful for investigating a misrouted lab result or a disputed delivery to an analytics platform. Provenance is one input to audit controls and incident investigation. It does not, by itself, show that a covered entity or business associate meets the HIPAA Security Rule, which requires audit controls, access controls and risk management across the whole environment, including the EHR, the lab system and the analytics platform on each end of the flow.
Provenance data can contain message content, so treat it as ePHI. Decide who may query the provenance repository and who may download FlowFile content from an event, and restrict those permissions through the NiFi authorization policies that cover provenance and data access, not through informal trust. Retention is a planning decision in its own right: set the provenance retention limits in nifi.properties against the period your policies require, size the provenance repository so it does not fill and stall the flow, and confirm with your legal and records team how long the event record and the content must each be kept. Sensitive values in flow parameters and controller services must also be protected, because they will not appear in provenance in plain form but can still expose credentials if handled carelessly.
Before you rely on provenance, test whether it is complete for the flows in scope. Send known test messages through each path, including failure and retry branches, and confirm that every expected event type appears with the correct timestamps and component names. Check that events are still recorded after a node restart and after a node disconnects in a cluster, and that dropped or expired FlowFiles are traceable to a documented outcome. Compare provenance against the source and destination systems' own logs for the same message. Record the results as evidence and repeat the test after every flow change, since a new processor can add or remove events. Ask your assessor early which evidence they will accept, because an audit trail that has never been tested is hard to defend.
How a healthcare NiFi rollout is phased
The sequence moves a healthcare integration estate from scoping to supported production one interface at a time, so that clinical and security owners approve each stage before data from live systems depends on it. Each phase closes with a check that the next phase can rely on.
Scope interfaces and data classes with owners
Start by listing every interface in scope: the source and target systems, message types, direction, volume, and the data classes each feed carries, including ePHI and any restricted categories. Clinical owners confirm which workflows depend on each feed, and security owners classify the data and identify the business associates that touch it. The client provides the interface inventory, existing interface engine documentation, and named owners for clinical and security decisions. DeployOpen delivers a scoped interface register and a data flow map. The step is done when each interface has an owner, a classification, and an agreed cutover candidate.
Stand up a non-production NiFi cluster
Build a non-production NiFi cluster on infrastructure the client controls, sized from the interface inventory and the expected message volumes. Confirm the Java runtime and the coordination method for the cluster, whether embedded ZooKeeper, external ZooKeeper, or Kubernetes state management, against the NiFi administration guide for the release chosen. The client provides hosting, network access between NiFi nodes and test endpoints, and a de-identified or synthetic HL7 v2 sample set. DeployOpen delivers the installed cluster, a build record, and a health check report. The step is done when all nodes join the cluster and remain connected under a basic load test.
Configure TLS, identity and authorization
Apply the security configuration before any flow carries real data. This covers TLS for the UI and site-to-site traffic, the authentication provider chosen for the environment (such as OpenID Connect, SAML 2.0, LDAP, or X.509 client certificates), and authorization policies that separate administrators, flow developers, and operators. Confirm that the Kerberos provider is not the chosen path, since the NiFi administration guide lists it as deprecated. The client provides identity provider access, certificate authority or certificate material, and the role mapping approved by the security owner. DeployOpen delivers the configured environment and an access matrix. The step is done when unauthenticated access is refused and each role can perform only its approved actions.
Build flows and test with message replay
Build the flows for each interface, covering HL7 v2 parsing, validation, routing, error handling, and delivery to the target. Replay the representative sample messages through the flows, including malformed, duplicate, and out-of-order cases, and compare outputs with expected results agreed with the interface owners. Version the flows in a Git repository through a supported flow registry client so that every change has a reviewable history. The client provides test scenarios, expected outputs, and access to test endpoints. DeployOpen delivers the flow definitions, a replay test record, and a defect log. The step is done when every test scenario passes or has an accepted exception signed off by the interface owner.
Cut over one interface at a time
Move one interface to production at a time, starting with the lowest-risk feed. Run the NiFi flow in parallel with the existing path so that both outputs can be compared before the old path is switched off. Provenance records the path of each message, which gives the team a trail to reconcile counts and content during the parallel period. The client provides the change approval for each cutover, a rollback decision owner, and access to the receiving systems for reconciliation. DeployOpen delivers the cutover runbook, reconciliation results, and a change record. The step is done when the parallel comparison matches within the tolerance agreed for that interface and the old path is retired with approval.
Hand over operations with monitoring and runbooks
Transfer day-two operation to the client team once the cutover interfaces run stably. Set up monitoring for cluster health, queue depth, error rates, and certificate expiry, and document the alerts and their responses. Write runbooks for common failures, including disconnected nodes, full repositories, and interface outages, and walk the operators through them. The client provides named operators, an on-call route, and monitoring tooling access. DeployOpen delivers monitoring configuration, runbooks, and a handover session with a recorded attendance list. The step is done when operators have executed the runbooks in a test and the client accepts ownership of the environment in writing.
Moving healthcare flows off NiFi 1.x before support ends
Hospital flows still running on NiFi 1.x need a dated migration plan now, because the project has stopped extending that line. The NiFi downloads page identifies NiFi 1.28 as the last minor release of the version 1 series and lists December 8, 2024 as the end-of-support date for 1.28.1. The project also explains that the 1.x line cannot be maintained further because it depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, none of which can be upgraded within that line. For a health data integration team, the decision is not whether to move but how to sequence the move around interface go-lives, downtime windows and clinical sign-off.
The migration guidance sets a fixed order of steps. Upgrade to NiFi 1.27.0 before moving to 2.0.0, then change the flow configuration file from flow.xml.gz to flow.json.gz. Expect to rework any flow or parameter that uses the variable registry expression language scope, which NiFi 2.0 removed in favor of an ENVIRONMENT scope. Distributed map cache components were also renamed, so any caching used for patient or encounter lookups must be found and updated. Inventory every process group that references these features before scheduling the cutover, and confirm the exact renamed component names against the migration guidance rather than relying on memory of 1.x.
Retest HL7 v2 parsing and validation after the move, even when the flow appears to run cleanly. Confirm that message segments, field mappings and routing rules for ADT, ORU and ORM messages produce the same outputs for a set of recorded sample messages, and that rejected messages still reach the error route with their provenance intact. Also plan for NiFi Registry, which the downloads page describes as deprecated and planned for removal in NiFi 3.0. Teams that version flows in NiFi Registry today should evaluate the Git-based Flow Registry Clients for GitHub and GitLab as the destination, and should confirm that approval records and change history carry over. Ask your implementation partner to document this retest as part of the migration deliverables.
Compliance considerations for healthcare NiFi flows
A NiFi flow that carries patient data sits inside a set of obligations that depend on who holds the data, who moves it and where the hospital operates. The cards below cover the US federal rules, how they are enforced, the contracts that reach integration partners and the evidence you will need to show an assessor.
HIPAA Security Rule scope
The Security Rule applies to covered entities, meaning health plans, health care clearinghouses and covered health care providers, and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. A NiFi cluster that parses HL7 v2 messages and routes them to a lab or analytics platform is handling ePHI, so its nodes, repositories and flow content fall in scope. Confirm with your privacy office which of your flows, and which of your NiFi nodes, are part of that boundary.
No certification, enforcement by OCR
There is no HIPAA certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not stop HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits. Any vendor or consultant who offers a HIPAA certificate for a NiFi deployment is offering something HHS does not recognize.
Business associate terms for partners
When an integration partner, such as a cloud analytics provider or an outsourced lab interface team, handles ePHI on your behalf, 45 CFR 164.314 requires a business associate contract. It must require compliance with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and require reporting of security incidents, including breaches of unsecured PHI. Check that the flows you hand over name the partner's responsibilities for each queue, endpoint and log destination.
Civil penalty exposure
For penalties assessed on or after January 28, 2026, the inflation-adjusted HIPAA civil money penalty under 45 CFR 102.3 ranges from $145 per violation where there was no knowledge, up to $2,190,294 per violation for uncorrected willful neglect, with a calendar-year cap of $2,190,294. Penalty amounts are set per violation, so a single misrouted message stream repeated across months can add up. Ask counsel how your incident response and correction records would be presented.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025, under RIN 0945-AA22. As of October 2026 no final rule has been published, and the Unified Agenda projects final action for July 2027. Treat the current rule as the baseline you must meet now, and design NiFi controls such as encryption, unique user identification and audit logging so they can absorb stricter requirements. Confirm the status with counsel before each planning cycle.
NIST SP 800-66 Rev. 2 as a mapping resource
NIST SP 800-66 Revision 2, published in February 2024, is a resource guide for implementing the Security Rule. It gives key activities, descriptions and sample questions for every standard. HHS lists it as informational rather than legally binding. Use it to map each NiFi control, such as TLS on listeners, authentication providers and provenance retention, to the standard it supports, and keep that mapping with your flow change records.
What healthcare NiFi projects ask before hiring a partner
What drives the cost of a healthcare NiFi integration project?
Cost follows the written scope, and the biggest drivers are the number of interfaces, the number of HL7 v2 message types and site-specific variants, the security integration, the cluster size and the depth of validation testing. Each interface adds mapping, routing rules, error handling and test cases, so a count of interfaces tells you more than a count of servers. Identity integration, such as connecting NiFi to your identity provider, and the number of environments you need for testing also add effort. Ask any partner for a quote that lists each interface, each message variant, each security task and each test stage as a separate line. NiFi itself is free to use under the Apache License 2.0, so the quote covers services and your infrastructure, not a NiFi license fee.
How long does a NiFi healthcare integration take to deliver?
The timeline depends on the written scope, so no duration is given here. The main factors are the number of interfaces, how many of them need new HL7 v2 parsing rules, how many source and target systems must be tested with their owners, and how quickly clinical and security reviewers can sign off. Your own change control and test window at the hospital also set the pace, because interfaces that touch patient data usually need staged approvals before go-live. Ask for a delivery plan that shows the phases, the sign-off points and what happens if a system owner is unavailable for testing.
What must our team provide before a NiFi partner starts work?
A partner needs the material that defines correct behavior, plus access to the systems involved. Prepare the interface specifications for each EHR, laboratory system and analytics target, and a set of sample HL7 v2 messages that includes the variants your sites actually send, including malformed or unusual examples. You also need test environments for each connected system, access to your identity provider for NiFi user authentication, and named owners for the network, security and clinical workflows. Clinical and security sign-off should be written into the plan at the start, with dates for review of routing rules, access roles and the encryption settings for data in transit.
Can an internal team build a healthcare NiFi integration alone?
Yes, an internal team can build and run NiFi, provided it has people who understand NiFi flow design, the HL7 v2 standard as your interfaces use it, secure cluster configuration and the test process for clinical data. The Apache NiFi project publishes its administration guide and migration guidance, so the skills are learnable, but the first integrations usually take longer than later ones because the team builds patterns from scratch. Many organizations split the work: internal staff own the interface knowledge and sign-off, while an outside partner brings repeatable build, hardening and documentation practice. Assess your team against the scope of the interfaces, and confirm who will be on call for production issues.
Which costs recur after a NiFi healthcare integration goes live?
Build work is one-time, but several costs recur. The main recurring items are support and incident response, upgrades to new NiFi releases, regression testing after every flow or configuration change, certificate and credential rotation, and patching of the underlying operating system and runtime. NiFi 1.x reached the end of support path described in the project's downloads page, and planning for version changes is an ongoing task. Ask a partner to separate one-time build fees from retainer or support terms, and to state what each retainer includes, such as monitoring, patch windows, test cycles and response times. Confirm any response commitment in writing before you rely on it.
Does using Apache NiFi for healthcare data require a license?
Apache NiFi is an Apache Software Foundation project released under the Apache License 2.0, and the project does not offer a paid edition. You can download, run and modify it without a NiFi license fee. Costs appear in the infrastructure that hosts it, the services for design and build, and any commercial support or retainer you choose. Check the license terms of any additional component you add to a flow, such as a database driver or a third-party connector, because those components may carry their own terms. Ask your partner to list every third-party component in the design so your legal and procurement teams can review them.
Can DeployOpen certify that our NiFi deployment is HIPAA compliant?
No. DeployOpen cannot certify HIPAA compliance, and no one can issue a HIPAA certification because HHS states that no Security Rule standard requires certification. DeployOpen plans, implements, hardens and documents NiFi inside your environment, and prepares the controls and evidence that your compliance program and any independent assessor will review. Under the Security Rule, covered entities and business associates decide how to meet each implementation specification, and addressable specifications require a documented risk-based decision. Your privacy officer, security officer and legal counsel own the compliance position, and your assessor provides any independent opinion.
What security work should a healthcare NiFi project include?
A healthcare NiFi project should cover several security tasks together, not as separate add-ons. The main items are TLS for every connection, an authentication provider that matches your identity system, role-based authorization that limits access to flows that carry patient data, and protection of sensitive parameters such as interface credentials. Provenance data should be retained according to your audit needs, and access to it should be restricted. NiFi binds to 127.0.0.1 when no security configuration is provided, so the first step is always a deliberate secure configuration. Ask the partner to show each control, the test that proves it and the person who approves it.
How DeployOpen scopes and delivers healthcare NiFi work
DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so NiFi flows for HL7 v2 and EHR, lab and analytics data run in environments you control. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory the HL7 v2 message types, EHR, lab and analytics endpoints each flow must touch before any design work starts.
- Record which flows carry ePHI, where they are encrypted in transit, and which business associate terms apply to each receiving system.
- Agree in writing the NiFi version path, including whether the work targets NiFi 2.x directly or includes a planned 1.x migration.
How we build
- Build HL7 v2 parsing and routing flows with error queues, duplicate handling and validation tests run against representative sample messages.
- Configure TLS, authentication through your chosen identity provider and authorization policies so access to ePHI follows your need-to-know model.
- Set up Git-based flow versioning and provenance retention settings so each change and data movement can be reviewed later.
How we hand over
- Deliver flow documentation covering message mappings, routing rules, parameters, secrets handling and the provenance evidence each flow produces.
- Walk your operations and security staff through deployment, change promotion, backups and the runbooks for stuck or failed flows.
- Provide a list of open items, including controls your compliance team must confirm with its own auditors and assessors.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, scoped to the NiFi versions and flows you run.
- Plan upgrade work alongside your change calendar so NiFi patches and version moves are tested on non-production flows first.
- Review access, certificate expiry and provenance retention periodically, with findings written up for your security and privacy owners.
