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.
It bridges the gap between two complementary perspectives:
- Auditors think in terms of control objectives, evidence, and accountability.
- Engineers think in terms of systems, pipelines, configurations, and automation.
Both views are valid — but they are not interchangeable. This article shows what auditors are actually trying to verify, how engineers should implement controls to satisfy those expectations, and where misunderstandings typically occur.
What Article 28 Audits Are Really About
From an audit perspective, Article 28 answers four fundamental questions:
- Do you know which ICT third parties you rely on?
- Are contractual obligations enforceable in practice?
- Can you continuously monitor third-party risks?
- Can you exit safely if a provider fails or becomes non-compliant?
Evidence must be operational, traceable, and verifiable — not policy-only.
How Auditors Approach an Article 28 Review
Auditors do not start with tools or architecture diagrams. They start with risk questions:
- Do third-party ICT providers introduce unmanaged operational risk?
- Are controls enforceable beyond internal systems?
- Can the organization demonstrate continuous oversight?
- Is evidence objective and time-bound?
Evidence is assessed as proof of operational control, not as policy confirmation.
| Perspective | Focus |
|---|---|
| Auditor View | Can this organization demonstrate effective third-party ICT risk control? |
| Engineer View | How do we enforce and generate evidence through CI/CD and cloud systems? |
Evidence Pack Overview
A DORA Article 28 evidence pack typically spans five evidence domains:
- Supplier inventory & criticality
- Contractual controls & audit rights
- CI/CD and cloud control enforcement
- Monitoring & incident evidence
- Exit strategy & resilience evidence
Each domain below explains what auditors expect, what evidence to show, and where it should come from — from both the Auditor View and the Engineer View.
1. Supplier Inventory & Criticality
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.
They expect inclusion of CI/CD SaaS platforms (not just traditional vendors), visibility into cloud services, registries, and code hosting, and linkage between suppliers and actual systems in use.
Evidence to provide
- Centralized ICT supplier inventory
- Criticality classification (critical / important / non-critical)
- Mapping between suppliers, CI/CD tooling, and cloud runtime components
Typical evidence artifacts
- Supplier inventory register (exportable)
- Risk classification methodology
- Mapping table: Supplier → CI/CD / Cloud component
Auditor View
Auditors ask:
- Do you have a complete inventory of ICT third-party providers?
- Are providers classified by criticality?
- Is this classification tied to business services and delivery systems?
What they verify: inventory completeness, consistency with actual systems in use, and traceability to risk management decisions.
Engineer View
Engineers must ensure:
- CI/CD platforms, Git hosting, registries, runners, cloud services are explicitly registered as suppliers,
- supplier metadata (criticality, owner, usage) is kept in sync with real usage,
- pipelines reference approved suppliers only.
Typical implementation:
- CMDB or supplier registry linked to CI/CD tooling,
- automated checks preventing unapproved services,
- documentation generated from live configurations.
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.
More importantly, they verify that these clauses are operationally enforceable.
“You have audit rights in the contract — how do you exercise them in practice?”
Evidence to provide
- Contract excerpts showing audit rights, monitoring access, and 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
Auditor View
Auditors look for:
- enforceable audit rights,
- incident notification obligations,
- evidence retention commitments,
- visibility over subprocessors,
- defined exit clauses.
They do not assume contracts are effective just because they exist.
Engineer View
Engineers must:
- know which contractual obligations impact technical controls,
- ensure platforms can actually produce the required evidence,
- support audits without ad-hoc data collection.
Typical implementation:
- mapping contract clauses → technical controls,
- ensuring logs, SBOMs, approvals are retained long enough,
- making audit access technically possible (read-only, scoped).
3. CI/CD & Cloud Control Enforcement
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, and 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
Auditor View
Auditors want proof that:
- access is controlled and segregated,
- approvals are enforced,
- artifacts are protected against tampering,
- third-party tooling does not bypass internal controls.
They test whether controls are systematic, not manual.
Engineer View
Engineers implement:
- IAM, role separation, branch protections,
- pipeline approvals and policy gates,
- SBOM generation and artifact signing,
- runner isolation and token scoping.
Key mindset shift:
“Secure by default” is not enough — controls must be provable.
4. Monitoring & Incident Management
What auditors expect
DORA requires continuous monitoring, not periodic checks. Auditors verify that third-party services are monitored, incidents are detected, and evidence is retained and traceable.
They look for:
- live or historical monitoring data,
- alerts tied to third-party services,
- visibility into CI/CD platform availability and integrity.
Monitoring evidence must demonstrate that third-party degradation would be detected and incidents would be escalated within defined timelines. Static risk assessments alone are insufficient.
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
Auditor View
Auditors assess whether:
- third-party services are continuously monitored,
- incidents involving suppliers are detectable,
- incident handling is documented and traceable.
They reject annual risk assessments without operational monitoring.
Engineer View
Engineers ensure:
- CI/CD platforms, registries, and cloud runtimes emit logs,
- monitoring feeds SIEM or centralized logging,
- incidents reference affected third-party providers.
Typical implementation:
- observability pipelines,
- incident tickets linked to logs and metrics,
- alerting on supplier degradation or failure.
Incident Notification SLAs: Tested in Reality
Auditors verify that:
- incident notification SLAs exist contractually,
- internal processes can receive and act on notifications,
- timelines are realistic and tested.
They often request past incident examples, timestamps showing notification delays, and evidence of escalation and response. An SLA that has never been exercised is treated as unproven.
5. Exit Strategy & Resilience
What auditors expect
Exit strategies must be realistic and tested. Auditors will challenge whether exit plans exist, whether they apply to critical providers, and 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
Auditor View
Auditors ask:
- Do exit strategies exist for critical suppliers?
- Have they been tested?
- Could you realistically exit under pressure?
A PDF exit plan alone is insufficient.
Engineer View
Engineers support exit strategies by:
- avoiding hard vendor lock-in,
- documenting replacement or fallback paths,
- participating in DR and exit tests.
Typical implementation:
- artifact portability,
- infrastructure-as-code reproducibility,
- tested backup and restore procedures.
Evidence Quality: How Auditors Judge Credibility
Auditors assess evidence against four implicit criteria:
- Objectivity – system-generated, not manually edited
- Traceability – linked to a specific supplier or control
- Continuity – produced consistently over time
- Integrity – protected against alteration
Evidence failing any of these criteria weakens the entire pack. 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.
| Situation | Auditor Reaction |
|---|---|
| “We trust this SaaS provider” | ❌ Not acceptable |
| Evidence collected manually before audit | ⚠️ Weak control |
| Logs exist but are not retained | ❌ Non-compliant |
| Exit plan never tested | ❌ High-risk finding |
From audit experience, evidence packs often fail because:
- CI/CD SaaS platforms are excluded from supplier scope
- Evidence exists but cannot be linked to a control
- Logs are available but not retained long enough
- Incident SLAs exist but were never tested
- Exit strategies are documented but unsupported by technical reality
These issues usually surface during the audit, not during preparation. 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.
Designing for Both Views
The most mature organizations:
- design controls once,
- satisfy both audit and engineering needs,
- generate evidence continuously via CI/CD and cloud platforms.
This is the foundation of continuous compliance under DORA.
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.
Recommended Related Reading
- DORA Article 28 Architecture — Explained
- Continuous Compliance via CI/CD Pipelines
- CI/CD Audit Red Flags
