What is ISO 27001 Annex A 8.4 – Access to Source Code?
ISO 27001 Annex A 8.4 requires organizations to appropriately restrict access to source code.
Source code is a critical information asset for software companies. Unauthorized access to source code can lead to intellectual property theft, malicious code changes, security vulnerabilities, data exposure, or loss of competitive advantage.
Source code can include:
- Application source code
- Backend and frontend code
- Mobile application code
- Infrastructure-as-Code (IaC)
- Automation scripts
- Database scripts
- Configuration files
- Build and deployment scripts
- APIs and integrations
- Internal tools
- Security-related code
- Proprietary algorithms
- Open-source components and customized code
Simple Explanation
Only authorized people should be able to access or modify source code, and their access should be controlled according to their role and business need.
For a startup, this does not necessarily mean creating a complicated security system.
A properly configured GitHub, GitLab, Bitbucket, or similar repository with role-based access, branch protection, MFA, approval requirements, and periodic access reviews may provide much of the required control.
Why is Access to Source Code Important?
Source code is often one of the most valuable assets of a technology organization.
If unauthorized users obtain access, they may:
- Steal intellectual property
- Introduce malicious code
- Create security vulnerabilities
- Modify authentication mechanisms
- Insert backdoors
- Expose secrets or credentials
- Copy proprietary algorithms
- Leak customer-related logic
- Manipulate production deployment processes
- Delete repositories or branches
- Introduce vulnerable dependencies
- Circumvent security controls
For SaaS companies, source-code security is particularly important because developers may have access to both the application code and the systems that deploy it.
Simple Principle
Not everyone who works in technology needs access to every repository.
Access should be based on:
Role + Business Need + Least Privilege + Authorization
What Does ISO 27001 Annex A 8.4 Require?
The organization should establish appropriate controls for managing access to source code.
This generally means controlling:
- Who can access source code
- Which repositories they can access
- What level of access they receive
- Who can modify source code
- Who can approve changes
- Who can merge changes
- Who can delete repositories or branches
- Who can create releases
- Who can deploy code
- How privileged source-code access is monitored
- How access is reviewed
- How access is removed when no longer required
The controls should be proportionate to the organization’s risks.
A 15-person startup may not need the same controls as a large financial institution, but it should still demonstrate that source-code access is controlled.
What is Source-Code Access Control?
Source-code access control means determining:
Who can access what code, what can they do with it, and under what conditions?
For example:
| User | Repository | Access |
|---|---|---|
| Developer | Product API | Read + Write |
| Developer | Production Infrastructure | Read |
| DevOps Engineer | Infrastructure | Read + Write |
| Security Team | Security Tools | Read |
| Product Manager | Product Repository | Read |
| HR | Product Repository | No Access |
| External Contractor | Specific Project | Temporary Read + Write |
| CTO | All Critical Repositories | Administrative |
The exact access model should depend on business requirements and risk.
Source Code Repositories
Source code is commonly stored in platforms such as:
- GitHub
- GitLab
- Bitbucket
- Azure DevOps
- Internal Git servers
- Other approved source-code management platforms
Organizations should understand what repositories exist and who has access to them.
A basic repository inventory might look like:
| Repository | Business Purpose | Classification | Owner | Criticality |
|---|---|---|---|---|
| Customer Portal | Customer application | Confidential | Engineering | High |
| Mobile App | Mobile application | Confidential | Engineering | High |
| Infrastructure | Cloud infrastructure | Restricted | DevOps | Critical |
| Internal Tools | Internal applications | Confidential | Engineering | Medium |
| Marketing Website | Public website | Internal | Marketing/IT | Low |
Activities Required to Implement Annex A 8.4
1. Identify Source-Code Repositories
First identify where organizational source code is stored.
Include:
- GitHub repositories
- GitLab repositories
- Bitbucket projects
- Internal repositories
- Infrastructure repositories
- Scripts
- Automation repositories
- Mobile applications
- Development tools
- Archived repositories
Do not limit the inventory to the main application.
Infrastructure and automation code can also contain highly sensitive information.
2. Identify Repository Owners
Every important repository should have an identified owner or responsible team.
Example:
| Repository | Owner |
|---|---|
| Customer Application | CTO / Engineering |
| Production Infrastructure | DevOps |
| Security Automation | Security Team |
| Mobile Application | Mobile Engineering |
| Internal HR Application | Internal IT |
This makes it easier to manage access and perform reviews.
3. Classify Source Code
Not every repository necessarily has the same sensitivity.
For example:
| Classification | Example |
|---|---|
| Public | Open-source project |
| Internal | Internal utility |
| Confidential | Commercial application |
| Restricted | Authentication/security code |
| Highly Restricted | Critical infrastructure or security tooling |
The classification should align with the organization’s information-classification approach.
4. Define Access Roles
Define appropriate roles for source-code repositories.
Typical roles may include:
- Repository administrator
- Maintainer
- Developer
- Reviewer
- Read-only user
- DevOps engineer
- Security engineer
- External contractor
Avoid giving administrative permissions simply because someone is a developer.
5. Apply Least Privilege
Users should receive only the access required for their responsibilities.
For example:
A frontend developer may require:
- Frontend repository → Write
- Backend repository → Read
- Infrastructure repository → No access or Read
- Production deployment system → No direct access
This reduces the potential impact of a compromised developer account.
6. Separate Code Access From Production Access
Source-code access and production access are related but different.
A developer may need to modify application code without having unrestricted access to production systems.
A good model could be:
Developer → Code Repository → Pull Request → Review → CI/CD → Approved Deployment
rather than:
Developer → Source Code → Direct Production Modification
This separation reduces the risk of unauthorized production changes.
7. Protect Repository Administrative Access
Administrative access to source-code platforms should receive stronger protection.
Examples include:
- MFA
- Strong authentication
- Separate administrator accounts
- Limited number of administrators
- Privileged access management where appropriate
- Logging
- Monitoring
- Periodic access review
Repository administrator accounts can often:
- Change permissions
- Delete repositories
- Modify branch protection
- Add collaborators
- Change security settings
- Access private repositories
Therefore, administrative access should be tightly controlled.
8. Protect Source Code From Unauthorized Modification
Organizations should implement mechanisms to prevent unauthorized changes.
Examples:
- Pull requests
- Code review
- Branch protection
- Protected main/master branches
- Required approvals
- Status checks
- CI/CD validation
- Commit controls
- Signed commits where appropriate
- Restricted direct pushes
For example:
Developer creates branch → Developer submits pull request → Reviewer approves → Automated checks pass → Code is merged.
9. Control Direct Changes to Critical Branches
Critical branches such as main, master, or production branches should generally have stronger controls.
Possible controls include:
- Prevent direct pushes
- Require pull requests
- Require one or more reviewers
- Require successful automated tests
- Require security checks
- Restrict branch deletion
- Restrict force pushes
The exact configuration should be based on the organization’s risk.
10. Control External and Contractor Access
Startups frequently work with:
- Freelancers
- Development agencies
- Contractors
- Consultants
- Offshore development teams
- Temporary developers
Their access should be:
- Authorized
- Limited to required repositories
- Limited to required duration
- Protected with appropriate authentication
- Reviewed
- Removed when the engagement ends
Example
A contractor working on the mobile application does not automatically need access to:
- Production infrastructure
- Security repositories
- HR systems
- Financial repositories
- Unrelated customer applications
11. Protect Secrets in Source Code
One of the most important practices is:
Do not store passwords, API keys, access tokens, private keys, or other secrets directly in source code.
Examples of secrets include:
- AWS access keys
- Database passwords
- API tokens
- Private encryption keys
- OAuth secrets
- Cloud credentials
- Service-account credentials
Use appropriate mechanisms such as:
- Secret managers
- Environment variables
- CI/CD secret stores
- Vault solutions
- Cloud secret-management services
Organizations should also consider automated secret scanning.
12. Review Source-Code Access Periodically
Access should not remain permanently simply because it was once approved.
Periodic reviews should identify:
- Former employees
- Transferred employees
- Inactive accounts
- Excessive permissions
- External collaborators
- Temporary access that has expired
- Unnecessary administrators
- Shared accounts
- Unexpected repository access
Example:
Quarterly repository access review → Repository owner reviews users → Unnecessary access removed → Evidence retained.
13. Remove Access When Employment or Role Changes
Source-code access should be integrated with the joiner-mover-leaver process.
Employee leaves
HR notification → Account disabled → Repository access removed → Tokens revoked → SSH keys/API access reviewed → Privileged access removed
Employee changes role
Role change → New access approved → Old access reviewed → Unnecessary repository permissions removed
This connects A.8.4 with:
- A.6.5 – Responsibilities After Termination or Change of Employment
- A.5.16 – Identity Management
- A.5.18 – Access Rights
Startup Example
Example: 40-Person SaaS Startup
A SaaS startup uses:
- GitHub
- AWS
- Google Workspace
- Slack
- Jira
- CI/CD pipeline
- Production database
The organization has:
- 15 developers
- 3 DevOps engineers
- 2 security personnel
- 1 CTO
- External development contractors
Current Problem
All developers have access to almost every private repository.
Several developers also have administrative GitHub permissions.
Contractors have permanent access even after completing their projects.
There is no formal repository access review.
Improved Approach
The startup creates a repository access matrix.
| Role | Application | Infrastructure | Security | Admin |
|---|---|---|---|---|
| Developer | Write | Read/No Access | No/Read | No |
| Senior Developer | Write | Read | Read | No |
| DevOps | Read/Write | Write | Read | Limited |
| Security | Read | Read | Write | Limited |
| CTO | Admin | Admin | Admin | Admin |
| Contractor | Project-specific | No | No | No |
The organization then implements:
MFA → Role-based access → Branch protection → Pull requests → Code review → Secret scanning → Access reviews → Immediate removal when access is no longer required
This creates a practical and auditable source-code access model.
Source-Code Access Review
A simple access review can look like this:
| User | Role | Repository | Current Access | Required? | Action |
|---|---|---|---|---|---|
| Developer A | Developer | Customer App | Write | Yes | Retain |
| Developer B | Developer | Infrastructure | Admin | No | Reduce |
| Contractor A | Contractor | Mobile App | Write | Yes | Retain temporarily |
| Former Employee | Former Employee | Customer App | Write | No | Remove |
| DevOps A | DevOps | Infrastructure | Admin | Yes | Retain |
| Product Manager | Product | Customer App | Write | No | Reduce |
The review should be approved by the appropriate repository owner or authorized management.
Source-Code Change Workflow
A practical startup workflow can be:
Developer
↓
Create Branch
↓
Make Code Changes
↓
Commit / Push
↓
Pull Request
↓
Automated Security & Quality Checks
↓
Code Review
↓
Approval
↓
Merge
↓
CI/CD
↓
Deployment
This creates separation between:
Development → Review → Approval → Deployment
What Evidence Can an Auditor Ask For?
An auditor may request evidence such as:
Governance
- Information Security Policy
- Access Control Policy
- Source Code Access Procedure
- Secure Development Policy
- Acceptable Use Policy
Repository Evidence
- Repository inventory
- Repository ownership records
- Access-control settings
- Repository permissions
- Branch protection configuration
- Pull request records
- Code review records
Identity and Access Evidence
- GitHub/GitLab user list
- MFA configuration
- Administrator list
- Access approval records
- Access review records
- Joiner/mover/leaver records
- Contractor access records
Security Evidence
- Secret scanning configuration
- Vulnerability scanning
- CI/CD security checks
- Security alerts
- Audit logs
- Repository activity logs
Offboarding Evidence
- Terminated employee access removal
- Contractor access removal
- Token revocation
- SSH key removal
- Repository access review
ISO 27001 Annex A 8.4 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Are source-code repositories identified? | Repository inventory | |
| Does each important repository have an owner? | Repository ownership register | |
| Is source-code access role-based? | Access matrix | |
| Is least privilege applied? | Permission configuration | |
| Is administrator access restricted? | Admin list | |
| Is MFA enabled for repository accounts? | Platform configuration | |
| Are critical branches protected? | Branch settings | |
| Are pull requests required where appropriate? | Repository settings | |
| Are code changes reviewed? | Pull requests | |
| Are external developers controlled? | Contractor access records | |
| Are secrets prevented from being stored in code? | Secret scanning | |
| Are source-code permissions periodically reviewed? | Access review | |
| Is access removed after termination? | Offboarding evidence | |
| Are source-code changes logged? | Audit logs | |
| Are source-code repositories backed up or recoverable where required? | Backup/recovery evidence |
Common Mistakes
1. Giving Every Developer Administrator Access
Being a developer does not automatically require repository administrator privileges.
2. Shared Git Accounts
Avoid accounts such as:
developer@company.com
being shared by multiple developers.
Individual accounts provide accountability.
3. No MFA
Source-code repositories are high-value targets.
MFA should be appropriately implemented for users with repository access, particularly privileged users.
4. Storing Secrets in Code
Examples:
password = "CompanyPassword123"
or:
AWS_ACCESS_KEY = "..."
This creates significant security risk.
5. Direct Production Changes
Allowing developers to make unrestricted changes directly in production can bypass review and change-management controls.
6. No Contractor Offboarding
A contractor who completed work six months ago should not automatically retain repository access.
7. No Periodic Access Review
Access can become excessive over time as employees change teams and responsibilities.
8. Protecting the Repository but Ignoring CI/CD
Source-code security is not limited to GitHub/GitLab permissions.
CI/CD systems may have access to:
- Source code
- Production systems
- Cloud credentials
- Deployment keys
- Secrets
Therefore, the complete development and deployment chain should be considered.
Practical Startup Implementation Model
A startup can implement Annex A 8.4 using this simple model:
Identify → Classify → Assign Ownership → Authorize → Restrict → Protect → Review → Monitor → Remove → Improve
Step 1 – Identify
List repositories and source-code locations.
Step 2 – Classify
Identify which repositories are sensitive or critical.
Step 3 – Assign Ownership
Assign responsible owners.
Step 4 – Authorize
Determine who actually needs access.
Step 5 – Restrict
Apply least privilege and role-based access.
Step 6 – Protect
Use MFA, branch protection, code review, secret scanning, and appropriate security controls.
Step 7 – Review
Perform periodic access reviews.
Step 8 – Monitor
Review repository activity and administrative actions.
Step 9 – Remove
Immediately remove unnecessary access.
Step 10 – Improve
Review incidents, audit findings, and changing development practices.
Policy vs. Process vs. Evidence
It is useful to distinguish these three.
| Type | Example |
|---|---|
| Policy | Source code must only be accessible to authorized personnel |
| Process | Repository access is approved by the repository owner |
| Configuration | GitHub branch protection requires two approvals |
| Evidence | Pull request showing reviewer approval |
| Record | Quarterly source-code access review |
| Technical Control | MFA and secret scanning |
A policy alone does not demonstrate effective control.
The auditor will usually want to see how the requirement is actually implemented.
What Should a Startup Document?
A startup does not necessarily need a large number of documents.
A practical documentation set could include:
- Source Code Access Policy – [Insert Draft Document Link]
- Source Code Access Procedure – [Insert Draft Document Link]
- Source Code Repository Inventory – [Insert Draft Document Link]
- Repository Access Matrix – [Insert Draft Document Link]
- Source Code Access Review Checklist – [Insert Draft Document Link]
- Developer Offboarding Checklist – [Insert Draft Document Link]
- Secure Development Policy – [Insert Draft Document Link]
- Source Code Change Management Procedure – [Insert Draft Document Link]
- Third-Party Developer Access Procedure – [Insert Draft Document Link]
- Source Code Security Audit Checklist – [Insert Draft Document Link]
ISO 27001 Annex A 8.4 and GitHub/GitLab
For many startups, the source-code platform itself becomes an important security boundary.
Organizations should consider:
Account Security
- Individual accounts
- MFA
- Strong authentication
- Controlled administrator accounts
Repository Security
- Private repositories where appropriate
- Role-based permissions
- Repository ownership
- Branch protection
- Pull requests
Development Security
- Code review
- Dependency scanning
- Secret scanning
- Security testing
- CI/CD security checks
Access Governance
- Access approvals
- Periodic reviews
- Contractor controls
- Termination controls
Monitoring
- Repository audit logs
- Administrative activity
- Permission changes
- Suspicious activity
A.8.4 vs A.8.2 – Privileged Access Rights
These controls are related but different.
| Control | Focus |
|---|---|
| A.8.2 | Privileged access rights |
| A.8.4 | Access to source code |
Example
A DevOps engineer may have privileged AWS access under A.8.2.
Their access to the company’s infrastructure repository is controlled under A.8.4.
Both controls may apply to the same person but address different risks.
A.8.4 vs A.8.3 – Information Access Restriction
| Control | Focus |
|---|---|
| A.8.3 | Restrict access to information and associated assets |
| A.8.4 | Specifically control access to source code |
A.8.4 provides specific protection for source-code access within the broader information-access framework.
A.8.4 vs A.8.5 – Secure Authentication
| Control | Focus |
|---|---|
| A.8.4 | Who can access source code |
| A.8.5 | How users/systems securely authenticate |
For example:
A.8.4: Only engineering staff can access the private repository.
A.8.5: Those users must authenticate using appropriate strong authentication mechanisms.
Questions an Auditor May Ask
1. Where is your source code stored?
The organization should be able to identify its repositories.
2. Who has access?
Provide the repository access list.
3. Who approves access?
Explain the approval process.
4. How do you prevent excessive access?
Show the access matrix and permissions.
5. How do you protect administrative access?
Demonstrate MFA and restricted administrator permissions.
6. How do you prevent unauthorized code changes?
Show branch protection, pull requests, approvals, and CI/CD controls.
7. What happens when an employee leaves?
Demonstrate the offboarding process.
8. How often do you review repository access?
Show access-review evidence.
9. How do you control contractors?
Show temporary access and approval records.
10. How do you prevent credentials from being committed to source code?
Demonstrate secret-scanning or equivalent controls.
Startup-Focused Quick Summary
For a startup, Annex A 8.4 can be implemented without building an overly complicated system.
Minimum practical approach
1. Inventory repositories
Know where your source code exists.
2. Assign owners
Every important repository should have a responsible owner.
3. Use individual accounts
Avoid shared developer accounts.
4. Enable MFA
Especially for privileged and repository-administrator accounts.
5. Apply least privilege
Developers should only access repositories they need.
6. Protect critical branches
Use pull requests and code reviews.
7. Control contractors
Give temporary, project-specific access.
8. Protect secrets
Do not store credentials directly in source code.
9. Review access
Perform periodic repository access reviews.
10. Remove access
Immediately remove access when it is no longer required.
Practical Example of a Small Startup
A 20-person SaaS startup may only need:
GitHub
↓
Individual Accounts
↓
MFA
↓
Role-Based Repository Access
↓
Protected Main Branch
↓
Pull Request
↓
Code Review
↓
Automated Security Checks
↓
Merge
↓
CI/CD Deployment
This can provide a strong practical foundation for Annex A 8.4.
The organization does not need to implement every advanced security technology simply because ISO 27001 mentions source-code protection.
The objective is to demonstrate that source-code access and modification are appropriately controlled based on risk.
Relationship With Other ISO 27001 Controls
Annex A 8.4 works closely with:
- A.5.9 – Inventory of Information and Other Associated Assets
- A.5.12 – Classification of Information
- A.5.15 – Access Control
- A.5.16 – Identity Management
- A.5.17 – Authentication Information
- A.5.18 – Access Rights
- A.6.3 – Information Security Awareness, Education and Training
- A.6.5 – Responsibilities After Termination or Change of Employment
- A.6.8 – Information Security Event Reporting
- A.8.1 – User Endpoint Devices
- A.8.2 – Privileged Access Rights
- A.8.3 – Information Access Restriction
- A.8.5 – Secure Authentication
- A.8.8 – Management of Technical Vulnerabilities
- A.8.9 – Configuration Management
- A.8.15 – Logging
- A.8.16 – Monitoring Activities
- A.8.25 – Secure Development Life Cycle
- A.8.26 – Application Security Requirements
- A.8.28 – Secure Coding
Together, these controls help establish a secure software-development environment.
Useful Resources
For implementing Annex A 8.4, organizations can maintain:
- [Source Code Access Policy – Insert Draft Document Link]
- [Source Code Access Procedure – Insert Draft Document Link]
- [Repository Inventory Template – Insert Draft Document Link]
- [Repository Access Matrix – Insert Draft Document Link]
- [Source Code Access Review Template – Insert Draft Document Link]
- [Developer Offboarding Checklist – Insert Draft Document Link]
- [Secure Coding Policy – Insert Draft Document Link]
- [Source Code Change Management Procedure – Insert Draft Document Link]
- [Third-Party Developer Access Form – Insert Draft Document Link]
- [Source Code Security Audit Checklist – Insert Draft Document Link]
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.4 is not simply about protecting GitHub or GitLab.
It is about protecting one of the organization’s most valuable information assets: its source code.
A practical startup approach is:
Know your repositories → Know who has access → Apply least privilege → Protect privileged access → Review code changes → Protect secrets → Review access regularly → Remove unnecessary access.
The most important question is not:
“Do we have GitHub?”
The important question is:
“Can we demonstrate that only authorized people can access and modify our source code, and that those permissions are appropriate, reviewed, and removed when no longer required?”
If the answer is yes, the organization has a much stronger foundation for implementing ISO 27001 Annex A 8.4.
One-Line Summary
ISO 27001 Annex A 8.4 ensures that access to source code is authorized, restricted, protected, reviewed, and controlled throughout the source-code lifecycle.