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.

ISO 27001 Annex A 8.4 Audit Checklist [+ Templates]

Q: 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.

Q: 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.

Q: 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.

In this ultimate how to audit guide to ISO 27001 Annex A 8.4 Access to Source Code, you will learn directly from an ISO 27001 Lead Auditor:

10 Key Audit Steps
Verification Criteria
Required Evidence
The Pass / Fail Test

I am Stuart Barker, the ISO 27001 Lead Auditor and author of the Ultimate ISO 27001 Toolkit.

Using over 30 years of industry experience across hundreds of audits, I’m giving you the exact templates, walkthroughs, and practical examples you need to achieve ISO 27001 certification.

ISO 27001 Annex A 8.4 Access to Source Code Audit Checklist

ISO 27001 Annex A 8.4 Access to Source Code Audit Checklist

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.

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.

READ THE FULL ARTICLE

Access to Business and Consultant Toolkit Members Only.

Get the Toolkit

Members Login

How to Audit ISO 27001 Annex A 8.4: Access to Source Code

Table of contents

ISO 27001 Annex A 8.4 Access to Source Code Audit Checklist

1. Source Code Access Policy Formalisation Verified

2. Repository Access Control Integrity Confirmed

3. Multi-Factor Authentication (MFA) for VCS Enforced