A.8.4 Access to source code: requirements and evidence

What A.8.4 access to source code requires in plain terms

A.8.4 asks you to control who can read, change and approve code, development tools and software libraries, so that only authorized changes reach your systems. If you are the compliance lead or engineer who has to show this control at audit, your job is to prove that access is granted on purpose, reviewed over time and removed when no longer needed. The control targets three risks named in its purpose: unauthorized functionality slipping into software, unintended or malicious changes, and loss of intellectual property. Because the scope includes development tools and software libraries, your evidence must cover more than the main Git repository. It also has to reach CI/CD runners, artifact registries, package and dependency sources, code review tools and the build servers that compile what customers receive.

The control is hard in practice for three reasons. Access accumulates: engineers keep repository roles after they change teams, contractors keep write access after projects end, and nobody asks whether a role still fits. Bots and service accounts also hold write or deploy rights, often through long-lived tokens that no one reviews. Finally, the control is about who can change code, not only who can read it. A developer with push rights to a protected branch can alter behavior just as much as one who can view a repository, so you need to see who can push, merge, force-push, tag and modify pipeline definitions.

The predecessor of A.8.4 is control A.9.4.5, Access control to program source code, in the 2013 edition. ISO/IEC 27002:2022 Annex B traces A.8.4 to that control, which helps you explain continuity to an assessor who holds an older mapping. Confirm with your certification body how they expect you to present the transition in your Statement of Applicability, and check the wording of the current control in the standard itself, not in secondary summaries.

Which repositories, tools and accounts fall inside A.8.4

A.8.4 applies to every place where code, build logic and dependencies can be read or changed, not only the main application repository. The scope should follow the ISMS scope and the Statement of Applicability, and the items below are the usual places where that scope is decided.

Production and internal repositories

Every repository that holds product source, internal tools or scripts that touch production belongs in scope. Start with an inventory that lists each repository, its owner, who can read it and who can write to it. Repositories holding customer or regulated code usually need the strictest treatment, including protected branches, required reviews and restricted write access. Ask whether forks and personal copies of these repositories exist outside the managed platform.

CI/CD runners and build systems

Build pipelines can read secrets, push artifacts and deploy code, so their configuration is part of A.8.4 even when no one edits source files directly. Check who can change pipeline definitions, which runners execute jobs, and whether a branch can trigger a build with elevated credentials. A change to a pipeline file is a change to the software that ships, so it needs the same authorization as a code change.

Package and library registries

Internal package registries and mirrors of public libraries control what dependencies reach builds. Define who can publish to each registry, who can approve new upstream sources and how namespaces are protected from overwrites. Without these limits, an attacker or careless user can replace a trusted library version. Confirm that registry write rights are separate from repository write rights where your tooling allows it.

Infrastructure-as-code repositories

Terraform, Ansible and similar repositories define the cloud accounts, networks and access policies that the rest of the ISMS relies on. A change here can open a network path or grant a role, so these repositories often carry more risk than application code. Confirm that they have their own access list, that changes go through review, and that state files and variable stores holding secrets are not readable by general developers.

Developer tools with write access

IDEs, code assistants, plugins and browser-based editors often hold personal access tokens with write rights to repositories. These tokens sit outside the central identity system unless they are inventoried. List the tools that have repository credentials, how those credentials are issued and revoked, and whether tokens expire. Ask who approves a new tool and how a departing developer's tokens are removed.

Contractor, outsourced and service accounts

Contractors and outsourced developers need access that is granted for a defined purpose and ends with the contract. Service accounts used by bots, pipelines and integrations need named owners, scoped permissions and a review cycle, because no individual person is tied to their activity. Record which external parties and non-human identities can read or write each repository, and check that their access is reviewed on the same schedule as employee access.

How an assessor tests A.8.4 and what they ask for

This table walks through the test approach an assessor typically follows for A.8.4, row by row, with the evidence each step asks for and the finding that appears most often. Read it as a preparation checklist: each row is a question the assessor will ask, and the evidence column shows what the organization should already have in hand before the audit starts.

