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, why they matter, and how auditors interpret them.
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.
Red flags in this area are therefore treated as high-severity findings.
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.”
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.
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.
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.
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.
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.
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.
Addressing these issues early 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
