Why This Split Matters
One of the most common causes of friction during DORA Article 28 audits is a mismatch of expectations.
- Auditors think in terms of control objectives, evidence, and accountability.
- Engineers think in terms of systems, pipelines, configurations, and automation.
Both views are valid — but they are not interchangeable.
This article bridges that gap by showing:
- what auditors are actually trying to verify,
- how engineers should implement controls to satisfy those expectations,
- and where misunderstandings typically occur.
High-Level Perspective
| Perspective | Focus |
|---|---|
| Auditor View | Can this organization demonstrate effective third-party ICT risk control? |
| Engineer View | How do we enforce and generate evidence through CI/CD and cloud systems? |
1. Supplier Inventory & Criticality
Auditor View
Auditors ask:
- Do you have a complete inventory of ICT third-party providers?
- Are providers classified by criticality?
- Is this classification tied to business services and delivery systems?
What they verify:
- inventory completeness,
- consistency with actual systems in use,
- traceability to risk management decisions.
Engineer View
Engineers must ensure:
- CI/CD platforms, Git hosting, registries, runners, cloud services are explicitly registered as suppliers,
- supplier metadata (criticality, owner, usage) is kept in sync with real usage,
- pipelines reference approved suppliers only.
Typical implementation:
- CMDB or supplier registry linked to CI/CD tooling,
- automated checks preventing unapproved services,
- documentation generated from live configurations.
2. Contractual Controls & Audit Rights
Auditor View
Auditors look for:
- enforceable audit rights,
- incident notification obligations,
- evidence retention commitments,
- visibility over subprocessors,
- defined exit clauses.
They do not assume contracts are effective just because they exist.
Engineer View
Engineers must:
- know which contractual obligations impact technical controls,
- ensure platforms can actually produce the required evidence,
- support audits without ad-hoc data collection.
Typical implementation:
- mapping contract clauses → technical controls,
- ensuring logs, SBOMs, approvals are retained long enough,
- making audit access technically possible (read-only, scoped).
3. CI/CD & Cloud Control Enforcement
Auditor View
Auditors want proof that:
- access is controlled and segregated,
- approvals are enforced,
- artifacts are protected against tampering,
- third-party tooling does not bypass internal controls.
They test whether controls are systematic, not manual.
Engineer View
Engineers implement:
- IAM, role separation, branch protections,
- pipeline approvals and policy gates,
- SBOM generation and artifact signing,
- runner isolation and token scoping.
Key mindset shift:
“Secure by default” is not enough — controls must be provable.
4. Monitoring & Incident Management
Auditor View
Auditors assess whether:
- third-party services are continuously monitored,
- incidents involving suppliers are detectable,
- incident handling is documented and traceable.
They reject:
- annual risk assessments without operational monitoring.
Engineer View
Engineers ensure:
- CI/CD platforms, registries, and cloud runtimes emit logs,
- monitoring feeds SIEM or centralized logging,
- incidents reference affected third-party providers.
Typical implementation:
- observability pipelines,
- incident tickets linked to logs and metrics,
- alerting on supplier degradation or failure.
5. Exit Strategy & Resilience
Auditor View
Auditors ask:
- Do exit strategies exist for critical suppliers?
- Have they been tested?
- Could you realistically exit under pressure?
A PDF exit plan alone is insufficient.
Engineer View
Engineers support exit strategies by:
- avoiding hard vendor lock-in,
- documenting replacement or fallback paths,
- participating in DR and exit tests.
Typical implementation:
- artifact portability,
- infrastructure-as-code reproducibility,
- tested backup and restore procedures.
Common Misalignment Patterns
| Situation | Auditor Reaction |
|---|---|
| “We trust this SaaS provider” | ❌ Not acceptable |
| Evidence collected manually before audit | ⚠️ Weak control |
| Logs exist but are not retained | ❌ Non-compliant |
| Exit plan never tested | ❌ High-risk finding |
Designing for Both Views
The most mature organizations:
- design controls once,
- satisfy both audit and engineering needs,
- generate evidence continuously via CI/CD and cloud platforms.
This is the foundation of continuous compliance under DORA.
Final Takeaway
DORA Article 28 compliance fails when:
- auditors expect evidence,
- and engineers provide explanations.
It succeeds when:
- engineers design systems that produce evidence by default,
- and auditors can verify controls without interpretation.
Recommended Related Reading
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 Architecture — Explained
- Continuous Compliance via CI/CD Pipelines
- CI/CD Audit Red Flags
