Skip to content
AuditFront
CQ-3 Tech Due Diligence

Tech Due Diligence CQ-3: Code Review Process and Standards

What This Control Requires

The assessor evaluates the code review practices, including whether all changes undergo peer review, the quality and thoroughness of reviews, review turnaround time, and whether automated code quality checks supplement manual review.

In Plain Language

Code review is the last line of defence before code reaches production, and it serves multiple purposes beyond catching bugs. It enforces consistency, spreads knowledge across the team (reducing bus factor risk), and provides a natural mentoring mechanism for junior developers. The absence of code review - or a culture of rubber-stamp approvals - is a significant risk indicator.

Assessors typically pull up the Git history and pull request records to evaluate average PR size (smaller is better), the number and quality of review comments, turnaround time from PR creation to merge, reviewer diversity (not always the same person reviewing), and whether reviews catch substantive issues or just wave things through.

This is one of the easiest areas to get right, which is why assessors view poor review practices as especially concerning. If a team cannot manage this basic quality gate, it raises questions about discipline in areas that are harder to implement.

How to Implement

Make code review mandatory for all production code changes. Use branch protection rules to require at least one approving review before merging - preferably two for critical systems. Nobody should be able to merge without review, regardless of seniority.

Write code review guidelines that define what reviewers should look for: correctness (does the code do what it claims), security implications, performance considerations, readability and maintainability, test coverage for the changes, adherence to coding standards, and appropriate error handling.

Encourage small, focused pull requests. PRs over 400 lines of changes receive less thorough reviews - that is just human nature. Set team norms for PR size and break large features into reviewable increments. Track PR size metrics and address trends toward larger PRs.

Set expectations for review turnaround time. Standard PRs should be reviewed within one business day, critical fixes within hours. Slow reviews create bottlenecks and push developers toward batching changes into larger, harder-to-review PRs.

Supplement manual review with automated checks: linting (ESLint, Pylint, RuboCop), static analysis (SonarQube, CodeClimate), security scanning (Snyk, Semgrep), dependency checking, and automated formatting. Run these automatically on every PR and block merging on failure.

Foster a constructive review culture. Reviews should be respectful and educational, focused on the code rather than the person. Encourage questions and discussion. Use comments as teaching moments.

Track review metrics over time: average turnaround, comments per PR, first-submission approval rate, and reviewer distribution across the team. Use these to spot bottlenecks and improve the process.

Evidence Your Auditor Will Request

  • Branch protection configuration requiring review before merge
  • Code review guidelines documentation
  • Sample of recent pull requests showing review depth and quality
  • Automated code quality tool configurations and reports
  • Review turnaround time metrics

Common Mistakes

  • Code review is technically required but practically rubber-stamped with minimal comments
  • Certain team members (CTO, senior devs) bypass review and merge directly to main
  • Review turnaround is slow (multiple days), creating bottlenecks in development flow
  • Pull requests are consistently large (500+ lines), making thorough review impractical
  • No automated quality checks; review relies entirely on human attention

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.25 Related

Frequently Asked Questions

Can the CTO or founder bypass code review?
This is a red flag every time. No individual should be able to merge to production without review, regardless of seniority or title. If the assessor finds that founders or senior leaders routinely bypass review, it signals a cultural issue that undermines quality across the board.
How many reviewers should be required per PR?
At minimum one reviewer for standard changes. For critical systems like payment processing, authentication, or sensitive data handling, two reviewers is recommended. The important thing is that reviews are substantive - meeting a reviewer count means nothing if the reviews themselves are just rubber stamps.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment