Code Review Checklist Example

Standard Operating Procedure: Code Review Checklist Example

Document Identifier: SOP-ENG-OPS-409
Classification: Internal Operational Standard / Enterprise Engineering

1. Document Control & Revision History

---

2. Executive Summary & Scope

2.1 Purpose

This Standard Operating Procedure (SOP) defines the rigorous, repeatable framework for executing code reviews within enterprise software engineering environments. The objective is to eliminate architectural regression, enforce institutional security postures, maintain deterministic code maintainability, and ensure absolute regulatory compliance prior to production deployment.

2.2 Scope

This standard applies universally to all software development lifecycle (SDLC) phases, spanning all internal engineering squads, external contractors, and automated code-generation agents. It governs all source code modifications destined for staging, pre-production, and production deployment branches across cloud-native and legacy repositories.

2.3 Regulatory & Compliance Standards

Operations governed by this SOP align directly with:

• SOC 2 Type II: Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality).
• ISO/IEC 27001: Information Security Management System (Secure Development Policy).
• OWASP Top 10: Mitigation of critical web application security vulnerabilities.

---

3. Prerequisites & Tool Requirements

Execution of this operational procedure requires strict adherence to environmental, toolchain, and credential prerequisites.

3.1 Software Access & Toolchain

• Version Control System (VCS): Enterprise GitHub Enterprise / GitLab Ultimate instance with branch protection rules enforced.
• Static Application Security Testing (SAST): SonarQube Enterprise, Semgrep, and Snyk integrated into the CI/CD pull request (PR) pipeline.
• Dynamic Analysis / Secret Scanning: GitGuardian or GitHub Secret Scanning active on target repository.
• Integrated Development Environment (IDE): Enterprise-approved IDE with standardized linter/formatter configurations matching repository editorconfig.

3.2 Certifications & Clearances

• Peer Reviewer Qualification: Reviewers must hold internal Certified Enterprise Reviewer (CER) status, achieved via completion of secure coding and threat modeling modules.
• Merge Authorization: Restricted to designated Tech Leads, Principal Engineers, and Senior Systems Architects.

---

4. Roles & Responsibilities (RACI Matrix Table)

Legend: R = Responsible, A = Accountable, C = Consulted, I = Informed

---

5. Step-by-Step Operational Procedure

Phase 1: Pre-Review Preparation & Author Self-Audit

• 1.1 Verify that the pull request (PR) references a single, verified Jira/Linear ticket or change request ID.
• 1.2 Ensure the PR scope is bounded (< 400 lines of code modified per review iteration to optimize cognitive load).
• 1.3 Confirm all local unit tests, integration tests, and linters pass cleanly on the author’s local environment.
• 1.4 Validate that no hardcoded credentials, API keys, private certificates, or internal IP addresses are present in the commit diff.

Phase 2: Automated Pipeline & CI/CD Gate Verification

• 2.1 Confirm that all automated CI/CD pipeline checks (GitHub Actions, GitLab CI) have completed and returned a green status.
• 2.2 Verify that SAST and secret scanning tools report zero High or Critical vulnerabilities.
• 2.3 Validate that test coverage metrics meet or exceed the institutional threshold (minimum 85% line and branch coverage on new code).
• 2.4 Check that dependency updates do not introduce known CVEs via automated Software Bill of Materials (SBOM) generation tools.

Phase 3: Architectural & Functional Code Review (Peer Assessment)

• 3.1 Architectural Alignment: Verify that design patterns, domain boundaries, and data flows adhere strictly to the target system architecture document.
• 3.2 Business Logic & Correctness: Trace the core logic execution paths to ensure edge cases, null states, and concurrency conditions (race conditions, deadlocks) are explicitly handled.
• 3.3 Error Handling & Resilience: Ensure exceptions are caught, logged with appropriate context (excluding PII/PHI), and handled gracefully without exposing internal stack traces.
• 3.4 Performance & Scalability: Inspect database queries for N+1 problems, missing indices, unpaged result sets, and inefficient memory allocation loops.

