Without a signed BAA, the vendor is not accepting HIPAA business associate obligations, so PHI stored or processed there is outside the covered compliance relationship. Risk appears as soon as patient identifiers enter task titles, comments, or attachments. The issue is not only storage, but any handling that exposes regulated data.
Why This Matters for Security Teams
A SaaS tool without a BAA is not just a procurement gap. It means the vendor has not contractually accepted the HIPAA business associate role, so PHI handled in that service may sit outside the legal and operational boundary security teams assume exists. That creates exposure in task titles, support tickets, comments, attachments, exports, and workflow automations. Current guidance suggests the risk is highest when teams treat a collaboration or productivity app as a harmless “system of record” for patient work.
This is where governance and day-to-day operations collide. Security, privacy, and compliance teams often inherit shadow workflows long after the tool was adopted, and the data path is usually wider than the original use case. NHIMG’s Top 10 NHI Issues shows why uncontrolled access paths and weak oversight keep showing up in real incidents. The same pattern appears in general control frameworks such as the NIST Cybersecurity Framework 2.0, which expects risk decisions to be tied to asset, access, and governance boundaries. In practice, many security teams discover PHI in unsanctioned SaaS only after a workflow has already spread across departments.
How It Works in Practice
The compliance problem starts with data flow, not with storage alone. If a user enters a patient name into a ticket, uploads a lab result to a shared folder, or pastes discharge details into an AI assistant, that SaaS service is now processing PHI. Without a BAA, the vendor is not under the HIPAA obligations that normally cover permitted use, safeguards, subcontractor handling, breach response, and termination requirements. That leaves the covered entity or business associate with an incomplete chain of accountability.
Operationally, teams should map where PHI can enter the tool, who can see it, where it is copied, and whether the vendor can retain it in logs, backups, analytics, or training workflows. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because the same audit logic applies: you need clear ownership, traceable access, and enforceable lifecycle controls. At the control level, frameworks like NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce data minimisation, auditability, and third-party oversight.
- Classify whether the workflow can ever contain PHI, even incidentally.
- Block or redact PHI before it reaches tools that lack a BAA.
- Restrict uploads, exports, and integrations that widen data exposure.
- Confirm retention, deletion, and subcontractor controls in the contract path.
- Review logs and notifications, because PHI often leaks there first.
NHIMG’s Lifecycle Processes for Managing NHIs is a useful operational analogy: access and data use must be scoped, monitored, and revoked with a defined lifecycle, not left to ad hoc team habits. These controls tend to break down when departments adopt SaaS tools faster than security can inventory data flows and enforce procurement gates.
Common Variations and Edge Cases
Tighter data handling often increases workflow friction, requiring organisations to balance clinician efficiency against regulatory exposure. That tradeoff becomes sharper in edge cases where a vendor says it “does not store data,” but still transmits, caches, indexes, or processes PHI transiently. Current guidance suggests transient processing still matters if the service can access the information, so “we do not keep it” is not a safe substitute for a BAA.
There is also no universal standard for every workflow pattern yet. For example, a scheduling tool may appear low risk until free-text notes, attachments, or automated reminders introduce identifiers. Similarly, AI-enabled SaaS can create downstream exposure through prompts, embeddings, summaries, and human review queues even when the interface looks benign. The Ultimate Guide to NHIs highlights how hidden dependencies and excessive access often remain invisible until an incident forces review. In healthcare, the safest assumption is that any workflow handling patient context needs explicit contractual and technical controls before go-live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC | Third-party risk governance is central when a SaaS vendor lacks a BAA. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement matters when PHI can enter unsupported SaaS workflows. |
| NIST AI RMF | GOVERN | Governance is needed when AI-enabled SaaS may process PHI outside approved controls. |
| OWASP Non-Human Identity Top 10 | NHI-01 | SaaS integrations often rely on secrets and tokens that expand PHI exposure paths. |
| CSA MAESTRO | GOV-1 | Agentic and automated SaaS workflows need explicit governance boundaries for sensitive data. |
Inventory SaaS data flows, assign vendor risk owners, and block PHI use until contractual safeguards exist.
Related resources from NHI Mgmt Group
- Why do non-human identities create compliance risk even when policies exist?
- Why do collaboration tools create such a large secrets risk?
- Why do cloud AI tools create more data exposure risk than traditional SaaS workflows?
- Why do credit card numbers in Slack create such a high compliance risk in SaaS collaboration workflows?
