How can an organisation prove that a role or authority change…

Direct answer

Propagation cannot be proved by a single 'operation successful' message. For each target system, record the change request, receipt, application result, read-back of the final state, a negative test of the former access path and the resolution of any inconsistency.

In plain language

Sending ten people a change of address does not prove that all ten updated their address books. You must also check that each message arrived, was applied and that the old address is no longer being used.

Why this matters

A central system may look current while a connected application, cache, token or third-party account continues to honour the former authority. This hidden difference is one of the most dangerous forms of residual access.

Do not confuse

Sent: the change was transmitted to the target.
Received: the target accepted the request.
Applied: the target changed its state.
Verified: the new state was read back and the old access path was tested.

What should you do?

Assign a unique event identifier to every change.
Create a target-system inventory and define the expected final state.
Record delivery, application and read-back evidence separately.
Run a controlled negative test against the old access path.
Retry failed targets and escalate unresolved cases for human review.
Do not close the event until every target has been evidenced.

How do you audit it?

Is the target list complete?
Do the expected and observed states match in every target?
Is success based only on the sender's log?
Is access denied with the old token or session?
Are all items of evidence linked to the same event identifier and timeline?

Limit

Absolute, immediate synchronisation is not always possible in distributed systems. The permitted delay, retry policy and closure rule should therefore be defined in advance.