Contents
Most change management processes control requests but forget settings. Yet a setting that turns a control off affects every request that control protects, all at once. A single checkbox can invalidate the output of a process that ran for months. This article covers the practical design of putting settings changes behind four eyes approval.
Why a Settings Change Is Critical
For three reasons. First, blast radius: a request affects one operation while a setting affects all of them. Second, visibility: a request goes through an approval flow that several people see, while a settings change is usually one click on one screen. Third, reversibility: a wrong request can be rolled back, but whatever a relaxed control let through in the meantime cannot be recalled.
The hardest finding to explain in an audit is this: the control exists, the records are tidy, but for a certain period the control was off and nobody knows who turned it off. That single finding puts the credibility of the whole control environment in question.
The Heart of the Design: Do Not Touch the Live Record
There are two ways to hold a pending settings change. The first is to put a pending flag on the settings row and keep the new value in the same row. It looks easy, but it forces you to change every place that reads the setting, and if you miss one you end up with a half applied control. That is more dangerous than the problem you set out to solve.
The second, and correct, approach is to hold the pending change in a completely separate record. The real settings table is untouched until approval. The rest of the system knows nothing and keeps reading the previous value, so the rule that the old value stays in effect comes for free.
What happens on approval? The cleanest method is to replay the user's save through the very same path. Every check that operation normally passes runs a second time: permission, validation, licence limits and concurrency. Re-checking the licence limit at approval time matters, because the binding moment is the approval rather than the request.
How to Choose the Scope
Putting every setting behind approval looks safest at first and is the most fragile in practice: waiting for approval to change a mail server address wears the team out quickly and the feature gets switched off. A three level scope strikes the balance in most organizations:
- Disabled: the feature is off. A reasonable default to start with.
- Control settings only: masking regime, approval policy, segregation of duties, automatic execution and rollback requirements wait for approval, while operational settings do not slow anything down.
- All settings: for highly regulated organizations.
The list of what counts as a control setting must be written down explicitly. It grows over time, and every new control should raise the question of whether it belongs on the list.
Who Should Hold Approval Authority
The common mistake here is defining a new approver role. A new role means a new permission matrix, a new assignment process and new maintenance. There is a simpler solution: let approval authority be the screen's own permission. A user who can change server settings can approve someone else's server settings change.
The logic holds up: whoever is trusted to change that screen is the person able to judge its content. The permission already exists in the role definition, so nothing new has to be built.
There is one absolute rule: nobody approves their own request. This must not be made configurable. A four eyes principle that can be switched off is not a four eyes principle.
Five Traps
1. Leaving the feature itself unprotected. The parameter that governs four eyes is a control too. Turning it on can apply immediately, but turning it off must require approval, otherwise the rule can be disabled with one click.
2. Locking out new records. A pending creation must not block another new record. If the locking key is chosen carelessly, two users end up blocking each other.
3. Telling the user it was saved. When a change goes to approval the interface must say so plainly. A user who sees a success message believes the setting is live, and that illusion surfaces at the worst moment.
4. Not showing old and new side by side. The approver must see what changed. A screen showing only the new value turns approval into a formality.
5. Exposing a sensitive value on screen. If the pending change contains a password or a key, it must be masked on the approval screen. The approver needs to see that something changed, not the value itself.
Frequently Asked Questions
Should every settings change go through approval?
No, that drowns the process and people start approving without reading. The scope should be limited to settings that relax a control: approval rules, masking mode, rollback requirement and the like. Display preferences and label texts do not need to go through the same gate.
Why is a pending change not written to the live record?
Because if it is, the setting takes effect before it is approved. A second benefit of keeping the pending change separate is that on approval the change can be replayed through the same command: there is a single application path, no second write path is written, and no behavioural difference appears between two paths.
Can someone approve a settings change they requested themselves?
No. That rule is the four eyes principle itself and should not be a setting that can be relaxed. Otherwise someone who wants to switch off a control first switches off four eyes and then does as they please. That is why the ban on approving your own request applies in all cases.
See the four eyes flow live
We will walk the entire flow together, from editing a setting to approval, rejection and the audit record.
Book a Demo →