Source Code Access Review Checklist

1. Purpose

The Source Code Access Review Checklist provides a structured process for reviewing access to source-code repositories, development platforms, CI/CD systems, package registries, code-hosting platforms, and related development environments.

The objective is to verify that:

Access is business-justified
Users have only the permissions they require
Privileged repository access is controlled
Former users no longer have access
Contractor and supplier access is controlled
Production-related access is appropriately restricted
Authentication and MFA requirements are enforced
Repository activity is logged where appropriate
Service accounts and automation identities are reviewed
Access remains aligned with current roles
Excessive or unnecessary access is removed
Review evidence is retained

Core Principle

Identify → Verify Need → Review Permissions → Validate Authentication → Assess Risk → Remove Excess Access → Approve → Record → Monitor

2. When to Use

Use this checklist:

During periodic access reviews
Before granting source-code access
After role changes
During employee transfers
During contractor onboarding
During contractor offboarding
After organizational changes
After security incidents
When repositories become production-critical
When new repositories are created
When privileged access is requested
When access-control weaknesses are identified

3. Review Information

Field	Details
Review ID
Review Date
Repository/Platform
Repository Owner
Application/System
Business Owner
Technical Owner
Security Reviewer
Environment
Review Period
Next Review Date
Review Status

Review Status

☐ Completed
☐ Completed with Actions
☐ Further Review Required
☐ Remediation Required

4. Source Code Repository Information

Record the repository being reviewed.

Field	Details
Repository Name
Repository URL/Identifier
Platform
Business Application
Environment
Classification
Repository Owner
Criticality
Production Dependency
Customer Impact

Repository Type

☐ Application
☐ Backend
☐ Frontend
☐ Mobile
☐ Infrastructure-as-Code
☐ Configuration
☐ Scripts
☐ Security tooling
☐ CI/CD
☐ Data/analytics
☐ Other: __________________

5. Information Classification

Determine the classification of information contained in or accessible through the repository.

☐ Public
☐ Internal
☐ Confidential
☐ Restricted

Consider whether the repository contains:

☐ Proprietary source code
☐ Customer-related information
☐ Personal data
☐ Security configuration
☐ Infrastructure configuration
☐ Architecture information
☐ Credentials/secrets
☐ Encryption configuration
☐ API configuration
☐ Business logic
☐ Intellectual property

6. Repository Criticality

Assess the importance of the repository.

☐ Non-critical development repository
☐ Important internal application
☐ Customer-facing application
☐ Business-critical application
☐ Security-critical application
☐ Production infrastructure
☐ CI/CD or deployment infrastructure

Criticality Rationale

7. Access Population

Obtain the current access list from the source-code platform.

User/Identity	Type	Role	Access Level	MFA	Last Activity	Action
	Employee
	Contractor
	Service Account
	Supplier

Identity Types

☐ Employee
☐ Contractor
☐ Consultant
☐ Supplier
☐ Customer
☐ Service account
☐ CI/CD identity
☐ Bot
☐ Application identity
☐ Organization/admin account

8. Business Need Verification

For every user, confirm:

☐ Current employment/engagement verified
☐ Current role verified
☐ Business need exists
☐ Repository is relevant to role
☐ Access is still required
☐ Access level is appropriate
☐ No unnecessary duplicate access
☐ Manager/owner confirmation obtained where required

Business Justification

9. User Access Review

User	Role	Business Need	Current Access	Required Access	Decision

Decision

☐ Retain
☐ Reduce
☐ Remove
☐ Change role
☐ Temporary extension
☐ Further investigation

10. Access Level Review

Determine the actual permission assigned.

Typical levels may include:

Read
Triage
Write
Maintain
Admin
Owner

Record the platform-specific permission where applicable.

User	Current Permission	Required Permission	Excess Access	Action

Principle

Access should be sufficient for the business role but no broader than necessary.

11. Read Access

For read-only users:

☐ Business need confirmed
☐ Repository relevance confirmed
☐ Confidential information exposure assessed
☐ Customer information exposure assessed
☐ Access still required
☐ External sharing reviewed

12. Write Access

For users who can modify source code:

☐ Business need confirmed
☐ Role requires code modification
☐ Code review requirements apply
☐ Branch protection applies
☐ Direct production branch modification restricted where appropriate
☐ Commit identity traceable
☐ MFA enabled
☐ Access monitored

13. Administrative Access

For repository administrators:

☐ Business justification documented
☐ Named individual account used
☐ MFA enabled
☐ Administrative actions logged where available
☐ Number of administrators minimized
☐ Privileged access periodically reviewed
☐ Emergency access controlled
☐ Administrative access not shared
☐ Access removal process defined

Administrator Review

Administrator	Business Need	Current Role	Required?	Action

14. Repository Ownership

Verify:

