An evidence-based framework for third-party cyber risk

Start with a statement a business owner can recognise: “This arrangement supports customer payment initiation,” rather than “This vendor supplies software.” Include the institution's role, the provider's role and the minimum useful service during disruption.

Separate three questions. What business outcome depends on the provider? What information and authority does the provider receive? What happens if the provider becomes unavailable or untrustworthy? A supplier can be important for confidentiality even when its service is easy to replace. Another can hold little sensitive information but be essential to transaction processing.

The proposed service record contains the following fields:

Use an identifier that links this record to procurement and asset inventories. Different teams can retain their specialist records; the identifier makes them navigable. Avoid asking the supplier to repeat information the institution already holds and can validate internally.

A proposed triage considers service disruption, information exposure, privileged access and substitutability. These dimensions should remain visible individually. Averaging them can hide a severe issue behind several low values.

For example, a provider with broad administrative access should receive a focused review of that access even if its contract value is small. A specialised processing provider may justify a detailed continuity review even if it does not store customer records. Neither conclusion requires a claim that the provider is generally insecure.

Assign an assessment depth after discussing the relationship with its owner. For a bounded low-consequence service, a limited evidence review may be appropriate. For a service with material disruption or data consequences, require deeper examination of architecture, rights and recovery. Add an explicit uncertainty marker when material facts are missing.

This triage is a proposed resource-allocation method. It does not define MAS materiality, regulatory outsourcing classification or a prescribed risk appetite. Those classifications need their own documented basis and can influence the assessment depth without being replaced by it.

The assessor should identify the claims on which approval depends. “The supplier has good security” is too broad to verify. “Administrative access to the production tenant requires an individually attributable identity and approved privilege” is specific enough to examine.

For each material claim, record the evidence and the boundary of what it establishes:

Independent assurance reports can be useful evidence, but their scope and period matter. Review the service covered, exclusions, exceptions and responsibilities assigned to the customer. When an assessor relies on a provider's statement without verification, preserve that distinction in the decision record.

Evidence freshness should follow the claim. A signed contractual right may remain current until amendment; a privileged-account sample may become outdated after an operational change. Give important claims review triggers and owners, rather than applying an identical expiry date to every document.

Contract review should translate important risk questions into provisions that the institution and supplier can actually perform. Relevant subjects can include security responsibilities, incident communications, evidence access, subcontracting, data return, assistance on termination and handling retained copies. Appropriate wording and enforceability require contractual review for the specific arrangement.

An operational walkthrough should accompany material provisions. If the contract provides for data return, establish who requests it, how identity is verified, which format is supplied and what the institution needs to use it. If cooperation during an incident is promised, identify the coordination route and any prerequisites for sharing evidence.

Keep a record of unmet needs. A provider may offer a standard service whose terms cannot support a desired control. The institution then needs to decide whether it can reduce the exposure itself, choose another arrangement or accept the gap. Marking the contract review as complete should not make the unresolved dependency disappear.

Select scenarios that challenge different dependencies: service unavailability, compromised provider administration, corrupted data, inability to contact essential support and abrupt termination. For each, describe how the institution would maintain or restore the business outcome.

Check whether the proposed alternative shares the dependency that caused the failure. A second environment can still rely on the same identity platform or deployment pipeline. Another provider might rely on the same upstream service. Where the institution cannot establish independence, record uncertainty rather than assuming diversity.

Treat manual alternatives as operating processes that need staffing, capacity and reconciliation. A procedure that works for a small test batch might not handle an extended outage. Include the time required to detect disruption, decide to switch and clear accumulated work after restoration.

Concentration does not automatically make an arrangement unacceptable. The institution may reasonably prefer a strong integrated provider to a fragmented design it cannot operate well. The acceptance should explain the tradeoff and the controls relied upon. A blanket instruction to diversify can create cost without establishing better service resilience.

Describe at least the planned end of a relationship and an accelerated exit under stress. Their destination, timing and provider cooperation assumptions may differ. If a rapid full exit is impractical, identify the interim operating state and its constraints.

An exit package should address the information and capabilities needed to move: data, schemas, configuration, interfaces, administrative rights, keys where transferable, licences and relevant operating knowledge. Identify elements that cannot move and the work required to replace them.

Verification can proceed in stages. A document review establishes the stated process. A controlled export demonstrates that data can be obtained. A target import examines usability. A bounded service exercise examines whether the institution can operate the result. Describe these stages separately; success at one does not prove the next.

The exit decision should account for transaction state and records reconciliation. A technically successful transfer can leave duplicate instructions, missing history or conflicting status. Assign ownership for the business checks that determine when the new arrangement can be trusted.

The proposed model uses five decision points. These are internal management gates, not regulatory categories.

A conditional approval should specify the operating boundary. For example, a pilot using synthetic information with restricted access is different from full production use. Record the condition in a place that the operational team can enforce, with a date for reassessment.

