Supplier management is one of the things the three-ministry guidelines require of hospitals, and at most hospitals the practice takes the form of sending out a check sheet. Run it for a year, though, and the sheets come back filled with "Yes / we comply" — and reading them tells you nothing.
The cause is in how the questions are written. Ask "do you implement access control?" and every vendor says yes. They are not lying; some form of access control always exists. What you actually want to know is who can reach your data, how many of them there are, and how quickly that stops when one of them resigns. If the question does not ask that, a formulaic answer is the only possible outcome.
This article sets out how to design the security check sheet a hospital sends to vendors: what to ask across six domains, how to phrase it so the reality surfaces, and how to read what comes back. The questions you build can be reused directly in procurement specifications — see Putting Security into Your Procurement Requirements.
Disclaimer: This article is general information. The authoritative texts are the MHLW guidelines and the METI/MIC guidelines themselves. Consult counsel before turning any of this into contract terms.
Three Reasons Check Sheets Go Hollow
| Cause | What happens | Fix |
|---|---|---|
| Questions answerable yes/no | "Do you?" → "Yes." Nothing about reality emerges | Ask for counts, frequencies, scope, and method |
| No evidence requested | Answers rest on the respondent's impression | Make a "supporting document name" column mandatory |
| Nothing happens afterwards | Vendors learn that submitting is the whole job | Copy parts of the answers into contract terms; diff against last year |
The third matters most. Once vendors know the answers end up in the contract, they stop writing things they cannot stand behind. Run the "collect and file" version for a few years and the sheet degrades into clerical work.
One practical constraint: too many questions and vendors start pasting boilerplate. Thirty to fifty questions is a workable target, weighted towards what matters to you. A few probing questions in each of six domains reveal more than an exhaustive 200-row grid.
Six Domains, and the Questions
The "better question" column below is phrased so you can use it as written.
1. Organisation and accountability
| Item | Weak question | Better question |
|---|---|---|
| Officer | Do you have a security officer? | State the title of your information security officer and whether the role is dedicated or held alongside other duties |
| Policy | Do you have internal rules? | State the name and date of last revision of your information security policy and procedures |
| Training | Do you train staff? | State the number of sessions, number of staff covered, and completion rate for the past 12 months |
| Certification | Are you certified? | State the name, certificate number, certified scope (sites and services) and expiry of any third-party certification |
| Leavers | Do you have a leaver process? | State the standard number of days to remove a departing employee's access to our data, and how removal is verified |
Always require the certified scope. Certificates whose scope covers only a head-office function, while the development or operations site serving you sits outside it, do exist. Being certified and your engagement being inside that certification are two different facts. See Defining ISMS Scope and What Is an ISMS?.
2. Access management
| Item | Better question |
|---|---|
| Headcount | How many of your employees can access our data? Break it down by role |
| Granting | Who requests and who approves the grant, change and removal of access? Are approval records retained? |
| Privileged IDs | How many hold administrator rights in production? Are any accounts shared? |
| Authentication | Is MFA applied to production access? List any paths where it is not |
| Recertification | How often is access reviewed, and when was the last review? |
Forcing a number is the point. A vendor answering "five" and one answering "forty" carry different kinds of risk. Likewise, an admission that shared accounts exist tells you there is a region where you cannot attribute actions after the fact.
3. Subcontracting
| Item | Better question |
|---|---|
| Existence | Will any work be subcontracted? If so, name the subcontractor, its country, and the work involved |
| Oversight | By what method do you verify the subcontractor's safeguards? |
| Prior notice | Can you notify us before changing a subcontractor? |
| Locations | State the countries where development and maintenance are performed |
| Cloud | Name the cloud providers and regions used |
Subcontracting is the hardest domain to get information on. "No subcontracting" often just means cloud platforms and SaaS monitoring services were not counted. Stating explicitly "include use of cloud services" improves accuracy markedly. See Supply Chain Risk for Hospitals.
4. Incident response
| Item | Better question |
|---|---|
| Contact | Give the emergency contact covering weeknights and weekends, and the target time to first response |
| Notification | When and through what channel will you notify us of an incident you detect? |
| Threshold | State the criteria that determine which incidents are reported to us |
| Recovery targets | State RTO and RPO for a system outage |
| Exercises | Do you run incident exercises? Give the date and content of the most recent one |
Asking for the notification threshold is the key move. "We will contact you if there is an incident" means the definition of incident is at the vendor's discretion. Notified on detection of attempted unauthorised access, or only once harm is confirmed? Left vague, you may learn of events at the same moment the press does. See Writing SLAs and Responsibility Boundaries and Hospital Incident Response Plans.
5. Data location and deletion
| Item | Better question |
|---|---|
| Location | State the country/region where our data is stored, separately for production, backups and logs |
| Segregation | How is our data separated from other customers' (logical or physical, and by what mechanism)? |
| Encryption | State encryption at rest and in transit, and the methods used |
| Copies | Is our data ever copied into your environment for maintenance or development? If so, state the procedure and retention |
| Termination | State the return format, the days until deletion is complete, and how deletion is evidenced |
| Backups | When is our data in backups deleted? |
Backup deletion is the item that is always missing. Deleting from production leaves generations in backup. Settle before contracting whether "deletion complete" includes backups. See Requirements for External Storage of Medical Information.
Copies for maintenance also slip through. Copying production data into a development environment to investigate a fault is common and obviously risky. Decide in advance whether to prohibit it or to require a procedure — request, approval, time limit, deletion on completion.
6. Audit and reporting
| Item | Better question |
|---|---|
| Periodic reporting | Will you report the status of your security measures to us? State frequency and format |
| Accepting audit | Will you accept an audit (documentary or on-site) by us or a third party we appoint? State any conditions |
| External assessment | Do you undergo external audit or vulnerability assessment? By whom, and when most recently? |
| Remediation | Describe your remediation process for findings, and how findings are shared with us |
Audit rights matter even unexercised: the obligation to accept an audit shapes how the vendor manages itself. Keep it realistic — documentary reporting as the norm, on-site by agreement for serious events — or it prices into the quote.
How to Phrase Questions So Reality Surfaces
1. Ask for a number. Not "do you manage access?" but "how many people can access it?" Numbers resist fudging and allow comparison.
2. Ask when it last happened. Not "do you run exercises?" but "date and content of the most recent one." The gap between having a policy and running it shows up here.
3. Ask for the supporting document. Add a column for the name of the governing procedure. Items where nothing can be cited are either undocumented or not actually operating.
4. Provide a "no" option. Allow "not applicable" and "not implemented", with a field for the reason and compensating measures. A sheet whose only option is yes gets nothing but yes.
5. Ask who answered. Name, title and department. Whether a salesperson guessed or the engineering team checked changes the weight of every answer.
| Weak | Better | What changes |
|---|---|---|
| Do you take backups? | State method, frequency, number of generations, storage location, and whether any copy is held offline | You can test it against the fee criteria |
| Do you manage logs? | State the log types and retention, and whether and how quickly you can disclose them on our request | You know in advance what an incident will reveal |
| Do you patch vulnerabilities? | State your standard number of days from a critical vulnerability disclosure to impact assessment and to patch application | Speed becomes comparable |
| Do you train staff? | Sessions, staff covered and completion rate for the past 12 months | "Once a year, 40% completion" surfaces |
Reading What Comes Back
- Where are the blanks? An item nobody could fill in usually marks an absent practice
- Are the "yes" answers backed by a cited document? An unsupported yes may be an impression
- Are the numbers implausible? "Two people can access it" sometimes means everyone shares one account
- Which department answered? A sheet completed entirely by sales warrants discounting on technical points
- How do vendors differ? Lining up several answers to the same question reveals the sector's working norm
Most important: copy parts of the answers into the contract. If they said five people have access, or that notification follows detection within two hours, put it in the memorandum or specification. Do this once and next year's sheets come back measurably more accurate.
Where answers fall short, consider setting a remediation deadline and requesting resubmission rather than disqualifying outright. A local vendor who has maintained your systems for years may simply be mid-way through building its posture. A buyer stating a concrete standard is what raises the supply side — and when a vendor sets out to meet it, building a certified management system is one of the routes, which is what our ISMS certification support exists for.
Conclusion
- Never use a question answerable yes/no. Ask for counts, frequency, the last occurrence, and scope
- Cover six domains: organisation, access management, subcontracting, incident response, data location and deletion, audit and reporting
- Aim for 30–50 questions — depth in what matters beats exhaustive coverage
- For certifications, require the certified scope and expiry, not just a yes
- Subcontracting only surfaces if you write "including use of cloud services"
- Copy answers into the contract. That is what determines the quality of next year's answers
Designing the sheet and reading the returns is heavy work for an in-house IT team alone. If you want to run a one-off review of existing suppliers, or rebuild the 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)
Note: guideline requirements change with revisions. Review your check sheet items against the latest published material periodically.