The U.S. Department of Health and Human Services (HHS) defines a business associate by the work it performs and its relationship to protected health information (PHI). An IT contractor whose service requires it to create, receive, maintain, or transmit electronic PHI (ePHI) is one of HHS's examples. That makes a penetration test a procurement question before it is a testing question: what data will the testers actually encounter, copy, and retain?
Quick answer. A penetration testing vendor may need a business associate agreement (BAA) when its service for a covered entity or another business associate requires it to create, receive, maintain, or transmit PHI. HHS distinguishes that from a service with no PHI use or disclosure where access would only be incidental, if it occurred at all, and reasonable safeguards are in place. The buyer should decide the data path with its privacy and legal teams, then write the permitted access, evidence handling, and subcontractor terms into the engagement before testing starts. Stingrai scopes human-led healthcare tests around the application, APIs, identities, cloud, and network systems actually in the environment; a buyer should confirm the PHI arrangement for the proposed test rather than assume any package includes it.
A hospital can give testers synthetic patient records in a production-like environment. A health plan may need them to test authorization across real claims workflows. A digital-health supplier may test its own software while acting as a business associate to a hospital. These are different arrangements. They can produce similar looking pentest reports, but they do not create identical data obligations. The decision belongs to the actual contract and data flow, not a generic label on an RFP.
This guide is for a U.S. HIPAA-covered entity or business associate purchasing a test, and for a Canadian or U.S. vendor selling into that environment. It helps security and procurement teams ask the right questions. It is not a legal determination for a particular organization. HHS's own software-vendor answer explains why the answer turns on access needed to perform the service.
The first decision: is PHI part of the service?
Start with the parties. A covered entity can be a health plan, health care clearinghouse, or a health care provider that conducts covered electronic transactions. A business associate can work directly for one, or can be a subcontractor of another business associate. HHS expressly includes subcontractors that create, receive, maintain, or transmit PHI on a business associate's behalf. This matters when a health-tech company buys the test on behalf of its hospital customers: the customer contract, the testing contract, and any hosting arrangements may form different links in the chain.
Next, separate access needed for the service from access that is merely conceivable. HHS says that selling or providing software alone does not make a vendor a business associate when it has no access to the customer's PHI. HHS also says a business associate contract is not required for a service that does not involve PHI use or disclosure, where any access would be incidental, if at all, and where reasonable safeguards are in place. A pentester who can only use synthetic records in an isolated environment presents a different question from a pentester whose assigned accounts can open real patient charts and whose report will include screenshots from them.
Do not turn the second case into a blanket rule about every penetration test. Whether a BAA is required depends on the regulated entity, the function performed, the access actually needed, and the planned data handling. Equally, do not call planned viewing of live patient data “incidental” simply because a tester intends to redact the final report. Seeing or receiving PHI can be part of the service even when the deliverable omits it. The HHS business associate guidance and software-vendor FAQ are the starting points for a fact-specific review.
A buyer decision tree
The diagram below is a procurement prompt, not a substitute for a legal conclusion. It separates the data-design decision from the contract decision. Ask the questions in order; do not start by asking a vendor whether it is “HIPAA certified.”
Figure 1: How a healthcare buyer can route the data-access question before engaging a penetration testing vendor. Sources: HHS business associate guidance, HHS software-vendor FAQ, and NIST SP 800-115.
Question | What to record | What changes in procurement |
|---|---|---|
Who is buying, and on whose behalf? | Covered entity, business associate, or business-associate subcontractor; owner of the system and data. | Identify the right contracting party and who approves data access. |
What data can the assigned test accounts see? | Synthetic records, HHS-method de-identified records, live PHI, or an unknown mix. Include exported files and API responses. | Decide whether the design can avoid PHI and whether a BAA review is needed. |
What will the tester collect or maintain? | Screenshots, request and response pairs, logs, downloaded objects, evidence attachments, chat, and report drafts. | Name permitted collection, redaction, storage, transfer, and disposal terms. |
Who else may receive it? | Testing platform, report host, cloud storage, subcontracted testers, ticketing integration. | Review each recipient and the required downstream terms. |
What is the fallback if live PHI appears? | Stop condition, named contact, minimization step, and report-edit process. | Agree on escalation before authorizing the test. |
The table is intentionally short enough to send with a request for quote. A vendor can price and schedule an engagement more accurately when the data path is already decided. It also prevents a mistaken assumption that “we will use test accounts” means “no PHI can reach the tester.” An account's label does not decide what the application's API returns.
Three common data paths, with different contract questions
Path A: synthetic records and no PHI in the testing flow
A buyer can sometimes create a production-like test tenant with fictitious patients, claims, prescriptions, or appointments that were never copied from real people. The buyer controls identities and can exercise authorization and workflow boundaries without deliberately exposing PHI. This design reduces privacy risk and can make scheduling easier. The scoped vendor still needs written authorization, data-handling terms, and a confidential report process, because architecture and vulnerabilities are sensitive even when patient data is absent. NIST SP 800-115 recommends considering non-production systems with false personal data when intrusive tests could expose sensitive information.
The buyer should verify the claim that no PHI enters the flow. Check API payloads, seeded databases, production integrations, error messages, logs, analytics events, object-storage buckets, and email or SMS test messages. An apparently synthetic front end can still query a live directory or return a production record through an integration. If the test's success criteria require showing that one real patient's record is accessible to another account, the design has crossed into a different path. The engagement's privacy review should follow the actual access, not the original plan.
Do not treat a copied production dataset with names replaced as automatically de-identified. HHS recognizes Expert Determination and Safe Harbor as the two methods for de-identification under the Privacy Rule. The buyer should document which method was used if it relies on the dataset's de-identified status. Better still, create wholly fictitious records when that supports the test objective. If real data is needed to exercise a business flow, move to Path B rather than stretching the label on the dataset.
Path B: live ePHI is part of the work
Some tests must exercise the real production authorization boundary. A hospital might need to know whether a delegated role can see another clinic's chart. A health plan might need a claim-level approval flow tested across distinct roles. The buyer may conclude that giving testers accounts with live ePHI access is necessary for the service. HHS's IT-contractor example and its software-vendor FAQ then make the BAA question concrete: the vendor is not merely selling a tool; its work may require access to PHI.
For this path, have privacy and legal reviewers decide the business associate arrangement before accounts are provisioned. The contract should describe the permitted work and the systems, records, and disclosures it entails. The testing statement of work (SOW) and rules of engagement (ROE) should state which accounts and roles are authorized, how findings will be proved without excessive patient detail, what evidence may be retained, and what happens if a tester reaches data outside the approved area. A BAA handles the HIPAA relationship; the SOW and ROE handle the concrete test mechanics. Neither document should be expected to silently supply terms the other lacks.
A useful report need not reproduce a full patient chart. The tester may be able to prove the access-control failure with record identifiers created for the test, a redacted response fragment, a count of unauthorized objects, or a screenshot cropped to the permission boundary. The client and tester should agree on that proof standard first. If the minimum evidence still contains PHI, the report, portal, and communications carrying it must be inside the reviewed data flow. HHS's minimum necessary guidance supports reducing unnecessary PHI exposure; it does not erase the need to determine whether the vendor is a business associate.
Path C: PHI access is possible but not part of the planned service
An enterprise network test may begin with no access to patient systems, while the environment contains routes to them. A mobile app test may use test data, yet a backend endpoint may return a live record after a defect is found. Those cases require a boundary in the ROE: how far may a tester go to verify an issue, what should be captured, and when must testing stop for client direction? NIST says the assessment plan should name scope, authorization, data handling, and incident handling before work starts. Its ROE template treats these as explicit decisions.
Do not assume a possible encounter is “incidental” under HHS's definition, and do not assume every possibility turns a vendor into a business associate. The decision needs facts about the test methods and data that would reasonably be involved. If the vendor's service is designed to traverse live patient workflows, Path B is likely the more accurate starting point. If PHI is outside the service, any access would only be incidental, and reasonable safeguards are in place, HHS describes a different case. Document those safeguards and the boundary, then have the responsible privacy team decide it.
Make the evidence flow visible before the test starts
A pentest produces more than a final PDF. The test team may record browser screenshots, HTTP requests, application logs, messages in a collaboration portal, draft findings, and retest notes. A vendor may use cloud storage and ticketing integrations to deliver them. Each artifact can carry PHI even if the vendor never downloads a database. A procurement review that looks only at the final report misses most of the working evidence.
Start with a data-flow map. List the application or environment, test accounts, record types, API endpoints, tools, evidence repository, communication channels, and intended recipients. Mark where PHI could appear. Then state the maximum evidence needed to prove each class of finding. For an authorization issue, that may be a test record identifier and the wrong role's access result. For a session issue, it may be a token-redacted trace. For a cloud exposure, it may be metadata about an object rather than the object's content. Those are scoping choices, not universal HIPAA prescriptions.
NIST's data-handling section says the assessment plan or ROE should document collection, storage, transmission, and destruction of sensitive test data. It calls out storage on assessor systems, data retained after the assessment, and transfer across networks. HHS's sample BAA provisions address permitted uses, safeguards, reporting, subcontractors, and return or destruction of PHI. Together, those primary sources point to a practical procurement rule: write down every place evidence goes and the permitted use of each copy.
Artifact | Why a tester may need it | Buyer question before granting access |
|---|---|---|
Test account and role inventory | Proves that each intended user boundary was exercised. | Are accounts synthetic, and can any account view live records? |
Request and response pairs | Proves an authorization or business-logic result. | Can payloads be truncated or redacted without losing proof? |
Screenshots and video | Shows the UI state and reviewer-visible impact. | Are names, dates of birth, or record numbers visible in the capture? |
Vulnerability ticket | Gives engineers a prompt fix and retest path. | Does the ticketing integration copy evidence into another system? |
Draft and final reports | Gives the buyer findings, scope, dates, and remediation advice. | Who may download, forward, retain, or delete each version? |
Retest evidence | Shows whether the specific issue was corrected. | Will a retest create another copy of the same sensitive data? |
A report can remain useful to engineering while the outward-facing summary is redacted. That division can help a buyer answer a customer questionnaire without sending detailed vulnerability evidence or PHI to someone who does not need it. The permission to disclose either version should follow the client's policy and contract. A “shareable” report is not automatically appropriate for every recipient.
Put the BAA, SOW, and ROE in their proper jobs
A BAA is the HIPAA arrangement for a business associate. HHS's sample provisions describe permitted and required PHI uses and disclosures, safeguards, reporting of impermissible uses or disclosures, subcontractor obligations, and return or destruction at the end of the relationship where feasible. HHS says the sample language is adaptable; it can be part of the services agreement or a separate agreement. Procurement and counsel should fit those terms to the actual engagement.
The SOW is the purchase definition. It should identify the systems, environments, applications, APIs, user roles, and testing objectives. It should distinguish a web application and associated APIs from internal networks, identity systems, cloud control planes, mobile apps, and social-engineering work. A vendor's fixed web price does not silently cover all of those. The SOW should also identify deliverables, report audience, retest method, schedule dependencies, and commercial assumptions. Use the broader penetration testing SOW template for the full contract structure; this guide adds the PHI-specific questions the SOW needs to answer.
The ROE is the operating boundary. NIST SP 800-115 says a test plan should identify who is authorized, the scope, logistics, sensitive-data handling, and incident response. For a health-data environment, the ROE should say whether a tester may open a real record, whether copying it is permitted, what to do when an access-control defect exposes more records than expected, and who can direct a pause or rescope. The ROE should also identify fragile clinical systems, permitted testing windows, production versus staging, and escalation contacts. These are buyer decisions to agree with the tester, not terms to infer from a standard methodology name.
A signed BAA does not enlarge the technical testing scope. A signed SOW does not, by itself, settle every HIPAA data-use term. A generic NDA does not answer the PHI question either. The three documents can reference each other, but the parties still need one consistent description of what is authorized. Before signature, compare their definitions of “customer data,” “test data,” “report,” “subcontractor,” and “deletion.” If they disagree, resolve that mismatch while the engagement is still easy to change.
The buyer's contract and data checklist
Send the same questions to every shortlisted vendor. Ask for written answers before comparing prices. The responses form a decision record that privacy, security, procurement, and the assigned test lead can all review.
Entity and access: Which legal entity will perform the work? Which named people will receive accounts or evidence? Will those people work for the contracting firm or a subcontractor?
BAA position: Based on the proposed access and service, does the vendor expect a BAA? If so, which entity signs it and when? Ask your own privacy and legal teams to decide the client's position.
Data minimization: Can the required test objectives be met with wholly fictitious records, or with data de-identified under an HHS method? Which tests genuinely need live PHI?
Production boundary: Which production systems, APIs, tenants, and accounts are included? What is outside the authorization, even if reachable?
Collection: What evidence will be retained for each finding? Can request bodies, screenshots, and downloads be truncated or redacted at capture time?
Storage and transfer: Where are working notes, portal findings, recordings, and final reports stored? What encryption and access controls protect them? Which integrations create copies?
Subcontractors: Which people or services can receive PHI? How will the vendor apply the agreed restrictions downstream? HHS's business associate contract guidance expressly addresses subcontractors.
Incident escalation: Who receives an immediate call if the test exposes unexpected PHI, causes clinical disruption, or reaches another tenant? What is the stop condition?
Report versions: Will there be a detailed technical report and a separately redacted version for customer or auditor requests? Who approves redactions?
Retention and return: When will raw captures, draft reports, backups, portal attachments, and final reports be returned or destroyed? What evidence of completion can the buyer request?
Retest: Does the fee include a retest of corrected findings? Will it use the same accounts and data path, and will it create new evidence copies?
Change control: If a new environment, user role, integration, or PHI data type enters scope, who can approve the change and how is the contract updated?
This is a procurement checklist, not a demand that every vendor use the same infrastructure. It lets a buyer judge the real test and data path. A brief “yes, we are HIPAA compliant” answer does not tell a privacy team where evidence goes or how a vendor will handle a PHI-bearing request trace. A strong answer names systems, people, controls, and the point at which the vendor will ask for direction.
A quote-ready ePHI scope sheet
Before sending an RFP, give bidders one version of the scope. Otherwise one proposal may assume a synthetic staging tenant while another prices production testing with live ePHI and a complex evidence process. The total prices will be incomparable because the work is different. Use the fields below with no real patient names, credentials, or secrets in the RFP. Share sensitive diagrams and access details only through the approved procurement channel.
Field | Buyer entry to complete | Why the bidder needs it |
|---|---|---|
Business owner | Covered entity or business associate, contracting entity, privacy contact. | Identifies whose approval and data obligations apply. |
System owner | Name of the owner of each app, API, tenant, or network segment. | Avoids testing a third-party surface without permission. |
Test objective | Authorization, business logic, external exposure, internal paths, cloud or identity controls. | Defines the depth of human testing and evidence required. |
Environment | Production, staging, or a production-like replica; note live integrations. | Determines safety controls and whether real records can appear. |
Record design | Wholly synthetic, documented de-identified, live PHI, or undecided. | Drives privacy review and the vendor's evidence plan. |
Roles and workflows | Clinician, patient, administrator, payer, integration partner, service account, and any tenant boundary that matters. | Prevents a quote based on a single generic login. |
Systems and APIs | Inventory or count, authenticated routes, file exchange, mobile backend, and cloud dependencies. | Prevents an app-only scope that misses the data path. |
Evidence limit | Approved proof for each finding class, redaction rule, prohibited downloads, and report audiences. | Defines what the vendor may collect and deliver. |
Handling terms | Approved storage, transfer, notification, subcontractors, retention, and disposal. | Allows the vendor to price and accept the operating model. |
Schedule | Test window, freeze periods, clinical safety owner, report date, and retest window. | Prevents a fast quote from ignoring operational constraints. |
The buyer can write “undecided” in a field, but should not let a vendor silently resolve it. If the data path is undecided, request a discovery call and a conditional proposal with explicit assumptions. After privacy review, issue one final scope to all bidders. That is the point at which a price comparison becomes meaningful. The quote comparison guide explains how to normalize tester time and exclusions after the scope is common.
Worked example: a provider portal and a claims API
Suppose a provider portal uses a claims API and several roles. The buyer wants to know whether a low-privilege clinic user can read a different clinic's claim, and whether a payer integration can change a claim status it should only view. In the RFP, the buyer can describe the roles, workflows, and endpoint families without sharing real claim data. It can ask each bidder to price a staging test with fictitious claims and an optional production phase if staging cannot reproduce the authorization boundary.
The privacy decision is then explicit. In the staging phase, the buyer verifies that records, logs, exports, and integration responses are not PHI. If production access is later necessary, the buyer and vendor pause, decide the BAA and evidence terms, and amend access and ROE before that phase. A vendor that quotes both phases separately has made the uncertainty visible. A vendor that assumes production access while describing “non-sensitive test data” has not reconciled the scope.
This example is hypothetical. It is a way to structure a purchase, not a claim that a particular client or application was tested.
What a useful healthcare pentest evidence pack contains
The Security Rule requires a regulated organization to assess risks and vulnerabilities to ePHI, as HHS explains in its Security Rule summary. A penetration test can support that program with technical findings and proof of remediation. It does not replace the organization-wide risk analysis or establish that every HIPAA obligation has been met.
For a buyer, the evidence pack should answer what was tested, when, by whom, what was found, and what was fixed. The scope statement names the applications, APIs, identities, and environments. The technical report states methodology, evidence, impact, and prioritized remediation. A retest record shows which specific findings were verified after changes. A management summary can communicate the result without circulating sensitive request traces. Those are deliverables to specify in the SOW; their exact format can vary by vendor.
The evidence itself may need protection. A finding that proves a user can open another patient's record is useful, but the report should disclose no more patient detail than necessary to establish the flaw. A breach of an access boundary should be reported promptly to the agreed contact, not held for the final PDF. NIST calls for critical findings to be escalated during assessment and for sensitive test data to be handled under the plan. The BAA and ROE should set the specific notification and handling terms for the engagement.
When a customer or auditor asks for the result, decide which artifact they are entitled to receive. A completion or attestation letter can state scope and dates. A redacted executive summary can state the outcome and remediation status. The full technical report may contain details that should stay with the security and engineering team. For more on that distinction, see completion letters versus full reports and the HIPAA penetration testing requirements guide.
Where Stingrai fits, and what to confirm in a quote
Stingrai is a Toronto-headquartered, CREST-accredited penetration testing company that performs human-led work across web and API applications, mobile, cloud, network, Active Directory, and social-engineering scopes. For healthcare buyers, the test should follow the actual data and identity paths: authenticated roles in a patient portal, authorization across API objects, mobile-to-backend flows, and the cloud or identity controls that protect them. Stingrai's PTaaS page says Hybrid engagements pair Snipe with two named penetration testers from a team holding OSCE³, OSWE, OSEP, CREST CRT and CISSP certifications. It says cloud, network, Active Directory and mobile testing is human-led, findings are delivered through a portal, and retesting of fixed findings is included. These are published service descriptions, not a representation that any particular HIPAA arrangement has been approved.
The live pricing page publishes fixed Autonomous and Hybrid Pentest packages for one web application and associated APIs. Autonomous is Snipe, Stingrai's agent for web applications and associated APIs, without human testers; its deliverable is a pentest report. Hybrid has Snipe and human testers working together throughout and includes an attestation letter. Wider healthcare environments, such as multiple applications, mobile, cloud, network, and identity, are custom scoped under Enterprise. The published package price does not answer whether a BAA is needed for a proposed data flow or whether a particular integration is in scope. Resolve those questions before comparing the quote with another vendor's.
Ask Stingrai or any bidder to state the precise access model, scope, handling of PHI-bearing evidence, report audience, and contract assumptions in the proposal. The buyer's privacy and legal teams should review the BAA question from those facts. If the environment cannot be tested without live PHI, a vendor that cannot agree to the necessary terms is not a fit for that scope. If synthetic data can prove the relevant controls, a narrower path may be available. In either case, the goal is an authorized test that produces evidence the security team can use and share appropriately.
Frequently Asked Questions
Does a penetration testing vendor need a BAA under HIPAA?
A penetration testing vendor may need a BAA when its service for a covered entity or business associate requires it to create, receive, maintain, or transmit PHI. HHS says an IT vendor that needs PHI access to provide its service can be a business associate. The buyer should document the proposed access and have its privacy and legal teams decide the arrangement before granting access.
Is a BAA required for a pentest that uses only synthetic data?
A pentest using wholly fictitious data may avoid the PHI access that raises the business associate question, but the buyer must verify that no production records, live integrations, logs, screenshots, or other evidence disclose PHI to the vendor. HHS distinguishes services with no PHI use or disclosure and only incidental possible access when reasonable safeguards are in place. The actual service and data flow, rather than the test-data label, control the analysis.
Is replacing patient names enough to call test data de-identified?
No. HHS describes Expert Determination and Safe Harbor as the two methods for de-identification under the HIPAA Privacy Rule. Replacing names alone does not establish that either method has been met. If the buyer relies on de-identified data, it should document the method and check identifiers and linkable fields before sending the dataset to a tester.
Can a vendor test a production patient portal without copying PHI into its report?
A vendor can plan evidence that avoids unnecessary PHI in the final report, such as test-record identifiers or redacted proof. That does not settle the BAA question if the vendor's service requires it to view or receive PHI during testing. Agree on permitted production access, evidence collection, storage, notification, and redaction before the test begins.
Does an NDA replace a business associate agreement?
An NDA does not by itself supply the HIPAA business associate terms HHS describes. When the arrangement calls for a BAA, HHS says the written contract must address permitted PHI uses and disclosures, safeguards, reporting, subcontractors, and return or destruction. The SOW and ROE should then define the practical testing scope and data-handling instructions.
Does the BAA need to cover a subcontracted tester or report platform?
HHS says business associate contracts must require subcontractors that will have access to PHI to accept the same restrictions and conditions. A buyer should ask which legal entities and services can receive PHI, including testers, storage, portals, and integrations, and have its privacy team review the resulting contract chain. Do not assume a vendor's brand name identifies every recipient of evidence.
Does HIPAA require an annual penetration test?
The current HIPAA Security Rule requires risk analysis and risk management but does not state a universal annual penetration-test mandate. A test can support the program and provide evidence of technical findings and remediation. The buyer should set frequency based on its risk analysis, changes, customer commitments, and other applicable obligations, and check the current rule before using a deadline in a contract.
What should I send vendors to get comparable healthcare pentest quotes?
Send the same scope sheet to each bidder: systems and APIs, roles and tenants, environment, record design, permitted PHI access, evidence limits, subcontractors, reporting, retesting, and schedule. Mark undecided items as assumptions to resolve in a discovery call. A price is comparable only after those assumptions are aligned.
Related reading
References
U.S. Department of Health and Human Services. Business Associates: Frequently Asked Questions. Accessed 1 November 2026. Definitions, examples, and BAA obligations.
U.S. Department of Health and Human Services. Is a software vendor a business associate of a covered entity?. Accessed 1 November 2026. Access needed for service compared with mere sale of software.
U.S. Department of Health and Human Services. Business Associate Contracts. Accessed 1 November 2026. Required contract elements and adaptable sample provisions.
U.S. Department of Health and Human Services. Guidance on HIPAA and Cloud Computing. Accessed 1 November 2026. Treatment of ePHI maintained by a cloud service provider.
U.S. Department of Health and Human Services. Guidance Regarding Methods for De-identification of PHI. Accessed 1 November 2026. Expert Determination and Safe Harbor.
U.S. Department of Health and Human Services. Minimum Necessary Requirement. Accessed 1 November 2026. General use and disclosure limitation with exceptions.
U.S. Department of Health and Human Services. Summary of the HIPAA Security Rule. Accessed 1 November 2026. Risk analysis and security management context.
National Institute of Standards and Technology. Technical Guide to Information Security Testing and Assessment, SP 800-115. September 2008. Assessment plans, rules of engagement, and data handling.
Stingrai. Plans and Pricing. Accessed 1 November 2026. Published web package scope and enterprise custom quoting.
Talk to Stingrai
For a healthcare test, send the system and role inventory, state whether the vendor will encounter live ePHI, and describe the evidence you need. Get a Quote or book a free discovery call to scope the authorized work and its deliverables.
