Four Eyes Without Pull Requests

Andrea Laforgia · newsletter · 2026-05-04 source ↗ Reader 🖥️

Pair & Mob Programming Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Pair programming teams can satisfy ISO 27001 and SOC 2 audit requirements for four-eyes review without pull requests by constructing a composite control of five pieces — written policy, structured commit trailers, automated enforcement, supplementary telemetry, and a sampling audit protocol — which together produce stronger evidence of real review than the PR approval artefact they replace.

practical · prescriptive — A detailed practical guide for engineering teams that pair-program on trunk-based development. Responds to a reader question about satisfying ISO/SOC 2 auditors without pull requests. Prescriptive throughout — delivers a five-part composite control with specific implementation details.

Structure

Part	Role
	Establishes that ISO/SOC 2 standards require a control objective (authorized, tested, documented changes) — not a specific mechanism like pull requests.
	Defines four properties of an acceptable review control: defined, implemented, evidenced, and enforced.
	Argues that PR artefacts do not distinguish real review from rubber-stamping, so the artefact alone is weak evidence. Pairing has the substance but lacks the artefact.
	Presents the five-piece solution: policy, commit trailers (Co-authored-by/Reviewed-by/Solo-work), enforcement hooks, telemetry, and a quarterly sampling audit with interview protocol.
	Addresses self-attestation weakness, distributed team challenges, and solo work exceptions — each with a candid assessment of residual risk.
	Scopes the advice: SOX, FDA, GxP, and defence regimes may require literal separation of author and approver beyond what pairing alone provides.
	Practical advice on framing the conversation around control objectives, with escalation options if the auditor insists on PRs.
	Frames the decision as compliance-from-appearance vs. compliance-from-substance, and closes with a clear recommendation.

Key terms

Propositions

explicitcorroboratedISO 27001 and SOC 2 require a control objective for change review, not a specific mechanism like pull requests.conf: high
supports ←Post-Commit Reviews != Post-Deployment Reviews · p3 — Both pieces independently make the same structural move: separating the compliance/control objective (four-eyes review, an audit trail) from the specific mechanism (a pre-merge PR gate) that is commonly but not necessarily how that objective gets satisfied.
explicitA pull request approval artefact does not, on its own, constitute evidence that real review occurred.conf: high
explicitPair programming produces genuine review substance but leaves no native audit artefact.conf: high
explicitThe fix for pairing's artefact gap is to add structured evidence, not to abandon pairing for PRs.conf: high
explicitA composite of five controls (policy, trailers, enforcement, telemetry, sampling audit) produces stronger audit evidence than a typical PR workflow.conf: high
explicitDetective controls (sampling audits) can compensate for the self-attestation weakness of commit trailers by raising the cost of circumvention above what casual misuse can sustain.conf: high
explicitcorroboratedMost teams keep pull requests not because they are the best review mechanism, but because they assume audit compliance demands them.conf: medium
supports ←Pair Programming Fixed Our Pull Request Bottlenecks · p2 — Direct real-world confirmation of the claim that teams keep PR approval mainly because they assume compliance demands the artifact, even once the actual review has already happened elsewhere.
explicitestablishedHigh-performing teams favour smaller batches, more frequent integration, and trunk-based development — patterns that continuous pairing review fits better than long-lived branches.conf: high
supports ←Mob Programming – key issues it can solve, benefits, and learnings · p4 — Both describe the same pattern — continuous/pairing-based review fitting trunk-based, small-batch, frequent-integration delivery better than long-lived branches and batched PR review — the Futurice piece supplies a concrete, first-person case study of exactly this claim.
supports ←Why your team doesn't need to use pull requests · p9 — Morris's claim that a faster loop drives smaller, more frequent commits anticipates the later article's observation that high performers favour smaller batches and more frequent integration.
implicitThe dominant residual risk after implementing the composite is process drift, not deliberate collusion.conf: medium
explicitRunning a parallel PR ritual alongside real pairing practice will erode the cultural commitment to pairing over time.conf: medium

Arguments

Teams are not required to use pull requests to be compliant strength: high

Implicit premises:

If a standard specifies objectives rather than mechanisms, any mechanism meeting the objective satisfies the standard

Adding artefacts to pairing (composite control) is superior to relying on PR artefacts that may lack substance strength: high

Implicit premises:

A control with verified substance plus added artefacts is stronger than a control with artefacts of unverified substance

The shift from preventative (PR gate) to detective (sampling audit) raises circumvention cost enough for ISO/SOC 2 purposes strength: medium

Implicit premises:

Audit regimes accept detective controls as substitutes for preventative controls when circumvention cost is sufficiently high
The relevant threat model is process drift, not sophisticated collusion

The composite is scoped to ISO 27001 and SOC 2; stricter regimes need additional controls strength: high

Narratives

Questions addressed

⭕ Can a team using pair programming and trunk-based development satisfy ISO/SOC 2 audit requirements without pull requests?
⭕ What exactly does an auditor need to see for four-eyes compliance?
⭕ How do you address the self-attestation weakness of commit trailers?
⭕ What if the auditor insists on pull requests regardless?

Gaps

evidentialNo empirical data on how auditors actually respond to the composite control. The article is confident about audit acceptance but relies on the author's reading of standards and general audit theory, not reported outcomes.
practicalThe sampling audit protocol is specified in detail but its operational cost is not estimated. For small teams the overhead of quarterly interviews may be significant relative to the team's capacity.
assumptionThe argument that detective controls compensate for self-attestation weakness assumes the dominant threat is process drift, not adversarial insiders. In environments with higher insider-threat risk, this assumption may not hold.
emergingNo discussion of how the composite interacts with AI-assisted coding (e.g., Copilot, Claude Code). If one 'pair' is an AI, do the four-eyes semantics still hold? The article's framework implicitly assumes both participants are human.

Four Eyes Without Pull Requests

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents