Start by checking whether the third party will create, receive, maintain, or disclose protected health information on your behalf. If PHI is involved, the relationship usually requires a HIPAA compliant business associate agreement and controls that limit permitted use, disclosure, and safeguarding. The practical test is not the industry label, but whether the service has access to PHI during the work.
What makes an outside service a HIPAA business associate?
An outside service usually becomes a business associate when it is doing work for the covered entity that involves PHI, even if the vendor is not in healthcare. The question is whether the service will create, receive, maintain, or disclose PHI on your behalf, because that operational relationship drives the compliance obligation, not the vendor’s industry label.
The practical test is functional: if the service cannot do its job without touching PHI, or if its personnel, systems, or support processes can access PHI while performing the service, you should treat the relationship as business associate territory. That means the downstream security, privacy, and use restrictions need to be defined before data is shared.
How to decide before PHI leaves your control
Start with the exact data flow and ask who will actually handle PHI, for what purpose, and at what points in the workflow. A vendor that only receives de-identified data is a different case from one that stores messages, handles backups, provides support access, or processes claims files that still contain PHI.
Then separate incidental exposure from intended access. If PHI may appear in logs, tickets, exports, screen shares, or administrative consoles, the service may still be functionally handling PHI even when the business team thinks of it as a “non-clinical” tool. The determining issue is access and handling, not whether the service is categorized as software, consulting, hosting, or analytics.
Before onboarding, document the minimum necessary PHI access, the allowed use, and the boundary for disclosure. If the service only needs a narrow slice of data, constrain the integration accordingly, because overbroad data feeds often create a business associate relationship that is larger, riskier, and harder to govern than the use case requires.
What the agreement and controls should actually cover
Once a service qualifies, the relationship should be governed by a business associate agreement that limits permitted uses and disclosures and requires safeguarding of the PHI involved. The agreement should match the real workflow, including storage, support access, subcontractors, retention, return or destruction, and incident notification expectations.
Controls should follow the data path, especially where the service can search, export, replicate, or support PHI-bearing systems. Healthcare organisations should confirm that the vendor’s access model, logging, encryption, retention, and support practices are consistent with the scope of PHI exposure created by the service. This is where many organisations fail: they sign the paper but do not verify the operating controls.
For services that touch PHI only indirectly, the right answer may still be business associate status if the service can maintain or disclose PHI during support or operations. A managed service, backup provider, claims processor, transcription platform, or hosted workflow system can all fall into that category when the service relationship depends on PHI access.
Risk and Threat Considerations
Misclassification creates direct exposure because PHI can flow to a third party without the legal and operational guardrails that should exist first. The main risk is not just paperwork failure, but uncontrolled access, weak subcontractor oversight, and broader disclosure than the service actually needs.
Failure mechanism: The organisation treats a PHI-touching vendor as a generic supplier, shares data before defining permitted use, and then loses control over where the PHI is stored, copied, supported, or forwarded.
Impact: That can lead to unauthorized disclosure, inadequate safeguarding, harder incident response, and a compliance gap that is created at the moment of onboarding rather than only after a breach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Covers external third-party access to systems handling PHI. |
| AC-6 — Least Privilege | Limits vendor access to only the PHI needed for the service. | |
| Recommendation — Require strong authentication for third-party access to PHI systems. Constrain third-party accounts to the minimum PHI access needed. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Applies to governing security obligations with vendors handling PHI. |
| A.5.34 — Privacy and protection of PII | Supports handling of regulated personal data such as PHI-like sensitive records. | |
| Recommendation — Define and monitor supplier security obligations before sharing PHI. Apply privacy controls and handling rules to sensitive personal data. | ||
| NIST CSF 2.0 | GV.SC-01 — Cyber Supply Chain Risk Management Strategy | Relevant because the decision depends on third-party data handling risk. |
| PR.AA-05 — Access Permissions and Authorizations | Supports restricting vendor access to PHI-bearing workflows. | |
| Recommendation — Classify PHI vendors in your supply-chain risk process before onboarding. Limit vendor authorizations to the smallest PHI-access scope possible. | ||
Practitioner Guidance
What to verify: Confirm the exact workflow, including support access, backups, logging, and subcontractors, before deciding the service is outside business associate scope. If any of those functions can expose PHI, treat the vendor as needing business associate governance rather than informal assurances.
Decision rule: If the service must create, receive, maintain, or disclose PHI to perform the contracted work, do not share PHI until the agreement and safeguards are in place. If the service can be redesigned to operate on de-identified or minimized data, reduce the exposure first and reassess the relationship.
Practitioner takeaway: The safest test is operational, not descriptive: once a third party can touch PHI in the course of service delivery, governance must be built around that access before the data is shared.
Related resources from NHI Mgmt Group
- How should healthcare organisations classify data to determine what counts as PHI under HIPAA?
- Why do healthcare organisations need PHI redaction before sharing data for collaboration or support?
- How should healthcare organisations determine whether GDPR applies alongside HIPAA?
- How should healthcare organisations manage business associate risk when sharing protected health information with third parties?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