☐ Repository owner identified
☐ Business owner identified
☐ Technical owner identified
☐ Security responsibility identified
☐ Ownership documented
☐ Backup owner identified where appropriate

Avoid repositories with no identifiable accountable owner.

15. Authentication

Verify that appropriate authentication controls are enabled.

☐ Individual accounts
☐ Strong authentication
☐ MFA
☐ SSO where appropriate
☐ Central identity management where appropriate
☐ No shared user accounts
☐ Account lifecycle integrated with organizational process
☐ Authentication events logged where appropriate

16. Multi-Factor Authentication

For repositories containing sensitive or production-related source code:

☐ MFA required
☐ MFA enforced rather than optional where appropriate
☐ Privileged accounts protected by MFA
☐ External/contractor accounts protected by MFA
☐ Recovery methods controlled
☐ Legacy authentication reviewed

17. Shared Accounts

Identify shared accounts.

☐ No shared accounts
☐ Shared account identified
☐ Business justification documented
☐ Individual accountability maintained
☐ Compensating controls implemented
☐ Shared credential rotation defined

Where practical, replace shared accounts with named identities.

18. Contractor Access

For contractors:

☐ Contractor engagement verified
☐ Contract active
☐ Business owner confirmed
☐ NDA/confidentiality requirements addressed
☐ Repository access justified
☐ Access level appropriate
☐ MFA enabled
☐ Expiry date defined
☐ Access monitored
☐ Offboarding process defined

Contractor Access

Contractor	Company	Repository	Access	Expiry	Owner

19. Supplier/Third-Party Access

For external organizations:

☐ Supplier identified
☐ Contract verified
☐ Security requirements reviewed
☐ Access purpose documented
☐ Access scope limited
☐ Named accounts used
☐ MFA enabled
☐ Expiry defined
☐ Supplier owner identified
☐ Access periodically reviewed

20. Temporary Access

Identify temporary access.

User	Purpose	Access	Start	Expiry	Approver

Verify:

☐ Business justification
☐ Approval
☐ Time limitation
☐ Automatic expiry where practical
☐ Monitoring
☐ Revocation after completion

21. Former Employees

Check for terminated or inactive personnel.

☐ Former employees identified
☐ Accounts disabled
☐ Repository access removed
☐ Organization membership removed
☐ SSH keys removed
☐ Personal access tokens revoked
☐ OAuth/application access reviewed
☐ Active sessions addressed

Former User Review

User	Termination Date	Access Found	Revoked	Evidence

22. Role Changes

Identify users whose organizational role has changed.

☐ Role changes reviewed
☐ Previous access reassessed
☐ New access justified
☐ Excess access removed
☐ Repository memberships updated
☐ Privileged access reassessed

23. Repository Groups and Teams

Review group-based access.

☐ Groups identified
☐ Group membership reviewed
☐ Group permissions appropriate
☐ Legacy groups removed
☐ Nested groups reviewed
☐ Privileged groups restricted
☐ Unused groups removed

24. Organization-Level Access

Where the platform provides organization-wide access:

☐ Organization membership reviewed
☐ Organization administrators reviewed
☐ Default repository access reviewed
☐ External members reviewed
☐ Guest access reviewed
☐ Organization-wide teams reviewed
☐ Unnecessary inherited permissions removed

25. Branch Protection

For important repositories:

☐ Branch protection enabled
☐ Production/main branch protected
☐ Pull request requirement
☐ Code review requirement
☐ Required reviewers defined where appropriate
☐ Direct push restrictions
☐ Status checks required
☐ Force-push restrictions
☐ Branch deletion restrictions

26. Pull Request and Code Review Access

Verify:

☐ Code review process defined
☐ Appropriate reviewers assigned
☐ Developer cannot bypass controls without authorization
☐ Sensitive changes receive appropriate review
☐ Administrative bypass privileges restricted
☐ Review evidence retained

27. Production Deployment Access

Determine whether source-code access provides a path to production.

☐ No production deployment capability
☐ CI/CD deployment access
☐ Manual deployment capability
☐ Production credentials available
☐ Infrastructure deployment capability
☐ Production administrative access

Review

☐ Production access separately authorized
☐ Separation of development and production maintained
☐ Deployment permissions restricted
☐ Privileged deployment access reviewed
☐ Deployment activity logged

28. CI/CD Access

Review access to development pipelines.

☐ Pipeline access identified
☐ Pipeline administrators reviewed
☐ Deployment permissions reviewed
☐ Build permissions reviewed
☐ Secrets access reviewed
☐ Environment permissions reviewed
☐ Production deployment approval reviewed
☐ Service accounts reviewed

29. Service Accounts and Automation Identities

Identify non-human identities.

Identity	Purpose	Repository	Permissions	Owner	Last Used	Action

Verify:

