Hospital Third-Party Risk Management: Verify Supplier Access with Evidence

Hospital TPRM needs evidence of the access a supplier actually has

Hospital third-party risk management should connect supplier assurances to the systems, identities, data and clinical services the supplier can actually reach. A questionnaire can help identify commitments, but technical access evidence is needed to determine whether the hospital’s own boundary matches those commitments. This guide focuses on that evidence, from onboarding through maintenance and offboarding.

A supplier may support imaging equipment, administer an application, host a service or receive information through an integration. Each relationship creates different questions. The useful assessment is not a generic verdict that the supplier is “secure.” It identifies the specific service, the access required to deliver it, the controls at the hospital boundary and the evidence available to support a decision.

This article provides a practical evidence pack and validation workflow for procurement, clinical engineering, IT and security teams. Examples are hypothetical and use designated test arrangements. It complements our hospital remote vendor access guide and hospital penetration testing service. It is not a substitute for contract review, clinical safety assessment or permission from the relevant system owners.

Define the service relationship before scoring the supplier

Record what the supplier delivers and which hospital process depends on it. Name the clinical or operational service owner, the technical owner and the procurement contact. A single supplier may provide several services with very different access and criticality. Keep these relationships separate enough that a reassuring answer about one hosted product is not accidentally applied to an unrelated remote-maintenance arrangement.

Describe the access in business terms first: what must the supplier be able to do, during which circumstances, and for how long? Then map that requirement to identities, connection methods, target systems and data flows. This provides a basis for comparison with the actual configuration. Without it, an assessor may find broad access but have no agreed boundary against which to judge it.

Use the supplier’s documentation as evidence to examine, not as an instruction to grant access. If a deployment guide asks for broad privileges or unrestricted connectivity, ask the service owner and supplier to explain the requirement and supported alternatives. Record the decision and constraints. A product’s default installation model does not automatically become the hospital’s approved risk position.

Build an access register that joins the contract to the network

Create a register for the relevant supplier access paths. Include the entry point, identity provider or account source, target systems, privilege level, approval process and evidence references. Resolve shared names and aliases so the hospital can identify who operates the route. A register that lists only a supplier company name and a VPN account misses the downstream permissions that determine the real exposure.

Include alternate and exceptional paths. Support may use a managed gateway during normal operations but a different arrangement during an outage. An integration may use a service identity even when interactive remote access is disabled. Ask the technical owner to identify these paths explicitly. Do not assume that disabling one visible account removes every capability associated with the supplier.

Record the source and age of each entry. Some details may come from configuration exports, others from interviews or supplier statements. Mark unverified information and assign a follow-up. This lets the risk owner distinguish a known restriction from an intended restriction that has not yet been demonstrated. The register should be a decision aid, not a polished document that hides uncertainty.

Ask for evidence that answers a specific question

For each material claim, define the evidence that would support it. “Access is approved” may require a representative approval record and a matching enabled session. “Access is limited to named devices” may require destination restrictions and a controlled validation. “Accounts are removed promptly” may require a completed offboarding example. A policy document can support the design, but it does not by itself show that the process operated.

Keep requests proportionate and specific. A hospital does not need unrestricted access to a supplier’s internal systems to review the hospital-facing route. Ask for relevant scoped evidence, suitable redaction and an explanation of limitations. Where a supplier cannot disclose a detail, identify whether an alternative assurance mechanism can answer the question and what residual uncertainty remains.

The general lifecycle approach in NIST SP 800-161 Revision 1 is useful for structuring supply-chain risk decisions. It should not be presented as proof that a supplier or hospital complies with a particular law. Apply the approach to the actual service relationship and retain the evidence behind each decision, rather than assigning confidence solely from a framework name.

Trace the supplier path from entry to operation

Map the complete relevant route: the supplier’s approved access method, the hospital entry point, any jump or management host, the target system and the operation permitted there. Identify where authentication, authorisation, destination restriction and logging occur. These controls may be owned by different teams. The assessment should expose the handoffs rather than assuming that the gateway owner controls every downstream permission.

Separate network reachability from application authority. A route to an engineering interface does not establish what operations the supplier can perform after connecting. Conversely, a restricted application role may not address unnecessary access to other services on the same target. Collect evidence at the layer relevant to each requirement and keep the conclusion within that layer unless further validation is authorised.

Use designated test identities and harmless operations for validation. Confirm the supplier and hospital approvals, the target population and the excluded techniques. Do not test a shared supplier service merely because the hospital uses it. Where external infrastructure is out of scope, focus on the hospital-controlled boundary and describe the remaining dependency in the report.

