Poro Advisory

Board guides · Practical companion

What does good cyber evidence look like?

What to ask for, what it tells you and where its limits lie.

A board paper says the controls are effective, recovery has been tested and the major findings are closed. What gives you confidence those conclusions are justified? Use it alongside our other board guides, or on its own.

6-page PDF Prepared by Professor Buck Rogers
Front cover of the Poro Advisory guide: What does good cyber evidence look like?

What's inside

  • Begin with the claim

    Turn broad statements like “our recovery arrangements work” into specific conclusions the board can actually examine.

  • Look for a traceable basis

    What a useful board paper summarises — results, limitations and a clear route to the supporting records, without raw technical logs.

  • Five familiar assurances

    Practical examples of the evidence worth discussing behind common cyber assurances, as prompts for board judgement.

  • Make room for uncertainty

    How to weigh what hasn’t been tested — and decide between further work, a temporary safeguard or explicit risk acceptance.

Claim · Evidence · Judgement

What are we being asked to accept? What was checked and what did it show? What can we reasonably conclude?

Get your free copy

Tell us where to send it and we'll email you the download link straight away.

We'll only use your details to send the guide and occasional Poro Advisory insights. No sharing, ever.

From the guide

Good cyber evidence: what to ask for and where its limits lie

A board paper says the controls are effective, recovery has been tested and the major findings are closed. What gives you confidence those conclusions are justified? The full guide works through this in detail; here are the essentials.

The questions a board should ask

Six questions to take into the meeting when a significant assurance appears in the cyber paper:

  • What claim are we being asked to accept? Be clear about the conclusion.
  • What evidence supports it? Ask for the relevant result and its source.
  • Does it cover what matters? Check the services, dependencies and circumstances.
  • What remains uncertain or untested? Understand the limits of the assurance.
  • What does that mean for our exposure? Connect the gap to its practical consequences.
  • Is a decision or action needed, and who owns it? Clarify responsibility and follow-up.

Begin with the claim. "Our recovery arrangements work" is a broad statement. "We restored the customer payment service within its agreed recovery target in last month's exercise" is a conclusion directors can actually examine.

The evidence to request

Behind five familiar assurances, the guide suggests the evidence worth discussing:

  • "Our backups are working" — results from restoring a relevant service: elapsed time, checks on data accuracy, and unresolved failures.
  • "Our critical suppliers have been assessed" — the services they support, significant dependencies and evidence that contingency arrangements are usable.
  • "Staff have completed their training" — evidence from exercises and incidents showing whether people recognise, challenge and report suspicious activity.
  • "The finding is closed" — a record of the change, checks that it addresses the weakness, and who verified closure.
  • "Our incident plan has been tested" — the scenario and participants, difficulties found, and evidence that follow-up actions were completed and checked.

Completion is one part of the picture. A completed activity shows something happened; the next question is whether it achieved the intended result.

A practical scenario

The headline: "Recovery testing completed successfully." The payment application was restored in three hours against a four-hour technical target. However, the external payment connection was excluded, so an end-to-end payment was not completed.

The result supports confidence in application restoration; it does not yet demonstrate that customers could make payments within the required time. The COO proposes an end-to-end retest within 30 days — and the board can judge whether that response is adequate, what the exposure is in the meantime, and when it expects an update.

Buck's interpretation

Evidence becomes useful when its relevance and limitations are clear. Check the scope (a test of one system may leave the wider service, its suppliers or its manual workarounds untested), the timing (what has changed since the evidence was produced), who checked it and how, and what failed or was excluded.

A failed test can be useful evidence — finding a weakness before a real incident gives the organisation a chance to act. A pass or fail label alone tells the board very little. Keep the conclusion proportionate: a successful test supports a conclusion about the conditions tested; it cannot establish that every disruption can be managed.

A useful follow-up for any assurance: "Given these limitations, what can we reasonably conclude today, and what would change that conclusion?"

The full guide includes the five assurance examples in detail, the confidence checks and a practical worksheet for your next meeting.

Download the full guide