DORA Article 28 — Controls & Evidence Mapping

Introduction

This article connects DORA Article 28 obligations to concrete technical controls and the evidence auditors expect to verify. It bridges two complementary perspectives:

• From tooling to evidence: how commonly used enterprise DevSecOps and CI/CD tools enforce controls and produce audit-ready outputs.
• From regulation to evidence: how each Article 28 requirement maps to implementable controls and verifiable evidence.

The objective is to remove ambiguity between regulatory text, tooling, governance, and compliance — and provide a single reference for audit preparation and continuous compliance.

Mapping by Article 28 Obligation

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 tooling	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

---

Mapping by Tooling Category

The following section maps commonly used enterprise DevSecOps tools to the controls they enforce and the evidence they produce under DORA Article 28.

1. Source Code Management (Git Platforms)

Typical tools: GitHub Enterprise, GitLab, Bitbucket

Controls enforced	Evidence produced
Role-based access control	Repository access logs
Segregation of duties (PR vs merge)	Branch protection rules
Mandatory reviews & approvals	Pull request history
Change traceability	Commit history
Third-party access governance	User and token audit logs

Article 28 relevance: Git platforms are ICT third-party providers influencing code integrity.

2. CI/CD Orchestration Platforms

Typical tools: GitHub Actions, GitLab CI, Jenkins (managed), Azure DevOps Pipelines

Controls enforced	Evidence produced
Pipeline approval gates	Pipeline configuration exports
Policy-as-code enforcement	Policy definitions
Controlled execution environments	Runner configuration
Least privilege pipeline tokens	Token scope configuration
Pipeline change logging	CI/CD audit logs

Article 28 relevance: CI/CD SaaS platforms must be governed as critical ICT suppliers.

3. Build & Dependency Security (SCA / SBOM)

Typical tools: Snyk, Dependency-Check, Mend, GitHub Dependabot, Syft / CycloneDX

Controls enforced	Evidence produced
Dependency risk analysis	SCA reports
SBOM generation	SBOM files
Provenance tracking	Build metadata
Vulnerability monitoring	Alerts and reports
Supply chain transparency	Dependency inventories

Article 28 relevance: Provides visibility into third-party software risks and subprocessors.

4. Artifact Repositories & Registries

Typical tools: Artifactory, Nexus, Docker registries, Cloud container registries

Controls enforced	Evidence produced
Access control on artifacts	Repository access logs
Artifact immutability	Repository configuration
Artifact signing	Signature verification
Provenance verification	Attestation records
Retention policies	Retention configuration

Article 28 relevance: Protects integrity of deliverables provided by third-party systems.

5. Runtime & Cloud Platforms

Typical tools: AWS / Azure / GCP, Kubernetes platforms, Managed PaaS services

Controls enforced	Evidence produced
IAM and role separation	IAM policy exports
Network isolation	Security group configs
Runtime monitoring	Logs and metrics
Incident detection	Alerts
Availability monitoring	SLA reports

Article 28 relevance: Cloud providers are critical ICT third-party service providers.

6. Secrets Management

Typical tools: HashiCorp Vault, Cloud-native secret managers, CI/CD secret stores

Controls enforced	Evidence produced
Centralized secrets storage	Secret inventory
Access restriction	Access logs
Secret rotation	Rotation records
Prevention of hard-coded secrets	Scan reports
Auditability	Secret access trails

Article 28 relevance: Controls access to sensitive data managed by third-party platforms.

7. Monitoring, Logging & SIEM

Typical tools: Splunk, Elastic, Datadog, Cloud-native logging

Controls enforced	Evidence produced
Centralized log collection	Log ingestion records
Monitoring of third-party services	Dashboards
Alerting on incidents	Alert logs
Incident correlation	Incident tickets
Evidence retention	Retention policies

Article 28 relevance: Supports continuous monitoring and incident evidence obligations.

8. Identity & Access Management (IAM)

Typical tools: Enterprise IAM, Cloud IAM, SSO platforms

Controls enforced	Evidence produced
Centralized identity management	User inventories
MFA enforcement	Authentication logs
Role separation	Role definitions
Access reviews	Review records
Access revocation	Offboarding logs

Article 28 relevance: Ensures controlled access to third-party ICT platforms.

9. Governance & Risk Management Platforms

Typical tools: GRC platforms, CMDB, Risk registers

Controls enforced	Evidence produced
Supplier inventory	Supplier registers
Risk assessments	Risk reports
Criticality classification	Classification records
Control ownership	RACI documentation
Audit preparation	Evidence repositories

Article 28 relevance: Provides governance backbone for third-party ICT risk management.

End-to-End View

Under DORA Article 28:

• Tools do not equal compliance.
• Controls create compliance.
• Evidence proves compliance.

Tools are acceptable only if they enforce controls and generate verifiable evidence.

How Auditors Use This Mapping

Auditors typically:

1. Start from Article 28 requirements (obligation mapping).
2. Identify the ICT third-party provider and its tooling category.
3. Verify that controls exist and operate through tooling.
4. Request direct evidence outputs for each control.
5. Validate consistency over time.

Any missing link between obligation → control → evidence, or between tool → control → evidence, is a potential finding. 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 — regardless of which tooling is used.

This dual mapping (by obligation and by tool) provides the backbone for:

• audit preparation,
• continuous compliance,
• CI/CD governance in regulated environments.

A DORA-aligned CI/CD environment is one where every third-party tool is governed, every control is enforced technically, and every control produces evidence automatically.

---

Recommended Related Content

• DORA Article 28 — Evidence Pack (Auditor & Engineer Views)
• DORA Article 28 — Auditor Checklist (Yes / No / Evidence)
• DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
• Continuous Compliance via CI/CD Pipelines

---

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.