Let clinical constraints determine the validation method

Clinical engineering and the service owner should determine which systems can be safely exercised and under what conditions. A technical assessment may rely on configuration review, passive evidence, an isolated representative device or a supplier-supervised maintenance check. Do not turn a third-party risk review into an unplanned active scan of medical equipment.

Healthcare-specific guidance such as the Health Industry Cybersecurity Practices technical volume discusses medical-device security and network controls in the context of care delivery. Use that context to ask better questions about support and isolation. It does not remove the need to agree device-specific constraints and authority with the hospital and supplier.

Record what each method demonstrates. A representative lab check may establish the product’s behaviour under specified conditions; a production configuration review may establish the deployed access scope; a witnessed support session may demonstrate a particular operational process. Combine the evidence carefully and identify where the production assurance remains incomplete. A limitation is useful information for the risk owner, not a reason to overstate the result.

Review individual accountability and shared downstream credentials

Identify the person or service responsible for each action across the route. A named gateway account may provide attribution at entry, while the downstream application uses a shared maintenance identity. Determine whether session records and operational procedures preserve the required accountability. Do not assume that a named first step resolves every attribution question later in the chain.

Review how supplier personnel changes reach the hospital’s access process. Who tells the hospital when an engineer leaves the supplier or changes role? Who verifies that the relevant access is removed? A contract may establish an obligation, but the assessment should examine how the obligation becomes a technical action and what evidence confirms it. Use a representative completed example where available.

Avoid collecting actual credentials into the report. Record the account references, ownership and control evidence using an agreed restricted format. If a credential-handling weakness is observed, describe the exposure without reproducing the secret. The goal is to improve accountability and lifecycle control, not to create another copy of the sensitive access material.

Make maintenance access a defined operating mode

For time-limited work, record the approved purpose, targets, operator, window and expected actions. Confirm who enables access and who verifies closure. A maintenance ticket should link to the technical route it authorises. If the ticket covers several systems, make the target list explicit so a general support request does not silently authorise unrelated access.

Test the lifecycle through an approved representative exercise or completed record. Can the owner show when access became available, what was done and how it ended? Does the evidence identify the operator and target? If a session continues beyond the planned window, who receives the information and who can decide whether it should remain active? The process must work in the actual operational context, including out-of-hours arrangements where relevant.

Treat emergency access separately from routine convenience. The hospital may need a rapid support route during a service interruption, but it still needs an accountable decision, a defined scope and retrospective review. Do not recommend removing an emergency capability without considering the clinical dependency. Recommend a controlled process that preserves the required response while reducing unnecessary standing access.

Verify that access evidence reaches someone who can act

Ask which events the hospital receives and which remain with the supplier. Identify the evidence needed to detect unexpected use, investigate a support action and confirm closure. Then trace a representative event through the review process. A log file that nobody can retrieve or interpret during an incident provides less assurance than its mere existence suggests.

Agree the operational question behind each alert or review. Is the concern use outside an approved window, access to an unexpected target, a privilege change or an unrecognised operator? Define the owner and response action. Avoid requesting an indiscriminate flood of events without a plan to use them. The risk review should help establish actionable visibility, not simply increase storage.

Document retention and evidence-access constraints. If supplier-held records require a support request, understand the expected process and whether it is usable during an urgent investigation. Do not invent a guaranteed response time that has not been agreed. Record what is contractually committed, what has been demonstrated and what remains an operational assumption.

Keep subcontractors and integrations visible

Ask whether the service relies on subcontractors, external support centres or additional software services that affect hospital access or data. The purpose is to understand relevant dependencies, not to demand an unlimited map of the supplier’s entire business. Identify which parties may operate the hospital-facing route or process the information within the agreed scope.

For application integrations, record the service identities, destinations and data categories separately from interactive support access. A supplier may no longer have a remote desktop route while an API client continues to receive information. Conversely, a hosted product may require no inbound network route but still create an important data dependency. The assessment should match evidence to the actual service model.

Where a dependency cannot be directly tested, request appropriately scoped evidence and document the assurance boundary. Do not describe an untested subcontractor as verified because the primary supplier answered a questionnaire. The hospital’s decision may still be to proceed, but it should be based on a visible understanding of the evidence and remaining uncertainty.

Verify offboarding across every relevant access path

