This mapping links DORA Article 28 obligations to concrete technical and organizational controls, and the evidence auditors expect to verify.
It is designed to eliminate ambiguity between regulatory text, implementation, and audit verification.
1. ICT Third-Party Identification
Article 28 Requirement
Financial entities shall identify and maintain an inventory of all ICT third-party service providers.
| Controls implemented | Evidence produced |
|---|---|
| Centralized ICT supplier inventory | Supplier register export |
| Mandatory registration of CI/CD, cloud, SaaS tools | Inventory records including CI/CD tooling |
| Ownership and business mapping | Supplier → business service mapping |
| Periodic inventory review | Review meeting minutes / logs |
2. Criticality Classification
Article 28 Requirement
ICT third-party providers shall be classified based on criticality and risk.
| Controls implemented | Evidence produced |
|---|---|
| Risk-based supplier classification framework | Classification methodology |
| Identification of critical ICT providers | Critical supplier list |
| CI/CD tools classified when supporting critical services | CI/CD → service mapping |
| Governance escalation for critical providers | Risk committee records |
3. Pre-Contract Due Diligence
Article 28 Requirement
Risk assessments shall be performed before entering into contractual arrangements.
| Controls implemented | Evidence produced |
|---|---|
| Security due diligence process | Due diligence reports |
| Risk assessment covering ICT and operational risk | Risk assessment documents |
| Subprocessor disclosure review | Supplier disclosures |
| Formal approval before onboarding | Approval records |
4. Contractual Safeguards
Article 28 Requirement
Contracts shall include minimum security, audit, and exit provisions.
| Controls implemented | Evidence produced |
|---|---|
| Standard contract clauses for ICT suppliers | Contract clause extracts |
| Audit and inspection rights | Signed contracts |
| Incident notification SLAs | SLA documentation |
| Evidence retention obligations | Contract terms |
| Exit and termination clauses | Exit provisions |
5. Access Control & Segregation of Duties
Article 28 Requirement
Access to ICT services shall be appropriately controlled.
| Controls implemented | Evidence produced |
|---|---|
| Role-based access control (RBAC) | IAM configuration exports |
| Segregation of duties in CI/CD | Access matrix |
| Privileged access monitoring | Access logs |
| Periodic access reviews | Review reports |
6. CI/CD Enforcement Controls
Article 28 Requirement
Controls shall prevent unauthorized changes and ensure integrity.
| Controls implemented | Evidence produced |
|---|---|
| Mandatory approvals and policy gates | Pipeline configurations |
| Policy-as-code enforcement | Policy definitions |
| Controlled CI/CD runners | Runner configuration |
| Artifact integrity protection | SBOM, signing reports |
| Change traceability | CI/CD audit logs |
7. Monitoring & Incident Management
Article 28 Requirement
ICT third-party risks shall be continuously monitored.
| Controls implemented | Evidence produced |
|---|---|
| Continuous monitoring of ICT services | Monitoring dashboards |
| Alerting on third-party failures | Alert logs |
| Incident tracking | Incident tickets |
| Incident escalation procedures | Incident workflows |
| Post-incident reviews | RCA reports |
8. Subprocessor Governance
Article 28 Requirement
Risks arising from subcontracting chains shall be managed.
| Controls implemented | Evidence produced |
|---|---|
| Visibility into subprocessors | Supplier disclosures |
| Subprocessor approval process | Approval records |
| Risk assessments for subprocessors | Risk reports |
| Monitoring of subprocessor changes | Change notifications |
9. Exit Strategy & Resilience
Article 28 Requirement
Exit strategies shall ensure continuity in case of supplier failure.
| Controls implemented | Evidence produced |
|---|---|
| Documented exit strategies | Exit plans |
| Feasibility assessments | Feasibility reports |
| Exit or fallback testing | Test reports |
| Periodic review of exit plans | Review records |
10. Evidence Management & Retention
Article 28 Requirement
Evidence shall be available, protected, and retained.
| Controls implemented | Evidence produced |
|---|---|
| Centralized evidence repository | Evidence storage |
| Time-stamped, immutable logs | Log configuration |
| Retention policies enforced | Retention policy documents |
| Controlled access to evidence | Access logs |
| On-demand evidence production | Audit extracts |
How Auditors Use This Mapping
Auditors typically:
- start from Article 28 requirements,
- verify that controls exist and operate,
- request direct evidence for each control.
If a control cannot produce evidence, it is considered ineffective.
Key Takeaway
DORA Article 28 compliance is achieved when every regulatory requirement is traceable to controls, and every control produces evidence.
This mapping provides the backbone for:
- audit preparation,
- continuous compliance,
- CI/CD governance in regulated environments.
Recommended Related Content
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 Auditor Checklist (Yes / No / Evidence)
- DORA Article 28 Architecture — Explained
- Continuous Compliance via CI/CD Pipelines
