If developers deploy their own code to production, is that a conflict, and what compensates?

Start

Developers can write code and deploy it to production

The question is whether one person can take a change from their keyboard to live systems with nobody else seeing it. If they can, the pack treats it as a segregation of duties conflict.

• Then: Treat it as a conflict, rated High by default

Step

Treat it as a conflict, rated High by default

Writing code and deploying it is a listed conflict: a developer could add a back door, change a calculation or disable a check and release it. The pack rates it High by default, and its worked example keeps it High: a release log read after the change is live is not a reason to lower it. Lower a rating only with a recorded reason and a review, shown to work, that would catch misuse.

• Then: Is there another developer who could review each change?

Decision

Is there another developer who could review each change?

The reviewer must be someone other than the author, with enough knowledge of the code to spot a problem. A contractor or a development partner can count. A sole developer, or a team where everyone reviews only their own work, is a no. If you are unsure, answer no.

• Yes: Require another developer's approval before any merge
• No, or not known: Have someone else review the deployment log monthly

Step

Require another developer's approval before any merge

Set the code platform to block a merge into the main branch until a different developer approves it. The author must not be able to approve their own change or switch the rule off. Most platforms offer this at no cost: it is the cheapest separation there is.

• Then: Can only the reviewed main branch reach production?

Decision

Can only the reviewed main branch reach production?

Required review means little if a developer can still deploy from their own branch or laptop. Check that deployment runs only through the build pipeline, only from the main branch. If you have not checked, answer no.

• Yes: Confirm the settings with a fresh export
• No, or not known: Restrict deployment to the pipeline, from main only

Step

Restrict deployment to the pipeline, from main only

Remove direct deployment rights from individual developers, so the pipeline is the only way to production and it deploys only the reviewed main branch.

• Then: Confirm the settings with a fresh export

Step

Confirm the settings with a fresh export

Export the platform's branch and pipeline settings, or take dated screenshots, after the change. That is the evidence the conflict is separated. A manager's statement that it is is not.

• Then: Is there an emergency route that skips review?

Decision

Is there an emergency route that skips review?

Many teams keep a way to push an urgent fix without waiting for a reviewer, or administrators who can override branch rules. That route reopens the conflict each time it is used. If you do not know whether one exists, assume it does.

• Yes, or not known: Put the bypass on the emergency access list
• No: Separated: close the conflict, no exception needed

Step

Put the bypass on the emergency access list

Name who may use it in advance. Log every use and alert someone other than the user. The user records the reason the same day, and someone else reviews what was done within 1 working day in the pack's defaults. Change any credentials afterwards. Unreviewed use is treated as a possible incident.

• Then: Separated: close the conflict, no exception needed

Outcome

Separated: close the conflict, no exception needed

Record the conflict as closed, with the settings export as evidence. Keep checking at each access review and at the annual review of the conflict list that the branch and pipeline rules are still on.

Step

Have someone else review the deployment log monthly

The pack's matrix names a monthly review of the deployment log. The reviewer, such as a technical director, the managing director or an outside development partner, pulls it from the pipeline themselves and follows up any release they cannot match to an agreed change. An automated alert on each production deployment, sent to someone else, adds a check as it happens.

• Then: Run it once, then raise an exception with an expiry

Step

Run it once, then raise an exception with an expiry

Run the review once and keep the evidence, because an untested control does not lower the score. Then raise an exception, in the pack's defaults within 5 working days of finding the conflict. Its score sets the approver and the longest duration. The developer does not approve it.

• Then: At each review, did someone else check every month?

Decision

At each review, did someone else check every month?

Review a High conflict quarterly and a Medium one every six months, in the pack's defaults. Check the reviewer pulled the log themselves, covered every release since the last review and followed up anything unexplained. A missed month, or a log supplied by the developer, is a failed control.

• Yes: Is a second developer now available to review?
• No, or not known: Failed control: re-score without it and tell the risk owner

Outcome

Failed control: re-score without it and tell the risk owner

Score the exception again at once without the review, which may move it to a higher approver, and report the conflict to the risk owner. Restore the review, or find a second reviewer.

Decision

Is a second developer now available to review?

Ask at every review. A new hire or a development partner makes required review possible, and required review removes the conflict rather than watching it.

• Yes: require review: Require another developer's approval before any merge (back to an earlier step)
• No: Covered and checked: renew the exception at expiry

Outcome

Covered and checked: renew the exception at expiry

Record the review and the next date in your register. At expiry the exception is scored again and renewed. Once its renewals run out it goes to the next approval level up, so management sees the combined duty at least once a year.