Test step	Evidence the assessor asks for	Common finding
Design review of the access policy and repository permission model	Written access policy for source code and tooling, a permission matrix mapping roles to repositories, and the approval owner for changes to that matrix	Policy exists but does not match how permissions are actually granted in the Git platform or CI system
Sampling of repositories and branches	Repository inventory with owners, a sample of production-relevant repositories, and the branch protection settings exported for each sampled branch	Legacy or forked repositories with weaker settings that nobody inventoried or assigned an owner
Review of who holds write and merge rights	Current membership lists with roles, the date each grant was approved, and the approver for each elevated role	Write access held by contractors or former project members, or by broad groups that were never reviewed
Testing of protected branch and approval settings	Screenshots or exports showing direct push blocked on the default branch, required reviews before merge, and force pushes disabled, plus a dated test showing a blocked push	Settings applied to the main branch only, leaving release or hotfix branches open to direct pushes
Review of access reviews for developers and service accounts	Periodic review records covering human and non-human accounts, reviewer sign-off, and actions taken on items marked for removal	Reviews cover employees but skip CI tokens, deploy keys and bot accounts that can push code
Checks that leavers lose repository access	Joiner and leaver tickets or identity provider logs showing removal dates, and a comparison of deprovisioning dates against repository membership	Accounts disabled in the identity provider while personal access tokens or SSH keys remained valid in the code platform

Implementing A.8.4 step by step, with the output of each step

This sequence moves source code access from informal habit to a documented, enforced and periodically reviewed state. Each step produces an artifact that an assessor can read, so the organization can show who may change code, how that is enforced and who checked it.

Inventory repositories, tools and libraries
The engineering lead and the security owner list every source code repository, build pipeline, package registry, artifact store and internal software library that holds or produces code, including repositories hosted by third parties. For each one, record the owner, the hosting location, the default branch and who currently has write access. The output is a versioned inventory, and the step is complete when the owners have confirmed that no repository is missing from it. Ask the team to check for forgotten personal forks and archived projects, since these often keep old access grants.
Define an access rule for each role
Working with engineering managers and the access control owner, define which roles may read, write, merge, administer and release each class of repository, such as production services, internal tools and shared libraries. Write the rules as a role matrix that maps roles to permissions per repository class. The output is an approved matrix with a named approver and a date, and it is complete when every role in the inventory has a row. This matrix becomes the reference that later configuration and reviews are checked against.
Configure branch protection and merge approvals
Platform engineers apply the role matrix to the repository platform, for example by setting protected branch rules so that only listed roles can push or merge to the default and release branches, and by requiring review approval before a merge. Where the platform is GitLab Community Edition, protected branches can restrict push and merge roles, and direct pushes can be blocked by setting push access to no one. The output is an export or screenshot of each protection setting, stored with the change record. Confirm the exact settings available in your platform version before writing the rule set.
Restrict direct pushes and force pushes
On every protected branch, disable force pushes unless a named exception has been approved, and confirm that no ordinary developer account can push directly to production-bound branches. Test the rule by attempting a direct push and a force push from a non-privileged test account and recording the rejected attempts. The output is a test record showing both attempts were refused, and the step is complete when the test is repeated after any platform upgrade. Keep the test account and its results in the evidence folder so the check can be repeated.
Tie repository access to the identity provider
Connect the repository platform and build tools to the central identity provider, so that sign-in and group membership come from one source rather than local accounts. Where the organization runs authentik as its identity provider, applications can delegate sign-in through OAuth2, OpenID Connect or SAML. Map identity groups to the roles in the matrix, and disable local accounts that are not needed for break-glass use. The output is a group-to-role mapping and a list of remaining local accounts with their justification. Confirm that the platform supports the protocol you intend to use before you commit to it.
Link access to joiner, mover and leaver processes
HR and IT agree how repository access follows the employment life cycle. A joiner receives the role matrix entry for their role, a mover loses the old group and gains the new one, and a leaver's accounts and tokens are disabled on the last working day. Personal access tokens, deploy keys and service accounts are included in the leaver checklist. The output is a written procedure and a sample ticket for each event, and the step is complete when one test leaver has been processed end to end with the evidence recorded.
Schedule access certification of repository rights
The access control owner sets up periodic access certification campaigns for repository rights, in which named reviewers decide whether each access item is kept, changed or revoked within a set timeframe. Tools such as midPoint support this pattern through certification campaigns that record reviewer decisions. The review period is a policy choice that the organization should set and document, not one imposed by the standard. The output is a signed review record for each cycle, listing reviewer, scope, decisions and revocations completed.
Record exceptions and keep them reviewable
Any access that departs from the role matrix, such as a temporary maintainer for an incident or a direct push to fix a broken pipeline, is logged as an exception with the requester, approver, reason, scope and end date. The security owner reviews the exception log at each certification cycle and confirms that every exception was closed or formally accepted. The output is an exception register, and the step is complete when the register shows no open exceptions past their end date. An assessor will usually sample exceptions, so the register should link to the change record each one produced.

How A.8.4 connects to secure development and change management