The business owner accepts the service consequences within delegated authority. Technology validates implementation and dependency claims. Security assesses cyber controls and evidence limitations. Procurement maintains commercial coordination. Compliance and legal assess applicable obligations and contractual issues. An independent risk function challenges decisions where the institution's governance requires it.

Roles may be combined in a smaller institution, but responsibilities should remain explicit. The same individual should understand when they are providing technical evidence and when they are accepting business consequences. Escalation is needed when the proposed acceptance exceeds their authority.

Keep the acceptance short enough to read. State the exposure, evidence, remaining gap, rationale, boundary, owner and review trigger. Supporting documents can be linked. A large evidence folder without a clear decision does not establish accountability.

Monitoring should target changes in the relationship's assumptions. Examples include expanded access, a new deployment region, a critical subcontractor change, a material incident or a failed recovery exercise. Require the relationship owner to route relevant changes to the appropriate technical and risk reviewers.

Use metrics with clear denominators. “Critical service relationships with a current decision record” requires a defined inventory. “Overdue material evidence gaps” requires a documented definition of materiality and a target date. Distinguish an open investigation from a confirmed control failure.

The following proposed dashboard supports management discussion:

Do not convert these indicators into a claimed breach probability or a universal institution ranking. Their value lies in directing attention to decisions and evidence gaps.

In the first 30 days, select one service and reconcile its procurement, technology and risk records. Agree ownership and the definition of minimum acceptable delivery. Confirm the regulatory scope through the institution's established process.

In days 31–60, identify the few claims that determine whether continued use is acceptable. Review existing evidence before requesting more. Walk through incident escalation and data retrieval with the supplier, and document shared dependencies.

In days 61–90, execute one bounded assurance exercise. It might test recovery access or a sample data export and import. Obtain written findings from the responsible internal teams, record limits and present treatment options to the decision owner.

In the following quarter, refine the templates using the pilot and expand to the next group of relationships. Estimate the review effort per relationship before setting coverage targets. A smaller evidence-based programme is more actionable than a large register of unsupported green ratings.

A hypothetical fintech uses a hosted case-management platform for payment investigations. It can tolerate limited disruption, but outstanding cases must retain their history and supporting documents. The provider offers a periodic data export, and the institution initially treats that as adequate exit assurance.

A controlled import trial finds that the export contains case fields but excludes some attachments and workflow state. This is a hypothetical result, not an observed provider finding. The decision changes: data return exists, but it is not yet a usable replacement service.

Management can request an expanded export, maintain an approved independent archive, redesign the workflow or accept a defined transition limitation. The assurance record should describe the remaining exposure and who will validate the selected treatment. The exercise earns its value by changing a specific decision.

The following proposed template can be completed after a review. It should be short enough for the acceptance owner to understand without reconstructing the assessment from its attachments.

Service and arrangement: Identify the customer or internal outcome, relevant legal entity, provider and technical scope. State whether the review covers current use, a proposed expansion or a transition.

Decision required: Describe the choice in concrete terms, including the proposed operating boundary. A request to continue a limited pilot is different from approval to process production customer information.

Claims relied upon: List the few claims essential to acceptance and link each to evidence. For each claim, record what was demonstrated, what came only from provider assertion and what remains untested.

Failure scenario: Name the scenario used to examine continuity or exit. Describe the alternative operation, its dependencies and its known capacity limits. Identify any assumption that would invalidate the proposed treatment.

Residual gap: Explain the remaining exposure in business terms. State whether the gap is a confirmed weakness, missing evidence or an architectural limitation. Those conditions may require different responses.

Acceptance and follow-up: Name the decision owner, rationale, conditions, action owners and review triggers. Include the next review date and the event that would require an earlier reassessment.

This template should not become a second inventory. Link established records and keep the decision itself current. When an important fact changes, update the acceptance rather than merely adding another document to the evidence folder.

An assurance review is most useful when it supports a choice. If a service depends on one difficult-to-replace provider, management may consider strengthening recovery, reducing the scope of dependence, preparing a staged transition or retaining the arrangement with additional oversight.

Compare options against the same scenario and service objective. Estimate implementation effort, ongoing operational burden, dependencies introduced and the evidence that would establish success. Do not claim a numerical reduction in risk unless the institution has an appropriate analytical basis.

For example, a hypothetical institution might choose between maintaining an independent archive and building a replacement processing platform. The archive could improve access to records without restoring transaction capability. The platform could address a wider service need but require substantial integration and staffing. The options solve different problems; their cost should be assessed against the specific outcome management needs.

Set an acceptance test before funding the change. If the intended outcome is usable records during supplier loss, define the retrieval and validation exercise. If it is service continuation, test the actual operating path and reconciliation. This makes the subsequent review about demonstrated capability rather than completion of procurement.