What to Show Auditors (CI/CD, Vendors, Software Supply Chain)
Supply chain security is one of the most scrutinized areas under the NIS2 Directive. Auditors and supervisory authorities are not looking for theoretical risk statements — they expect concrete, system-generated evidence showing how supplier-related cybersecurity risks are identified, controlled, monitored, and addressed.
This article provides a practical NIS2 supply chain evidence pack, outlining what auditors typically ask for and what organizations should be able to demonstrate in practice, particularly in environments relying on CI/CD pipelines and third-party services.
It covers both cross-sector expectations and sector-specific considerations for financial institutions and public sector entities.
Purpose of This Evidence Pack
The goal of this evidence pack is to:
- structure audit preparation around facts and proof,
- avoid improvisation during supervisory reviews,
- align supplier governance with CI/CD enforcement,
- demonstrate compliance with NIS2 cybersecurity risk-management measures.
This pack focuses on evidence, not tools or policies in isolation.
Scope of the Supply Chain Under NIS2
Under NIS2, the supply chain typically includes:
- software vendors supporting critical business or public services,
- CI/CD platforms and developer tooling,
- cloud and infrastructure service providers,
- managed security and monitoring services,
- outsourced development or maintenance partners,
- artifact registries and package ecosystems.
Auditors expect this scope to be explicitly documented and aligned with ICT risk management frameworks.
Sector-Specific Scope Considerations
Financial institutions must also account for: inter-institutional dependencies, concentration risk across shared providers, and alignment with financial sector regulatory expectations (e.g., DORA overlap).
Public sector entities must also account for: inter-agency or shared service providers, national procurement frameworks, and data sovereignty requirements.
1. Supplier Identification and Criticality Classification
What auditors typically ask
How do you identify suppliers and assess supply chain cybersecurity risks?
Evidence to provide
- A maintained supplier inventory including software vendors, SaaS providers, CI/CD platforms, cloud and infrastructure services.
- Supplier criticality classification (critical / important / non-critical).
- Risk assessment criteria based on: business impact, access level, data sensitivity, operational dependency, and substitutability.
- Clear designation of supplier ownership within the organization.
Expected evidence examples
- Supplier register or inventory export with criticality clearly marked
- Risk scoring or tiering methodology
- Mapping of suppliers to supported services or systems
Sector notes
Finance: Lack of clear criticality classification is a frequent high-severity finding in financial audits. Concentration risk must also be assessed.
Public sector: Unclear supplier accountability and ownership is a frequent audit finding. Supplier governance processes must be documented even when services are shared across multiple entities.
2. Supplier Security Requirements and Contractual Controls
What auditors typically ask
How are cybersecurity requirements enforced on suppliers?
Evidence to provide
- Security requirements integrated into procurement processes.
- Contractual clauses covering: cybersecurity obligations, incident notification timelines, right to audit or assurance, and continuity of service.
- Defined minimum security expectations for critical suppliers.
Expected evidence examples
- Contract extracts (security-related sections only)
- Supplier security addenda
- Procurement or vendor onboarding checklists
Auditors generally do not require full contracts — targeted extracts are sufficient. They focus on consistency and enforceability, not legal detail.
Sector notes
Finance: Contractual alignment with financial sector regulatory expectations is expected where applicable.
Public sector: Auditors understand procurement constraints but expect consistency and traceability. Alignment with national procurement and regulatory frameworks is assessed.
3. CI/CD Controls Supporting Supply Chain Security
What auditors typically ask
How do CI/CD pipelines reduce supply chain risk?
Evidence to provide
- CI/CD pipelines enforcing: protected branches and code review, restricted pipeline modification access, secrets management controls.
- Mandatory use of CI/CD pipelines for all production changes.
- Strong access control (RBAC, MFA) on CI/CD platforms.
- Segregation of duties enforced through approval workflows.
- Dependency scanning (SCA) integrated into pipelines.
- Policy enforcement blocking builds or deployments on critical risk.
Expected evidence examples
- CI/CD pipeline definitions (YAML or configuration exports)
- Example of a failed pipeline due to dependency or policy violation
- Approval and deployment logs
- Access control configuration screenshots
Sector notes
Finance: CI/CD pipelines are treated as regulated ICT systems, not developer tooling. Auditors often request end-to-end traceability demonstrations during reviews.
Public sector: CI/CD pipelines are assessed primarily as change management and traceability mechanisms. Auditors are generally less focused on tool sophistication than on enforcement. Emergency changes must still be traceable.
4. Dependency and Artifact Integrity
What auditors typically ask
How do you know that deployed software has not been tampered with?
Evidence to provide
- Software Bill of Materials (SBOM) for critical releases.
- Provenance linking: source code → build execution → generated artifact → production deployment.
- Artifact integrity controls (signing, verification, trusted registries).
- Dependency inventories and vulnerability scanning.
- Procedures for handling critical vulnerabilities in third-party components.
Expected evidence examples
- SBOM files for representative releases
- Artifact repository metadata
- Deployment trace showing commit → artifact → production
- Risk acceptance or remediation records
Sector notes
Finance: Inability to demonstrate traceability is often escalated as a material risk.
Public sector: SBOMs are increasingly expected for critical public services but may be applied proportionately based on technical maturity.
5. Third-Party Access and Privilege Management
What auditors typically ask
Do suppliers or third-party tools have privileged access?
Evidence to provide
- Inventory of third-party and service accounts.
- Least privilege justification for each privileged access.
- Periodic access reviews and recertification.
- Formal approval processes for privileged supplier access.
- Defined access revocation procedures.
Expected evidence examples
- IAM role and permission listings
- Access review reports
- Approval tickets or workflow records
- Revocation or decommissioning evidence
Sector notes
Finance: Over-privileged CI/CD service accounts are a common audit finding.
Public sector: Long-lived supplier accounts without review are a common audit issue.
6. Monitoring and Detection of Supply Chain Events
What auditors typically ask
How do you detect supply chain-related security events?
Evidence to provide
- Monitoring of: CI/CD pipeline activity, dependency vulnerability alerts, anomalous third-party behavior, supplier access events.
- Defined alerting thresholds and escalation paths.
- Integration with SOC or security monitoring functions.
Expected evidence examples
- SIEM or monitoring rules
- Example alerts or investigations related to dependencies or pipeline anomalies
- Incident tickets linked to supplier-related events
Sector notes
Finance: Integration with SOC and security monitoring functions is expected.
Public sector: Auditors focus on awareness and response capability, not necessarily advanced analytics.
7. Incident Response and Supplier Coordination
What auditors typically ask
What happens if a supplier is compromised?
Evidence to provide
- Incident response playbooks covering: compromised dependencies, compromised CI/CD components, supplier security incidents.
- Revocation and containment procedures.
- Supplier escalation and communication paths.
Expected evidence examples
- Incident response playbook excerpts
- Tabletop exercise or test records
- Post-incident review reports (if applicable)
Sector notes
Finance: Supervisors assess both preparedness and execution capability.
Public sector: Coordination mechanisms with internal stakeholders, other public entities, and national authorities (where applicable) are assessed. Preparedness and clarity of roles are key criteria.
8. Evidence Retention and Auditability
What auditors typically ask
Can you retrieve historical supply chain evidence?
Evidence to provide
- Defined retention periods for: CI/CD logs, security scan results, supplier-related records, deployment records.
- Centralized and protected evidence storage.
- Demonstrated retrieval capability.
Expected evidence examples
- Retention policy documentation
- Logging platform retention configuration
- Example historical log or report retrieval
Sector notes
Public sector: Long-term traceability is particularly important due to procurement and accountability requirements.
Common Audit Findings
Auditors frequently identify issues such as:
- incomplete supplier inventories,
- lack of supplier criticality classification,
- CI/CD pipelines with excessive privileges or excluded from ICT risk scope,
- insufficient evidence retention,
- undocumented supplier exceptions,
- informal supplier risk acceptance,
- CI/CD pipelines bypassed for urgent fixes (public sector),
- weak documentation of supplier incidents.
Addressing these gaps proactively significantly reduces NIS2 compliance risk.
Finance-Specific Findings
- CI/CD platforms excluded from ICT risk scope
- Excessive privileges in automation accounts
- Unclear criticality classification for shared infrastructure
Public Sector-Specific Findings
- Unclear supplier accountability
- Informal risk acceptance without documentation
- Insufficient evidence retention for long audit cycles
Conclusion
NIS2 supply chain compliance is not achieved through documentation alone. It requires operational enforcement, technical controls, and continuous evidence generation across suppliers, CI/CD pipelines, and production systems.
Organizations that treat CI/CD pipelines as enforcement points for supply chain security — and maintain structured, retrievable evidence — are best positioned to meet NIS2 supervisory expectations with confidence.
This applies across sectors: financial institutions must demonstrate systemic risk control and regulatory alignment, while public sector entities must demonstrate governance, accountability, and proportionate controls adapted to their operational constraints.
Related Content
- NIS2 Security Architecture — Explained
- NIS2 Supply Chain Security Deep Dive
- Supplier Governance & CI/CD Controls Checklist
- How Auditors Actually Review CI/CD Pipelines
