The LIS Security Review: 30 Questions US Labs Should Ask Vendors
Most clinical LIS sales calls fall apart in the same room, the one where IT security starts asking questions the slide deck never answered. This is the list that gets you through that
Table of Contents
TL;DR
An LIS security review is the due diligence process where a hospital or enterprise IT team tests a lab software vendor across access control, encryption, hosting, certifications, subprocessors, incident response, backup, and data exit before signing. This guide walks through all eight domains with what a credible answer sounds like and the red flag that should stop a review cold, built around a free thirty-question list you can take straight into your next vendor call.
- Eight domains, thirty questions, one good answer and one red flag for each
- A scoring method that turns a vague sales call into a documented review
- Where security questions overlap with HIPAA, SOC 2, and ISO 27001
- What to request before the call so the review does not stall on paperwork
A lab software demo can look finished and still be nowhere near signed. Enterprise lab and hospital buyers will not move past a strong product impression until IT security signs off, yet most LIS vendors are only prepared to answer security questions live, on a call, without documentation behind them. The people in that room are rarely just one person. Expect IT or informatics, a compliance officer, procurement, and sometimes legal, each testing a different part of the same answer. Labs hold protected health information that attackers specifically target, which means a vendor who treats security as a one-page slide is asking a hospital to take on risk it has no way to verify. A vendor with published, specific answers shortens that review by weeks, simply because nobody is waiting on a callback.
How Hospital and Lab Enterprise IT Teams Actually Run a Security Review
Reviews tend to follow the same path everywhere, even when the paperwork looks different. A questionnaire goes out first, then a documentation request covering an attestation report, a signed Business Associate Agreement, and a penetration test summary. A call with the LIS vendor’s security lead follows, then a risk rating that feeds into contract terms. Knowing this sequence in advance means a lab can show up with documents ready instead of promising to send them later.
What the reviewer is trying to learn
Each domain below answers one question in the reviewer’s head: who can touch the data, is it protected everywhere it sits, where does it physically live, can the vendor prove its claims, who else touches the data, what happens when something breaks, can the lab recover, and what happens at the end of the contract.
What to have ready before the first call
A signed or reviewable BAA, the most recent SOC 2 or ISO 27001 report, a penetration test summary, and a named list of subprocessors. Showing up with these ready, rather than promising to chase them down later, is usually the single biggest thing that speeds a review up.
| Domain | Questions | What the reviewer wants to confirm |
|---|---|---|
| Access control | 1 to 4 | Who can reach patient data, and how tightly that is scoped |
| Encryption and keys | 5 to 8 | Data is protected in transit, at rest, in backups, and in test environments |
| Hosting and residency | 9 to 12 | Where data physically lives and who can reach it from where |
| Certifications and BAA | 13 to 16 | Independent proof behind the vendor's own claims |
| Subprocessors | 17 to 19 | Which other vendors touch the data and how changes are handled |
| Incident response | 20 to 23 | Detection speed, notification timing, and what happens after |
| Backup and recovery | 24 to 27 | Whether backups survive an attack and how fast service returns |
| Data exit | 28 to 30 | Getting data back, proof of deletion, and continuity if the vendor changes hands |
Those eight domains, in that order, are the backbone of nearly every LIS vendor security questionnaire a hospital or enterprise lab group will send.
Domain One: Who Can Access Patient Data, and How Is It Controlled?
Access control is usually the first thing a reviewer tests, because most breaches trace back to a credential or a permission that was broader than it needed to be.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 1 | How do you control which users see which patient records? | Role-based access, least privilege, a documented role matrix | Shared logins or broad admin roles that see everything |
| 2 | Do you support multi-factor authentication and single sign-on? | MFA enforceable; SAML or OIDC SSO; session timeout controls | Password-only login, or SSO sold as a custom project |
| 3 | How is vendor staff access to our data approved and logged? | Just-in-time, approved, time-limited access with full logs | Standing access to production data for support staff |
| 4 | Can we export a log of who viewed or changed a record? | User, time, action, and before and after values, exportable on demand | Logs available only through a support ticket |
Domain Two: Encryption and Key Management: What to Ask
Encryption questions test whether data stays protected in transit, at rest, in backups, and in the hands of the vendor’s own staff during testing.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 5 | How is data encrypted in transit, including instrument interfaces? | Current TLS everywhere, including tunneled interface traffic | Interface traffic sent unencrypted with no compensating control |
| 6 | How is data encrypted at rest, including backups? | Strong encryption for databases, files, and backups alike | Database encrypted but backups or file storage left out |
| 7 | Who manages encryption keys, and how are they rotated? | Managed key service, a rotation schedule, separation of duties | Keys stored beside the data with no rotation policy |
| 8 | How is data protected in test environments and exports? | No real patient data in test, masking, secure delivery | Production data copied straight into development |
Domain Three: Hosting and Data Residency, Where Your Data Lives
Hosting questions establish where protected health information sits, who can reach it from where, and how one customer’s data stays apart from another’s.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 9 | Which region hosts our data, and can we choose it? | Named provider and region, written into the contract | "In the cloud" with no region named |
| 10 | Is our data ever accessed from another country? | Written cross-border access policy, exceptions disclosed upfront | Offshore access that only surfaces when asked |
| 11 | How is our tenant separated from other customers? | Documented, tested logical isolation, dedicated options available | Shared database with no documented isolation |
| 12 | What protects the platform: firewalls, scanning, penetration tests? | Regular scanning and an annual pen test summary under NDA | No independent test, or refusal to share a summary |
Lab data residency is the single question US reviewers ask first, since it decides whether every other answer even applies.
Domain Four: Which Certifications and Agreements Should a Vendor Hold?
A US lab software vendor handling protected health information should offer a Business Associate Agreement before contract and be able to show independent attestation, with the report type, period, and scope stated plainly rather than implied.
A Business Associate Agreement is the written contract HIPAA requires between a covered entity and any vendor that handles protected health information on its behalf, spelling out permitted uses and breach obligations.
As per HHS, a Business Associate Agreement is required when a vendor creates, receives, maintains, or transmits protected health information on behalf of a covered entity. As per AICPA, SOC 2 Type I attests to a vendor’s security controls as designed at a single point in time; Type II attests that those controls actually operated effectively over a defined period, which is the stronger and more commonly requested report.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 13 | Will you sign a BAA, and what does it cover? | Standard BAA offered before contract, covering subprocessors and breach terms | BAA refused, or offered only after signature |
| 14 | Which independent attestations do you hold, and what is their scope? | SOC 2 type and period stated; ISO 27001 scope and issuer named | Logo-only claims with no stated scope |
| 15 | Can we review your latest SOC 2 report under NDA? | Yes, with any exceptions in the report explained plainly | A marketing summary instead of the actual report |
| 16 | How do you handle HIPAA risk analysis and staff training? | Documented annual risk analysis and security training for all staff | No documented risk analysis on file |
Lab data residency is the single question US reviewers ask first, since it decides whether every other answer even applies.
Domain Five: Subprocessors and Third-Party Risk Questions
Your data is only as safe as the vendors your vendor relies on, which is why reviewers ask for a named list and a defined change process rather than a general assurance.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 17 | Which subprocessors touch our data, and for what purpose? | A published list naming purpose and location for each | A list offered "on request" with no change notice |
| 18 | How are we told about a new subprocessor, and can we object? | Advance written notice with a real right to object | Changes made with no notice at all |
| 19 | How do you assess and monitor your own vendors? | A vendor risk process with BAA terms flowed down and reviewed annually | No flow-down of HIPAA terms to subprocessors |
Domain Six: How Will the Vendor Respond When Something Goes Wrong?
Under the HIPAA Breach Notification Rule 45 CFR §164.410, a business associate must notify the covered entity of a breach without unreasonable delay and no later than sixty days after discovery, a legal outer bound rather than a target to aim for. Incident response questions test whether a vendor can detect a problem, say so quickly, and fix it, with commitments written into the contract rather than left to goodwill.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 20 | Do you have a written incident response plan, tested recently? | Written plan with named roles, tested within the last year | A plan that exists but has never been tested |
| 21 | How quickly will you notify us of a breach, in writing? | A stated window in the contract, shorter than the legal maximum | "As required by law" with no actual number |
| 22 | How do you detect and monitor for suspicious activity? | Central logging and alerting with defined monitoring coverage | Logs reviewed only after an incident is already reported |
| 23 | What do we receive after an incident is resolved? | A root-cause report, remediation steps, and a named contact | No written post-incident report at all |
The ransomware patterns driving most of these questions are covered in more depth in this lab cybersecurity guide for 2026, which goes deeper into attack patterns than a vendor questionnaire needs to.
Domain Eight: What Happens to Your Data When the Contract Ends?
Exit questions ask whether a lab can actually get its data back, whether it gets deleted afterward, and what happens if the vendor is acquired or shuts down. Export format and cost sit in a separate commercial conversation; the angle here is secure transfer, proof of deletion, and continuity.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 24 | How often is data backed up, and where are backups stored? | Automated, frequent, encrypted backups kept apart from production | Backups stored in the same place as production data |
| 25 | What are your recovery time and recovery point objectives? | Stated numbers, referenced directly in the contract | "Best effort" with no actual figure attached |
| 26 | When did you last test disaster recovery, and can we see it? | Tested at least once a year, with a summary shared | A recovery plan that has never actually been tested |
| 27 | How would you restore service after a ransomware attack specifically? | Immutable backups, network segmentation, a tested restore process | No ransomware-specific plan beyond the general backup policy |
Domain Eight: What Happens to Your Data When the Contract Ends?
Exit questions ask whether a lab can actually get its data back, whether it gets deleted afterward, and what happens if the vendor is acquired or shuts down. Export format and cost sit in a separate commercial conversation; the angle here is secure transfer, proof of deletion, and continuity.
| # | Question | Good answer | Red flag |
|---|---|---|---|
| 28 | How is our data returned, and how is it transferred securely? | Vendor-neutral format, complete dataset, secure transfer included in standard terms | A proprietary format or a paid custom export job |
| 29 | When and how is our data deleted after termination? | A defined deletion period with a written certificate of deletion | No deletion commitment anywhere in the contract |
| 30 | What happens to our data if you are acquired or shut down? | A continuity clause where BAA obligations pass to any successor | No clause covering a change of control at all |
How to Score and Use These Thirty Questions
A security review works best as a scored exercise rather than a conversation that trails off into a general good feeling. Score every answer green, amber, or red, then ask for documents behind anything that is not green.
| Score | What it means |
|---|---|
| Green | Specific, documented, and backed by a report you can actually read |
| Amber | Specific, but no document yet behind the claim |
| Red | Vague, evasive, or an outright refusal to answer |
Treat any red answer in access control, the BAA, breach notification, or data exit as a stop, not a note to revisit later. Those four are the ones that tend to cause real damage if the vendor’s answer turns out to be wrong.
- Send the thirty-question list ahead of the first call, along with a request for the BAA, the SOC 2 or ISO evidence, and a penetration test summary.
- Run the call against the scoring guide above rather than general impressions.
- Follow up only on anything scored amber or red, with a specific document request attached to each one.
If your lab wants the current state of the vendor’s own certifications, hosting setup, and subprocessor list rather than a general answer, requesting the security pack directly gets you the documents a reviewer actually needs instead of a marketing page.
FAQ
What is a vendor security questionnaire for lab software?
A vendor security questionnaire for lab software is a structured set of questions that helps healthcare organizations assess a vendor’s data security, privacy controls, compliance practices, and breach-response readiness before implementation.
Does a lab software vendor need a signed BAA?
Yes, whenever the vendor handles protected health information on behalf of a covered entity. The Business Associate Agreement is a HIPAA requirement, not an optional add-on, and a vendor that resists signing one before a contract is a clear warning sign.
What separates SOC 2 Type I and Type II?
SOC 2 Type I evaluates whether security controls were properly designed at a specific point in time. Type II goes further, assessing whether those controls operated effectively over an extended period, typically three to twelve months, as per AICPA. That sustained evidence is why security reviewers often ask for a Type II report.
How long does a full vendor security review take?
It varies by lab size and how ready the vendor’s documentation is, but reviews move fastest when a vendor has its BAA, attestation reports, and subprocessor list ready to send immediately rather than promising to follow up after the call.
What documents should a vendor provide during review?
A signed or reviewable BAA, the current SOC 2 or ISO 27001 report with its scope stated, a penetration test summary, a named subprocessor list, and a written incident response summary are the core five documents any serious review should expect.
What is the legal deadline for HIPAA breach notification?
A business associate must notify the covered entity without unreasonable delay and no later than sixty days after discovering a breach, under the HIPAA Breach Notification Rule. That sixty-day figure is the outer legal limit, not a target a lab should settle for.
Where This Leaves You
A LIS vendor that answers all thirty questions with specifics and documents is telling you something real about how it operates day to day, not just what it says on a sales call. Any red answer in access control, the BAA, breach notification, or data exit is reason enough to stop and dig further before signing anything. Take the scoring method above into your next vendor conversation, and request the CrelioHealth security pack if you want to see how these thirty answers look when backed by actual documentation rather than a slide.
Recent Posts
Related Posts
Most clinical LIS sales calls fall apart in the same room, the one where IT security starts asking questions...
Somewhere between the first server crash and the third compliance audit, every diagnostic lab that built...
Revenue Cycle for Diagnostic Labs: How US Labs Recover Revenue Lost to Billing Leakage
Table of...