§ DORA

Threat-led testing with a chain that survives the supervisor.

The Digital Operational Resilience Act requires financial entities to run threat-led penetration testing on critical functions and to manage ICT third-party risk. SecHive produces the per-finding chain that makes both defensible.

Book a compliance demo → How the chain works

FrameworkDORA

JurisdictionEU 2022/2554

ReferenceArticles 24–28

ScopeFinancial entities & ICT third parties

SecHive evidencetechnical

Auditor opinionout of scope

§ Articles → Evidence

Where SecHive evidence fits in DORA.

The mapping is intentionally narrow. We list only the articles where SecHive produces a directly defensible artifact, and we name the artifact.

Article / control	What it requires	SecHive artifact
Art. 24 — Testing programme	Sound and comprehensive ICT security testing programme.	Per-engagement scope policy, methodology spine, retained proof packs.
Art. 25 — Vulnerability assessment	Vulnerability assessments, scans, source code reviews, scenario-based tests.	SecHive run modes cover all four — clearly labeled per finding.
Art. 26 — TLPT	Threat-led penetration testing on critical functions.	Threat-scenario hypothesis graph; benign-PoC validation under scope guard.
Art. 27 — TLPT testers	Requirements on testers and methodology.	Auditable identity + methodology label on every finding; operator-controlled.
Art. 28 — ICT third-party risk	Sound management of ICT third-party risk.	Source-audit and PR-audit modes for supplier artifacts and integration points.

§ Buyer view

SecHive provides.

What you can put in front of an auditor or a security review.

For the CISO

Mappable evidence per Article 21(2) sub-clause.
Time-bounded findings with severity and impact.
Retest records that close the loop with the engineering team.

For the legal / compliance team

Redaction manifests for cross-border or supplier engagements.
Operator identity stamped on every disposition.
Cosigned attestation on report bundles.

For engineering

Deterministic replay.sh per finding.
Source references when source mode is enabled.
Negative evidence for refuted candidates.

For the auditor

Run-mode-labeled evidence rows.
sha256 binding to underlying artifacts.
Methodology spine consistent across engagements.

§ Sample evidence

A page from the matrix.

SecHive renders an evidence matrix per engagement. Below is one row, redacted.

EVIDENCE ROW — sample

# evidence-row.yaml — redacted
control:    Art. 26 (TLPT)  # effectiveness testing
finding_id: VTX-RPL-0042
mode:       black-box
target:     redacted
target_ref: image@sha256:9c4e…  # pinned
artifact:
  path:    artifacts/replay.sh
  sha256:  7c3a…
  signed:  cosign:sechive-key
disposition:
  reviewer:  redacted-operator
  state:    confirmed
retest:
  status:    fixed @ 2026-04-18
  evidence:  artifacts/retest-receipt.json

What an auditor sees

The control id and the finding id, bound together.
A run-mode label (black-box, source-aware, etc.).
A sha256 of the underlying artifact.
A reviewer disposition with operator identity.
A retest record if the finding has been remediated.

See the full output matrix →