Access to source code

Plain-language summary

Controlling who can read and change source code, development tools and software libraries, so that code cannot be altered without authority, intellectual property does not walk out of the door, and secrets embedded in code are not exposed.

What the clause is really asking

Source code is both valuable intellectual property and a blueprint of how your systems could be attacked or changed, so access to it has to be managed. The control asks you to manage who can read and change code, development tools and libraries; in practice that means holding code in a central, controlled repository; granting read and write access according to role and need, with write access restricted more tightly; routing changes through approved, reviewed paths rather than direct edits; logging access and changes; and protecting development tools and libraries from tampering. Branch protection and pull-request review are the everyday mechanisms. The common misunderstanding is 'we do not develop software, so this is not applicable'. Most organisations have code somewhere: the website, integration scripts, automation flows, infrastructure templates, report queries, or the bespoke application a contractor built and still hosts. If a supplier writes your code, ask who owns the repository, who has access, and whether you could get the code back if the relationship ended. Passwords and API keys left in code are a practical part of the scope.

What auditors look for

Auditors ask where the code lives and who can reach it, then pull the repository's member list and compare it with the development team and any contractors. They check whether the main branch is protected, whether changes need a reviewed pull request, and whether anyone can push straight to production. They look for leavers and former contractors still holding access. They ask how build tools and third-party libraries are controlled. Where development is outsourced they ask for the contract clause on code ownership and access. The hard question: show me a change running in production and trace it back to who wrote it and who approved it.

Typical evidence

Source code access procedure; repository inventory with owners; repository member and permission lists; branch protection and review settings; access and change logs; records of access reviews and removals; secret-scanning configuration and results; contracts covering code ownership, access and escrow for outsourced development; controls over build tools and third-party libraries.

How to comply — recommendations

Inventory every repository you own or rely on, including the website, scripts and supplier-held code, and name an owner for each. Move code into a managed platform such as GitHub, GitLab or Azure DevOps under an organisation account you control, not a developer's personal account. Grant access through teams, give write access only to those who need it, and protect the main branch so every change needs a reviewed pull request. Enforce MFA on the platform. Switch on secret scanning and rotate any credential it finds. Review repository membership quarterly and remove leavers on the day they go. For outsourced work, put code ownership and your right of access in the contract.

Common nonconformities

Code held in developers' personal accounts or on laptops; former staff or contractors still with repository access; write access to the main branch for everyone; production changes with no review or approval trail; passwords and API keys committed to code; no agreement on ownership of, or access to, supplier-developed code; repository access never reviewed.

Resources for this clause

• ArticleISO/IEC 27001:2022 Annex A explained: the 93 controls in plain English, theme by theme, with the 114-to-93 map and the attribute tags
• ArticleThe Statement of Applicability, explained — what ISO/IEC 27001 clause 6.1.3 requires, the four ways an SoA fails Stage 1, and how to build one from the risk register
• ArticleISO/IEC 27001:2022 explained for people who already run ISO 9001: what is the same, what is new, and how to get certified
• Toolkit · $39Risk & SoA ToolkitScore your information security risks on a documented method, pick the Annex A controls that treat them, and the Statement of Applicability writes its own first draft — every justification citing the risks behind it.
• Toolkit · $29ISMS Metrics & Evidence TrackerThe three things an ISMS has to show after certification, in one workbook: measures with a live Green / Amber / Red status, management review minutes that cover every required input, and an evidence register that gives every control an owner, a rhythm and a due date.
• Free downloadAnnex A 93 Controls Quick ReferenceOne A3 page: all 93 Annex A controls in their four themes, the eleven new in 2022 flagged, and the ISO/IEC 27002:2022 attribute legend — the poster for the wall beside the Statement of Applicability.
• Free downloadISO 27001 Gap Analysis ChecklistWhere you stand against ISO/IEC 27001:2022 in one afternoon — the 30 management-system requirements and all 93 Annex A controls, scored, with owners, dates and a readiness figure that calculates itself.
• Free masterclass · ~27 minISO 27001 MasterclassYou already know four fifths of ISO 27001. Here is the other fifth — the risk method, the SoA, the 93 controls, the evidence rhythm, POPIA, and a 44-week path.
• Free appAudit ManagerPlan the programme, anchor each finding to its clause and drive the NC to closure.