---
title: "ISO 27001 Annex A 8.4: access to source code in practice"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-8-4-access-to-source-code
published: 2023-06-12
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.8.4 Access to source code"
journeyStage: implementation
---

# ISO 27001 Annex A 8.4: access to source code in practice

## Key takeaways

Annex A 8.4 is met by controlling who can change code, not who can read it. Protected branches, a hardened CI/CD toolchain and same-day leaver revocation satisfy auditors and keep developers fast. Managed as configuration, the evidence assembles itself from routine pull-request activity.

- **Scope** — The control covers application code, designs, third-party libraries, build tools and test environments, not only repositories, because anything shaping what reaches production can alter the product.
- **Role tiers** — Broad internal read access is acceptable. Write access follows active project assignment, and organisation admin sits with two or three named people using individual SSO and MFA accounts.
- **Protected trunk** — Block direct pushes to main, require pull-request approval from someone other than the author, dismiss stale approvals, and apply code owners to sensitive paths such as authentication and payments.
- **Audit grading** — Auditors reconcile HR leavers with the member list and sample merged pull requests. No review gate or active leaver accounts grades major; isolated stale items grade minor.

The auditor has the HR leaver list open in one window and your GitHub member list in the other. One name appears in both. ISO 27001 Annex A 8.4 is the control behind that moment. Most engineering teams meet it through configuration, not by locking developers out of code.

This guide is for engineering leads, CISOs and DevSecOps practitioners at UK software firms of 25–250 staff. It covers the role model, protected branches, the build toolchain, leaver revocation, audit sampling, evidence and the automation that assembles it.

## What does ISO 27001:2022 Annex A 8.4 access to source code require?

Annex A 8.4 requires you to manage who can see your code and, far more strictly, who can change it. Reading can be broad inside the company; writing goes through controlled tooling and authorisation, never straight onto the trunk. The scope covers designs, libraries, build tools and test environments, not only application code.

That distinction shrinks the problem. Hiding code from your own engineers buys little, because broad visibility helps review, onboarding and incident response. The effort belongs on the write path, which should track active need and leave a record of every change.

The scope reaches well beyond the repositories your product lives in:

- **Designs and specifications** that describe how the system is built.
- **Third-party libraries** pulled into the build.
- **Development tooling**, including compilers, build systems and test platforms.
- **Infrastructure-as-code and scripts** that shape what runs in production.

This is a preventive control: gating who can alter code stops unauthorised or accidental changes before they exist. It protects confidentiality, because a repository leaks IP and secrets together, and integrity, because nothing should enter the product unreviewed. It also protects availability, since an unreviewed bad merge is a common cause of outages.

For a B2B firm selling into regulated buyers, code integrity is a due-diligence line item. Enterprise security reviews now often ask how you stop one developer, or one compromised developer account, from shipping something unreviewed. An engineer who leaves with access still live is an insider incident waiting to happen.

This ISO 27001 Annex A access to source code control applies your access-control policy (Annex A 5.15) to the development estate. It works alongside secure coding (Annex A 8.28) and change management (Annex A 8.32), which govern what a permitted change must go through.

## How should ISO 27001 access to source code be tiered by role?

Tier access in three levels: broad internal read access, write access limited to people on active projects, and organisation admin held by two or three named people. Every account is individual, behind SSO and MFA, so all activity is attributable and least privilege is technically enforced rather than assumed.

Three tiers cover most engineering organisations:

- **Read, broad.** Engineers can see most repositories. That helps collaboration and review, and restricting it buys little.
- **Write, project-scoped.** Permission follows active project assignment, so a move between teams moves the access with it.
- **Admin, two or three named people.** Organisation admin covers settings, protection rules and membership, so each holder should be accountable by name.

