DORA Article 28 — Auditor Checklist (Engineer & Auditor Perspectives)

Introduction

This checklist is designed for formal audit reviews of ICT third-party risk management under DORA Article 28. It serves two audiences simultaneously:

• Auditors use it to verify controls, assess evidence, and identify gaps.
• Engineers use it to understand what must be implemented and where common gaps occur.

Each section covers a specific Article 28 domain with: the formal audit checklist (Yes / No / Evidence), the corresponding engineer implementation expectations, and the common gaps that typically surface during audits.

1. ICT Third-Party Inventory

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Complete inventory of ICT third-party providers	CMDB or supplier registry including CI/CD, Git, cloud, registries
Supplier classification by criticality	Criticality tags linked to delivery systems
Alignment with business services	Mapping pipelines → services → suppliers
Inventory kept up to date	Automated or process-driven updates tied to tooling usage

Common gap: CI/CD SaaS tools not listed as suppliers.

2. Criticality Classification

Audit Checklist

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

Audit Checklist

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

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Audit rights defined in contracts	Platforms capable of read-only audit access
Incident notification obligations	Monitoring and alerting pipelines connected to incident workflows
Evidence retention commitments	Log and artifact retention configured to meet contract duration
Subprocessor visibility	Documented SaaS dependency chains

Common gap: Contracts exist but tooling cannot technically support audits.

5. Access Control & Segregation of Duties

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Role separation enforced	IAM roles for dev, approver, operator
No single-user end-to-end control	Branch protection + approval workflows
Access reviews performed	Periodic access reviews supported by logs
Least privilege applied	Token scopes, runner permissions, environment separation

Common gap: Admin access shared across CI/CD roles.

6. CI/CD Enforcement Controls

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Controls enforced automatically	Policy-as-code in pipelines
No bypass of approvals	Mandatory gates for release and deploy
Artifact integrity ensured	SBOM generation, signing, verification
Third-party tools governed	Approved runner images, restricted plugins

Common gap: Controls enforced “by convention”, not technically.

7. Monitoring & Incident Management

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Continuous monitoring of suppliers	CI/CD, registry, cloud logs collected
Incident detection capability	Alerts tied to third-party services
Incident traceability	Tickets linked to logs, pipelines, artifacts
Evidence of past incidents	Retained logs, timelines, RCA documentation

Common gap: Logs exist but are not centralized or retained.

8. Subprocessor Governance

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Visibility into subprocessors	Documentation of SaaS dependencies
Awareness of data flows	Architecture diagrams showing third-party paths
Risk awareness	Risk assessment referencing real dependencies

Common gap: “Hidden” subprocessors inside CI/CD platforms.

9. Exit Strategy & Resilience

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Documented exit strategy	Alternative tooling identified
Exit feasibility	Artifact portability, IaC reproducibility
Exit testing evidence	DR / exit tests executed and logged
No single-vendor dependency	Reduced coupling to SaaS-specific features

Common gap: Exit plan exists only as a document.

10. Evidence Management & Retention

Audit Checklist

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

Engineer Implementation

Auditor checks	Engineer implements
Evidence is objective	Logs, approvals, SBOMs generated automatically
Evidence is time-bound	Timestamped and immutable records
Evidence is accessible	Centralized storage, controlled access
Evidence is consistent	Same controls across environments

Common gap: Evidence collected manually “just before audit”.

---

Auditor Conclusion

Assessment	Result
Overall Article 28 compliance	☐ Compliant ☐ Partially Compliant ☐ Non-Compliant
Major findings identified	☐ Yes ☐ No
Remediation plan required	☐ Yes ☐ No

Key Principles

Auditor Reality Check

Auditors do not validate intentions, explanations, or architecture slides alone. They validate: controls in operation, evidence produced by systems, and consistency over time.

Under DORA Article 28, absence of evidence is evidence of absence. Controls must be operational, repeatable, and provable.

Engineer Reality Check

Engineers succeed when: compliance is designed into CI/CD, controls generate evidence continuously, and audits become verification — not reconstruction.

Recommended Related Content

• DORA Article 28 — Evidence Pack (Auditor & Engineer Views)
• DORA Article 28 — Controls & Evidence Mapping
• 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.