☐ Owner identified
☐ Purpose documented
☐ Permissions minimized
☐ Credentials protected
☐ Rotation defined
☐ Activity monitored
☐ Unused identities removed

30. SSH Keys

Where SSH access is supported:

☐ Keys associated with named users
☐ Unknown keys investigated
☐ Old keys removed
☐ Contractor keys reviewed
☐ Former employee keys removed
☐ Key purpose documented
☐ Key rotation addressed
☐ Deploy keys reviewed

31. Personal Access Tokens

Review:

☐ Tokens identified
☐ Token owners identified
☐ Scope reviewed
☐ Expiration configured where supported
☐ Old tokens revoked
☐ Excessively privileged tokens reduced
☐ Contractor tokens reviewed
☐ Former-user tokens revoked

Never record token values in the review.

32. OAuth and Application Access

Review connected applications.

☐ OAuth applications identified
☐ Application owners identified
☐ Permissions reviewed
☐ Unused applications removed
☐ Excessive permissions reduced
☐ Third-party applications approved
☐ Application tokens reviewed

33. Secrets in Source Code

Check whether repositories contain secrets.

☐ Secret scanning enabled
☐ Historical secret exposure considered
☐ Credentials detected
☐ Exposed credentials revoked
☐ Secrets removed
☐ Secret-management solution used
☐ Developers informed where appropriate

Examples include:

API keys
Passwords
Cloud credentials
Private keys
Database credentials
Tokens
Certificates

34. Repository Visibility

Review repository visibility.

☐ Private
☐ Internal
☐ Public
☐ Restricted

For public repositories:

☐ Public exposure intentional
☐ Business owner approval
☐ IP implications assessed
☐ Customer information excluded
☐ Confidential information excluded
☐ Secrets excluded
☐ License requirements reviewed

35. Forks and Copies

Review whether source code exists outside the primary repository.

☐ Forks identified
☐ Personal forks reviewed
☐ Contractor forks reviewed
☐ Supplier copies reviewed
☐ Archived repositories reviewed
☐ Backup copies reviewed
☐ Unauthorized copies investigated

36. Local Source-Code Copies

Where relevant, determine whether source code is stored locally.

☐ Local copies permitted
☐ Device security requirements defined
☐ Encryption enabled
☐ Access restricted
☐ Synchronization controlled
☐ Data-loss controls considered
☐ Contractor storage reviewed

37. Repository Logs and Monitoring

Verify that appropriate activities can be investigated.

☐ Login events
☐ Authentication events
☐ Repository access
☐ Administrative actions
☐ Permission changes
☐ Branch changes
☐ Repository settings changes
☐ Token/key events
☐ Deployment events

38. Suspicious Access Review

Look for indicators such as:

☐ Unusual login location
☐ Unusual access time
☐ Unexpected repository access
☐ Unexpected permission escalation
☐ Unknown SSH key
☐ Unknown token
☐ Unusual cloning/download activity
☐ Unauthorized repository creation
☐ Unexpected branch modification
☐ Unexpected administrative activity

Escalate suspicious activity according to the organization’s incident-management process.

39. Access Exceptions

Record approved exceptions.

Exception	User	Access	Reason	Risk	Compensating Control	Expiry	Approver

Exceptions should have an owner and expiry/review date where practical.

40. Access Findings

Finding ID	User/Group	Repository	Finding	Risk	Action	Owner	Due Date

41. Remediation Actions

Typical actions include:

☐ Remove unnecessary access
☐ Reduce permission level
☐ Enable MFA
☐ Remove former employee
☐ Remove contractor access
☐ Revoke token
☐ Remove SSH key
☐ Remove OAuth application
☐ Disable shared account
☐ Protect production branch
☐ Remove public exposure
☐ Rotate exposed credentials
☐ Review service account
☐ Implement logging
☐ Other: __________________

42. Risk Assessment

Assess significant access findings.

Risk	Likelihood	Impact	Risk Rating	Treatment
Excessive repository access
Unauthorized source-code access
Privileged account compromise
Former user access
Credential exposure
Contractor access
Public repository exposure
CI/CD compromise

43. Final Access Decision

For each reviewed identity:

☐ Retain current access
☐ Reduce access
☐ Remove access
☐ Change role
☐ Temporary access only
☐ Further investigation required

Summary

44. Approval

Repository Owner: ______________________

Business Owner: ________________________

Security Reviewer: ______________________

Technical Owner: _______________________

Risk Owner: ____________________________

Approval Date: __________________________

Next Review Date: _______________________

45. Evidence Retention

Retain appropriate evidence such as:

☐ Access export
☐ Repository membership list
☐ Permission report
☐ User/role confirmation
☐ Manager approval
☐ Repository owner approval
☐ Access-removal evidence
☐ MFA configuration evidence
☐ Privileged-access review
☐ Token/key review
☐ Findings
☐ Remediation evidence
☐ Exception approvals
☐ Final review record

