A hospital signs with an EMR provider on a Friday. Two years later, on a Tuesday morning, the provider gets breached, and the records team discovers three things at once: nobody can find the signed agreement, the vendor's support engineers still hold standing remote access, and the credentials shared with the integration partner have never been rotated. The breach was the vendor's. The notification to the Nigeria Data Protection Commission is the hospital's. That gap, between who failed and who answers, is the whole reason a vendor risk programme exists.
Vetting a vendor once, at procurement, is a single photograph. A programme is the film. The point of view here is simple: stop treating vendor security as a questionnaire you complete before signing and start treating it as a lifecycle you run, with the same discipline you would apply to a clinical pathway. Three things carry that lifecycle: tiering, contracting, and offboarding. The technical "what questions do I ask" sits inside our security assessment checklist for third-party vendors, so we will not repeat it. This is about the governance around it.
Tier vendors by what they can reach, not by how big they are
Most procurement teams sort suppliers by spend. For security, that is the wrong axis. A small locum-scheduling app that holds nothing but shift rosters is low risk however large the invoice. The EMR vendor with a live database connection to every patient record is your highest risk even if the annual fee is modest. Tier by data sensitivity and depth of access, not by contract value.
A workable scheme has three tiers. Tier 1 is any vendor that stores, processes, or has standing access to patient health information: the EMR, the cloud host, the laboratory information system, a teleradiology partner reading scans off your PACS. These are your processors under the Nigeria Data Protection Act, and they get the full programme. Tier 2 is operational systems that touch personal but not clinical data, like HR payroll or a billing gateway. Tier 3 is everything that never sees regulated data at all, like the firm that services the generators. The tier decides how hard you push: a Tier 1 vendor earns a full data processing agreement and a right to test; a Tier 3 vendor does not need either.
Put the obligations in the contract, where they bind
A vendor who promises good security in a sales call owes you nothing. A vendor who signs to it owes you a remedy. The contract, and specifically a data processing agreement for any Tier 1 supplier, is where vendor risk stops being a hope and becomes an obligation. Under the Nigeria Data Protection Act, the hospital is the data controller and the EMR provider is a processor, and the Act expects that relationship to be governed by a written contract. The National Health Act sits alongside it, treating health records as confidential and the facility as the custodian. So the clauses below are not aspirational. They are the paperwork that turns a regulatory duty into something you can enforce on a named counterparty.
For a Tier 1 vendor, the agreement should pin down at least these:
- Controller and processor roles, named explicitly. State that the hospital is the controller and the vendor the processor, that the vendor processes data only on your documented instructions, and that it may not use patient data for its own purposes such as model training or analytics resale.
- Breach notification with a clock. The vendor must tell you within a fixed, short window (commonly stated in hours, not "promptly") so you can meet your own NDPA notification duty to the Commission and, where required, to data subjects. A vendor that learns of a breach on Tuesday and tells you the following month has already cost you your compliance position.
- Right to audit and right to commission a test. Reserve the right to review the vendor's controls and to have an independent party (your own senior penetration testers, for instance) test the system that holds your data, on reasonable notice. Folding the right to test into the contract is far stronger than asking for permission after something goes wrong.
- Sub-processor disclosure. Your EMR vendor almost certainly relies on others: a cloud platform, an SMS gateway, an offsite backup provider. Require a current list, require notice before a new sub-processor is added, and require that they be bound to the same terms. You cannot govern a chain you cannot see.
- Exit and data handling on termination. The contract must say, before you ever need it, how data comes back to you and how the vendor's copies are destroyed.
Offboard as if the vendor might turn hostile
Offboarding is the step almost everyone skips, and it is where the quiet breaches live. A contract ends, the new system goes live, everyone moves on, and the old vendor still has a VPN account, an admin login, and a full copy of your patient database sitting in a backup bucket. Months later that dormant access is exactly what an attacker, or a disgruntled former engineer, walks through. Treat the last day of a vendor relationship with the same care as the first.
A clean exit covers four things. Get certified return and destruction of the data in writing, a signed statement that copies and backups held by the vendor and its sub-processors have been purged, not just "deleted" from the live system. Revoke every route in: VPN accounts, API keys, support-engineer logins, jump-host access. Rotate any shared or service credentials the vendor ever touched, because you cannot prove who still has the old ones. And confirm that backups the vendor held offsite are gone, since that is the copy people forget. Until all four are done, the relationship is not actually over.
Keep one living register, and name an owner
Ask most hospitals to list every vendor with access to patient data and you get a pause, then a scramble through old email and the memory of whoever happens to be in the room. None of this survives in people's heads. The programme needs a single vendor register: who each vendor is, their tier, what data they reach, where the signed DPA lives, when the contract renews, who inside the hospital owns that relationship, and the date of the last review. When the NDPC asks who processes your patient data, that register is your answer in one page rather than a fortnight of archaeology through inboxes.
Internal accountability matters as much as the vendor's. Every Tier 1 vendor should have a named owner inside the hospital, someone whose job includes checking that the breach clause is still current and that access has not quietly crept wider than the contract allows. Vendor risk is not the IT department's secret. It belongs to whoever signed, and ultimately to the facility that the law holds accountable. The design-stage questions that precede all of this, what data a system should collect at all, live in our note on privacy by design; the contract is where those answers get enforced.
- Tier by access, not spend -- a vendor's risk is set by the data it can reach, so an EMR provider outranks a costly service that never sees patient records.
- The contract is the control -- a Tier 1 data processing agreement under the NDPA fixes controller and processor roles, a breach-notification clock, the right to audit and test, and sub-processor disclosure.
- Offboard deliberately -- certified data destruction, revoked remote access, rotated shared credentials, and purged vendor backups, or the relationship is not over.
- Run a living register -- one page mapping every vendor to its tier, data, signed DPA, and a named internal owner.
- Accountability stays with the hospital -- the breach may be the vendor's, but the NDPC notification and the National Health Act custody duty are yours.
The breach will be the vendor's. The notification, and the answer to the regulator, will be yours.
