You can ask good questions without having a security specialist on staff — and if the questions are right, the answers reveal a great deal about a vendor. Put vaguely, though, even the most conscientious vendor can only answer vaguely.
This article sets out, in ready-to-use form, the questions a hospital should put to its system vendors. Five areas, each question paired with why it is asked, what a good answer looks like, and what a worrying one looks like. Copy the tables straight into an RFP question sheet or a review of your existing suppliers.
For turning these into a structured check sheet, see Security Check Sheets for Vendors; for writing them into a specification, Putting Security into Your Procurement Requirements. This article aims at the stage before those — questions you can ask out loud, in a meeting.
Disclaimer: This article is general information. A "worrying answer" is a signal to probe further, not evidence that a vendor is unsuitable. The authoritative texts are the MHLW and METI/MIC publications.
How to Use This List
1. A worrying answer is not a disqualification
It is a cue to dig in on the spot. "Two people can access it" means opposite things depending on whether that is genuinely tight control or a shared account nobody is tracking. Use the right-hand column to generate your next question.
2. Record who answered
An answer's weight depends on whether a salesperson guessed or engineering checked. Even when asked verbally, follow up with a request for the answer in writing.
3. Put the answers into the contract
Ask once and file it, and next year's answers go formulaic. If they said five people have access, or that notification follows detection within two hours, copy it into the specification or memorandum. Once vendors know answers become contract terms, they stop writing what they cannot stand behind.
1. Organisation and Accountability
| Question | Why ask | Good answer | Worrying answer |
|---|---|---|---|
| What is the title of your information security officer, and is the role dedicated or held alongside other duties? | Where the role is nominal, decisions default to whoever is nearest | A specific title, with the scope of the role explained | "The CEO covers it" and no answer on who runs it day to day |
| What is the name and last revision date of your security policy? | Rules untouched for years have drifted from practice | Revised within the last two or three years, with a stated reason | "We have rules" but no name and no date |
| Sessions, staff covered and completion rate for staff training in the past 12 months? | "We train" and "everyone completed it" are different facts | Numbers for all three | "Annually" with no completion rate |
| Name, number, certified scope and expiry of any certification you hold? | Certificates whose scope covers only a head-office function exist | Shows the certificate and explains that your engagement is in scope | Shows a logo; checking the scope takes days |
| Standard number of days to remove a departing employee's access to our data? | Leftover leaver accounts are a classic exposure | A concrete process — same-day on request, monthly recertification | "We handle it case by case", with no days and no verification |
On certification, always check scope rather than possession. Proposals do present a platform provider's certificate as the vendor's own. See What Is an ISMS? and Defining ISMS Scope.
2. Data Location and Handling
| Question | Why ask | Good answer | Worrying answer |
|---|---|---|---|
| In which country/region is our data stored — separately for production, backups and logs? | The three often differ; offshore regions are common for redundancy | Names the region for each immediately | "In Japan", then asks what you mean by the three |
| In which countries are the staff who operate production located? | Domestic data administered from abroad is still cross-border access | States where operations sit and explains any overseas site | "The data is in Japan, so there is no issue" — deflection |
| How many of your employees can access our data, by role? | A count resists fudging and allows comparison | Counts by role, plus how permissions are scoped | "Only a limited number", with no figure, or shared accounts |
| How many hold production administrator rights, and are any accounts shared? | Shared accounts mean you cannot attribute actions afterwards | Individual accounts, with privileged actions recorded | Admits shared accounts with no recording mechanism |
| Is our data ever copied into your environment for maintenance or fault investigation? | Copying to development is common and usually unprocedured | Prohibited in principle, or governed by request/approval/expiry/deletion | "As needed", with no procedure |
| What is encrypted at rest and in transit, and how? | "We encrypt" says nothing about coverage | Separates database, files and backups, and states the methods | "We encrypt", then vagueness when you ask what |
The third row is the highest-value question here. A vendor answering five and one answering forty carry different kinds of risk — and being able to answer at all is itself evidence that access is managed.
See Requirements for External Storage of Medical Information and Selecting a Cloud Provider.
3. Incident Response
| Question | Why ask | Good answer | Worrying answer |
|---|---|---|---|
| What is the emergency contact covering weeknights and weekends, and the target time to first response? | Healthcare runs 24/7; a daytime-only desk is not a response capability | Contacts and targets broken out by time band | "Call the support centre", with nights and weekends unstated |
| When and by what channel will you notify us of an incident you detect? | A late notification delays your entire internal response | A time target from detection, and the channel | "We will contact you promptly", with no basis in time |
| What are the criteria for which incidents get reported to us? | If "incident" is at the vendor's discretion, you may learn from the news | Explains tiers — immediate, same day, periodic report | "We will tell you about serious ones", with no definition of serious |
| What are your RTO and RPO for an outage? | RPO is really "how many hours of records get re-typed" | Numbers, plus the backup frequency behind them | Offers uptime only, and takes RTO/RPO away to check |
| If ransomware stops the system, does that count against the uptime calculation? | Most SLAs exclude it — the worst case sits outside the guarantee | States the exclusions plainly and what happens instead | "Force majeure is excluded", with no explanation of the boundary |
| Do you run incident exercises? Date and content of the most recent? | Having a runbook and being able to act are different | A date and whether it was tabletop or live | "We have a runbook", with no exercise history |
The third row is the critical one. "We will tell you about serious ones" means the judgement of seriousness sits with them. Notified when attempted unauthorised access is detected, or only once harm is confirmed? Left unagreed, you have handed the vendor control over when you find out.
See Writing SLAs and Responsibility Boundaries and Hospital Incident Response Plans.
4. Subcontracting
| Question | Why ask | Good answer | Worrying answer |
|---|---|---|---|
| Will any work be subcontracted, including use of cloud services? | Without that clause, platforms and monitoring SaaS vanish into "none" | Walks through platform, monitoring, development and support | "No subcontracting" — and cloud use emerges later |
| Name, country and scope of work for each subcontractor? | A subcontractor whose name cannot be produced may not be managed | Names and roles, specifically | "A partner company", without naming it |
| By what method do you verify a subcontractor's safeguards? | Without a method, subcontracting is a break in the chain of management | Contract clauses plus an annual check, described | "They are a trusted firm", with no method |
| Will you notify us before changing a subcontractor? | Subcontractors change mid-term; without notice your picture goes stale | Agrees to a prior-notice clause | "We will let you know", but resists writing it into the contract |
| In which countries is development and maintenance performed? | With offshore development, keeping production data out of dev matters doubly | States the sites and how production data is handled | Names the site, then goes vague on contact with production data |
The phrase "including use of cloud services" decides the quality of this whole section. Without it, many vendors read "subcontracting" narrowly — not out of bad faith, but because industry habit does not call cloud use subcontracting. See Supply Chain Risk for Hospitals.
5. End of Contract
| Question | Why ask | Good answer | Worrying answer |
|---|---|---|---|
| In what format can our data be returned at termination? | Proprietary-only export adds a conversion project to any migration | Standard format or CSV export available | "Export is in our own format" |
| Does the return include attachments, images and audit logs? | Clinical records come back; attachments stay behind | States coverage and explains any exclusions | "The full data set", with no breakdown |
| Is the return chargeable, and if so how is it calculated? | A large exit invoice at replacement time destroys your leverage | Free, or a stated basis given in advance | "We will quote at the time" |
| Will you brief the successor vendor and disclose data specifications? | Migration succeeds or fails on the outgoing vendor's cooperation | Agrees to write the scope of cooperation into the contract | "To the extent we are able" |
| When does deletion of our data complete, including backups? | Deleting production leaves generations in backup — the classic gap | A completion date that accounts for the generation cycle | "Promptly", with backups unaddressed |
| Can you issue written proof of deletion? | It is the evidence you will need when explaining your data handling | Agrees to issue a certificate | "We keep records but do not issue documents" |
These questions matter at evaluation, not at renewal. By the time replacement is near, there is almost no room left to change the terms. See Security Requirements for EMR Replacement and The EMR Data Migration Guide.
Reading the Answers Side by Side
| Lens | What to look at |
|---|---|
| Answered on the spot? | Figures produced immediately usually reflect something managed daily |
| How much went away to check? | Taking items away is honest; a majority of basics going away signals a thin posture |
| Can they say no? | A vendor who names what they cannot do and proposes an alternative is more trustworthy than one who says yes to everything |
| Are the numbers consistent? | "Two people have access" and "24/7 monitoring" sit awkwardly together; contradictions are where to dig |
| Which department answered? | A sheet completed entirely by sales warrants discounting on technical points |
One last observation. Sometimes a vendor will say "nobody has asked us this before." That is not an indictment of the vendor so much as a sign that buyers had not stated a standard. Buyers asking concretely is what raises the level of the sector — and when a vendor sets out to meet it, certifying its management system is one of the routes, which is what our ISMS certification support exists for.
Conclusion
- Treat a worrying answer as a cue to probe, not a disqualification
- The highest-value single question is "how many of your people can access our data?" — counts resist fudging
- In incident response, always ask for the notification threshold, or you hand over control of when you find out
- Subcontracting only surfaces if you add "including use of cloud services"
- Ask the end-of-contract questions while still evaluating, not at renewal
- Copy the answers into the contract — that is what determines their quality next year
Building the list, lining up several vendors' answers and reading the differences is not a spare-time task. To start with a review of existing suppliers, or to build a question sheet ahead of a replacement, contact us.
References and Sources
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Guidelines, edition 6.0 (PDF) | MHLW
- Personal Information Protection Commission
- Information-technology Promotion Agency (IPA)
- Information Management System Accreditation Center (ISMS-AC)
Note: guideline requirements change with revisions. Review your question set against the latest published material periodically.