Reuse supplier evidence across CPS 230 and CPS 234 carefully

A supplier sends a recovery-test report to the continuity team. Security requests the same report a week later. Both teams need it, but they are trying to establish different things.

Sharing the document can reduce duplicate requests. Sharing an unqualified “passed” conclusion can hide gaps. A private health insurer needs to know which information assets were protected and whether the claims service it relies on could actually resume.

The approach below is a suggested evidence-mapping method. It helps teams reuse relevant work without treating two prudential standards as interchangeable.

Start with two questions

For the continuity review, ask what the evidence shows about maintaining or recovering the relevant operation. For the information-security review, ask what it shows about the protection of the relevant information assets.

CPS 230 addresses operational risk, continuity and service-provider arrangements. CPS 234 addresses information security, including assets managed by related and third parties. Their scopes overlap without becoming identical.

Write the two questions before deciding which documents to reuse. That prevents the evidence inventory from defining the review's scope by accident.

Establish the boundary of the artefact

For each report or test record, capture the provider entity, service, systems, environment, period and excluded components. Note whether the material describes a design, an implemented control, an observed test result or an independent assurance conclusion.

Then inspect the detail that affects your organisation. A group-wide report may not cover the claims environment you use. A test in a non-production environment may answer some questions while leaving assumptions about capacity or interfaces unresolved.

Keep those limitations beside the document link. If they are buried in one team's notes, another reviewer may reuse the artefact without seeing them.

Work through a recovery-test example

Consider a fictional private health insurer using an outsourced claims platform. Its provider reports that a backup was restored into a test environment and that sample records were readable. The report excludes the external payment interface and does not test reconciliation of claims submitted during the outage.

The security reviewer may use the report as evidence relevant to part of the recovery-control assessment, while examining integrity checks, access arrangements and whether the test was appropriate to the assets and risks. The continuity reviewer still needs to examine how interrupted claims would be completed and how the payment interface would reconnect.

Neither reviewer should infer an end-to-end service recovery result that the exercise did not produce. The same source can support a limited conclusion in one review and expose an unanswered question in another.

A useful shared record could contain:

• Artefact: the exact report and its version.
• Security question: what part of backup restoration and integrity checking was demonstrated?
• Operational question: can the insurer resume the claims process, including reconciliation and payment?
• Supported finding: the tested environment restored the selected records described in the report.
• Remaining questions: interface recovery, interrupted transactions and any untested scope.
• Owners: the people responsible for obtaining and assessing each missing piece.

This example is illustrative. It is not a finding about a provider or a prescribed regulatory evidence format.

Keep assurance judgments with the right reviewers

Document reuse should not obscure who reached a conclusion. A security specialist may be qualified to evaluate control-testing evidence while an operations owner understands the claims process and its manual workarounds. Both perspectives can be necessary.

CPS 234 contains specific requirements concerning third-party control design and reliance on third-party testing. Consult the current standard when determining the appropriate review and assurance arrangements. A generic supplier risk score cannot replace that assessment.

Where two teams disagree, record the precise difference. One may be assessing a narrower system boundary or assuming a dependency is available. Resolve the assumption rather than forcing a single colour into the dashboard.

Reuse evidence with version control

Store one controlled artefact where authorised reviewers can access it, with separate links to the assessments it supports. Record when the artefact was checked and what would make it unsuitable for continued reliance.

Examples of review triggers include a changed hosting environment, a major release, a relevant incident or a new test that contradicts the old result. A later upload should not silently erase the source used for an earlier decision.

If a supplier imposes confidentiality or distribution restrictions, check those before sharing the report beyond its authorised audience. Reusing information internally is not a reason to copy it into broadly accessible tools or send it to unrelated providers.

Make the next request specific

In the fictional example, asking for “more CPS 230 evidence” would be vague. A focused request would ask how the untested payment interface and interrupted claims are recovered, and what exercise or other evidence supports the answer.

Combine shared factual questions where possible, then keep distinct evaluation questions visible. The supplier receives a coherent request, while each internal reviewer retains responsibility for their conclusion.

Use the assurance-report review when the shared artefact is an audit or assurance report with its own scope, period and exceptions.

Begin with one report that two teams already use. Map its scope, the conclusions it supports and the gaps it leaves. The CPS 230 evidence checklist provides a broader review-record structure; this mapping adds the boundaries needed when an artefact serves more than one purpose.