ISO 27001 A.8.4: source code access, explained for startups

A.8.4 Access to source code

Only the right people can read or change your source code. What proves it: the people with access to your code repositories, and the rules that protect the main branch.

A certification auditor samples code repository access list. A file that usually does the job: a code host member list with roles, and branch protection settings on the main branch.

How to put it in place

Each step leaves a record, and the record is what the auditor samples rather than the step itself. Inside Polara, the control card for A.8.4 walks you through it in this order.

1. Give repository access through teams in your code host.
2. Protect the main branch so every change needs review.
3. Review the member list every quarter.

The free ISO 27001 readiness assessment asks one question that evidences it:

• How do code changes reach production?

Policies, connectors and the SOC 2 overlap

In the ISO 27001 policy pack, the Secure Development and Change Management Policy covers A.8.4. An auditor reads the policy for the rule, then samples the records to see the rule was followed.

The same evidence counts toward SOC 2. The Trust Services criteria that cover this ground: CC6.1, logical access and CC8.1, change management.

Technological controls

A.8.4 is one of the 34 technological controls in Annex A. The controls built into your systems: access, devices, malware, vulnerabilities, backups, logging, networks, encryption and secure development. Exports and settings screenshots prove most of them.

Nearby controls in the same theme:

• A.8.1, laptops and phones
• A.8.2, privileged access
• A.8.3, restricting access to data
• A.8.5, secure sign in
• A.8.6, capacity
• A.8.7, malware protection

Before it: A.8.3, restricting access to data. After it: A.8.5, secure sign in. Every control, by theme, is on the Annex A controls page.