DORA Article 28 failures rarely come from missing policies.
They come from hidden weaknesses in third-party–dependent CI/CD pipelines that surface only during audits or incidents.
Auditors look for red flags — signals that third-party ICT risk is unmanaged, unenforced, or unsupported by evidence.
CI/CD platforms are a frequent source of such findings because they combine external services, privileged execution, and automation.
This article highlights the most common Article 28 red flags related to CI/CD pipelines, explains why they matter and how auditors interpret them, and gives you an audit checklist to test your own pipelines before an assessment.
Why CI/CD Red Flags Matter Under Article 28
Under DORA, third-party risk is not theoretical.
Auditors assess whether a failure at a third-party provider could:
- disrupt critical services,
- compromise system integrity,
- or prevent regulatory obligations from being met.
CI/CD pipelines are often single points of failure in software delivery. They hold privileged credentials, push code into production, and depend on a chain of external providers that most organizations never fully map.
Red flags in this area are therefore treated as high-severity findings. They are read not as isolated technical gaps but as evidence that third-party ICT risk is not being governed to the standard Article 28 expects.
Red Flag #1 — No Exit Plan from CI/CD SaaS Platforms
What auditors observe
Organizations rely heavily on CI/CD SaaS platforms but cannot demonstrate:
- how to migrate pipelines,
- how to retrieve historical logs and artifacts,
- how to maintain continuity if the provider becomes unavailable.
Why this is a red flag
DORA Article 28 explicitly requires exit strategies for critical ICT third-party providers.
An exit plan that exists only on paper — without technical feasibility — is considered insufficient.
Typical auditor conclusion
“The organization is operationally locked-in to a critical ICT provider.”
What good looks like
A credible exit plan names an alternative platform, documents how pipelines and secrets would be rebuilt there, and has been rehearsed at least once so the recovery time is a measured figure rather than an assumption. Exported logs and artifacts are retained in a location the organization controls, independent of the provider.
Red Flag #2 — Shared CI Runners Across Tenants
What auditors observe
CI jobs execute on:
- shared runners,
- multi-tenant infrastructure,
- with limited visibility into isolation controls.
Often, organizations cannot explain:
- how runner isolation is enforced,
- who controls the execution environment,
- whether data leakage is technically prevented.
Why this is a red flag
Shared runners increase:
- confidentiality risk,
- integrity risk,
- lateral movement exposure.
Under Article 28, this raises questions about supplier risk classification and control effectiveness.
What good looks like
Critical pipelines run on dedicated or ephemeral runners whose isolation model is documented and attributable to a named owner. The organization can explain, in plain language, what separates one workload from another and how that separation is verified.
Red Flag #3 — No Visibility on Sub-Processors
What auditors observe
Organizations:
- contract with a primary CI/CD or Git provider,
- but lack visibility into sub-processors (cloud providers, runners, registries, monitoring services).
Supplier inventories often stop at the first level.
Why this is a red flag
DORA Article 28 requires oversight not only of direct providers, but also of critical sub-contracting chains.
Lack of sub-processor visibility indicates:
- incomplete risk assessment,
- insufficient supplier governance.
What good looks like
The supplier inventory extends past the contracting party to the cloud regions, runner fleets, registries, and monitoring services that sit behind it. Material changes to that sub-processor chain are notified to the organization and trigger a review rather than passing unnoticed.
Red Flag #4 — No Audit Rights in CI/CD Contracts
What auditors observe
Contracts with CI/CD or Git SaaS providers:
- lack audit or inspection clauses,
- or contain audit rights that are practically unusable.
In some cases, engineering teams are unaware of contractual limitations.
Why this is a red flag
Without audit rights:
- controls cannot be independently verified,
- reliance on supplier assurances becomes unavoidable.
Auditors treat this as a structural compliance gap, not a procedural oversight.
What good looks like
Contracts grant audit or inspection rights that the organization can actually exercise, or provide an accepted equivalent such as pooled audits or independent assurance reports. Engineering and procurement share a common view of what the contract permits, so technical reliance never outruns the contractual right to verify it.
Red Flag #5 — No Evidence Retention for CI/CD Activities
What auditors observe
CI/CD platforms generate logs, approvals, and execution traces, but:
- logs are retained for short periods,
- evidence is overwritten or inaccessible,
- retention policies are undefined.
Evidence is often collected after audit notification, not continuously.
Why this is a red flag
DORA Article 28 is evidence-driven.
If evidence cannot be produced on demand, controls are considered ineffective.
This red flag frequently results in:
- audit observations,
- remediation plans,
- follow-up reviews.
What good looks like
Logs, approvals, and execution traces are exported to an independent, tamper-resistant store with a defined retention period aligned to the organization’s obligations. Evidence is generated as a by-product of the pipeline running, so it is already in place when an auditor asks — not assembled in response to the request.
Additional CI/CD Red Flags Auditors Commonly Identify
- Unrestricted use of CI/CD marketplace plugins
- No approval gates for pipeline changes
- Secrets exposed to third-party execution contexts
- No monitoring of CI/CD platform availability
- Inconsistent control enforcement across pipelines
Each of these points weakens confidence in third-party risk management.
How Auditors Use Red Flags
Red flags are rarely evaluated in isolation.
Auditors look for patterns:
- multiple red flags around the same provider,
- gaps between contracts and technical enforcement,
- missing links between controls and evidence.
When patterns emerge, auditors may:
- escalate supplier criticality,
- expand audit scope,
- request remediation within strict timelines.
How to Address These Red Flags Proactively
Organizations that perform well under Article 28 typically:
- explicitly scope CI/CD platforms as ICT third parties,
- enforce controls through pipeline configuration,
- align contracts with technical reality,
- generate continuous, immutable evidence.
Most importantly, they treat CI/CD security as part of third-party risk governance, not just DevOps tooling.
Mapping Red Flags to Article 28 Obligations
Each red flag above maps back to a specific expectation in DORA Article 28, which is why auditors weigh them so heavily.
The absence of an exit plan speaks to the requirement to maintain exit strategies for critical ICT providers. Shared runners and undocumented isolation speak to control effectiveness and to the accurate classification of supplier criticality. Missing sub-processor visibility speaks to oversight of sub-contracting chains, and missing audit rights to the ability to verify controls independently rather than on trust. Weak evidence retention undermines the whole framework, because a control that cannot be demonstrated on demand is, for audit purposes, a control that does not exist.
Seen this way, the red flags are not five unrelated technical issues. They are five different ways the same governance gap becomes visible — the distance between what the organization believes it controls and what it can actually prove.
Audit Checklist for CI/CD Third-Party Red Flags
The red flags above describe how individual failures appear during an assessment. The checklist below turns them into a repeatable review you can run before an audit, after onboarding a new CI/CD provider, or during a periodic third-party risk review.
Each ticked box corresponds to a situation frequently identified as a third-party ICT risk failure. Where one or more items apply, auditors may classify the CI/CD platform or supplier as high-risk or non-compliant.
Governance & Exit Strategy
- ⬜ No documented exit plan for CI/CD SaaS platforms
- ⬜ Exit plan exists but has never been tested technically
- ⬜ No ability to export historical CI/CD logs and artifacts
- ⬜ Pipelines cannot be redeployed on an alternative platform
CI/CD Infrastructure & Isolation
- ⬜ CI jobs run on shared or multi-tenant runners without clear isolation guarantees
- ⬜ Runner isolation mechanisms are undocumented or unknown
- ⬜ CI execution environment is controlled entirely by the provider
- ⬜ Secrets are exposed to third-party execution contexts
Supplier & Sub-Processor Visibility
- ⬜ CI/CD SaaS provider is not listed in the ICT third-party inventory
- ⬜ Sub-processors (cloud, runners, registries) are not identified
- ⬜ No risk classification for CI/CD-related third parties
- ⬜ Supplier criticality does not influence applied controls
Contractual & Legal Controls
- ⬜ CI/CD contracts do not include audit or inspection rights
- ⬜ Audit rights exist but are not practically enforceable
- ⬜ No contractual incident notification SLA
- ⬜ Exit and termination clauses are missing or unclear
Evidence & Auditability
- ⬜ CI/CD logs are retained for a short or undefined period
- ⬜ Approval and change records are not traceable
- ⬜ Artifact metadata and provenance are missing
- ⬜ Evidence is collected manually only during audits
CI/CD Governance & Policy Enforcement
- ⬜ No approval gates for pipeline changes
- ⬜ Unrestricted use of marketplace plugins or actions
- ⬜ No version pinning or review for third-party CI/CD components
- ⬜ Controls vary across pipelines without justification
Auditor-Style Checklist (Yes / No)
| Checkpoint | Yes | No |
|---|---|---|
| CI/CD platforms are included in the ICT third-party inventory | ⬜ | ⬜ |
| CI/CD suppliers are risk-classified | ⬜ | ⬜ |
| Exit strategies exist and are technically feasible | ⬜ | ⬜ |
| CI runners are isolated and controlled | ⬜ | ⬜ |
| Sub-processors are identified and governed | ⬜ | ⬜ |
| Audit rights are contractually defined | ⬜ | ⬜ |
| Incident notification SLAs are in place | ⬜ | ⬜ |
| CI/CD logs are retained and protected | ⬜ | ⬜ |
| Approvals and policy gates are enforced | ⬜ | ⬜ |
| Evidence can be produced on demand | ⬜ | ⬜ |
Red Flags Explained (Audit Interpretation)
| Red Flag | Why Auditors Care | Expected Control |
|---|---|---|
| No exit plan | Vendor lock-in risk | Tested technical exit strategy |
| Shared runners | Confidentiality & integrity risk | Isolated or dedicated runners |
| No sub-processor visibility | Hidden risk exposure | Full supply chain mapping |
| No audit rights | No independent verification | Enforceable audit clauses |
| No evidence retention | Controls cannot be proven | Automated log retention |
How to Use This Checklist
Auditors do not expect zero risk. They expect risks to be identified, controls to be enforced, and evidence to be available and consistent.
Multiple unchecked items in the same category often result in a high-risk classification, a remediation plan, and follow-up audits. Used internally, the checklist works best when you:
- run it before an audit,
- run it after onboarding a new CI/CD provider,
- include it in third-party risk reviews,
- link it to your CI/CD Security Checklist and Evidence Pack.
Key Takeaway
CI/CD pipelines are among the most common sources of Article 28 audit findings.
Red flags such as:
- lack of exit strategies,
- weak isolation,
- missing audit rights,
- insufficient evidence retention
signal unmanaged third-party risk.
Working through the checklist above early — and closing the gaps it surfaces — transforms CI/CD pipelines from audit liabilities into strong compliance assets.
Related Content
- Third-Party Risk in CI/CD Pipelines under DORA Article 28
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 Architecture: Third-Party Risk Controls Across CI/CD Pipelines
- CI/CD Audit Red Flags
- CI/CD Security Checklist for Enterprises
