This checklist is designed for formal audit reviews of ICT third-party risk management under DORA Article 28.
Each control must be objectively verifiable through evidence.
1. ICT Third-Party Inventory
| Control | Yes | No | Evidence |
|---|
| A complete inventory of ICT third-party providers exists | ☐ | ☐ | Supplier register |
| CI/CD platforms are included as ICT providers | ☐ | ☐ | Supplier inventory extract |
| Cloud service providers are included | ☐ | ☐ | Supplier inventory |
| Artifact registries and package ecosystems are listed | ☐ | ☐ | Supplier mapping |
| Inventory is reviewed and updated periodically | ☐ | ☐ | Review records |
2. Criticality Classification
| Control | Yes | No | Evidence |
|---|
| ICT providers are classified by criticality | ☐ | ☐ | Classification methodology |
| Classification criteria are documented | ☐ | ☐ | Risk framework |
| Critical providers are explicitly identified | ☐ | ☐ | Supplier list |
| CI/CD tooling supporting critical functions is classified accordingly | ☐ | ☐ | Mapping document |
| Classification impacts governance requirements | ☐ | ☐ | Control mapping |
3. Pre-Contract Due Diligence
| Control | Yes | No | Evidence |
|---|
| Security due diligence is performed before onboarding | ☐ | ☐ | Due diligence reports |
| Risk assessment covers ICT and operational risks | ☐ | ☐ | Risk assessment |
| Subprocessor usage is assessed | ☐ | ☐ | Supplier disclosures |
| Due diligence results are documented | ☐ | ☐ | Review records |
| Approval is required before onboarding | ☐ | ☐ | Approval workflow |
4. Contractual Safeguards
| Control | Yes | No | Evidence |
|---|
| Contracts include information security requirements | ☐ | ☐ | Contract clauses |
| Audit and inspection rights are defined | ☐ | ☐ | Contract extracts |
| Incident notification obligations are defined | ☐ | ☐ | SLA clauses |
| Evidence retention requirements are included | ☐ | ☐ | Contract terms |
| Exit and termination clauses are defined | ☐ | ☐ | Contract clauses |
5. Access Control & Segregation of Duties
| Control | Yes | No | Evidence |
|---|
| Access to third-party platforms is role-based | ☐ | ☐ | IAM configuration |
| Segregation of duties is enforced | ☐ | ☐ | Access matrix |
| Privileged access is restricted and monitored | ☐ | ☐ | Access logs |
| Access reviews are performed periodically | ☐ | ☐ | Review records |
| Access revocation is documented | ☐ | ☐ | Offboarding records |
6. CI/CD Enforcement Controls
| Control | Yes | No | Evidence |
|---|
| CI/CD pipelines enforce approval gates | ☐ | ☐ | Pipeline configuration |
| Security controls cannot be bypassed | ☐ | ☐ | Policy definitions |
| Third-party CI/CD runners are governed | ☐ | ☐ | Runner configuration |
| Artifact integrity is protected | ☐ | ☐ | SBOM / signing reports |
| Pipeline changes are logged | ☐ | ☐ | Audit logs |
7. Monitoring & Incident Management
| Control | Yes | No | Evidence |
|---|
| Third-party services are continuously monitored | ☐ | ☐ | Monitoring dashboards |
| Security incidents are detected | ☐ | ☐ | Alert logs |
| Incidents involving ICT providers are tracked | ☐ | ☐ | Incident tickets |
| Incident notification timelines are respected | ☐ | ☐ | Incident records |
| Incident post-mortems are documented | ☐ | ☐ | RCA reports |
8. Subprocessor Governance
| Control | Yes | No | Evidence |
|---|
| Visibility into subcontractors exists | ☐ | ☐ | Supplier disclosures |
| Subprocessors are approved | ☐ | ☐ | Approval records |
| Subprocessor risks are assessed | ☐ | ☐ | Risk assessments |
| Changes in subprocessors are monitored | ☐ | ☐ | Change notifications |
9. Exit Strategy & Resilience
| Control | Yes | No | Evidence |
|---|
| Exit strategies exist for critical providers | ☐ | ☐ | Exit plans |
| Exit strategies are documented | ☐ | ☐ | Documentation |
| Exit feasibility has been assessed | ☐ | ☐ | Assessment reports |
| Exit or fallback tests have been performed | ☐ | ☐ | Test reports |
| Exit strategies are reviewed periodically | ☐ | ☐ | Review records |
10. Evidence Management
| Control | Yes | No | Evidence |
|---|
| Evidence is centrally stored | ☐ | ☐ | Evidence repository |
| Evidence is time-stamped and immutable | ☐ | ☐ | Log configuration |
| Evidence retention meets regulatory needs | ☐ | ☐ | Retention policies |
| Evidence access is controlled | ☐ | ☐ | Access logs |
| Evidence can be produced on request | ☐ | ☐ | Audit extracts |
Auditor Conclusion
| Assessment | Result |
|---|
| Overall Article 28 compliance | ☐ Compliant ☐ Partially Compliant ☐ Non-Compliant |
| Major findings identified | ☐ Yes ☐ No |
| Remediation plan required | ☐ Yes ☐ No |
Key Audit Principle
Under DORA Article 28, absence of evidence is evidence of absence.
Controls must be operational, repeatable, and provable.
Recommanded Internal Links
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.
