DORA Article 28 Evidence Pack — What to Show Auditors

by

Introduction

DORA Article 28 requires regulated financial entities to demonstrate effective control over ICT third-party risks.

This obligation goes far beyond vendor questionnaires or contractual statements.

Auditors do not assess intent — they assess evidence.

This article provides a practical evidence pack for DORA Article 28, focusing on what auditors typically ask for, where evidence should come from, and how CI/CD and cloud delivery systems must support third-party ICT risk management.

What Article 28 Audits Are Really About

From an audit perspective, Article 28 answers four fundamental questions:

  1. Do you know which ICT third parties you rely on?
  2. Are contractual obligations enforceable in practice?
  3. Can you continuously monitor third-party risks?
  4. Can you exit safely if a provider fails or becomes non-compliant?

Evidence must be operational, traceable, and verifiable — not policy-only.

Evidence Pack Overview

A DORA Article 28 evidence pack typically spans five evidence domains:

  1. Supplier inventory & criticality
  2. Contractual controls & audit rights
  3. CI/CD and cloud control enforcement
  4. Monitoring & incident evidence
  5. Exit strategy & resilience evidence

Each domain below explains:

  • what auditors expect,
  • what evidence to show,
  • where it should come from.
DORA Article 28 — Tools → Controls → Evidence Diagram mapping enterprise DevSecOps tooling to enforceable CI/CD controls and resulting audit evidence, with cross-cutting DORA Article 28 third-party governance requirements. Tools → Controls → Evidence DORA Article 28 view: third-party ICT governance enforced through CI/CD controls and provable evidence. CROSS-CUTTING (ARTICLE 28) Supplier governance Contract clauses Monitoring Exit plan Evidence retention MAPPING LAYER Tools Platforms & services Controls Enforced requirements Evidence What auditors verify TOOLS Git / Source Hosting CI/CD Orchestrator + Runners Registries + Dependencies Cloud Runtime + Observability CONTROLS Access control + MFA + SoD Approvals + policy gates Integrity: SBOM + signing + provenance Monitoring + incident workflows EVIDENCE Audit logs + access reviews Approvals & change traceability SBOM + attestations + signatures Monitoring data + incident records Tip: Under DORA Article 28, tools are acceptable only if they enforce controls and continuously produce auditable evidence.
Diagram mapping enterprise DevSecOps tooling to enforceable CI/CD controls and resulting audit evidence, with cross-cutting DORA Article 28 third-party governance requirements.

1. Supplier Inventory & Criticality Evidence

What auditors expect

Auditors want proof that you have:

  • identified all ICT third-party providers,
  • classified them by criticality,
  • linked them to business services and delivery pipelines.

Evidence to provide

  • Centralized ICT supplier inventory
  • Criticality classification (critical / important / non-critical)
  • Mapping between:
    • suppliers,
    • CI/CD tooling,
    • cloud runtime components

Typical evidence artifacts

  • Supplier inventory register (exportable)
  • Risk classification methodology
  • Mapping table: Supplier → CI/CD / Cloud component

2. Contractual Controls & Audit Rights

What auditors expect

Contracts must enable control, not just describe it.

Auditors look for enforceable clauses covering:

  • audit rights,
  • incident notification timelines,
  • evidence retention,
  • subcontractor transparency,
  • exit and transition obligations.

Evidence to provide

  • Contract excerpts showing:
    • audit rights,
    • monitoring access,
    • incident notification clauses
  • Proof contracts apply to actual providers in use

Typical evidence artifacts

  • Contract clause extracts
  • Supplier contract register
  • Legal review notes linking clauses to Article 28 requirements

3. CI/CD & Cloud Control Enforcement Evidence

What auditors expect

Auditors verify that third-party tooling is controlled in practice, not trusted blindly.

This includes:

  • source code hosting platforms,
  • CI/CD orchestration services,
  • runners and execution environments,
  • artifact registries and dependency ecosystems.

Evidence to provide

  • Access control configuration (IAM, roles, SoD)
  • Branch protection and approval rules
  • Build isolation and runner governance
  • Artifact integrity (SBOM, signing)

Typical evidence artifacts

  • CI/CD platform configuration screenshots or exports
  • Pipeline policy definitions (Policy as Code)
  • SBOM and artifact signing reports
  • Access logs from Git / CI/CD platforms

4. Monitoring & Incident Evidence

What auditors expect

DORA requires continuous monitoring, not periodic checks.

Auditors verify that:

  • third-party services are monitored,
  • incidents are detected,
  • evidence is retained and traceable.

Evidence to provide

  • Monitoring dashboards (availability, integrity signals)
  • Incident logs involving third-party services
  • Evidence of incident escalation and notification

Typical evidence artifacts

  • Logs and metrics from CI/CD and cloud platforms
  • Incident tickets referencing third-party providers
  • SIEM or observability integration evidence

5. Exit Strategy & Resilience Evidence

What auditors expect

Exit strategies must be realistic and tested.

Auditors will challenge:

  • whether exit plans exist,
  • whether they apply to critical providers,
  • whether they have ever been tested.

Evidence to provide

  • Documented exit strategies per critical provider
  • Evidence of exit or fallback testing
  • DR / BCP test results involving third-party dependencies

Typical evidence artifacts

  • Exit plans and transition procedures
  • Test reports or tabletop exercise outputs
  • Dependency replacement or fallback documentation

Evidence Characteristics Auditors Care About

Across all domains, auditors assess evidence against four criteria:

  • Traceable → linked to a specific provider or control
  • Repeatable → generated consistently by systems
  • Time-bound → shows when controls were active
  • Tamper-resistant → logs and evidence are protected

Manual spreadsheets alone rarely meet these criteria.

Common Article 28 Audit Findings (Red Flags)

Auditors frequently raise findings when they see:

  • supplier inventories not linked to CI/CD tooling,
  • contracts without operational enforcement,
  • monitoring limited to annual reviews,
  • no proof of subcontractor visibility,
  • exit plans that were never tested.

Designing evidence into pipelines avoids these gaps.

How CI/CD Architecture Enables Article 28 Compliance

Modern Article 28 compliance depends heavily on CI/CD and cloud architecture:

  • pipelines enforce access and approvals,
  • SBOMs provide supply chain transparency,
  • logs and audit trails generate evidence automatically,
  • monitoring systems detect third-party failures.

Without CI/CD-level evidence, Article 28 compliance remains fragile.

Final Takeaway

DORA Article 28 is not a documentation exercise — it is an operational control problem.

The strongest evidence packs:

  • integrate CI/CD, cloud, and vendor governance,
  • generate evidence continuously,
  • align architecture, contracts, and monitoring.

If auditors can verify controls without relying on explanations, your Article 28 posture is solid.

Optional Internal Links (recommandé en bas d’article)

Audit-ready context

Written for regulated environments: controls before tools, policy enforcement in CI/CD, and evidence-by-design for audits.

Focus areas include traceability, approvals, exception governance, and evidence retention across build, release, and operations.

See methodology on the About page.