Vendor Security Due Diligence Before You Sign an HMS Contract

Start with location, because it constrains everything else and because a wrong answer here disqualifies rather than discounts. Ask where patient data is stored, where it is backed up, where it is processed, and where support staff access it from. Those four answers are frequently different, and the last one catches hospitals out: data resident in one place but routinely accessed by a support team elsewhere raises the same questions as storing it there.

Then map the sub-processors. Almost no vendor operates alone; there will be an infrastructure provider, probably a messaging or notification service, possibly an analytics tool, sometimes an offshore development or support partner. Ask for the list, ask what each one can reach, and ask to be notified before it changes. A vendor who cannot produce this list quickly has not thought about it, which is itself the finding.

Establish who at the vendor can see your data in normal operation, what approval that requires, and whether that access is logged in a way you can request. Support access to production data is legitimate and necessary. Unlogged, unrestricted, permanently-enabled support access to production data is neither, and it is common enough to be worth asking about specifically rather than assuming.

Security certifications appear on every vendor's material and are frequently misread. A certificate demonstrates that a defined scope was assessed against a standard at a point in time. What matters is the scope, the date, and what the assessment actually found — none of which is on the certificate. A certification whose scope covers the corporate office but not the platform hosting your patient data is accurate, current and irrelevant to you.

So ask for the scope statement rather than the logo, and read what is in it. Ask when the assessment was performed and when the next one is due. Ask whether any nonconformities were raised and how they were closed. A vendor confident in their programme will discuss findings openly, because every real assessment produces some; a vendor who insists there were none is either unlucky in their assessor or not telling you much.

The same applies to penetration testing. Ask when the platform was last tested, by whom, whether it was a genuine technical test or an automated scan, and whether the issues found were remediated and retested. A summary letter is normally what you will be offered and is normally sufficient, provided it states scope, dates and remediation status. A vendor who has never had an independent test of a system holding patient records is telling you where they are on the maturity curve.

Breach notification is the clause hospitals most often accept in a form that will not help them. The standard vendor drafting commits to notifying you without undue delay, which means nothing enforceable and, more importantly, gives you no ability to plan. You have your own notification duties running on their own clocks, and those clocks start when the incident occurs rather than when your vendor gets around to mentioning it.

Negotiate a defined period in hours, and negotiate what the notification contains: what happened, when, what data categories were involved, whether your hospital's data was affected, what has been done, and what you need to do. Then add an obligation to keep informing you as the picture develops, because the first notification in any real incident is always incomplete and vendors rarely volunteer the second one.

Establish the mechanics too, because they fail under stress. Who at the vendor notifies whom at the hospital, through which channel, and what happens at two in the morning on a holiday. An escalation path that runs through an account manager's working-hours inbox is not an incident process. Ask for a named security contact and a route that does not depend on one person being awake.

The clause that protects a hospital most reliably over ten years is the one governing how it leaves. Clinical systems accumulate years of records, and a vendor holding them with no contractual obligation to hand them back in usable form has leverage over every subsequent negotiation, including price. Establish at signature that the data is the hospital's, that it will be provided in a documented, non-proprietary format on request, and that assistance is included rather than chargeable at the time.

Specify what gets returned. A database dump is not a record hand-over if the schema is undocumented, and clinical systems hold a great deal outside the main tables: attached documents, images, audit trails, configuration, and the code lists that make the data interpretable. A hospital that receives raw tables with no documentation has technically received its data and cannot practically use it.

Then specify deletion. Once migration is verified, the vendor should delete your data across production, backups and any sub-processor, within a defined period, and confirm it in writing. Backup retention makes this slower than people expect, which is fine as long as it is stated. What is not fine is discovering years later that a former vendor still holds a complete copy of your patient records with no obligation to do anything about it.

Vendor viability is a security question, not only a commercial one, because a vendor in difficulty stops patching before it stops trading. Ask how long the company has operated, how many comparable hospitals it serves, and whether the product you are buying is actively developed or in maintenance. A product with no meaningful release in two years is a product whose security posture is frozen wherever it was.

Ask what happens operationally if they fail. For on-premise deployments, source code escrow with defined release conditions is worth having, though it is worth being clear-eyed that escrow releases code rather than the ability to run it. For hosted arrangements, the more useful protections are a right to regular exports of your own data in usable form and a clear statement of how long the service would continue during any wind-down.

The most practical protection is the one you control: take your own regular export and confirm it is readable, independent of any contractual promise. A hospital that holds a current, verified copy of its own clinical data is far less exposed to a vendor's fortunes than one relying on terms it would have to enforce against an entity in administration.

Most hospitals doing this evaluation have no dedicated security function, and the questions above can feel like they need one. They do not. They need someone senior enough to insist on answers and organised enough to record them, which is usually the IT head with support from whoever handles contracts. The value is mostly in asking rather than in expert assessment of the replies.

Send the questions in writing before any demonstration and ask for written answers. Written answers are considered, comparable across vendors, and become part of the contractual record if you attach them to the agreement, which is worth doing. Verbal assurances in a sales meeting are worth precisely nothing six months later and are usually given by someone with no authority to give them.

Score the answers alongside functionality rather than as a gate at the end, and be willing to let security weight actually change the outcome. A hospital that has never rejected a vendor on this basis is not running an evaluation, it is running a formality. Keeping the completed assessments as part of the vendor file, with the same activity trail as the rest of the hospital's operational records, also means the next renewal starts from what was established rather than from scratch.