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 | ☐ | ☐ |
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.
