A healthcare vendor security questionnaire is the written set of questions a provider or billing team sends a vendor before it handles PHI. It covers the BAA, encryption, access, audit logs, retention, subprocessors, incident response and security testing. Judge each answer by the evidence attached to it and by how it fits your own risk analysis.
What a healthcare vendor security questionnaire covers
A healthcare vendor security questionnaire covers every place a vendor could expose PHI: the contract, protection in storage and transit, who can reach it, what is recorded, how long it is kept, who else handles it, what happens when something goes wrong and how the vendor tests itself. Each area pairs a question with the evidence that backs it.
The areas follow the HIPAA Security Rule closely. 45 CFR 164.308 on the eCFR sets out the administrative safeguards, from risk analysis to incident procedures and contingency plans. 45 CFR 164.312 on the eCFR sets out the technical ones: access control, audit controls, integrity, authentication and transmission security. A questionnaire built on those headings asks about the things a business associate is already required to address.
Here is a questionnaire table grouped by area. The questions are a starting set; add your own for anything specific to how you will use the vendor.
| Area | Questions to ask | Evidence to request |
|---|---|---|
| BAA | Will you sign our BAA? Do your terms cover subcontractors, incident reporting and return or destruction of data? | The signed or draft BAA, with any changes marked |
| Encryption | Is PHI encrypted in transit and at rest, including backups and exports? Who holds the keys? | A written description of the encryption scheme and key management |
| Access | Who on your staff can reach our data? How is access granted, reviewed and removed? Is multi-factor sign-in required? | Access control policy, a sample access review, a screenshot of the sign-in settings |
| Audit logs | Which events are logged? Can we see logs for our own data? How long are logs kept? | A sample log export with fictional or redacted entries |
| Retention | How long do you keep source documents and extracted data? Can we shorten it? How is data deleted? | Retention policy, a description of the deletion process, a sample deletion confirmation |
| Subprocessors | Which outside companies handle our data, and for what? Is each under a BAA with you? | A current subprocessor list and confirmation of agreements |
| Incident response | How do you detect, contain and report incidents? Who contacts us, and how fast? | Incident response plan summary and the notification terms in the BAA |
| Testing | When was your last penetration test? Do you run vulnerability scans? Who performs them? | A pen test summary or attestation letter, with remediation status |
The detail behind two rows has its own posts. The question of key ownership is covered in who holds the encryption keys for PHI, and the events a log should hold are listed in which events belong in a PHI audit log.
Why the BAA comes first
The contract row is first because everything else hangs on it. 45 CFR 164.314 on the eCFR requires a business associate contract to commit the vendor to the Security Rule, to flow those duties down to its subcontractors and to report security incidents. If a vendor will not sign, the rest of the questionnaire does not matter. For document software in particular, the guide to HIPAA compliant OCR explains why the tool alone cannot be compliant and the service around it has to be.
How do you run a HIPAA security risk assessment for vendors?
A HIPAA security risk assessment for vendors scores each vendor's answers against the risks in your own risk analysis. List what PHI the vendor will see and how much of it, rate the likelihood and impact of each weakness the answers reveal, and record what you will do about each one: accept it, require a fix, or decline the vendor.
The requirement behind this is your own risk analysis. Paragraph (a)(1)(ii)(A) of 45 CFR 164.308 calls for "an accurate and thorough assessment of the potential risks and vulnerabilities" to electronic PHI held by the covered entity or business associate. A vendor that will hold your PHI becomes part of that picture. The vendor assessment is how you fold it in.
A simple scoring method
Rate each questionnaire area on two scales from 1 to 3.
- Exposure. How much PHI does this area touch for this vendor? A vendor that stores every EOB you receive scores 3 for retention. One that processes pages and keeps nothing scores 1.
- Answer quality. How well does the answer and its evidence address the risk? A clear policy with a sample log scores 1. A vague answer with no evidence scores 3.
Multiply the two. A score of 6 or 9 is a finding you must act on before signing. A score of 3 or 4 is a finding to track. A score of 1 or 2 is acceptable as it stands. The thresholds are an example; set your own and apply them the same way to every vendor.
A worked example
Take a fictional vendor, Example Document Co., that will process 3,000 intake forms a month and keep them for a year. Its retention answer is "we keep data as long as needed" with no policy attached. Exposure is 3, answer quality is 3, and the score is 9. The action is a contract clause setting a retention period and a deletion confirmation. Its audit log answer includes a sample export with fictional entries showing views, edits and exports by user and time. Exposure is 3, answer quality is 1, and the score is 3: track it, no action now.
Write the scores, the actions and the reviewer's name in one document per vendor. When the vendor changes its service or you change how you use it, update the scores. Paragraph (a)(8) of 164.308 asks for evaluation "in response to environmental or operational changes", and a new vendor or a new use of an old one is exactly that kind of change.
Reading penetration test reports from healthcare vendors
Penetration test reports from healthcare vendors show whether an outside tester tried to break in, what they found, and what the vendor fixed. A fair request is a summary or attestation letter, not the full report. Read it for scope, dates, who did the testing, findings by severity and the status of each fix.
A penetration test is an authorized attempt to break into a system the way an attacker would. The Security Rule does not use the term. Its evaluation standard in 164.308(a)(8) calls for "a periodic technical and nontechnical evaluation" of a business associate's safeguards, and a pen test is one common way a vendor shows the technical part.
What to read first
- Scope. Which systems were tested? A test of the marketing website says nothing about the application that holds your documents. Look for the production application, its programming interfaces if any, and the storage behind them.
- Dates. When was the test done? A report from three years ago describes a different system.
- Tester. Was the tester independent of the team that built the system? An internal test is useful, but an outside firm is harder to argue with.
- Findings by severity. How many critical, high, medium and low findings? A report with zero findings of any kind deserves a question about how wide the scope was.
- Remediation. Is every critical and high finding marked fixed or retested? Open high findings with no date are a reason to pause.
What not to ask for
A vendor may decline to send the full report, because it describes how to attack the system. That is a reasonable position. Ask for the executive summary or an attestation letter from the testing firm, and ask the vendor to walk you through open findings on a call. Refusing even a summary is a different matter.
Which security questionnaire answers need evidence attached?
Security questionnaire answers need evidence attached whenever the claim is about a control that you cannot see from outside. Claims about encryption, access reviews, logging, retention, subprocessors and testing should each come with a document, a screenshot or a report. Claims about intentions, such as "we plan to", need a date and a contract clause instead.
A useful rule is to sort every answer into one of three types.
- Shown. The vendor attached a policy, a sample log, a screenshot or a report. Read it and check it says what the answer says.
- Stated. The vendor wrote an answer but attached nothing. Ask for evidence, or note the gap in your risk assessment.
- Promised. The vendor described something it will do later. Ask for a date and put it in the contract, or treat the control as absent.
These answers should always be "shown":
- That the BAA is signed, with its subcontractor and incident clauses.
- The subprocessor list, with dates.
- Encryption of data in storage and in transit, with key ownership.
- That access is reviewed, with a sample review record.
- That logging covers views and exports, with a sample export.
- That a recent pen test or vulnerability scan happened, with a summary.
Audit reports are evidence too, but they need careful reading. A SOC 2 report shows how an auditor tested a set of controls over a period; it is not a statement of HIPAA compliance. The comparison of SOC 2 vs HIPAA explains the difference, and the section on what a SOC 2 Type II report tells a healthcare buyer covers which parts to read.
When a full security questionnaire is overkill for a vendor
A full security questionnaire is overkill when the vendor will never see PHI. A trial on de-identified sample documents, a tool that only processes blank forms, or a service that never stores data may need a short review instead. Scale the review to what the vendor will actually touch, and run the full one before any real patient data moves.
A trial on de-identified samples
A document AI trial on pages with every identifier removed does not put PHI in the vendor's hands. A short review is enough: confirm the vendor's terms for sample data, check what it keeps and for how long, and confirm it will sign a BAA if the trial goes well. How to build that sample set is covered in the guide to de-identified sample documents for a pilot. Schema Care's free plan is for de-identified sample documents, every paid plan includes a BAA, and its custom Health system plan adds a security review, as the Schema Care pricing section lists.
Small vendors with narrow access
A vendor that will see a narrow slice of PHI, such as a courier that moves sealed record boxes, may warrant a handful of questions rather than the full table. Whether its contract needs BAA terms is a question for your compliance lead. Score the areas that apply and mark the rest as not applicable, with a reason.
Vendors whose use changes
A vendor that started on samples and moves to live documents is a new review, not a continuation. The same goes for a fax service that starts routing documents into your EHR, a change the post on how to process medical faxes automatically describes. When the data changes, run the full questionnaire before the change goes live, and check the vendor against the questions to ask a BAA OCR vendor if it reads documents.
Keep the short review on file
A short review is still a review. Write down why the full questionnaire did not apply, what you checked instead, and what would trigger the full one. That note is what makes the decision defensible later.