Phase 4: Security & Data Privacy Validation

• 4.1 Input Validation & Sanitization: Confirm all external inputs (API payloads, query parameters, headers) are explicitly validated and type-checked.
• 4.2 Injection Defenses: Verify parameterized queries or secure ORM usages are implemented to neutralize SQL, NoSQL, and Command injection vectors.
• 4.3 Authorization & Access Control: Confirm that the principle of least privilege is enforced on every endpoint or service method (RBAC/ABAC checks).
• 4.4 Data Protection: Validate that data in transit utilizes TLS 1.3 and data at rest complies with AES-256 encryption standards.

Phase 5: Maintainability & Documentation Sign-Off

• 5.1 Ensure code readability, meaningful naming conventions, and adherence to language-specific style guides (e.g., PEP 8, Google Java Style).
• 5.2 Verify that public APIs, public classes, and complex algorithms contain accurate, up-to-date documentation comments (OpenAPI/Swagger specs updated if applicable).
• 5.3 Ensure obsolete or commented-out code blocks ("dead code") have been entirely purged from the diff.

---

6. Quality Assurance & Verification Criteria

To successfully clear the code review process, the pull request must achieve 100% compliance with the following metrics:

6.1 Acceptance Benchmarks

• Mandatory Approvals: Minimum of two (2) explicit approvals from certified peer reviewers (CER), including at least one approval from a designated domain architect for core framework modifications.
• Zero Blocking Comments: All reviewer-flagged comments marked as "Blocking" or "Security" must be officially resolved, committed, re-reviewed, and marked as closed in the VCS interface.
• Test Coverage Compliance: Codecov / SonarQube gate reports must confirm that the incoming diff does not degrade the overall repository test coverage ratio below the 85% baseline.

6.2 Audit Trail Verification

• All review communications, approval timestamps, and override justifications must be immutably recorded within the VCS pull request audit log for SOC 2 evidentiary collection.

---

7. Practical Troubleshooting Scenarios

Scenario A: Critical Security Vulnerability Identified Post-PR Submission

• Trigger: SAST tool flags a high-severity SQL injection or secret exposure vulnerability during Phase 2/4.
• Immediate Corrective Action Protocol:
  1. The automated pipeline immediately blocks the merge action.
  2. The Reviewer tags both the Author and the designated SecOps Engineer on the pull request comment thread.
  3. The Author uses interactive rebasing/amending to remove the offending secret or patch the injection vector, force-pushes the remediation branch, and re-triggers the CI/CD pipeline.
  4. If a secret was exposed in git history, the Author and SecOps execute an immediate credential rotation protocol and run git-filter-repo or BFG Repo-Cleaner to purge historical artifacts.

Scenario B: Architectural Disagreement / Deadlocked Review

• Trigger: Peer Reviewer and Author reach an irreconcilable disagreement regarding design patterns or performance optimizations, halting workflow progression.
• Immediate Corrective Action Protocol:
  1. Either party formally invokes the "Architectural Escalation" flag on the PR.
  2. The PR is automatically routed to the Principal Systems Architect on duty (per the on-call rotation).
  3. The Principal Architect convenes a mandatory 15-minute synchronous engineering alignment session within 4 business hours.
  4. The Principal Architect issues a binding architectural ruling. The ruling is documented as a comment on the PR, and the opposing party executes the required code adjustment immediately.

Scenario C: Unresolvable Pipeline Failure (Flaky Test / Infrastructure Timeout)

• Trigger: CI/CD pipeline fails due to external dependency timeouts or an intermittent flaky test unrelated to the PR code diff.
• Immediate Corrective Action Protocol:
  1. The Author investigates the pipeline logs to verify if the failure originates outside the modified scope.
  2. The Author posts the specific log output indicating flakiness and manually triggers a pipeline rebuild.
  3. Prohibited Action: Authors and Reviewers are strictly forbidden from bypassing required pipeline checks or utilizing administrative override tokens without written concurrence from the Engineering Operations Manager.