A.8.4 is the access layer under three related controls. A.8.25 Secure development life cycle sets the rules for how software is built, A.8.28 Secure coding covers how developers write and review code, and A.8.32 Change management governs how a change is requested, approved, tested and rolled back. A.8.4 decides who can read and write the repositories, build tools and libraries those processes depend on. If a developer can push to a protected branch without review, the secure development rules and the change approval record can both be bypassed. Mapping these controls to one another in your Statement of Applicability, and naming the same repositories and roles in each, avoids gaps between the owners of each control.

In practice, one change record can serve several controls. A merge request in your Git platform can show who requested the change (A.8.32), who approved it and whether the approver is independent of the author, which static analysis and review gates ran (A.8.28 and A.8.29), and the account that was allowed to merge it (A.8.4). Protected branch settings, such as those in GitLab Community Edition, restrict which roles can push or merge and keep force pushes disabled, so the merge record and the permission setting tell one consistent story. Confirm with your assessor which of these artifacts they will sample, and retain the approval, the permission configuration and the pipeline result together.

NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.8.4 to AC-3 (Access Enforcement) and CM-5 (Access Restrictions for Change). NIST cautions that mapped controls are not always equivalent, so treat that relationship as a starting point for your own analysis, not as proof that one control satisfies the other. Ask your assessor whether they accept the mapping for your scope, and document where your evidence differs. Reviewing your repository permissions against your change records at least once each audit cycle is a practical check that the controls still agree with each other.

Which evidence passes A.8.4 and how to keep it current

An assessor testing A.8.4 looks for proof that access to repositories, development tools and libraries was granted deliberately, reviewed on a schedule and removed when people left. Each artifact below answers one part of that question, and they only work together if they cover the same audit period.

Role and permission matrix

A written matrix that lists each repository, the roles that may read, push, merge or administer it, and who approves changes to that matrix. Include CI/CD service accounts, deploy keys and tokens, not only human users. Check that the matrix matches what the platform actually grants, because a diagram that drifts from live settings is the first thing an assessor will test. Date each version and keep the previous ones.

Protected branch settings with timestamps

Export the protected branch configuration on a schedule, showing who may push, who may merge and whether force pushes are blocked. For GitLab, the protected branch settings in the project are the artifact to capture. A settings export with a date proves the control state on that day. Repeat the export across the audit period so that changes made between exports are visible in the next one.

Merge request approval records

Records showing that changes were reviewed and approved by someone other than the author before they reached protected branches. Keep the approval history, reviewer identity and timestamps from the platform rather than screenshots taken later. Sample a set of merges across the period and confirm that each one has an approval, and that none were merged by the author alone.

Periodic access review sign-offs

Signed records from reviewers who confirmed that each person and service account still needs their repository, tool or library access. Record what was kept, changed or revoked and the deadline for the decision. Access certification tooling can generate these campaigns and capture decisions, which helps with segregation of duties. The review is only evidence if the revocations that followed actually appear in the platform logs.

Leaver removal records

Tickets or identity system logs showing that repository, package registry, CI and development tool access was removed on or near the person's last working day. Leaver removal is where access quietly survives, so compare the list of active repository members against HR departures for the period. Keep contractor and departed service account records too. Ask your team which systems sit outside the identity provider, since those need a manual removal step with its own record.

Logs of permission changes

Audit logs of who granted, changed or removed repository roles, branch rules and group memberships, with the actor and time for each event. These logs show that access changes followed the approved process and let an assessor reconcile them with the matrix and review sign-offs. Confirm that the logs are retained for the whole period, are protected from edits by project maintainers, and are exported to a store that administrators cannot silently alter.

What meeting A.8.4 costs in money and effort

