What to Show, Where to Find It, and Why It Matters
This evidence pack lists the technical and operational artifacts that financial institutions should present to demonstrate compliance with DORA Article 21.
How to Use This Evidence Pack
Use as a checklist during audit preparation
Share with engineering, security, and compliance teams
Attach references to real systems, logs, and repositories
Ensure evidence is current, traceable, and reproducible
Article 21(1) — ICT Risk Management Framework
Evidence to Provide
Evidence Type What Auditors Expect ICT risk register CI/CD pipelines explicitly listed as in-scope ICT systems Threat models CI/CD-related risks (credential abuse, supply chain, integrity) Risk treatment plans Controls mapped to CI/CD pipelines Governance documentation Ownership of CI/CD security and risk
Typical Sources
Risk management tooling
Architecture documentation
Security governance repositories
Article 21(2)(a) — Access Control Evidence to Provide Evidence Type What Auditors Expect IAM policies Least privilege for CI/CD service accounts RBAC configuration Role separation for pipeline administration MFA enforcement Proof MFA is required for privileged users Identity inventory Distinction between human and automation identities
Typical Sources
IAM platform
CI/CD system configuration
Access review reports
Article 21(2)(b) — Segregation of Duties Evidence to Provide Evidence Type What Auditors Expect Code review rules Mandatory peer review enforced Approval workflows Independent approval for production changes Role mapping Separation between build, validation, deploy roles Exception logs Records of overrides and approvals
Typical Sources
Source control platform
CI/CD pipeline definitions
Audit logs
Article 21(2)(c) — Logging and Monitoring Evidence to Provide Evidence Type What Auditors Expect Pipeline execution logs Complete history of runs and outcomes Security event logs Failed checks, blocked releases Monitoring dashboards Visibility into pipeline health Log retention policies Alignment with regulatory requirements
Typical Sources
CI/CD platforms
SIEM / logging systems
Monitoring tools
Article 21(2)(d) — Change Management & Integrity Evidence to Provide Evidence Type What Auditors Expect Deployment records All production changes traceable to pipelines Artifact signing Proof of cryptographic integrity Provenance metadata Source → build → artifact linkage Release approvals Auditable decision points
Typical Sources
Artifact repositories
CI/CD metadata stores
Release management systems
Article 21(2)(e) — Resilience, Backup, and Recovery Evidence to Provide Evidence Type What Auditors Expect CI/CD architecture diagrams Redundancy and isolation Backup procedures Secure backups of pipeline configs Recovery tests Evidence of rollback and recovery exercises Incident playbooks CI/CD-specific response procedures
Typical Sources
Architecture documentation
Backup systems
Incident management tooling
Article 21(2)(f) — Continuous Improvement Evidence to Provide Evidence Type What Auditors Expect Review reports Periodic CI/CD security reviews Change logs Improvements to pipeline controls Metrics & KPIs Security and resilience indicators Management oversight Evidence of governance review
Typical Sources
Security review records
CI/CD change history
Governance meeting notes
Common Audit Pitfalls (What NOT to Show Alone) Auditors will challenge:
High-level policies without technical enforcement
Screenshots without traceability
Manual attestations without system evidence
One-off examples instead of repeatable controls
Evidence must be system-generated, timestamped, and reproducible .
Auditor-Friendly Packaging Tips
Group evidence by Article 21 subsection
Provide read-only access to logs and dashboards
Include sample evidence + explanation
Clearly indicate control owners
Avoid overloading auditors with irrelevant data
🔗 Related Resources
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.
