Compliance mapping for GitHub Actions

Last reviewed: 15 October 2026

Supports, doesn’t certify. A guide, not legal or audit advice. Using SecureCI doesn’t make you compliant or certified; your assessor, auditor or regulator decides. Full terms →

Every uses: line in your workflows runs someone else’s code in your pipeline, and auditors increasingly ask how you control it. The SecureCI GitHub Action turns your pipeline standards into a required check and leaves evidence you can show an assessor.

Short answer:

Supply-chain inventory: every third-party action, locked to a commit SHA, with drift caught on each pull request.
Change control for pipelines: workflows that drop a required step or use an unpinned or unapproved action can’t merge.
Evidence by default: your contract, secureci.lock and its history, and a report for every run.

What it supports

Strong fit Strong fitSupports Supports

PCI DSS v4.0.1 — Requirement 6

Requirement	How SecureCI helps	Fit
6.3.2 — inventory of software and its third-party components	Lockfile inventory of every action, resolved to commit SHAs	Strong fit
6.2.1 — secure development	Required security steps enforced in every pipeline	Supports
6.5.1 — change control	A required check on every pipeline change	Supports

DORA — RTS on ICT risk management (EU) 2024/1774

For EU financial entities.

Article	How SecureCI helps	Fit
Art. 16(1)(c) — protection against manipulation during development and deployment	SHA pinning, approved owners and drift checks	Strong fit
Art. 16(7) — source code integrity	Pipeline dependencies pinned and locked	Supports
Art. 17(1)(a) — security requirements verified on change	Your pipeline standard checked on every change	Supports

NIS2 — Directive (EU) 2022/2555, Article 21(2)

Measure	How SecureCI helps	Fit
(d) supply chain security	Inventory, approved owners, pinning and drift checks	Supports
(e) secure acquisition, development and maintenance	Required security steps in every pipeline	Supports

UK Software Security Code of Practice

Principle	How SecureCI helps	Fit
1.2 — understand software composition and third-party risk	Lockfile inventory of the code your builds run	Strong fit
2.1 — protect the build environment	Only approved, pinned actions run	Supports
2.2 — control and log changes to the build environment	A required check on changes; lockfile history as the log	Strong fit
3.3 — manage vulnerabilities in components	Actions with known security advisories and moved action tags are flagged	Supports

ISO/IEC 27001:2022 — Annex A

Control	How SecureCI helps	Fit
A.5.21 — ICT supply chain security	Inventory, approved owners, pinning and drift checks	Supports
A.8.9 — configuration management	A versioned, enforced baseline for pipelines	Strong fit
A.8.25 — secure development life cycle	Required security steps in every pipeline	Supports
A.8.32 — change management	A required check on every pipeline change	Supports

SOC 2 — Trust Services Criteria

Criterion	How SecureCI helps	Fit
CC8.1 — change management	Checked, recorded pipeline changes	Supports
CC7.1 — detecting configuration changes	Drift alerts when an action changes underneath you	Supports

Add it to your pipeline

One step validates every workflow against your pipeline contract, fails on action drift, and uploads findings to code scanning:

- uses: actions/checkout@v4
- uses: secure-ci/[email protected]
  with:
    contract: contracts/standard.yml
    inventory: check

Commit a pipeline contract and a secureci.lock (npx @secureci/cli inventory), then make the job a required check. One standard for every repository? Point contract at owner/repo/path@sha in a central repository, and each report records the commit that was enforced (details). Keeping the evidence →

What it doesn’t cover

Runner monitoring at runtime, application dependencies and SBOMs, ASV scans and penetration tests, access control, and the policies and records frameworks ask you to keep.

Start with the GitHub Action

Free for public and private repositories. Need this evidence across every repository, with audit export? Org-wide SecureCI is in early access.

Get the GitHub Action → Get early access

FAQ

Does using SecureCI make us PCI DSS, DORA or ISO 27001 compliant?

No. SecureCI supports specific controls with checks and evidence for your GitHub Actions pipelines. Compliance is decided by your assessor, auditor or regulator across your whole environment.

Do GitHub Actions count as third-party software components for PCI DSS 6.3.2?

Actions are third-party code that runs while your software is built and deployed, so many teams include them in their 6.3.2 inventory. Agree the scope with your QSA. secureci.lock gives you that inventory, resolved to commit SHAs.

Is SecureCI an Approved Scanning Vendor (ASV) or a penetration testing tool?

No. ASV scans (PCI DSS 11.3.2) test internet-facing systems, and penetration tests (11.4) are carried out by people. SecureCI checks CI pipeline configuration before it merges; it complements both but replaces neither.

Sources

We checked these on 15 October 2026. Standards change; if something here is out of date, email [email protected] and we’ll fix it.

PCI DSS is a trademark of PCI Security Standards Council, LLC. SOC 2 is a trademark of the AICPA. ISO/IEC 27001 is published by ISO and IEC. SecureCI is not affiliated with or endorsed by any of these bodies. See our terms.