To show control over source code access for ISO 27001 control 8.4, define who may read or change code, tools and libraries, grant access by request, and review it on a schedule. Keep the rules, a dated access list and records of requests and reviews. Auditors look for managed access, not a perfect list.
What 8.4 covers
The control covers source code, development tools and software libraries. The goal is to prevent unauthorized changes and disclosure of sensitive software data. Documentation is not mandatory. Smaller companies can use an access control policy, and larger ones may write a procedure for source code access.
The four questions the process answers
The guidance describes a process that does four things:
- Restricts access based on how sensitive the code, tools and libraries are
- Assigns who is responsible for restricting access
- Defines how access requests are made and fulfilled
- Specifies how restrictions are reviewed and updated
What to include in scope
| Item | Example restriction |
|---|---|
| Source repositories | Read for the team, write for approved roles |
| Build and CI tools | Admin limited to a few named people |
| Package registries | Publish rights held by few accounts |
| Internal libraries | Same rules as the code they protect |
Evidence to keep
- The access rules in the access control policy
- A current list of who can reach each repository
- Records of recent access requests and approvals
- The last access review with changes made
- Removal of access for leavers
Repository settings can produce much of this. A dated export of members and roles, kept each quarter, answers most auditor questions.
Where small teams slip
- Everyone is an admin because it was faster once
- Contractor accounts that outlive the contract
- Old deploy keys and tokens nobody reviewed
- Package publish rights held by a former employee
A quarterly rhythm that works
Pick one day each quarter. Export members and roles for each repository, build system and registry. A named reviewer marks anything that looks wrong, such as people who changed teams or contractors past their end date, and raises tickets for the fixes. Save the export, the marks and the tickets together. Four of these sets per year give an auditor a clear picture without anyone doing special work in audit month.
Quick check
Does 8.4 only apply to source code?
No. It also covers development tools and software libraries, so build systems and registries belong in scope.
What counts as a review?
A dated check that compares who has access with who should, with changes recorded. A signed note or ticket is enough.
Where tooling helps
Safeguard offers asset discovery and compliance and evidence automation, which can help keep dated records of repositories and access reviews. Deciding who should have access stays with your team. Try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
