Why your SoD conflict
count never goes down

Run the report in January, run it again in December, and the conflict count is within a few percent of where it started. Meanwhile the team has spent the year working on it. This pattern is common enough that it is worth being blunt about why it happens.

The count is not a measure of risk

A standard ruleset generates conflicts at the level of authorisation objects. One over-broad role assigned to two hundred users produces two hundred conflicts. Fixing that single role removes all of them at once; fixing two hundred individual user assignments removes the same number and leaves the role in place to regenerate them next month.

Both look identical on the report. Only one of them is remediation. If the metric being tracked is the total conflict count, there is no way to tell which kind of work is being done — and the second kind is easier, so it is usually what happens.

Three things that actually move the number

1. Remediate roles, not users

Sort conflicts by the role that generates them rather than by the user who holds them. In most estates a small number of composite roles — often ones built during the original implementation and never revisited — account for a disproportionate share of everything on the report. Rebuilding five of those does more than a year of user-level clean-up.

2. Retire the mitigating controls nobody performs

Mitigating controls accumulate. A conflict gets flagged, a control is written to accept the risk, an owner is assigned, and then nothing happens — the review does not occur, or it occurs as a signature with no underlying work. The conflict is off the report but the risk is unchanged, which is worse than leaving it visible.

Pull every mitigating control and ask two questions: when was it last actually performed, and can the person named produce evidence. The ones that fail should go back onto the report as open conflicts. The count will rise before it falls, and that is the point — you are now measuring something real.

3. Fix the ruleset before you fix the roles

Shipped rulesets are generic by necessity. They flag combinations that are genuine risks in a manufacturing business and irrelevant in a services one, and they miss conflicts that only exist because of how your custom transactions are built. A ruleset nobody has tuned produces a stream of findings the business has learned to ignore, which is how a report becomes background noise.

Tuning is unglamorous and it is the highest-leverage work available. Remove what does not apply, add what your custom code introduces, and get the remaining rules described in language a business owner can approve without a translator.

What good looks like

A healthier set of measures than the raw count:

• Conflicts per role, trending down — evidence that role design is improving rather than assignments being shuffled.
• Mitigating controls with evidence, as a percentage of all mitigating controls. If this is below half, the acceptance process is fiction.
• Time from detection to decision. Not to remediation — to a decision. A conflict that has sat undecided for eight months is an unowned risk regardless of what the report says.
• New conflicts introduced per quarter. If this is not near zero, provisioning is creating work faster than remediation removes it, and nothing downstream will ever catch up.

The uncomfortable part

Doing this properly makes the numbers worse before they improve. Retiring unperformed mitigating controls puts conflicts back on the report. Tuning a ruleset for your custom code usually finds risks the generic version never looked for. Any organisation reporting the raw count upward will find this politically difficult, and that difficulty is the actual reason the number has stayed flat for three years.

Getting agreement in advance that the count is expected to rise — and that the rise is evidence the work is real — is usually the first task of the engagement rather than a technical one.