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 24(6) 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.
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.
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 an evidence-posture check on whether your test records are retained, traceable to a release, and durable enough for a supervisory look-back, 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. Findings are never conditioned on buying anything else: if we recommend closing gaps, the recommendation stands whether or not you engage us to do it, and we hold no referral or revenue-share arrangement with any tool vendor.
Fixed fee, agreed before you commit. We set the delivery date with you in the statement of work and hold it: the audit is three days of focused work, scheduled to a date that suits both sides, a commitment and not an estimate.
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.
We interview an engineering lead and someone from product, the people who know which journeys carry the money and the risk, and inventory every test you run, working from an artefact bundle your engineer exports and reviews. Your QA lead joins where useful; the journey map comes from the people who own the business outcomes, not only from the test suite. The audit never touches your systems.
We map your business-critical journeys and score coverage against Tier 1, 2, and 3 risk. Before the day closes we send you a short written checkpoint: how many of your critical journeys look unprotected, and where the single biggest exposure is forming. Findings are still provisional at that point, so nothing in the final report arrives as a surprise.
We walk your engineering team and risk lead through the findings in a one-hour session: the coverage map, the single biggest exposure, and the fixes in priority order. You receive the report as a draft at that walkthrough, then have one business day to correct any fact, a test that does exist or a journey named wrong, before the final version is issued. The judgments are ours and they stand; the facts they rest on are yours to check.
Code coverage counts executed lines. The Coverage 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.
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.
Article 24(6) requires that all ICT systems and applications supporting critical or important functions are tested at least yearly, and Article 25(1) names gap analyses, scenario-based tests, and end-to-end testing among the eligible methodologies. The audit is a gap analysis of test coverage against critical business journeys, and it produces a risk-mapped coverage record and gap register that function as testing evidence in front of a supervisor. Read: test evidence under DORA →
Test evidence under DORA: what Articles 24 and 25 require →Three days, fixed scope. Your team's involvement is roughly two hours of interviews and one engineer exporting the artefact bundle.
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.
Ivan Stepantsov, founder of Certance Advisory. A quality engineering leader with more than ten years building and leading test automation in regulated financial services, healthcare, and defence systems.
On a date we agree with you in the statement of work, before the engagement begins. The audit is three days of focused work; we schedule those days and set the delivery date around both sides' availability, then hold the date we agreed. You also see the shape of the findings in a written checkpoint at the end of day two, before the report is written.
You have one business day after the walkthrough to correct any fact: a test that does exist, or a journey we named wrong. The judgments, the tiers and the risk scores, are ours and they stand; the facts they rest on are yours to check. Corrections are made before the final report is issued.
