DORA Article 28 requires financial entities to manage ICT third-party risk in a way that is verifiable, enforceable, and auditable.
However, auditors and engineers do not read architectures the same way.
This section presents the same CI/CD architecture, viewed through two different lenses:
- the Auditor View, focused on governance, risk, and evidence
- the Engineer View, focused on implementation, automation, and control enforcement
Understanding both perspectives is essential to avoid compliance gaps and audit friction.
Auditor View (Governance & Evidence Lens)
What the auditor is looking for
An auditor reviewing DORA Article 28 compliance is not assessing tools or pipelines directly.
They are verifying that risk is controlled, documented, and continuously managed.
From an auditor’s perspective, the architecture must answer the following questions:
- Do you have a complete inventory of ICT third-party providers?
- Are providers classified by criticality?
- Are security and audit requirements enforceable by contract?
- Can you demonstrate ongoing monitoring, not just annual reviews?
- Can you produce evidence, not explanations?
- Do you have a realistic exit strategy, and has it been tested?
How auditors read the architecture
In the DORA Article 28 architecture diagram, auditors focus on:
- The boundary between internal delivery and third-party providers
- The presence of cross-cutting controls:
- supplier inventory & tiering
- contract clauses & audit rights
- monitoring & incident reporting
- evidence retention
- exit strategy
- The evidence outputs, not the technical flow
For auditors, the CI/CD pipeline is primarily:
a risk surface that must be governed and evidenced.
They are less interested in how controls are implemented than in whether controls exist, apply to third parties, and leave traceable proof.
Engineer View (Implementation & Control Lens)
What engineers are focused on
Engineers implementing CI/CD and DevSecOps controls approach the same architecture differently.
Their questions are typically:
- Where do I enforce controls automatically?
- How do I limit access and privileges?
- How do I prevent unauthorized changes?
- Where are security gates executed?
- How do I generate evidence without manual work?
- How do I avoid breaking delivery speed?
How engineers read the architecture
In the same diagram, engineers focus on:
- Control placement inside the pipeline:
- SAST enforcement in CI
- SBOM generation during build
- signing and provenance
- security gates before release
- Integration points with third-party platforms:
- Git access controls
- CI/CD runner isolation
- registry trust boundaries
- cloud runtime monitoring
- Automation and repeatability
For engineers, the CI/CD pipeline is primarily:
a control plane that must enforce policy by design.
Evidence is a by-product of correct implementation, not a separate activity.
Same Architecture, Two Readings
The key point is that both views rely on the same architecture.
| Aspect | Auditor View | Engineer View |
|---|---|---|
| Focus | Risk, governance, compliance | Automation, enforcement, reliability |
| Primary question | “Can you prove control?” | “Where do I enforce control?” |
| CI/CD pipeline | Risk surface | Control plane |
| Third-party providers | Suppliers to govern | Platforms to integrate securely |
| Evidence | Explicit requirement | Automatic output |
| Exit strategy | Mandatory | Often overlooked |
DORA Article 28 requires both perspectives to be satisfied simultaneously.
Why This Distinction Matters Under DORA
Many organizations fail DORA Article 28 reviews not because controls are missing, but because:
- engineers implemented controls without contractual backing
- evidence exists but is not clearly attributable
- exit strategies exist only on paper
- third-party dependencies are implicitly trusted
By explicitly separating Auditor View and Engineer View, you ensure that:
- governance expectations are met
- implementation aligns with regulatory intent
- audits become predictable instead of adversarial
How to Use This in Practice
Recommended approach:
- Design architecture once
- Validate it against:
- Auditor questions (Article 28 obligations)
- Engineer constraints (CI/CD reality)
- Ensure every control:
- is enforceable
- produces evidence
- applies to third-party providers
- Use the architecture diagram as:
- a design reference
- an audit conversation tool
- a shared language between teams
Key Takeaway
DORA Article 28 compliance is not about choosing between governance and engineering.
It is about designing architectures that engineers can implement and auditors can verify.
The same CI/CD architecture must satisfy both — by design.
