Third-Party ICT Risk Controls for Regulated CI/CD Pipelines
Why this checklist exists
In regulated environments, suppliers are not “external.” They are part of your delivery system.
When third-party services support your SDLC (Git hosting, CI/CD SaaS, artifact registries, cloud runtime, security scanners), auditors expect you to demonstrate:
- Supplier governance (inventory, classification, contracts, exit plans)
- CI/CD technical controls (access isolation, policy enforcement, evidence retention)
- Continuous monitoring and accountability (sub-processors, SLAs, incidents)
This checklist is designed to be used by security, engineering, risk, and audit teams as a shared control baseline.
Scope: suppliers that typically affect CI/CD
Use this checklist for any supplier providing:
- Git hosting (GitHub/GitLab SaaS)
- CI/CD platform (GitHub Actions, GitLab CI SaaS, CircleCI, etc.)
- Runners (hosted runners / shared runners / cloud runners)
- Artifact registries (container / Maven / binary registries)
- Dependency proxies and mirrors
- Cloud runtime / managed Kubernetes / PaaS
- Security tooling SaaS (SAST/DAST/SCA, secret scanning)
- Observability and logging SaaS (SIEM / monitoring)
1) Supplier inventory & ownership
✅ Checklist
- A complete inventory of suppliers used across SDLC/CI/CD exists (including shadow usage).
- Each supplier has a named business owner and technical owner.
- The inventory captures where the supplier sits (Git, CI, registry, runtime, logging).
- Criticality is defined per supplier (impact if unavailable/compromised).
- Supplier data locations and hosting model are documented (EU/US, multi-region, etc.).
- Third-party access paths to your systems are listed (SSO, API tokens, agents, webhooks).
Evidence examples
- Supplier inventory spreadsheet / CMDB entry
- Architecture map showing supplier touchpoints
- Ownership register (RACI)
2) Supplier risk classification
✅ Checklist
- A formal risk classification exists (Critical / High / Medium / Low).
- Risk rating includes confidentiality, integrity, availability, and regulatory impact.
- CI/CD and artifact suppliers are treated as integrity-critical by default.
- Risk rating drives mandatory control requirements (e.g., stronger logging, exit plan).
- Risk rating is reviewed at least annually or upon major change.
Evidence examples
- Risk assessment report / questionnaire
- Third-party risk methodology
- Review timestamps and approvals
3) Contractual baseline (security + auditability)
✅ Checklist
- Contract includes security obligations (baseline controls, vulnerability handling, encryption).
- Contract includes audit rights or equivalent assurance mechanism.
- Contract includes breach/incident notification timelines (including materiality criteria).
- Contract includes sub-processor disclosure obligations.
- Contract includes data retention and deletion requirements.
- Contract includes service continuity expectations (BCP/DR).
- Contract includes exit/transition terms (data export, migration support).
Evidence examples
- Signed contract clauses (security annex)
- Sub-processor register
- Incident notification SLA clause
4) Identity, access, and isolation (technical enforcement)
✅ Checklist
- SSO is enforced for supplier admin consoles where possible.
- MFA is mandatory for privileged accounts.
- Roles are minimal and mapped to job needs (least privilege).
- Access reviews are performed regularly (quarterly for critical suppliers).
- CI/CD runners are isolated (no shared runners for sensitive workloads).
- Secrets are not stored in supplier UIs unless controlled (use vault/injection).
- Third-party tokens are scoped, rotated, and monitored.
Evidence examples
- IAM policy exports / screenshots
- Access review logs
- Runner configuration showing isolation
- Token rotation policy + proof
5) Pipeline policy enforcement (gates that cannot be bypassed)
✅ Checklist
- Mandatory approvals exist for production deployments.
- Policy gates block releases on critical scan failures (SAST/SCA/DAST as applicable).
- Artifact signing is enforced before release promotion.
- SBOM generation is automated for releases.
- Protected branches / merge rules are enforced for regulated repos.
- Exceptions are governed (time-bound, approved, documented).
- Pipeline administrators cannot silently disable controls (tracked changes).
Evidence examples
- CI/CD pipeline config (gates)
- Protected branch configuration
- Release approval records
- Exception register
6) Evidence generation and retention (audit-ready by design)
✅ Checklist
- CI/CD logs are retained for a defined period aligned with requirements.
- Approval events are logged and exportable.
- Security scan results are stored centrally (not only in vendor dashboards).
- Traceability exists: commit → pipeline run → artifact → deployment → production.
- Evidence store is tamper-resistant or access-controlled.
- Audit exports are tested (ability to produce evidence quickly).
Evidence examples
- Evidence retention policy
- SIEM retention settings / archive configuration
- Traceability report (sample release)
- Export test record (“audit drill”)
7) Monitoring, incidents, and supplier accountability
✅ Checklist
- Supplier provides security incident notifications within defined SLA.
- You monitor supplier status/availability and integrate signals into ops workflows.
- CI/CD pipeline anomalies are monitored (unexpected workflows, new tokens, new runners).
- Supplier security advisories are tracked and assessed.
- You maintain an internal incident playbook referencing supplier escalation paths.
- You can correlate pipeline events and supplier events (shared timeline).
Evidence examples
- Monitoring dashboards + alert rules
- Incident response plan with vendor contacts
- Postmortems referencing supplier involvement
- Advisory tracking tickets
8) Sub-processor visibility (supply chain depth)
✅ Checklist
- Supplier provides a current list of sub-processors.
- Changes to sub-processors are notified and reviewed.
- Critical sub-processors are risk assessed.
- Data flows involving sub-processors are understood.
- Contracts include sub-processor obligations (security & notification).
Evidence examples
- Sub-processor list export
- Risk review record
- Data flow diagrams
9) Exit strategy testing (DR & BCP realism)
✅ Checklist
- You have a documented exit plan for each critical CI/CD supplier.
- You can export source code, pipeline definitions, artifacts, logs.
- You have a tested migration path (alternative CI/CD, registry, runner model).
- You conduct exit tests (tabletop + technical drills) at defined intervals.
- RTO/RPO expectations are documented and validated with evidence.
Evidence examples
- Exit plan document
- Export test logs and screenshots
- DR exercise report
- Migration proof-of-concept
Audit Table (Yes / No / Notes)
| Control Area | Check | Yes | No | Notes / Evidence Link |
|---|---|---|---|---|
| Inventory | Supplier inventory complete (SDLC/CI/CD) | ☐ | ☐ | |
| Ownership | Business + technical owner defined | ☐ | ☐ | |
| Classification | Risk tiering applied to CI/CD suppliers | ☐ | ☐ | |
| Contracts | Security obligations in contract | ☐ | ☐ | |
| Contracts | Audit rights / assurance mechanism | ☐ | ☐ | |
| Contracts | Incident notification SLA defined | ☐ | ☐ | |
| Contracts | Exit clauses included | ☐ | ☐ | |
| Access | SSO enforced (where possible) | ☐ | ☐ | |
| Access | MFA mandatory for privileged accounts | ☐ | ☐ | |
| Access | Least privilege roles enforced | ☐ | ☐ | |
| Runners | Runner isolation (no shared runners) | ☐ | ☐ | |
| Secrets | Secrets injected at runtime (vault) | ☐ | ☐ | |
| Policy gates | Mandatory approvals for prod | ☐ | ☐ | |
| Policy gates | Blocking gates on critical findings | ☐ | ☐ | |
| Integrity | Artifact signing enforced | ☐ | ☐ | |
| Integrity | SBOM generated automatically | ☐ | ☐ | |
| Evidence | Logs retained per policy | ☐ | ☐ | |
| Evidence | Approval records exportable | ☐ | ☐ | |
| Evidence | Traceability commit→prod proven | ☐ | ☐ | |
| Monitoring | Supplier + pipeline anomalies monitored | ☐ | ☐ | |
| Sub-processors | Sub-processor visibility + review | ☐ | ☐ | |
| Exit testing | Exit plan tested with evidence | ☐ | ☐ |
The Strict Auditor Version
The checklist above reflects a healthy baseline. A demanding auditor — particularly under DORA, NIS2, or a rigorous ISO 27001 or SOC 2 engagement — goes further: every control must carry a named owner, a specific evidence reference, and a documented decision at the end of the review. This stricter worksheet reorganises the same expectations into an assessment format an auditor can complete in the room, recording an evidence reference against each line rather than accepting a verbal assurance.
Use the Evidence Reference column to point to the exact artifact — a log export, a configuration screenshot, a signed contract clause, or a ticket — that proves the control. A blank reference is treated as a gap, not a pass.
Section A — Governance & Inventory
A strict auditor begins by confirming that the supplier population is fully known and owned. Gaps here undermine every downstream control, because a supplier you have not inventoried cannot be governed, monitored, or exited.
| Control | Yes | No | Evidence Reference |
|---|---|---|---|
| Complete inventory of CI/CD-related suppliers exists | ☐ | ☐ | |
| Supplier criticality classification defined | ☐ | ☐ | |
| Business owner formally assigned | ☐ | ☐ | |
| Technical owner formally assigned | ☐ | ☐ | |
| Annual risk assessment performed | ☐ | ☐ | |
| Sub-processor list documented | ☐ | ☐ |
Section B — Contractual & Regulatory Controls
Beyond technical measures, the contract must grant you enforceable rights. The auditor checks that assurance, breach notification, data-location, and exit obligations are written into the agreement rather than assumed from a vendor’s marketing.
| Control | Yes | No | Evidence Reference |
|---|---|---|---|
| Security obligations included in contract | ☐ | ☐ | |
| Incident notification SLA defined | ☐ | ☐ | |
| Audit rights clause present | ☐ | ☐ | |
| Data location transparency included | ☐ | ☐ | |
| Exit strategy clause contractually defined | ☐ | ☐ |
Section C — Technical CI/CD Enforcement
Here the auditor tests that governance is actually enforced in the pipeline, not merely documented. Each control is expected to be demonstrable in the live configuration.
| Control | Yes | No | Evidence Reference |
|---|---|---|---|
| SSO enforced on CI/CD admin accounts | ☐ | ☐ | |
| MFA mandatory for privileged roles | ☐ | ☐ | |
| Role-based access with least privilege | ☐ | ☐ | |
| Protected branches enforced | ☐ | ☐ | |
| Mandatory production approvals configured | ☐ | ☐ | |
| Policy gates block critical findings | ☐ | ☐ | |
| Artifact signing enforced | ☐ | ☐ | |
| SBOM generation automated | ☐ | ☐ | |
| Runner isolation implemented | ☐ | ☐ |
Section D — Evidence & Retention
The auditor confirms that you can produce evidence on demand and that it is retained long enough to cover the full review period, independent of any single vendor dashboard.
| Control | Yes | No | Evidence Reference |
|---|---|---|---|
| CI/CD logs retained per policy | ☐ | ☐ | |
| Approval logs exportable | ☐ | ☐ | |
| Security scan results archived centrally | ☐ | ☐ | |
| Full traceability commit → artifact → prod | ☐ | ☐ | |
| Evidence retention period documented | ☐ | ☐ |
Section E — Exit Strategy & DR Testing
Finally, the auditor looks for proof that dependence on the supplier has been tested, not just planned — export and migration paths that have actually been exercised and evidenced.
| Control | Yes | No | Evidence Reference |
|---|---|---|---|
| Documented exit plan exists | ☐ | ☐ | |
| Code export tested | ☐ | ☐ | |
| Pipeline config export tested | ☐ | ☐ | |
| Artifact export tested | ☐ | ☐ | |
| DR / migration exercise performed | ☐ | ☐ |
Auditor Decision Block
A demanding review closes with a documented decision rather than an open-ended list of observations. Recording these four lines turns the worksheet into a defensible audit conclusion:
- Overall risk rating: ___
- Critical findings: ___
- Remediation required by: ___
- Follow-up audit date: ___
Technical Implementation Guide
This checklist defines governance expectations.
For a practical engineering implementation guide (GitHub, GitLab, runner isolation, policy gates, artifact signing), see:
👉 Engineer Remediation Guide for CI/CD Supplier Controls
This companion article provides concrete configuration examples and implementation patterns.
