The Setting That Waits for a Second Person
Most of the controls in an operations system can be switched off by the one person they are meant to check. A change review makes the handful of settings that weaken a control wait for somebody else, keeps the reason and the setting as it was, and lets everything that tightens a control through at once.
The short version
Approvals protect documents. Almost nothing protects the settings that decide whether approvals happen. Put the six or seven settings that loosen a control behind a second person, let anything that tightens a control apply immediately, and record the reason and the old value either way. It costs a few minutes a month and closes the quietest route around every other control you have.
The purchase order needed two signatures, and it got them. What nobody noticed was that, a week earlier, the approval rule for that amount band had been edited down from two steps to one and then back again, by the same administrator who later raised the order. Every document in the trail was correctly approved under the rule in force at the time. The rule was the thing that had been approved by nobody.
This is the gap in most internal-control set-ups, and it is structural rather than careless. Segregation of duties is applied to transactions: the person who raises a payment does not approve it, the person who counts stock does not adjust it. We wrote about that in segregation of duties. But the settings that define those controls are usually editable by anyone with the administrator role, alone, immediately, and the only record is an audit line that somebody would have to know to look for. An audit trail is necessary, as we argued in an audit trail nobody can delete, but a trail tells you afterwards. It does not make anyone wait.
The settings worth holding
Not every setting deserves a second person. Changing a company logo does not, and a review queue full of trivia gets approved without being read. The test is narrower: would this change make it easier for one person to do something that should have needed two, or to do it without being noticed?
| Change | Why it matters | What the review holds |
|---|---|---|
| Loosening the security policy | Weaker MFA, longer sessions, looser IP or device rules | Only the loosening; tightening applies at once |
| Creating or rotating an API key | A key is a login with no person behind it | The key, until approved; its secret is shown once |
| Tax settings | Every invoice after the change carries it | The new rates and switches |
| Inventory defaults | How stock is costed and what counts as available | The changed defaults |
| Approval rules | Who has to sign, and for how much | The edited chain |
| Deleting the organization | Nothing comes back | The deletion itself |
Tightening is never held
Requiring MFA, shortening a session, adding an IP rule: these apply the moment they are saved. A review that slowed down a security improvement would teach people to avoid making one. Only the direction that weakens a control waits.
What happens when a guarded change is made
-
The change asks for a reason
Instead of applying, it is held as a request with the reason given and a snapshot of the setting as it was.
-
Someone else decides
A different active member holding the review permission approves or rejects it, on the web, in the mobile app or over the API.
-
Approval applies exactly what was asked
Nothing is retyped by the reviewer, so what was reviewed is what takes effect.
-
Silence is a no
A request nobody decides on expires after 72 hours rather than applying itself.
One loophole has to be closed for the rest to mean anything: the guard itself. While any guard is switched on, switching one off is also a held change. Otherwise the shortest route around a review is to disable it, make the change, and enable it again, which is exactly the pattern from the opening paragraph with one more step.
A control that the controlled person can switch off is a preference, not a control.
The organization with one administrator
A small team may have exactly one person who can approve. A review that could never be decided would be switched off on the first busy day, so the rule bends in one visible way: if nobody else is eligible, the requester can approve their own change after 24 hours, and it is recorded as self-approved. That is not a second pair of eyes. It is a cooling-off period and a mark on the record, which is the honest best a one-person administration can have, and it shows an auditor exactly where the gap is. The same instinct, giving a risky action a gate of its own rather than borrowing a broader one, is behind the override that shares a permission.
If you have one administrator
Guard the security policy and API keys first
Those two are where a single compromised account does the most damage. The 24-hour self-approval still buys time for somebody to notice.
If finance and operations have separate leads
Add approval rules and tax settings
These are the settings an auditor asks about, and the people who own them are the right reviewers for each other.
If you run several branches
Add inventory defaults
A costing or availability change made for one warehouse lands on all of them.
Three questions for your own system
Who approved the last change to your approval rules?
What you will probably hear
The administrator made it.
How to read it
Then the rule that governs every signature was itself signed by one person. That is the gap.
Can an administrator switch MFA off for everyone, right now, alone?
What you will probably hear
Yes, but they would not.
How to read it
Controls are written for the day somebody would. A compromised account would.
When a setting changed last month, what did it change from?
What you will probably hear
We would have to check the log.
How to read it
A held change carries the old value with it, so the reviewer sees the difference before it happens rather than after.
A review that fits how your authority is delegated
The review engine already holds the change, keeps the reason and the before snapshot, and applies the approved version. Three extensions come up most often.
Two reviewers for the riskiest changes
A quorum on organization deletion or a security downgrade, so one colleague cannot wave it through.
A named reviewer role per change type
Tax settings to the finance lead, device rules to security, rather than anyone holding the review permission.
More guarded settings
Numbering sequences, period locks or notification routing, held the same way.
What AWRA OpsHub does today
- Change reviews on seven kinds of change: security policy downgrades, API key creation and rotation, tax settings, inventory defaults, approval rules and organization deletion, each switched on separately.
- A required reason and a snapshot of the setting as it was on every held change.
- A different person decides, holding the review permission, on the web, in the mobile app or over the API.
- Expiry after 72 hours, so an undecided request never applies itself.
- The guard on the guards: switching a review off is itself held while any review is on.
- Self-approval after 24 hours only when nobody else is eligible, recorded as self-approved.
More we can add to your workspace
- A reviewer quorum, so the riskiest changes need two approvers rather than one.
- A named reviewer role per kind of change, routing tax settings and security settings to different people.
- Reviews on more settings, such as document numbering or period locks.
Where we point you to a specialist
- We will not hold a change that tightens a control. A delay on making something safer is a reason to avoid making it.
The named reviewer per change type is the one most organizations with separate finance and IT leads ask for first, and it uses the routing the review inbox already has.
See governance and roles
Roles, conflicting permission pairs, delegated admins and change reviews, so the people who set the controls are checked too.
Explore governanceFrequently asked questions
Which settings can be put behind a change review?
Security policy downgrades, creating an API key, rotating an API key, tax settings, inventory defaults, approval rules and deleting the organization. Each is switched on separately, and all are off until you switch them on.
Does making security stricter need approval?
No. Tightening a rule, such as requiring MFA or shortening sessions, applies immediately. Only a change that loosens a control is held.
What if nobody else can approve?
If no other active member holds the review permission, the requester can approve their own change after 24 hours. It is recorded as self-approved, so the exception is visible.
What happens if a request is never decided?
It expires after 72 hours and the setting stays as it was.
Which plans include change reviews?
Change reviews are part of the Premium and Enterprise plans.
