Structuring Compliant Pull Requests and Peer Reviews

The Maker-Checker Principle

Change Management (CC8.1)

In a SOC 2 audit, the focus is on Segregation of Duties (SoD). You must prove that no single developer can push code to production without an independent review.

Auditors look for the 'Maker-Checker' workflow: one person makes the change, another verifies it.

Welcome. To satisfy SOC 2, we must move beyond 'trust' and implement technical proof of change management. Here we have the 'Maker'—the developer writing the code. And here is the 'Checker'—the independent reviewer. This Segregation of Duties ensures that no single person has total control over the production environment.

Hard Controls: Branch Protection

Policy documents are 'soft' controls. SOC 2 requires 'hard' controls—technical guardrails that make it impossible to bypass the process.

Policy is just paper; branch protection is the law. First, we mandate at least one approval from someone other than the author. We also dismiss stale reviews to prevent someone from sneaking in code after getting an approval. Finally, we lock the merge button until all CI/CD security scans return green.

Anatomy of a Compliant PR Template

A compliant Pull Request acts as a self-contained audit package. Use a template to ensure every change includes the necessary context.

Click the template sections to see why auditors care about them.

Standardizing your PRs makes audits painless. Click on the different sections of this PR template to see the compliance value of each. Linking to a Jira or GitHub issue provides the business justification. It proves the change was authorized. Evidence of testing—like a link to a staging deploy or a screenshot—proves the change was verified before it hit production. The security checklist is a 'Point-of-Work' control. It forces the developer to confirm they've checked for secrets or unsanitized input.

The Auditor's View: Sufficient Evidence

When an auditor samples your work, they look for a digital trail. This trail must be immutable and clearly identify the 'Who', 'When', and 'What'.

Imagine an auditor is looking at your screen. They want to see a clear sequence. First, who requested the change? What exactly was changed in the code diff? And where is the proof that the security scanners passed?

Configuring GitLab & GitHub

Compliance looks slightly different in every tool. Explore the mandatory settings for both GitHub and GitLab to ensure Segregation of Duties.

Let's look at how to actually turn these on. Toggle between GitHub and GitLab to see the specific settings you need to configure today. In GitHub, you'll head to Branch Protection. Make sure 'Restrict who can push' is enabled and 'Allow force pushes' is disabled. In GitLab, look at Approval Rules. Crucially, ensure 'Prevent approval by author' is checked to satisfy the SoD requirement.

Audit Review: Identify the Risk

You are acting as an internal auditor. Read the PR description and the review history below. Identify the compliance failure and explain why it's a risk.

Here is a PR from the last sprint. It was merged into main. Look closely at the timestamps and the participants. Is there a compliance issue here? Type your diagnosis.