ISO 27001 A.8.4: Access to Source Code

ISO 27001 A.8.4 requires that read and write access to source code, development tools, and software libraries is restricted to what a person needs for their role, so the code that becomes production software cannot be read or changed by anyone who happens to have a login. The action teams get flagged on most is write control on the main branch: unprotected default branches that any contributor can push to directly, with no required review and no record of who merged what.

What is ISO 27001 A.8.4?

ISO 27001 A.8.4 Access to source code governs how access to program source code, development tools, and software libraries is granted and restricted. In the words of ISO/IEC 27001:2022, Annex A, the control title is Access to source code. The intent, as described in ISO/IEC 27001:2022, Annex A, is that read and write access to source code and the associated development artifacts is managed on a need basis, so that source is not altered without authorization and its integrity is preserved.

Source code is a controlled asset because it defines how the production system behaves and often contains the configuration, logic, and occasionally the secrets that protect customer data. A.8.4 applies the general access control intent of A.5.15 specifically to the software development estate: the repositories that hold the code, the build tools and pipelines that turn it into deployable artifacts, and the package and artifact registries that store the libraries and outputs. Restricting who can read that code, and controlling much more tightly who can change it, is what the control asks for.

How do you implement A.8.4?

Implement ISO 27001 A.8.4 by inventorying the source code estate, applying least-privilege permissions to every repository, and gating changes to protected branches behind review. The sequence a team follows:

1. Inventory repositories, tools, and libraries. List every repository, the internal package and artifact registries, and the build and deployment tooling that reaches the code. This inventory is the scope for every later step; a repository nobody tracks is a repository nobody controls.
2. Apply least-privilege repository permissions. Grant access by role and business need rather than giving the whole engineering group admin on every repository. Most contributors need write to the repositories they work in and read elsewhere; a small number need admin. Separate private product repositories from anything public.
3. Protect the main and release branches. Turn on branch protection for the default branch and any release branches so no one pushes directly. Require a pull request, at least one review by someone other than the author, and passing status checks before a merge is allowed.
4. Control write access and merge rights. Merge rights to protected branches are the privileged permission in the source estate: restrict them to the roles that need them, keep the author and the approver separate, and treat a force-push or a protection override as an exception that is logged.
5. Restrict access to build tools and artifact registries. The CI/CD system, the container registry, and the internal package registry are part of the code supply chain. Limit who can change pipeline definitions, publish packages, or pull private artifacts, and require authentication for every path into them. Dependency scanning, for example Dependabot or Snyk, watches the third-party libraries this supply chain pulls in, and the paths between repository, pipeline, and registry are part of the system's security architecture and worth mapping deliberately.
6. Keep secrets out of the code. API keys, database credentials, and signing keys do not belong in the repository. Move them to a secrets manager or the pipeline's protected secret store, and run secret scanning on commits so a credential that slips in is caught and rotated.
7. Log and review access. Repository access, permission changes, and merges to protected branches are logged, and repository permissions are reviewed on a defined cadence so stale access from role changes and departures is removed.

SaaS version control vs self-hosted Git

Most teams run a SaaS version control platform (GitHub, GitLab, Bitbucket) where A.8.4 is implemented through organization roles, branch protection rules, and identity integration. Repository and organization roles set who can read, write, or administer; branch protection and required reviews gate changes to protected branches; and SSO with SCIM ties repository access to the identity provider so joiners and leavers are provisioned and deprovisioned centrally rather than as standalone Git accounts.

A self-hosted Git server (a self-managed GitLab, Gitea, or bare Git over SSH) implements the same control through the team's own access management. Repository permissions are backed by the server's own model or an LDAP directory, SSH keys or directory accounts authenticate contributors, and the same branch-protection and required-review settings are configured on the self-hosted instance. The access model is the team's responsibility end to end rather than inherited from a SaaS provider. The on-prem access control guide covers directory-backed permissions and access review in depth.

What evidence demonstrates A.8.4?

Evidence for ISO 27001 A.8.4 is the record that source code access is scoped, that changes to protected branches are reviewed, and that access is logged and periodically re-confirmed. Teams that export permission and merge records straight from the platform on a schedule, instead of compiling them by hand each audit, are practicing GRC engineering.

How does A.8.4 map to SOC 2?

ISO 27001 A.8.4 maps to the SOC 2 criteria that restrict logical access and that govern authorized, reviewed change.

The overlap is Partial because CC6.1 governs logical access across the whole environment and CC8.1 governs the entire change process, while A.8.4 addresses one slice of each: access to the source code and development tooling specifically. The SOC 2 to ISO 27001 control mapping covers the full crosswalk and where SOC 2 work transfers to ISO 27001.

Related controls

ISO 27001 A.8.4 restricts access to the code itself; the controls around it govern who holds elevated rights, what an identity can reach, and how code is built. A.8.2 privileged access rights governs the admin and merge permissions that A.8.4 restricts on repositories and build systems, and A.8.3 information access restriction limits what an authenticated identity can reach once inside a system. A.8.25 secure development life cycle sets the wider secure-development rules around source code access, and A.5.15 access control defines the overall access policy that A.8.4 applies to the development estate. All four belong to the ISO 27001 certification guide.

Frequently Asked Questions

What is ISO 27001 A.8.4?

ISO 27001 A.8.4 is the Annex A control titled Access to source code, in the Technological theme. It requires that read and write access to program source code, development tools, and software libraries is restricted on a need basis, so that source cannot be read or altered without authorization and its integrity is preserved.

What evidence satisfies A.8.4?

Typical A.8.4 evidence includes a repository permission export showing least-privilege access, branch-protection configuration for protected branches, pull request and merge records showing second-person review, periodic repository access review records, artifact and package registry permissions, and secret-scanning configuration with its findings and remediation.

Is A.8.4 new in ISO 27001:2022?

No. Access to source code carried over from the 2013 version of the standard and was not introduced in the 2022 revision. The 2022 revision reorganized Annex A into four themes and placed access to source code under the Technological controls as A.8.4, but the control itself is not new.

How do you handle A.8.4 on a very small development team?

Restrict access through the tooling rather than through headcount. Move code into a hosted or controlled repository with role-based permissions, turn on branch protection with a required status check on the main branch, and enable secret scanning. On a single-developer team where real-time peer review is not possible, automated checks on the protected branch and a documented periodic review of changes provide the controlled, reviewable access A.8.4 expects.

How does A.8.4 differ from A.8.2 privileged access rights?

A.8.4 restricts access to source code, development tools, and software libraries specifically, while A.8.2 governs elevated permissions across the whole environment. They meet on the source estate: the admin and merge rights that A.8.2 treats as privileged access are the same write permissions A.8.4 asks you to restrict on repositories and build systems.

How does A.8.4 map to SOC 2?

A.8.4 has Partial overlap with SOC 2 CC6.1 and CC8.1. CC6.1 covers logical access and CC8.1 covers change management across the whole environment, while A.8.4 addresses one slice of each: access to source code and development tooling. Repository permission exports, branch-protection configuration, and merge approval records are reusable across both frameworks.