When a developer leaves your organization and their repository access stays active for months, you have a window that attackers — or disgruntled former employees — can use to inject backdoors, exfiltrate proprietary logic, or tamper with production code. ISO 27001 control 8.4 exists to close that window by forcing organizations to treat source code access as a first-class security concern, not an afterthought delegated to engineering teams.
What 8.4 Requires
ISO/IEC 27001:2022 Annex A 8.4 requires your organization to strictly manage and restrict both read and write access to source code, development tools, and software libraries. The goal is to prevent unauthorized modification of code and protect intellectual property — but the control’s scope extends further than most teams initially assume.
You need to control who can view repositories, who can commit changes, and who can alter the tools that build and deploy your software. That means implementing role-based access tied to job function, requiring formal approval before granting write privileges, and revoking access immediately when someone changes roles or leaves the organization.
The control also covers development tooling and third-party libraries. If an attacker compromises your CI/CD pipeline or poisons a dependency in your package registry, the effect is the same as if they had direct write access to your production code. Organizations that focus exclusively on repository permissions while leaving build systems and library management uncontrolled are missing half the picture that 8.4 is designed to address.
Why 8.4 Matters
Organizations that fail to implement this control often discover the gap through incident response rather than audit findings. In a common pattern, a former contractor retains write access to a production repository for months after their engagement ends. During that time, a single malicious commit — disguised as a routine dependency update — propagates through the build pipeline and ships to every customer environment.
The risk class here is unauthorized code modification and supply chain compromise, and the severity is high. A single compromised commit can affect every downstream deployment, turning an access control failure into a widespread supply chain attack that damages customer trust and triggers regulatory scrutiny.
What Attackers Exploit
- Orphaned developer accounts — former employees or contractors whose repository access was never revoked during offboarding
- Overly broad permissions — every developer granted admin access by default, rather than scoped read/write privileges
- Missing branch protection — direct pushes to main or production branches without peer review or approval gates
- Unsigned commits — no commit signing enforcement, allowing identity spoofing in the commit history
- Unmonitored bulk access — mass cloning or downloading of repositories going undetected because audit logging is disabled or unreviewed
- Compromised CI/CD service accounts — build system credentials with excessive privileges that bypass normal access controls
- Unvetted third-party libraries — dependencies pulled from public registries without integrity verification or approval workflows
How to Implement 8.4
Implementation splits into two tracks: securing your own development environment and verifying that your vendors do the same. Both require documented processes and evidence that auditors can review.
For Your Organization (First-Party)
Start by centralizing all source code in a managed repository platform such as GitHub, GitLab, Bitbucket, or Azure DevOps. Code scattered across personal accounts, file shares, or email attachments cannot be controlled — and if you cannot see it, you cannot protect it.
Next, enforce a role-based access model with three tiers. Read-only access goes to team members who need to review code but not modify it. Write access is limited to developers actively contributing to a specific project or service, with changes submitted through pull requests that require peer review. Admin access is restricted to a small group of repository and platform administrators, with multi-factor authentication enforced on all privileged accounts.
Enable branch protection rules on production branches. At minimum, require pull request reviews before merging, block direct pushes, and enforce status checks from your CI pipeline. Consider requiring commit signing with GPG or SSH keys so that every change is cryptographically tied to the person who authored it.
Extend controls beyond the code itself. Restrict who can modify build pipelines, CI/CD runner configurations, and deployment scripts. Manage access to internal package registries and enforce dependency scanning through software composition analysis tools. Build system service accounts should follow the same least-privilege principles as human accounts.
Enable comprehensive audit logging for all repository events — clones, pushes, permission changes, branch protection modifications, and merge activity. Forward logs to a centralized platform where they can be retained and reviewed. Conduct quarterly access reviews by cross-referencing active repository users against HR records, paying particular attention to leavers and role changes.
Document a formal access request and approval workflow. Every grant of write or admin access should have a corresponding ticket or approval record that an auditor can trace.
Common mistakes:
- Granting admin access by default because “the team is small” — least privilege applies regardless of team size
- Failing to automate access revocation during offboarding, leaving orphaned accounts active for weeks or months
- Treating branch protection as optional for development or staging branches, where malicious changes can still reach production
- Excluding CI/CD service accounts from access reviews because they are “not human users”
- Ignoring third-party library and package registry access, leaving a supply chain attack vector unaddressed
For Your Vendors (Third-Party Assessment)
When assessing vendors against 8.4, include these questions in your security questionnaire:
- How do you manage access to source code repositories? Is access tied to an identity provider?
- Do you enforce branch protection rules on production branches? What are the specific requirements?
- How frequently do you review developer access permissions, and what triggers a review?
- Do you require commit signing or other integrity verification for code changes?
- How do you manage access to build tools, CI/CD pipelines, and internal package registries?
Request specific evidence: the vendor’s access control policy, a screenshot or export of branch protection settings on a production repository, recent user access review records with sign-off, and a sample of audit logs showing repository activity.
Red flags in vendor responses include: all developers having admin-level access, no documented access review process, no branch protection on production branches, shared credentials for CI/CD systems, and inability to provide audit logs on request.
To verify beyond self-attestation, ask for the vendor’s SOC 2 Type II report and check whether change management controls are in scope. Review their ISO 27001 Statement of Applicability to confirm 8.4 is included and not marked as not applicable. If the vendor supports it, request read-only access to repository audit logs for a defined review period.
Audit Evidence for 8.4
Auditors assessing 8.4 will look for both policy documentation and technical evidence that controls are operating as described. The following table covers the most commonly requested artifacts.
| Evidence Type | Example Artifact |
|---|---|
| Access Control Policy | Policy defining repository access roles, approval workflows, and review cadence for source code, development tools, and libraries |
| Source Code Access Register | Current list of users with read, write, and admin access per repository, including service accounts |
| Branch Protection Configuration | Screenshots or exports showing pull request requirements, review rules, and merge restrictions on production branches |
| User Access Review Records | Quarterly review logs showing repository access validated against HR records, with reviewer sign-off and documented remediation |
| Audit Logs | Repository event logs covering clone, push, permission change, and merge activity for the review period |
| Offboarding Evidence | Ticket or workflow records demonstrating access revocation within the defined SLA following departure or role change |
| Commit Signing Policy | Documentation of GPG/SSH signing requirements and configuration evidence from the repository platform |
| Third-Party Library Policy | Approved package registry configuration, dependency scanning reports, and records of library approval decisions |
Cross-Framework Mapping
If you are mapping ISO 27001 controls to other frameworks — whether for multi-framework compliance or to demonstrate equivalence to auditors — the following table shows how 8.4 aligns with related requirements. The NIST 800-53 mappings are drawn from the official OLIR crosswalk.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AC-03 (Access Enforcement) | Full |
| NIST 800-53 | AC-03(11) (Restrict Access to Data Repositories) | Full |
| NIST 800-53 | CM-05 (Access Restrictions for Change) | Full |
| SOC 2 | CC6.1 (Logical and Physical Access Controls) | Partial |
| CIS Controls v8.1 | 6.1, 6.2 (Access Control Management) | Partial |
| NIST CSF 2.0 | PR.AA (Identity Management, Authentication, and Access Control) | Partial |
The NIST 800-53 controls provide the closest alignment, with AC-03 covering general access enforcement, AC-03(11) specifically addressing restrictions on data repositories (which includes source code), and CM-05 covering access restrictions tied to change management — all core aspects of what 8.4 requires. SOC 2, CIS Controls, and NIST CSF map partially because they address access control broadly but do not isolate source code and development tooling as a distinct control objective.
Related ISO 27001 Controls
Control 8.4 does not operate in isolation. It connects to access management, change control, and personnel security controls that collectively protect the software development lifecycle.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.15 | Access Control | Overarching access control policy that governs all access decisions, including source code |
| 5.18 | Access Rights | Provisioning and revocation lifecycle that 8.4 applies specifically to development environments |
| 6.1 | Screening | Background checks and vetting that inform trust decisions for granting code access |
| 6.5 | Responsibilities After Termination | Ensuring access revocation on departure — a critical failure point for 8.4 |
| 8.2 | Privileged Access Rights | Managing elevated permissions (admin access) on repositories and build systems |
| 8.3 | Information Access Restriction | Broader restriction principles that 8.4 specializes for source code |
| 8.5 | Secure Authentication | MFA and authentication controls that protect developer accounts |
| 8.9 | Configuration Management | Securing build tool and CI/CD pipeline configurations |
| 8.25 | Secure Development Life Cycle | Broader SDLC security framework that 8.4’s access controls support |
| 8.32 | Change Management | Linking code changes to formal change requests — works hand-in-hand with 8.4 |
Frequently Asked Questions
What is ISO 27001 8.4?
ISO 27001 8.4 is an Annex A control that requires organizations to strictly manage and restrict read and write access to source code, development tools, and software libraries. It exists to prevent unauthorized code modifications, protect intellectual property, and reduce the risk of supply chain attacks through compromised development environments.
What happens if 8.4 is not implemented?
Without 8.4 controls in place, organizations are exposed to unauthorized code changes, insider threats from former employees retaining repository access, and supply chain injection through compromised build tools or libraries. During a certification audit, a missing or ineffective 8.4 implementation will result in a nonconformity that must be remediated before certification can be granted or maintained.
How do you audit 8.4?
Auditors verify 8.4 by reviewing the access control policy for source code, examining the current user access list for repositories, checking branch protection configurations on production branches, and reviewing records of quarterly access reviews. They may cross-reference the HR leavers list against active repository accounts to confirm that offboarding procedures are working, and they will look for audit logs demonstrating that repository activity is monitored.
How UpGuard Helps
Monitor and Manage Source Code Access Risk Across Your Organization
Controlling access to source code starts with visibility into who has access to what — and whether that access is still appropriate. UpGuard User Risk helps you monitor user access patterns, identify excessive permissions, and track access changes across your organization so that 8.4 controls stay effective between quarterly reviews.