Auditing ISO 27001 Annex A 8.4 Access to Source Code is the technical verification of administrative and logical barriers surrounding development environments. The Primary Implementation Requirement is strict repository access restriction and peer review enforcement, providing the Business Benefit of protecting intellectual property and preventing unauthorised software alterations.
ISO 27001 Annex A 8.4 Access to Source Code Audit Checklist
This technical verification tool is designed for lead auditors to confirm the protection of intellectual property and prevent unauthorised software modification. Use this checklist to validate compliance with ISO 27001 Annex A 8.4.
1. Source Code Access Policy Formalisation Verified
Verification Criteria: A documented policy exists defining the strict ‘need-to-know’ requirements and authorisation levels for accessing program source code.
Required Evidence: Approved Secure Coding Policy or Version Control Access Standard with defined developer roles.
Pass/Fail Test: If the organisation cannot produce a formal policy restricting source code access to specific authorised personnel, mark as Non-Compliant.
2. Repository Access Control Integrity Confirmed
Verification Criteria: Access to Version Control Systems (VCS) is restricted to authorised developers only, with no public or unauthenticated access allowed.
Required Evidence: Repository settings from GitHub, GitLab, or Bitbucket showing ‘Private’ status and a list of active authorised collaborators.
Pass/Fail Test: If any production repository is found set to ‘Public’ or accessible without unique user authentication, mark as Non-Compliant.
3. Multi-Factor Authentication (MFA) for VCS Enforced
Verification Criteria: All developer accounts with access to the source code repository are required to use Multi-Factor Authentication for login.
Required Evidence: MFA enforcement reports from the VCS provider showing 100% compliance across all developer seats.
Pass/Fail Test: If the organisation permits developers to access the code repository using only a username and password, mark as Non-Compliant.
4. Least Privilege Branch Protection Validated
Verification Criteria: Protection rules are active on primary branches (e.g. main, master, production) to prevent direct pushing and require peer review.
Required Evidence: Branch protection rule configurations in the VCS showing mandatory pull request (PR) approvals and blocked force-pushes.
Pass/Fail Test: If a developer can unilaterally push code directly to the production branch without a second-party review, mark as Non-Compliant.
5. External Contractor Access Segregation Verified
Verification Criteria: Third-party developers or contractors are restricted to specific sub-repositories or branches relevant only to their assigned tasks.
Required Evidence: Access control list (ACL) showing contractors are excluded from core repositories or highly sensitive internal projects.
Pass/Fail Test: If a contractor is granted ‘Owner’ or global ‘Admin’ rights to the entire organisation’s code portfolio, mark as Non-Compliant.
6. Source Code Extraction and Export Restrictions Confirmed
Verification Criteria: Technical controls or documented procedures are in place to prevent the unauthorised download or extraction of the code base to personal devices.
Required Evidence: Data Loss Prevention (DLP) logs, MDM configurations, or signed agreements prohibiting local code storage on unmanaged hardware.
Pass/Fail Test: If developers can clone the entire production repository onto a personal, unencrypted device without technical restriction or audit, mark as Non-Compliant.
7. Personal Identity Provider (IdP) Integration Validated
Verification Criteria: Access to the code repository is integrated with the corporate Identity Provider to ensure immediate access revocation upon termination.
Required Evidence: SSO (Single Sign-On) or SCIM configuration connecting the VCS to the corporate directory (e.g. Okta, Azure AD).
Pass/Fail Test: If the VCS uses standalone local accounts not linked to the central IdP, allowing access to persist after HR termination, mark as Non-Compliant.
8. Audit Logging of Repository Activity Verified
Verification Criteria: All administrative changes, access events, and code extractions are recorded in an immutable audit log.
Required Evidence: Export of VCS audit logs showing events such as ‘Repository Created’, ‘User Added’, and ‘Code Downloaded’.
Pass/Fail Test: If the organisation cannot produce an audit trail of who accessed or modified repository permissions in the last 90 days, mark as Non-Compliant.
9. Removal of Hardcoded Credentials Confirmed
Verification Criteria: Technical scanning tools are utilised to ensure that source code does not contain hardcoded secrets, keys, or passwords.
Required Evidence: Reports from Secret Scanning tools (e.g. GitHub Secret Scanning, GitGuardian) showing zero active high-risk secrets in the code.
Pass/Fail Test: If a manual or automated check reveals plain-text API keys or DB passwords within the code repository, mark as Non-Compliant.
10. Periodic Access Rights Review Records Present
Verification Criteria: Management performs a formal review of repository access rights at regular intervals (e.g. quarterly) to prune unnecessary access.
Required Evidence: Documented Access Review meeting minutes or signed reports cross-referencing repository users against active projects.
Pass/Fail Test: If there is no evidence of a formal review of developer access rights in the last six months, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Access Restriction | Tool checks if “GitHub is connected” and marks as green. | Verify Permission Granularity. GRC tools often ignore ‘Shadow’ repositories or personal forks containing corporate code. |
| MFA Enforcement | GRC dashboard reports “MFA: Yes” based on a static setting. | Check the Exemptions. Verify if ‘Bot’ accounts or SSH keys bypass MFA requirements for repository access. |
| Branch Protection | Tool assumes developers follow a ‘policy’. | Demand Configuration Proof. GRC tools cannot see if the ‘production’ branch actually has ‘0 mandatory reviewers’ set in the VCS. |
| Leaver Revocation | Platform identifies a user is ‘Inactive’ in HR. | Verify Personal Emails. Many tools fail to flag developers who use personal GitHub handles to access corporate repos. |
| Extraction Control | Tool relies on a “Don’t Copy Code” clause in the contract. | Check Endpoint Logs. If a developer can git clone to an unmanaged home PC, the “Control” is a legal wish, not a security reality. |
| Secret Management | Platform ignores the content of the repository. | Run a Secret Scanner. If the GRC tool says you’re compliant but your repo contains AWS keys, the tool has failed. |
| Access Review | Tool creates an automated ‘Task’ every 12 months. | Check the Delta. Developers move projects weekly. Annual reviews are too slow to stop ‘Privilege Creep’ in high-velocity dev teams. |
About the author
