Multi-party approval and segregation of duties — financial-grade controls and when they matter

LVII-04 covered pull request approvals as the change-side gate. This lesson covers the structure of those approvals when the consequences of a bad change are financial, regulatory, or both. Multi-party approval and segregation of duties are not generic best practices; they are controls that exist because a single compromised identity must not be able to complete a sensitive change alone.

What segregation of duties is

Segregation of duties is the principle that no single individual should control all phases of a sensitive operation. The phases are request, approve, execute, and audit.

For an infrastructure repository:

• Request. The engineer who opens the PR.
• Approve. The reviewers who sign off.
• Execute. The workflow that applies the change.
• Audit. The post-incident review or regulator’s check.

flowchart LR
    A["Request"] --> B["Approve"]
    B --> C["Execute"]
    C --> D["Audit"]
    A -.->|"same identity"| X["Violation"]
    B -.->|"same identity"| X
    C -.->|"same identity"| X
    D -.->|"same identity"| X

Each phase is a role. A single identity may occupy different roles across different changes but must not occupy all in one change.

Multi-party approval as the mechanism

Multi-party approval enforces segregation of duties at the approval phase. The mechanism requires N approvals from M distinct pools, with no single identity satisfying more than one approval.

gh environment edit production \
  --required-reviewers user:alice,user:bob,team:platform-sre

The command requires three approvals. The multi-party rule: Alice cannot approve Bob’s change if Alice opened the PR; Bob cannot approve Alice’s if Bob pushed the diff. Enforced by require approval from non-author.

The structure:

• At least two distinct approvers.
• At least one outside the requester’s team.
• At least one with privileged context.

When the control is required

The control is required where the consequences include regulatory exposure or financial loss:

• Financial transactions. SOX requires segregation for systems that touch financial reporting.
• IAM changes. Policies, production credentials, audit logging, break-glass accounts.
• Data privacy controls. Encryption at rest, retention policies, export permissions. GDPR, HIPAA, and equivalents.
• Audit and observability. Audit logging, security monitoring, incident response tooling.

The consequences are measured in regulatory exposure or financial loss, not in uptime.

When the control is overkill

The control is overkill where the consequences are limited to uptime and the change is recoverable quickly:

• Documentation changes. Markdown, READMEs, runbooks. Recovery is a revert.
• Internal tooling. No external customer impact.
• Low-traffic services. No customer data, no financial flow, no regulatory exposure.

For these workloads, multi-party adds latency without the regulatory protection the control exists to provide.

Configuring multi-party on a protected environment

The pattern on GitHub:

1. Define two or more reviewer pools: primary (engineers who normally approve) and privileged (production context).
2. Require N approvals from primary, at least one from privileged.
3. Enable require approval from non-author in branch protection.
4. Enable dismiss stale on push.

gh environment edit production \
  --required-reviewers team:platform-sre,team:security-ops

The command requires two teams. The distinct-pool rule requires at least one from security-ops. Two platform-sre approvals fail.

Production discipline

1. Segregation of duties is a structural control. The platform enforces it.
2. Multi-party approval requires distinct approver pools. One pool rubber-stamping another is not multi-party.
3. Scope the control to the workloads that need it.
4. Self-approval must be rejected by the platform.

Cross-course references

• This course, Part LVII-04 (Pull request approvals) covers the change-side mechanism.
• This course, Part LVII-03 (Protected environments) covers the platform-side enforcement.
• Linux for Production Sysadmins - Part XXXVI (ChangeWindows) covers change-control discipline.

Quiz