Traceability without the Friction
In regulated industries, demonstrating that every deployed change can be traced back to an approved request is not optional. Auditors expect to see a clear chain linking requirements, code authorship, review, testing, and deployment. Too often, teams interpret this as a mandate for heavyweight processes and additional tooling. GitHub offers a different path: building the compliance trail around the pull request, a construct developers already use every day.
Even for organizations not bound by specific regulations, adopting these practices pays off. Teams gain a clearer picture of what shipped and why, which directly aids troubleshooting production incidents and measuring the business impact of changes. A Forrester report found that customers who embedded compliance into their GitHub workflows saved significant time and expense on audit preparation. Standardized, automated workflows also reduce friction between development, operations, and security teams by giving everyone a single source of truth.
| Read more about how you can support developer-enabled compliance in your business. |
What the standards actually ask for
A quick survey of common frameworks shows a consistent set of expectations for change control. All focus on linking deployed changes to an initial request, the author, approval by the right people, and test/build artifacts.
PCI/DSS v4.0 requirement 6.5.1 demands that every change follow a procedure capturing the reason for and description of the change, its security impact, documented approval by authorized parties, and evidence of secure development and security testing. ISO 27001 (A.12.1.2, expanded in A.14.2) similarly calls for formal change management covering the request, evaluation, approval, and implementation, with explicit review and testing to prevent adverse security impacts. The COBIT framework, often used to define internal audit processes, states in BAI06.01 that all requests for change must be evaluated for impact and risk, and that changes must be logged, prioritized, categorized, assessed, authorized, planned, and scheduled.
A crucial caveat: compliance is assessed against your process, not against a vendor’s certificate. A “compliant” tool can be used in a non-compliant way, and vice versa. Also consider whether a standard applies to your systems at all—requirements for protecting PHI or PII apply to deployment targets and data stores, not to source code and work tracking systems, which should never hold such data.
The pull request as the control point
Every standard above hinges on controlling “requests for change.” A pull request is precisely that: a proposal to change committed code. It is the natural locus for discussion, testing, security analysis, approval, and deployment. Auditing around the pull request keeps all controls in one place.
Tracing backwards to planning
Work begins in GitHub Issues, where feature requests, bugs, and requirements are captured and discussed. Link pull requests to one or more issues by referencing them in the description or a commit message; that linkage is then visible in the pull request itself. Teams can manage both issues and pull requests in GitHub Projects, creating tailored views for planning and tracking.
Not every change needs an issue. Minor fixes and typos can be handled directly in a pull request, which—as ISO 27001 A.12.1 implies—contains the request, evaluation (human review plus automated checks), approval, and implementation all in one place. If you prefer to require an issue link, a community-maintained GitHub Action (nearform-actions/github-action-check-linked-issues) can enforce that rule.
Approvals inside the pull request
Both human and automated approval are logged directly in the pull request, making traceability straightforward. Repository owners can enforce required code reviews and use CODEOWNERS to route review requests based on modified files. To support separation of duties, you can require that approving reviewers have not contributed to the pull request.
Automated review covers the testing requirements of COBIT BAI06.01 and PCI DSS 6.5.1. GitHub Actions can run test suites and code scanning, and the results appear in the pull request. Branch protection rules can require these checks to pass before merging.
Tracing forward to deployment
When GitHub Actions deploys a pull request, events are logged to the pull request timeline. Deployments can additionally require review by specific people or teams before running, with that approval recorded in the workflow run.
Linking batched deployments
A single deployment often includes many pull requests. Scripting the retrieval of commit and PR lists via the GitHub API is possible but tedious. A cleaner approach is to use GitHub releases. Associate a git tag with a release, and GitHub can auto-generate notes that list all merged pull requests included, all committers, and a full changelog. A complete REST API allows you to integrate release creation, including those auto-generated notes, into your deployment automation.
Data retention and the audit trail
Building traceability around the pull request means everything has a URL. An auditor with repository access can step through the entire process from a single page. Pull requests and their timeline events are retained for the life of the repository. Checks data (pass/fail status) is kept for 400 days, and GitHub Actions log retention is configurable, also up to 400 days.
For longer retention or off-platform storage, the audit log can be streamed to your own systems. Webhooks can notify internal systems of events, and the GitHub API can retrieve detailed records as needed. This lets you meet any data-retention policy without sacrificing the convenience of a single, URL-addressable source of truth.
Grounding compliance in the pull request gives auditors a complete, navigable record while keeping development teams in their normal workflow—reducing friction for both sides.
