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.