This table lists the cost components of putting A.8.4 in place, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No figures are published here, so use the drivers and quote requests to compare offers against your own repositories and identity setup.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Repository hosting or licenses	Software vendor or hosting provider; internal team if self-hosted	Recurring for hosted seats; one-time setup for self-hosted	Number of users and repositories, enterprise tier features, and whether GitLab Community Edition (MIT) can cover your protected branch needs without a paid tier. Self-hosted open source removes per-seat license spend but moves hosting and upkeep in-house.
Identity integration	Internal identity team, or an implementation partner for the setup	One-time for connecting the repository to the identity provider; recurring for upkeep	Number of identity sources, whether single sign-on and group mapping are already in place, and whether an open-source identity provider such as authentik (MIT) is used. Ask the quote to state which applications and sign-in methods are covered.
Engineering time to configure protection and roles	Internal platform or DevOps engineers, or an implementation partner under a fixed-scope agreement	One-time, with later changes	Number of protected branches and tags, the number of roles that need write or merge rights, and how many repositories follow the same pattern. Ask for the protection rules to be written as configuration so they can be reproduced.
Scanning tooling	Tool vendor for commercial products; internal team for CI/CD integration	Recurring for run time and rule upkeep; one-time for pipeline setup	Languages in use, custom rule authoring, and whether Semgrep Community Edition (LGPL-2.1-only) covers your stack. Check the supported language list before quoting and ask who maintains custom rules.
Recurring access reviews	Designated reviewers in each business unit; compliance or security staff who run the campaign	Recurring, usually on the review cycle you set	Number of repositories and members, how often roles change, and whether a tool such as midPoint (EUPL-1.2+) runs the campaigns or reviews are done by spreadsheet. Fewer, well-scoped groups reduce review effort.
Evidence upkeep	Internal compliance or security staff; implementation partner if the setup includes evidence design	Recurring through the year	How much evidence is captured automatically (audit logs, branch rule exports, pipeline records) versus collected by hand before each audit. Automated exports lower this cost.
External review or testing	Independent security testing firm or code review specialist	Recurring if done periodically; one-time for an initial review	Size and risk of the codebase, depth of the review, and whether the review covers access paths to the repository itself. Ask for the scope in writing before comparing quotes.
Auditor sampling time	Certification body or auditor, billed under its own agreement	Recurring, in each audit cycle	Number of sample changes and access records the auditor selects, the number of repositories in scope, and how quickly you can produce records. Clear, complete evidence shortens sampling. Auditor fees are set by the certification body, not by DeployOpen.

Which self-hosted open-source tools support A.8.4 evidence

GitLab Community Edition (MIT) can restrict who may change the code that matters most. Protected branches let maintainers limit which roles can push or merge to a branch, and they can block direct pushes by setting push access to no one. Force pushes stay disabled unless someone explicitly allows them, which protects commit history from being rewritten.

Role-based push and merge rules: Settings for each protected branch show which roles can push and which can merge, and changes to those settings are recorded in the project audit trail.
Blocked direct pushes: Setting push access to no one forces every change through merge requests, which gives a reviewable record of who approved each change.
Force pushes off by default: Rewriting history on a protected branch is blocked unless an administrator enables it, so the commit record is harder to alter quietly.
Exported configuration: Protected branch settings can be captured through the project settings or API and stored as dated evidence.

Confirm which GitLab edition and features your organization runs, because approval rules and some access controls depend on the tier. Also confirm that administrators cannot silently bypass protections, and that exports are taken on a schedule an assessor can see.

Where A.8.4 implementations usually fall short

Most A.8.4 failures are not missing tools. They are unowned accounts, exceptions nobody reviews, and evidence assembled for the auditor rather than kept as a running record. The cards below cover the gaps assessors most often find, each with the check that closes it.

Shared service accounts with write access

A CI bot or shared login that pushes to protected code, with a password known to several people, means no change can be traced to a named person. An assessor will ask who holds the credential and whether a change can be attributed to an individual. Inventory every non-human account with repository rights, give each an owner, and move it to scoped tokens that expire. Confirm each service account has a named owner and a documented purpose.

Administrators bypassing protected branches

Protected branch rules often exempt maintainers or admins, so the people with the most access can push or force-push past review. This defeats the separation between writing code and approving it. Check which roles can push or merge to each protected branch, confirm direct pushes are blocked for everyone, and confirm force pushes stay disabled unless a documented exception exists.

No periodic review of developer rights

Developers accumulate repository access as they move between projects, and nobody removes it. Without a recurring review, access drifts away from current responsibilities and undermines the authorization A.8.4 expects. Set a review cycle per repository, have a designated reviewer keep, change or revoke each grant, and keep the signed decisions as evidence.

Libraries and tools left out of scope

Access controls usually cover the main repositories but not package registries, build runners, container image stores, or the shared libraries and IDE plugins developers use. A malicious change to a dependency reaches production without touching the main code. Extend the access inventory to every registry, artifact store and development tool, and record who can publish to each.

Leavers keeping repository tokens

A departing developer may still hold personal access tokens, SSH keys or deploy keys that continue to work after the account is disabled. These credentials outlive the employment relationship and are rarely listed in offboarding checklists. Add token and key revocation to the leaver process, search for keys tied to inactive users, and test that a disabled account cannot clone or push.

Evidence captured only at audit time

Screenshots of repository settings taken the week before an audit show the state on that day, not that controls worked over the audit period. Assessors typically want records produced as the system runs, such as access logs, review sign-offs and configuration history. Export access and protection settings on a schedule into a retained store, and keep the change history that shows when rules were altered.

Common questions about A.8.4 cost, effort and outside help

How much effort does A.8.4 take for a small engineering team?