Define the event that ends the supplier’s need for access: contract termination, service migration, completion of a project or replacement of a support arrangement. Translate it into a technical checklist covering the identified identities, routes, privileges and integrations. Assign an owner for each action and preserve the service continuity requirements so removal does not unexpectedly disable a still-required workflow.

Validate closure rather than relying only on completed tickets. A designated check can confirm that a removed test identity no longer reaches the agreed target, while configuration evidence confirms the intended route changes. Review relevant alternate paths and retained exceptions. If the supplier continues to provide another service, document the access that remains and its separate justification.

Address retained evidence and data through the appropriate contractual and operational process. The technical access review should identify the issue and responsible owner without making unsupported legal promises about deletion or retention. Keep the report precise: access removed, evidence retained under an agreed arrangement, data-handling confirmation pending, or another clearly defined status.

Example: a support route survives a supplier transition

Consider a fictional hospital that replaces a maintenance supplier. Procurement closes the old contract, but an application owner retains a support account because it was once used for troubleshooting. The access register does not identify that account, and the network route remains available. This is a plausible assessment scenario, not a statement about a real supplier or hospital.

The supported finding is an unowned access path after the service relationship changed. The assessment should identify the account and target scope, the current configuration and the absence of a continuing approved need. It should not claim the former supplier used the route unless activity evidence supports that conclusion. The difference matters for both technical prioritisation and fair reporting.

The correction includes confirming the remaining dependency, removing or narrowing the route through change control and verifying the result. The process improvement links supplier termination to the technical access register and requires closure evidence from the relevant owner. This addresses the reason the path survived, instead of treating the single account as an isolated housekeeping issue.

Prioritise by consequence, access and evidence confidence

Evaluate the service’s importance, the capability granted and the strength of the evidence. A supplier with a narrowly controlled read-only integration presents different questions from one with broad privileged maintenance access to a critical service. Avoid using the same questionnaire score as the sole decision for both. The technical evidence should explain the exposure in terms the service owner understands.

Keep confidence separate from severity. A potentially high-impact route with incomplete evidence may need urgent clarification, while a fully verified low-impact administrative issue may be straightforward to schedule. Do not lower the apparent risk merely because evidence is missing. State the uncertainty and the action that would resolve it, then let the accountable owner make an informed decision.

Use dispositions that reflect reality: approved, approved with conditions, remediation required, evidence pending or rejected for the defined use. A retained exception should name the owner, justification, controls and review trigger. Avoid a permanent green status that outlives the contract, architecture or personnel on which the original assessment depended.

Build a concise owner-ready evidence pack

Keep the decision summary short and link it to the technical details. Include the service relationship, intended access, observed access, material gaps, agreed treatment and outstanding evidence. The technical appendix should provide enough references for the administrator to locate the route and reproduce the validation. Sensitive configuration and identity details belong in a restricted evidence location.

Show the difference between supplier assurance and hospital-boundary verification. A certification or independent report may provide useful context within its stated scope, but it does not automatically verify the specific access arrangement deployed at the hospital. Record the scope and date of external assurance and identify the local checks still required. This prevents a procurement document from substituting for a technical acceptance decision.

Review the pack with the clinical or operational service owner, procurement and the technical control owner. Each should understand the decisions assigned to them. A report that identifies risk but leaves ownership unclear is unlikely to change the environment. The practical measure of value is whether the hospital can approve, restrict, remediate or retire the access with evidence.

Commission technical validation alongside supplier risk review

A useful scope identifies the supplier population, hospital-facing routes, target systems, operating modes and validation methods. Agree the relevant permissions with both the hospital and supplier before testing. Include clinical safety constraints, a stop authority and secure evidence handling. Ask the assessor to distinguish configuration review, witnessed operation and active validation in the final coverage statement.

Request an access register, evidence matrix, findings with owners and retest criteria. Define how unresolved supplier questions will be handled and which items can be concluded from hospital-controlled evidence. Avoid a proposal that promises to prove the entire supplier secure after a short scan. The engagement should answer specific questions about the service and access boundary the hospital needs to manage.

Use our hospital pentest scoping tool to outline supplier access and critical services, or discuss a technical supplier-access assessment with Atlant Security. Share a high-level description first; detailed diagrams, credentials and confidential supplier evidence should follow through an agreed secure channel. The aim is a defensible access decision that supports care delivery and can be checked again when the relationship changes.

Reviewed 25 October 2026. This guide provides technical assessment recommendations. It does not determine contractual compliance, clinical safety certification or legal obligations. Those decisions remain with the hospital’s qualified owners and advisers, supported by the relevant evidence.