Overview
The Code Review Process is a formal control that ensures all code changes are reviewed and approved before being merged into production systems. It supports SOC 2 CC8.1 by reducing the risk of unauthorized or defective changes through documented peer review.
Step-by-Step Process
Create code change request
A developer creates a pull request or merge request for each code change against the appropriate target branch. The request must include a clear description of the change, purpose, and any related ticket or issue reference. The output is a submitted code review request in the version control system.
Role: Developer
Assign reviewers
The developer or repository rules assign at least one qualified reviewer who was not the author of the change. Reviewer assignment must align with team standards for separation of duties. The output is an assigned reviewer visible in the code review tool.
Role: Engineering Lead
Perform code review
The assigned reviewer examines the code for security, functionality, and adherence to coding standards. Review comments, questions, or required changes are documented directly in the code review tool. The output is a completed review with comments or approval.
Role: Reviewer
Address review feedback
The developer updates the code to address all reviewer comments and responds within the review thread. Any new commits are automatically linked to the same review request. The output is an updated code change ready for re-review or approval.
Role: Developer
Approve code change
The reviewer formally approves the change after verifying that all feedback has been addressed. Approval must be recorded in the tool using the native approval mechanism. The output is a documented approval with reviewer name and timestamp.
Role: Reviewer
Merge approved code
Once approved, the code is merged into the target branch using protected branch rules. Only approved requests can be merged, preventing bypass of the review process. The output is a completed merge with an audit trail.
Role: Engineering Lead
Retain review records
Code review records are retained automatically in the version control system. The Engineering Lead periodically confirms that review history remains accessible for audit purposes. The output is retained review evidence with timestamps.
Role: Engineering Lead
What You Need Before Starting
- Access to the source code repository (GitHub, GitLab, or Bitbucket)
- Defined coding standards or contribution guidelines
- Change request or issue ticket reference (e.g., Jira ID)
- User accounts with reviewer and approver permissions
Evidence Your Auditor Expects
- Pull request or merge request showing reviewer approval and timestamp
- Screenshot of branch protection settings enforcing required reviews (dated)
- Commit history linked to an approved review with merge date
- Exported audit log showing review and merge activity for a specific change
How This Looks In Your Tools
GitHub
In GitHub, navigate to the repository and select the “Pull requests” tab, then click “New pull request” to create a code review. Select the base and compare branches, add a description, and assign reviewers using the “Reviewers” section on the right panel.
Reviewers open the pull request, select the “Files changed” tab, add inline comments, and choose “Approve” under the “Review changes” button. After approval, merge the pull request using the “Merge pull request” button, ensuring branch protection rules require at least one approval.
GitLab
In GitLab, go to the project and select “Merge requests” from the left menu, then click “New merge request.” Choose the source and target branches, complete the description, and assign reviewers in the “Reviewers” field.
Reviewers add comments under the “Changes” tab and approve the merge request using the “Approve” button. Once approvals meet the project rules, merge the code by selecting “Merge” and confirm the merge commit.
Bitbucket
In Bitbucket, open the repository and select “Pull requests” from the left navigation, then click “Create pull request.” Choose the source and destination branches, add a summary, and assign reviewers in the reviewers section.
Reviewers provide feedback using inline comments and approve the request by selecting “Approve.” After approval, merge the pull request using the “Merge” button, ensuring branch permissions require reviewer approval.
Common Audit Findings
- Code merged without documented approval
- This occurs when branch protection rules are not enforced or administrators bypass controls. Prevent this by requiring approvals in repository settings and limiting merge permissions.
- Self-review of code changes
- Auditors flag cases where the author also approves the change. Prevent this by configuring tools to block self-approval and training teams on separation of duties.
- Missing review comments or evidence
- Reviews performed offline or informally leave no audit trail. Ensure all feedback and approvals are recorded directly in the code review tool.
- Inconsistent review practices across repositories
- Different repositories may lack standardized rules. Prevent this by applying organization-wide branch protection and review policies.