For a small team, the effort for A.8.4 is mostly configuration and evidence, not new software. The work is to list every repository, build pipeline and shared software library, decide who may read, write and approve changes to each, and then turn those decisions into settings that stay in place. The biggest variable is how many repositories and how many people with write access already exist, because each one needs an owner and a recorded decision. Ask your team to inventory repositories first, since that inventory sets the size of everything that follows.

Can we implement A.8.4 in-house without an outside partner?

Yes, many organizations do this in-house, provided someone owns the access policy and has time to maintain it. An in-house team usually handles the repository settings, branch protection and access reviews well, and the harder parts are sustaining them and producing dated evidence over time. An outside partner is most useful when the team lacks hosting, identity or CI/CD experience, or when the work must finish before a customer or certification deadline. Either way, the organization keeps ownership of the control and its decisions.

What does A.8.4 need from engineering and security leads?

Engineering leads need to define who is allowed to push, merge and approve changes for each repository, and to accept that some developers will lose direct-push rights. Security leads need to define the access policy, review access on a set schedule, and decide how exceptions are approved and recorded. Both groups must agree on who can grant and remove access to source code, development tools and library registries. Without that agreement, settings drift and the evidence cannot show who authorized what.

How long does it take to prepare A.8.4 evidence?

The timeline depends on the size of the code estate, how far current settings differ from the policy, and how much access history the organization can reconstruct. No fixed duration applies to every organization. Ask any implementation partner to base its estimate on a written inventory of repositories, identity sources and pipelines, and ask whether the plan includes a first full access review. Evidence needs a period of operation before an auditor can see it working, so start early rather than waiting for the audit date.

Can a consultant or partner make the auditor's job unnecessary for A.8.4?

No. A partner can prepare settings, documentation and evidence, but only an independent auditor or certification body can assess the control and issue a certificate or report. The organization owns its controls and must be able to explain them and show them working. A partner's role ends at preparation, and any firm that suggests otherwise is describing a service no independent assessor will accept. Confirm the auditor's expectations before work starts, so the preparation matches what will be tested.

Which cost drivers matter most for A.8.4?

The main cost drivers are the number of repositories and pipelines, the number of people with write access, the identity systems that must be connected, and how much remediation existing settings need. Recurring costs include access reviews, staff time to approve exceptions, and tool upkeep if self-hosted platforms are used. One-time costs include the initial inventory, configuration and first review. When requesting a quote, ask for the scope in writing, which repositories are included, who does each task, and what evidence is delivered at the end.

Does a self-hosted platform produce A.8.4 evidence on its own?

A platform can produce useful evidence, such as branch protection settings, access lists and change records, but it cannot decide your access policy or prove that people followed it. Settings in a self-hosted code platform can be exported and dated, and identity providers can show how sign-in is delegated. Confirm the exact logging and export features of the platform version you run, because capabilities differ between editions. Your evidence pack should combine platform records with approved decisions and completed review sign-offs.

How DeployOpen scopes and prepares A.8.4 evidence

DeployOpen's work on A.8.4 starts with a written, fixed scope that names the repositories, development tools and software libraries in question, the identity source that will govern them, and the evidence the organization's auditor will expect to see. The scope document decides what gets configured, so it should list each code host, each package registry and each CI/CD runner that can write to production code, along with the people or groups who hold write rights today. Agreeing this list before any configuration change is what keeps the engagement fixed-scope in practice.

In a typical self-hosted engagement, the configuration covers branch protection on critical repositories, using the protected branch settings in GitLab Community Edition to limit which roles can push or merge, block direct pushes where the policy requires it, and keep force pushes disabled. Identity links are set up so that sign-in to the code host is delegated to the organization's identity provider, for example authentik through OAuth2, OpenID Connect or SAML, so that joiners, movers and leavers are handled in one place. Review of standing access can be run as access certification campaigns in midPoint, with named reviewers and a deadline. Evidence exports, such as protected branch settings, group membership lists, review decisions and scan results from Semgrep Community Edition in CI/CD, are generated on a schedule and stored in the client's own evidence location. Each of these items should be confirmed against the current version of the relevant product before the scope is signed.

DeployOpen prepares systems, controls and evidence for the organization's assessment. It does not issue audit reports, attestations or certificates. The organization owns its control design and its risk decisions, and an independent auditor or accredited certification body decides whether A.8.4 is met. Before engaging, ask the implementation partner to state in writing which items it will configure, which it will only document, and which remain the organization's own work, such as deciding who is approved for write access. Ask the certification body early which evidence samples it will select, so the export format matches what it will test.

A.8.4 Access to source code