Do not store passwords, API keys, tokens, SSH private keys, or other secrets in the checklist.

46. AWS SaaS Startup Example

A SaaS startup hosts its application on AWS and uses GitHub for source-code management.

Repository

Repository: Customer API
Classification: Confidential
Criticality: Business-critical
Production Dependency: Yes

Access Review

User	Role	Current Access	Required	Decision
CTO	Technical Owner	Admin	Admin	Retain
Senior Developer	Developer	Write	Write	Retain
Junior Developer	Developer	Write	Write	Retain
Contractor	External Developer	Write	Temporary Write	Reduce/Expiry
Former Developer	Former Employee	Write	None	Remove
CI/CD Bot	Automation	Repository access	Required scope	Retain/Review

Additional Checks

MFA enabled
Production branch protected
Pull requests required
Contractor access has an expiry date
Former employee access removed
GitHub tokens reviewed
SSH keys reviewed
AWS deployment permissions reviewed separately
Secrets scanning enabled
Production credentials not stored in source code
CI/CD service account permissions reviewed

Audit Trail

Access Export → Identity Verification → Business Need → Permission Review → Privileged Access Review → Contractor Review → Former User Review → Token/Key Review → Findings → Remediation → Approval → Evidence

47. Startup-Friendly Review Model

A startup can keep source-code access reviews simple while maintaining strong control.

Every Review

Check:

Who has access?
Why do they need it?
What permission do they have?
Do they still need that permission?
Are MFA and named accounts used?
Are contractors and former employees controlled?
Can the access lead to production?
Are service accounts and tokens controlled?
Are secrets protected?
Was unnecessary access removed?

Recommended Evidence

Keep:

Repository access export
Permission review
Owner approval
Access-removal evidence
Findings
Remediation records
Exception approvals

48. Common Mistakes

Avoid:

Reviewing only repository membership without reviewing permissions.
Treating repository access and production access as the same thing.
Allowing contractors permanent access.
Forgetting former employees.
Ignoring SSH keys and personal access tokens.
Ignoring OAuth applications.
Using shared developer accounts.
Giving all developers administrator permissions.
Allowing unrestricted production deployment.
Leaving repositories public unintentionally.
Ignoring personal forks.
Storing credentials in source code.
Failing to review CI/CD identities.
Reviewing human users but ignoring service accounts.
Removing a user without checking their tokens, SSH keys, or sessions.
Completing the review without retaining evidence.

49. Relationship With Other ISMS Documents

Document	Relationship
Access Control Policy	Defines access-control requirements
User Access Review Checklist	Reviews general user access
Privileged Access Management Procedure	Controls privileged access
Source Code Security Policy	Defines source-code protection requirements
Secure Development Policy	Controls development activities
Contractor IP Review Checklist	Reviews contractor IP ownership and access
Supplier Security Assessment	Assesses third-party security
Software License Register	Tracks software licensing
Open-Source Software Register	Tracks OSS components
SBOM	Provides software-component visibility
Secrets Management Procedure	Protects credentials and secrets
CI/CD Security Standard	Secures development pipelines
Incident Management	Handles unauthorized source-code access
Offboarding Procedure	Removes access when relationships end
Risk Register	Tracks significant access risks

50. ISO/IEC 27001 Connection

Source-code access review supports the organization’s risk-based management of:

Access control
Identity and authentication
Privileged access
Information protection
Intellectual property
Secure development
Supplier and contractor access
Logging and monitoring
Offboarding
Information-security risk

The Source Code Access Review Checklist is not itself a universally mandatory ISO/IEC 27001 document.

The organization should determine the appropriate review frequency and depth based on:

Source-code sensitivity
Business criticality
Production dependency
User privileges
Contractor/supplier access
Customer requirements
Security risk
Regulatory and contractual obligations

Applicable controls should be addressed through the organization’s risk assessment and Statement of Applicability.

51. Final Source Code Access Audit Trail

For every important source-code repository, the organization should be able to demonstrate:

Who has access?
Why do they have access?
What level of access do they have?
Is the access still required?
Who approved the access?
Are privileged users controlled?
Are contractors controlled?
Are former employees removed?
Are service accounts reviewed?
Are SSH keys and tokens controlled?
Is MFA enabled?
Can the access lead to production?
Are repository changes appropriately controlled?
Were excessive permissions removed?
What evidence proves the review occurred?

52. Final Principle

Know Who Has Access → Know Why They Have It → Verify the Permission → Protect Authentication → Control Privileged Access → Remove Excess Access → Monitor → Reassess → Preserve Evidence

Source-code access management is not simply a repository membership exercise. It connects identity, least privilege, source-code protection, intellectual property, CI/CD security, production access, contractor access, secrets, and offboarding into one defensible access-control process.