The identity layer makes the tiers real. Put the platform behind your identity provider with SSO and MFA, give every engineer an individual account, and issue personal tokens and SSH keys per person. The [NCSC secure development repository guidance](https://www.ncsc.gov.uk/collection/developers-collection/principles/protect-your-code-repository) states the principle: technically enforce least privilege on who can change the repository, and make all activity attributable.

Attribution is what an auditor tests. When two people share a login, a merge traces to nobody, and a leaver's departure cannot be proven.

Two pitfalls recur:

- **Org-wide write access "because we're collaborative".** Read can be broad. Write should not be.
- **Shared automation credentials with god-mode scope**, unrotated since the seed round. Give each pipeline or integration its own identity, scoped as narrowly as the job allows.

## What does a protected trunk look like in practice?

A protected trunk blocks direct pushes to main and release branches. Every change arrives by pull request, with at least one approval from someone other than the author. Stale approvals are dismissed when new commits land, and code owners sign off on sensitive paths such as authentication, payments and infrastructure.

The rule set an auditor accepts, in the order most teams configure it:

1. **Block direct pushes** to main and release branches, for administrators as well as engineers.
2. **Require a pull request** with at least one approval from someone other than the author.
3. **Dismiss stale approvals** when new commits land, so the approval covers what actually merges.
4. **Assign code owners** to the paths that matter most: authentication, payments and infrastructure.
5. **Require checks to pass** before merge, including tests and any pre-merge security checks.
6. **Switch on secret scanning**, so a hardcoded key is caught before it becomes history you cannot rewrite.

Rules that exist but do not bind are the common failure. Picture admins who can bypass protection, or a teammate who approves seconds after the ping. The settings page looks right, and the merge history says otherwise.

A review rule that an admin can bypass is a suggestion, not a control.

On GitHub or GitLab, this is largely configuration: a few days of effort, best done as one pass with secure coding and change management. Enforced consistently, this single pattern answers most of the questions an auditor asks about your branching model.

## Why does the build toolchain need the same access rigour as the repositories?

CI/CD runners, build servers, artifact registries and test environments can inject code into a release as effectively as a direct push. OWASP calls compromise of the source control system a significant supply-chain risk. NIST SP 800-218 asks you to protect all software components from tampering and unauthorised access.

The [OWASP software supply chain security cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Software_Supply_Chain_Security_Cheat_Sheet.html) names protected branches and merge policies among the controls to use. It also warns that compromised build tools are an appealing target, because they enable a wide range of exploits. The [NIST SP 800-218 Secure Software Development Framework](https://csrc.nist.gov/projects/ssdf) groups this duty under its Protect the Software practices, which reach the whole estate, not just the repositories.

Apply the repository discipline to each system that alters what ships:

- **CI/CD runners.** Restrict who can edit pipeline definitions and which jobs reach privileged runners.
- **Build servers.** Put them behind SSO and MFA, with named administrators and no shared logins.
- **Artifact and package registries.** Let the pipeline's own identity publish; humans read.
- **Test environments.** Tie access to project assignment, and keep standing production credentials and customer data copies out.

A pipeline definition edited without review bypasses the protected trunk entirely. Put those files under the same code-owner rules as application code, so changing how the build works needs the same independent approval as changing what it builds.

Auditors look at the CI/CD configuration, not just the repositories, so a team that locked down its repos and left the build servers open is found out quickly.

## How do you revoke leavers' access to code on their last day?

Connect the HR leaver event to the identity provider. Code platform seats, personal access tokens and SSH keys are then revoked the same day as email. Orphaned accounts on the code platform are the most common finding for this control, and offboarding that only covers email creates them.

Treat the leaver as one event with many consequences. HR records the departure, the identity provider disables the account and drops group membership, and repository access, which flows from those groups, goes with it. Tokens and keys need their own step. A personal access token or SSH key registered on the platform can outlive a disabled login unless you revoke it.

On the leaver's last day, confirm that:

- the seat is removed from the code platform organisation;
- personal access tokens are revoked;
- SSH keys and deploy keys they registered are deleted;
- access to the build server and artifact registry is gone;
- any shared secret they knew has been rotated.

The NCSC guidance asks that repository access is joined up with your joiner and leaver processes. The exhibit that settles it is a removal timestamp that matches the HR date. Movers matter too: if write access follows project assignment through identity-provider groups, a transfer between teams drops the old access automatically.

Contractors and agency developers need the same path. Give their accounts an expiry date when you create them, so access ends even if nobody remembers to raise a ticket.

## How do auditors test ISO 27001 Annex A 8.4?

Auditors check recent HR leavers against the code platform's member list and pull merged pull requests to find self-approved merges. They also ask who runs the organisation and the build pipeline. No review gate on production code, or active accounts for departed staff, grades major; single stale items grade minor.

Questions to expect in the room:

- "Show me the protection rules on your main branch. Can anyone push straight to it?"
- "Who has admin over the organisation, and why those people?"
- "This engineer left in June. When did their repository access end?"
- "Pick a recent production change and walk me from pull request to approval to deploy."
- "How do you control who can touch the build pipeline and the artifact registry?"

Sampling usually runs in two directions. Leavers go from the HR list to the platform, to prove access ended. Current members go from the platform back to the staff list, to catch accounts nobody can name. The auditor also takes a handful of merged pull requests, where self-approved merges are the classic catch.

For a software company, certification bodies grade findings like this:

- **Major:** no review gate on production code, meaning anyone can push to main, or active accounts piling up for departed staff.
- **Minor:** a single stale collaborator, an unprotected archive repository or unenforced commit signing.
- **Pattern:** minor findings that recur aggregate to a major.

A policy describing a branching model the team abandoned two years ago is evidence against you.

Auditors read the policy first and the repository settings second, so keep the policy short enough to stay true. Where a setting contradicts a sentence, the setting wins.

## What evidence proves Annex A 8.4 is operating?

Evidence is five artefacts: branch-protection settings, a member and role list that matches current staff, sampled merged pull requests showing independent approval, access review and leaver records tied to removal dates, and the platform audit log. Secret-scanning configuration and signing setup add support.

Each one proves something:

- **Branch-protection settings,** exported or screenshotted, prove that direct pushes are blocked, reviews are required and stale approvals are dismissed.
- **The member and role list** proves least privilege, because it matches current staff and project work with no orphans.
- **Sampled merged pull requests** prove that independent approval and passing checks happen in practice, not only in settings.
- **Access review and leaver records** prove that removals happen on time, once cross-referenced to removal dates.
- **The platform audit log** proves who changed permissions, cloned repositories or took admin actions.

Two supporting items round out the pack: secret-scanning or pre-merge check configuration, and signing setup where code ships externally. Neither replaces the five, but they answer follow-up questions before they are asked.

Date every export and keep it where you can hand it over without asking an engineer to share a screen. A small firm can hold this in one folder refreshed at each access review. Larger estates should collect it automatically, as the final section describes.

## Who owns Annex A 8.4, and when can you exclude it from the Statement of Applicability?

The CTO or Head of Engineering owns enforcement, with the security lead owning the policy; ownership fails when security has no rights over the repositories. You can exclude the control from the Statement of Applicability only if the firm genuinely writes no code, with a one-line justification.

The split matters because enforcement needs rights. Engineering holds administrative access to the repositories and the pipeline, so engineering can configure protection rules and run the reconciliations. Security writes the policy that defines the tiers, the review rule and the leaver deadline, and checks that practice matches it.

In a 50-person firm, one CTO may hold both roles. That is fine, provided someone still compares the policy with the configuration at each access review.

On exclusion, the test is narrow. If the firm genuinely writes no code, record the control as not applicable in the Statement of Applicability, with a one-line justification. That is the document that records which Annex A controls apply and why. Revisit the entry if that changes.

Be strict about what counts as code. Infrastructure-as-code and scripts that matter are code, so a firm that only configures SaaS tools but maintains Terraform or automation scripts still has something to protect.

## How do you automate Annex A 8.4 so the evidence builds itself?

Define branch-protection and role settings as code and drift-check them on a schedule. Drive repository membership from identity-provider groups, diff org members against HR with a scheduled job, and collect pull-request approvals and audit-log exports automatically. The audit pack becomes a by-product of shipping.

Four mechanisms do the work:

1. **Configuration as code.** Define branch-protection rulesets and role settings declaratively, through your platform's API or a Terraform provider, and run a scheduled drift check that compares live settings with the declared state. "Are the rules still on?" becomes a query, not an annual screenshot hunt.
2. **IdP-driven membership.** Repository access flows from identity-provider groups tied to project assignment, provisioned through SCIM where the platform supports it. The leaver event then revokes code access with everything else, timestamped.
3. **Continuous reconciliation.** One scheduled job diffs organisation members against HR and flags strays. Another samples merged pull requests for missing independent review and raises a ticket.
4. **Evidence from the pipeline.** Pull-request approvals, check results and audit-log exports are collected automatically into your evidence store.

Drift is the gap most guidance misses. A repository is created from defaults, an admin loosens a rule to unblock a release and forgets, a new repository never receives the template. Across dozens of repositories, nobody remembers which, and the rulesets quietly stop matching the policy. The table sets the manual and automated routes side by side.

Development-platform data is among the first sources our GRC Engineering service wires into continuous assurance. Our Cloud Security Architect engagement configures repository and pipeline hardening, guardrails and secrets management hands-on inside your CI/CD.

| Control area | Manual route | Automated route |
| --- | --- | --- |
| Branch protection | Annual screenshot hunt | Settings defined as code, drift-checked on a schedule |
| Membership | Spreadsheet review | Identity-provider groups tied to project assignment |
| Leaver check | Ad hoc comparison with HR | Scheduled diff of org members against HR |
| Review quality | Auditor samples at audit | Scheduled sample of merged pull requests |
| Evidence | Gathered before the audit | Exports collected automatically and timestamped |

## Frequently asked questions

### Does Annex A 8.4 require commit signing?

Not as a blanket rule. If you publish code externally, commit or release signing gives consumers integrity assurance, so sign your releases. Internally it is worthwhile but secondary to review enforcement: a signed commit proves who wrote a change, not that anyone else checked it.

### Where does secret scanning fit under A.8.4?

As a pre-merge check on the protected trunk, with push protection switched on where the platform offers it, so a key is blocked before it reaches the server. If a key does land in a commit, rotate it first. Rewriting history does not recall copies already cloned, so treat the key as exposed.

### Which repositories should have tighter read access under Annex A 8.4?

Genuinely sensitive ones: repositories holding secrets or security tooling. There, read access tightens to named people in the same way write does. Keep the list short, record why each repository is on it, and leave the rest open for collaboration.

### How does A.8.4 treat source code cloned onto personal devices?

The repository is controlled, but the copies are not, which is the gap auditors notice. Decide whether personal devices may clone sensitive code at all. If they may, back the answer with endpoint controls, such as managed devices with disk encryption. Document the decision so the policy matches what engineers do.