A team owns its service end to end, including deploying to production. How is segregation of duties satisfied?

The apparent conflict

Traditional segregation separates the person who develops from the person who deploys. A team owning its service end to end appears to violate that directly, and the naive resolution — a separate deployment team — reintroduces the handoff that the operating model exists to remove.

The resolution

Separate the authority to change code from the authority to change what runs, without separating the people.

• No human deploys. The pipeline deploys, from a reviewed, merged, signed artefact. The developer's authority ends at proposing a change.
• Code review by someone other than the author, enforced by the repository rather than by convention.
• The pipeline's configuration under the same review requirement as the code, because the control is only as strong as the pipeline definition — otherwise the developer changes the gate rather than bypassing it.
• No standing production access. Access is elevated on request, time-bounded, justified and logged, so direct intervention is an exception with a record rather than a routine capability.
• Artefact provenance verified at deployment, so what runs is demonstrably what was reviewed.

Why this is stronger than the traditional control

A separate deployment team performs the deployment and does not meaningfully assess the change; the control is procedural and the assurance is weak. An enforced pipeline provides the same separation mechanically, on every change, with evidence — and the evidence is complete rather than sampled.

What must be watched

The break-glass path. Every organisation needs a way to intervene directly in an emergency, and that path is where segregation actually breaks. It needs strong authentication, automatic logging, mandatory post-incident review, and use frequency monitored — routine break-glass use means the normal path is inadequate, and the control has become a formality.