The Coverage & Evidence Audit

A fixed three-day engagement that maps your test suite to the business journeys it is supposed to protect. Independent and risk-ranked, delivered without access to your systems.
Approach

We measure quality as business risk.

Coverage where failure costs the most.

We rank every critical path, in the interface or behind it, by what a failure actually costs. Tier 1: failures that move money, expose data, block access, or cannot be undone. Tier 2: failures that stay silent, where the system returns an answer that looks right and is wrong. Tier 3: operational friction. Coverage is judged against this map.

Eight-dimension maturity model

A structured read of how a team manages quality, scored across Change Capability, Test and CI Health, Knowledge Architecture, Engineering Culture, Dependency Health and Learning Culture, plus Regulatory Alignment and Audit Evidence Posture for regulated teams.

Built for regulated environments

2026 is the first year supervisors enforce DORA rather than phase it in. In 2025, EU financial entities reported 3,383 major ICT incidents, with system failures the single largest cause, ahead of external attacks. The question has moved from whether you test to whether you can prove it.

We speak the language your risk function already uses: DORA Article 25 testing evidence, FCA Important Business Services, test data exposure, and audit-ready release records. Findings land as independent evidence of regulatory risk the business can act on.

What is a test coverage audit?

A test coverage audit is an independent assessment of whether a software test suite actually protects the business journeys that matter: the flows that move money, prove compliance, or expose data. It measures coverage against business risk, not lines of code, and produces evidence a risk function can use. Most coverage numbers are code percentages. A suite can score 80% and still leave every Tier 1 journey unverified. The audit replaces that percentage with a journey-by-journey map.

What you get

A business-readable report: a journey coverage table mapped to Tier 1, 2, and 3 business risk, the top five gaps ranked by consequence, and a clear view of where your coverage holds and where it breaks, written for a Head of Risk to act on. The assessment is independent. It holds in front of your risk function and your regulator in a way a self-assessment cannot.

How it works

A fixed, three-day engagement. No open-ended discovery, no surprise scope.

The audit needs no access to your systems.

It runs on test artefacts your own engineer exports and reviews before anything leaves your environment: test names and assertions, pipeline configuration, recent run summaries, coverage output. No account provisioning, no production data, no customer data. For most vendor-risk frameworks this is the lowest access tier a supplier can occupy. If the audit leads to implementation work, access for that is scoped separately under your own onboarding rules, with a delivered engagement already behind us.

Day 1: Discovery interviews and a full test suite inventory

We interview your engineering and QA leads and inventory every test you run, working from an artefact bundle your engineer exports and reviews. The audit never touches your systems.

Day 2: Business journey mapping and risk-tier gap scoring

We map your business-critical journeys and score coverage against Tier 1, 2, and 3 risk.

Day 3: The risk-framed gap report, delivered

You receive a business-readable gap report: what is protected, the top gaps, and what to fix first.

FAQ

Questions a risk function asks

How is this different from code coverage?

Code coverage counts executed lines. The Coverage & Evidence Audit measures whether business-critical journeys are verified through to the business outcome, ranked by what a failure costs, and whether you could evidence that verification to a supervisor. A suite can have high code coverage and zero verified Tier 1 journeys.

Does the audit need access to our systems?

No. It runs on an artefact bundle your own engineer exports and reviews before anything leaves your environment. No account provisioning, no production or customer data.

How does the audit map to DORA Article 25?

Article 25 requires testing of ICT tools and systems and the ability to evidence it. The audit produces a risk-mapped coverage record and gap register that function as testing evidence in front of a supervisor.

How long does it take and what does it require from our team?

Three days, fixed scope. Your team's involvement is roughly two hours of interviews and one engineer exporting the artefact bundle.

What happens after the audit?

The report is yours: your team can close the gaps, or Certance can scope implementation work separately under your own onboarding rules. Nothing in the audit locks you in.

Who conducts the audit?

Ivan Stepantsov, founder of Certance Advisory: a test automation practitioner with years building and leading quality engineering in regulated financial services, healthcare, and defense systems.

Not ready to book a call?

Subscribe to Certance research and the AI Token Efficiency Guide lands in your inbox. The audit is here whenever you are ready: book a scoping call at the top of the page.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.