In most organisations an authorization review is a photograph. Data is extracted, studied for a week, written up, filed. The photograph is accurate on the day it is taken.
A month later it is partly invalid. Roles have changed, new users were opened, and the access someone got for two weeks is still there. The report was not wrong. It just no longer describes that system.
The bad habit here is not producing the report. It is treating the report as a conclusion. Authorization risk is not a state; it is a story of change, and you cannot read it from a single frame.
Splitting synchronisation into groups
AccessGuard synchronises SAP user, role, role-authorization, user-role and profile data into local tables. That work is not one block: users, roles, assignments, profiles, the static catalog and risk scanning can each be run on their own.
The split that pays off in practice is simple. Catalog data changes rarely; user and assignment data needs refreshing often. Synchronisation jobs are scheduled through the job framework, with progress and status records kept along the way.
The one real risk here is a synchronisation that fails quietly, leaving the review to run on stale data. So when you look at a finding, look at the date of the data underneath it.
User delta and role changes travel different paths
Alongside full synchronisation there is a delta path for user changes that watches the USRSTAMP marker. Role-side changes are handled in a separate event and polling flow over AGR_TIMEB.
Knowing that sets the expectation correctly: no single general delta mechanism covers every type of change. How often role changes become visible is a scheduling decision, and it is yours to make.
What the gap between two scans tells you
Four hundred findings from one scan cannot be managed. The difference between that set and the previous scan can be: which findings are new, which were fixed, which are ongoing, which sit in an accepted state.
That distinction answers two questions at once. Did last period’s remediation hold? And are the new findings connected to a role change?
It is also the only version that works at the management table. “We have four hundred findings” is a pile, not a sentence. “This many closed this quarter, this many opened, and most of the new ones trace to the same role change” is a sentence.
Putting the change log beside the finding list
A change log is kept for added, updated and deleted records. That turns “when did this authorization appear?” into a searchable question and shortens the hunt for a cause.
On the organisational side, authorization values such as BUKRS, WERKS, EKORG and VKORG can be compared against HR and organisation master data, which is how excessive, wildcard or unresolvable access becomes visible. In roles that have grown for years, this is the check that earns its keep.
Let us also keep expectations straight: AccessGuard does not replace SAP GRC and does not change role assignments itself. What it does is synchronise, evaluate rules and manage findings. Who remediates, when, and on what grounds is still a question about your process.
Here is a concrete starting point. Look at the dates of your last two authorization reviews and admit that nobody currently knows how many roles changed in between. Pick one system, take two scans two weeks apart, and read the difference together. The scan that changes the conversation is the second one.