However well you secure your own perimeter, the effective level of protection is set at the weakest point through which your information travels outward. For a healthcare company that "outward" includes development contractors, cloud infrastructure, call centres, data entry vendors, AI API providers and maintenance vendors — most of them either much smaller than you or vastly larger. Requirements land on the former and bounce off the latter, and that asymmetry is what makes supplier management hard.
It is also where audit findings concentrate. The classic three: a supplier list with no evaluation records, questionnaires returned but never reviewed, and contracts with no information security clause. None of these is "we didn't do it"; each is "we did it, but without substance or evidence."
This article covers selection criteria, questionnaire design, the clauses to include, how to handle cloud providers, and how all of this connects to Japan's three-ministry guidelines when medical information is involved. See also How to Run a Risk Assessment, Organisational Controls, and What Is an ISMS (ISO/IEC 27001)?.
Disclaimer: General information only. The standard and the accreditation/certification bodies' publications are authoritative for ISMS requirements; MHLW, METI and MIC publications are authoritative for handling medical information. Consult a lawyer on the legal effect of contract clauses.
Why This Is Where People Get Stuck
Trying to manage every supplier at the same depth
With fifty suppliers, sending everyone the same questionnaire, signing everyone the same clauses and reviewing everyone annually collapses in practice. There is no reason to treat a business-card printer like a development contractor holding patient data. Tier them and vary the depth — that is the only workable answer.
Being satisfied that the questionnaire came back
A hundred questions go out; every answer comes back "yes"; the file is stored and the review is "done." That record documents that nothing was evaluated. The auditor will ask how you assessed the answers.
Contracts left on the old template
The standard services agreement has confidentiality but no security clause. Sub-processing says "with written consent" and no consent has ever been given. Return and deletion of data is absent. Because it can only be fixed at renewal, it gets deferred.
Requirements that large cloud providers will not accept
Major cloud services generally do not negotiate individually, complete questionnaires, or accept audits. Treating that as "cannot evaluate, no record" punches a hole through the whole programme. You need a different method built on public information and third-party assurance.
Invisible sub-processors
Supplier A subcontracts implementation to B, who uses freelancers. Nothing prohibits it, so nothing is breached — you simply do not know. The structure surfaces during an incident, which is the worst way to learn it.
What You Decide
Tiering
Cut on two axes: access to medical information or personal data, and impact on your service's availability.
| Tier | Rough test | At selection | Periodic review | Contract |
|---|---|---|---|---|
| Tier 1 | Accesses patient/medical data, holds production privileges, or its outage stops your service | Questionnaire + evidence + on-site or interview as needed | Annual | Full set (sub-processing, audit, notification, deletion, governing law) |
| Tier 2 | Handles personal but not medical data, or affects service indirectly | Questionnaire + verification of certifications | Annual (light) | Standard set |
| Tier 3 | No access to information assets, easily replaced | Basic information only | At renewal | Confidentiality + basics |
Document the tiering criteria. If you cannot say why a supplier is Tier 2, the tiering looks arbitrary. One line of justification in the register is enough.
Fields in the supplier register
| Field | Purpose |
|---|---|
| Name, contract number, term | Ties to the contract |
| Scope of work | What they do |
| Type of information handled | Medical / personal / confidential / none |
| Access scope | Production / staging / read-only / removal permitted |
| Tier and justification | Sets the depth of management |
| Sub-processing and sub-processor names | Supply chain visibility |
| Certifications held | ISMS, Privacy Mark, ISO 27017, SOC 2 |
| Last review date and outcome | Tracks the cycle |
| Planned data disposition at termination | Prevents exit gaps |
| Internal owner | A named person per supplier |
Registers without an internal owner never get reviewed. Work belonging to nobody does not happen; assign a person in the commissioning department and make the annual review part of their job.
Clauses to include
The contract is your only enforceable instrument. Questionnaires carry no obligation; clauses do. For Tier 1, at minimum:
| Clause | What it must state | Risk if omitted |
|---|---|---|
| Security obligations | The level you require (compliance with your policies, or an enumerated set of measures) | Disputes over what was required |
| Sub-processing restriction | Prior written consent; equivalent obligations flowed down; a list of sub-processors and notice of changes | The supply chain goes dark |
| Audit right | Acceptance of document and on-site review; frequency and cost; whether third-party reports substitute | No means of verifying reality |
| Incident notification | A deadline in hours from awareness, recipient, content, duty to cooperate with investigation | You miss your own notification deadlines |
| Data handling scope | No use beyond purpose; specified storage location (country/region); limits on copies | Data ends up somewhere unexpected |
| Return and deletion at exit | Return or delete, deadline, method of proof, treatment of backups | Data lives on after termination |
| Personnel | Flow-down of confidentiality, post-employment duties, training | Leakage via individuals |
| Liability | Caps, and treatment of breach events | Exposure diverges from expectation |
Stating the notification deadline in hours has the largest practical effect. "Promptly" lets a supplier finish investigating first, which blows your own deadlines. Write the first notice as a separate duty: "a first report within 24 hours of awareness, even if the facts are not yet established." See Building an Incident Response Procedure.
Make proof of deletion concrete too. Is an email enough, or do you want a certificate, and does it cover backups? Since generational backups rarely delete on demand, a realistic formulation is confirmation that the data ages out of backups within N days.
The Practice
1. Selection
For Tier 1 candidates, pair the questionnaire with evidence. A questionnaire alone gives you no way to test the answers.
Forty to sixty questions is the practical ceiling; beyond a hundred, neither side reads carefully. For a healthcare company the questions narrow to:
| Area | Example questions | Evidence to request |
|---|---|---|
| Governance | Security officer appointed, policies in place, training delivered | Policy table of contents, training record template |
| Certification | ISMS / Privacy Mark / ISO 27017 / SOC 2, and their scope | Copy of the certificate — read the scope statement |
| Access | Granting and recertification process, privileged IDs, MFA | Recertification record format and frequency |
| Data | Storage location, encryption, removal limits, production data in development | Data flow diagram, stated storage locations |
| Sub-processing | Whether used, who, what is required of them | Sub-processor list |
| Incidents | Procedure, history, notification track record | Procedure table of contents |
| Continuity | Backup, recovery targets, escalation during outages | Recovery outline, exercise records |
| Exit | Return and deletion process | Description of the deletion process |
Always read the certificate's scope. A supplier may hold ISMS certification while the site or unit performing your work sits outside the certified scope. Treating "certified = fine" without reading "head office only" or "services X at the Tokyo office" is not an evaluation. See ISMS-AC, UKAS and ANAB.
Write one line of your own assessment against each answer. That is the minimum cost of keeping questionnaires real.
| Item | Supplier answer | Our assessment |
|---|---|---|
| MFA | Yes (partial) | Production yes, staging no. Acceptable given no production data in staging |
| Sub-processing | Yes (part of design to firm X) | Sub-processor uncertified. Acceptable on condition the contract states no access to our data |
| Backup | Yes | Frequency and location unstated. Follow-up required (owner, due date) |
Auditors check whether "follow-up required" items were ever followed up.
2. Contracting
Turn the clauses into templates — three of them, matching the tiers, each reviewed once by counsel. Negotiating from scratch per supplier does not scale.
Plan the retrofit of existing contracts. Re-papering everything at once is impossible, so plan to replace from Tier 1 downward at each renewal — and keep the plan itself as a record. Auditors are less troubled by outstanding contracts than by the absence of a plan.
3. Monitoring
Annual review is the base, but time is not the only trigger.
| Trigger | Action |
|---|---|
| Annual | Re-collect questionnaire, check certificate validity, update the register |
| Supplier incident | Impact assessment, remediation status, possible re-tiering |
| Scope of work changed | Re-check information types and access, revisit clauses |
| Sub-processor changed | Vet the new party, run the consent process |
| Ownership or organisational change | Confirm any change in data handling |
| Certification lapsed or suspended | Identify alternatives, re-tier |
Include routine monitoring: recertification of accounts granted to suppliers, access log review, SLA attainment. These run more often than the annual review.
4. Exit
Exit gaps are the most common hole. Keep a termination checklist and record completion.
- Recover loaned equipment and media
- Delete accounts and access rights — with a record of deletion
- Terminate VPN and dedicated connections
- Return or delete data, and obtain proof
- Confirm ageing out of backup generations
- Update the register (termination date, data disposal date)
- Confirm survival of confidentiality obligations
Records of account deletion are missing remarkably often, and like leavers' accounts, orphaned supplier accounts are a real risk.
Handling Cloud Providers
Major providers will not negotiate, complete questionnaires or host your auditors. Rather than writing them off as unmanageable, change the method of evaluation.
| Normal supplier method | Cloud provider substitute |
|---|---|
| Questionnaire responses | Obtain and review published third-party reports and certifications (ISO 27001, 27017, 27018, SOC 2 Type II) |
| Negotiated clauses | Review and record the terms of service, data processing terms and SLA; watch for material changes |
| On-site audit | Review of published audit reports and the provider's compliance portal |
| Incident notification | Point status pages and notification email at an organisational address, never an individual's |
| Sub-processor visibility | Review the published sub-processor list and subscribe to change notices |
The key is being explicit about your own side of the shared responsibility model. The provider secures the platform; configuration, permissions and data classification remain yours. Conflating the two produces the false conclusion that "the provider is certified, so we are fine." See Shared Responsibility in AI EMR Security Design and Cloud Security for Medical Institutions, and for the cloud-specific certifications, ISO 27017 and ISO 27018.
Confirm the storage region whenever medical information is involved. Some services keep primary data in-country while logs, metadata or backups sit abroad. Where contracts and specifications are silent, record the provider's answer to your enquiry.
Generative AI APIs are suppliers too. Whether inputs are used for training, how long they are retained, and in which region they are processed — record at least these three in the register. See Generative AI in Healthcare: Legal and Security Guide.
Connecting to the Three-Ministry Guidelines
For a company handling medical information, supplier management is simultaneously an ISMS requirement and a medical information safeguarding requirement.
| Layer | Who manages whom | Framework |
|---|---|---|
| Hospital → provider | The hospital manages its system and service providers | MHLW guidelines on safe management of medical information systems |
| Provider → sub-processor | The provider manages its own contractors and their contractors | METI/MIC guidelines for providers handling medical information |
| Overall | The organisation manages suppliers within its ISMS | ISO/IEC 27001 supplier relationship controls |
Do not build three systems; build one. Make the ISMS supplier procedure primary and add extra requirements for suppliers touching medical information:
| Additional requirement | Why |
|---|---|
| Stated country/region where medical information is stored | External storage requirements |
| Disclosure sufficient for the hospital's own accountability | So customers can explain their guideline compliance |
| Definition of incidents requiring hospital notification | Flows your notification duty down the chain |
| Restricted working hours reflecting clinical operations | Maintenance must not stop care |
| Requirements for remote maintenance connections and logging | Remote maintenance is a classic intrusion path |
Feeding your customers' questionnaires straight into your own supplier questionnaire works well: what hospitals ask you is largely what you should ask your sub-processors. See Security Questionnaires for Vendors and Questions to Ask Your Provider.
For document integration see Integrating ISMS Documents with the Three-Ministry Guidelines; for the guidelines themselves, Three-Ministry Guidelines and Implementation Steps.
Where It Goes Wrong
Defining "supplier" too narrowly
Only parties with a services agreement make the register; SaaS, cloud and API usage do not. The test should be any relationship where your information leaves, or an outside party can reach it — regardless of contract form.
Never reviewing the answers
As above: an all-"yes" response is a reason to look harder, not a reason to relax. Request evidence at least for the material items.
An audit right never exercised
Having the clause matters, but for Tier 1 you should run at least a documentary annual review. Where on-site is impractical, an online interview plus document review substitutes.
Sub-processing consented to verbally
The contract says prior written consent; practice is one email exchange with no record. Create a consent form and tie it to the register.
Reviews that never turn into remediation
"Backup details not stated" is raised, and raised again the next year. Issue findings as dated improvement requests and confirm closure. Decide in advance what happens if they are not closed — renewal, or replacement.
Reviews run by the security function alone
A team that does not know the work cannot see the risk. Include the commissioning department, and gaps surface — such as read-only access on paper and production data on screen in practice.
Personnel risk omitted
Confidentiality obligations on the supplier's staff, offboarding, access control for on-site personnel. These get less scrutiny than technical items, yet human factors dominate real breach cases. See People Controls.
Healthcare Examples
A healthcare SaaS provider
The most important supplier is usually the development and maintenance contractor — production access, and a legitimate reason to look at patient data during incidents. Tier 1. The distinctive item to verify is production data in development and test environments. Copying production data "for testing" genuinely happens, and is where contract and reality diverge most. Put masking and anonymisation, and how you verify them, in the questionnaire.
The second is the sub-processor chain. If your service rests on cloud infrastructure, an identity provider, email delivery, an AI API and a monitoring service, all of them are your customers' sub-processors. Maintaining a disclosable sub-processor list lets you answer hospital enquiries immediately and shortens sales cycles.
A PHR operator
The question is whether the scope of user consent flows down to suppliers. Does any contract permit a supplier to use or analyse data for purposes the user never agreed to? Check the "no use beyond purpose" clause against the consent wording. See ISMS for PHR Operators.
A clinical trial systems company
Add retention periods and audit trails to what you require. Because records must be kept long after a study closes, deletion-at-termination clauses can collide with retention duties. A blanket "delete promptly on termination" can put you in breach.
A SaMD developer
Supplier management spans ISMS supplier controls and QMS (ISO 13485) purchasing controls. Evaluating the same supplier twice is wasteful: build one merged questionnaire with a column marking which framework each item serves. See SaMD, ISMS and ISO 13485.
A small organisation
Many suppliers, few people. Make Tier 3 genuinely light and concentrate effort on Tier 1. Spreading equally leaves everything shallow. See ISMS for Small Organisations.
Conclusion
- Tier suppliers and vary the depth. Managing all at one depth always collapses
- The questionnaire's purpose is assessing answers, not collecting them — one line of your own assessment per item
- Four clauses are non-negotiable: sub-processing limits, audit rights, incident notification with an hour deadline, and return/deletion of data
- For cloud providers, design an evaluation built on third-party assurance and published reports — and always read the scope of any certificate
- For suppliers touching medical information, add clauses that flow your hospital notification duty down the chain, and merge the three layers into one system
- Account and data deletion at termination is the most commonly missed step; close it with an exit checklist
For supplier incidents see Building an Incident Response Procedure; for the availability impact of a supplier outage, Business Continuity and the ISMS; for remediating review findings, Writing a Corrective Action Report. Supplier management status is also a standing input to Management Review.
Pottech supports ISMS certification and operation with a focus on healthcare. Designing supplier management as a reflection of what customer hospitals demand depends on knowing how the healthcare supply chain actually works. See ISMS Certification Support or contact us.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Ministry of Economy, Trade and Industry
- Ministry of Internal Affairs and Communications
- Personal Information Protection Commission, Japan
Note: the standard and the accreditation and certification bodies' publications govern ISMS requirements; the ministries' publications govern medical information handling. Both may change with revisions. Consult a lawyer on the legal effect of contract clauses.