¶ Testing a Role Change Before Making It
A what-if analysis in the RedRays Security Platform applies a proposed SAP role grant or removal to a copy of a sealed segregation of duties scan and re-runs the same analysis over it, so the effect of a change can be read before anything is changed.
The two questions it answers are the ones asked in every access request: would granting this role put this person into a conflict, and would withdrawing that role actually clear the one they are in. Both are answerable from access data, and both are routinely guessed at instead.
¶ What is a what-if analysis?
A scan over a copy of a population rather than over a system. It takes a sealed scan that already happened, applies the proposed change to the copy, runs the same analysis with the same active ruleset, and reports what that population would produce.
It reaches no SAP system, writes nothing to SAP, and writes nothing anywhere until the run starts. It is a scan in every other respect, which is why its results carry the same structure as a real one: the same rules, the same evidence, the same distinction between reported and suppressed. It also does not hold up the scheduled scan of that system.
The screen carries a warning that cannot be dismissed: nothing on it is the state of the system. That is not a disclaimer for form's sake. It is the difference between a projection and a measurement, and a projection quoted as a measurement is how a role change gets approved on a landscape that has moved since.
The warning over a projection cannot be hidden, because a projection read as a measurement is how a role change gets approved on a landscape that has moved.
¶ What can be proposed?
| Proposal | What it models |
|---|---|
| Grant a role or profile to an account | The access request that is sitting in the queue |
| Remove a role or profile from an account | The remediation somebody is about to carry out |
| Several grants and removals together | A role redesign, or a move between jobs where access is added and withdrawn in one act |
| A grant with the dates it would be valid between | A temporary or emergency window, rather than a permanent grant |
Applying several changes together matters, because a redesign that adds one role and withdraws two is not the sum of three separate answers. The population is changed once and analysed once.
¶ What is the answer measured against?
The scan named on the run, and nothing more current than that. A what-if inherits everything about that scan, including what it was not able to read, and it says which gaps it inherited rather than presenting a clean projection over incomplete input.
One inherited gap is worth calling out. A role that staged no live authorisation rows produces no conflicts in a projection, and there are two reasons a role can look like that: it genuinely grants nothing, or the extract could not read its contents. Those are opposite facts about a proposed grant, so the count of such roles is shown beside the run rather than left for the reader to discover.
Results are also not a series. Each run reports the total for its own population, so two runs are comparable only when they were built on the same scan and the same ruleset. A run built on an earlier scan is marked as one, and the ruleset moving between two runs is enough to make their totals answer different questions.
¶ Limits
- It is a projection, not a state. It tells you what the analysed population would produce, and the landscape may have changed since the scan it was built on. The card says how old that scan is for exactly this reason.
- It does not make the change. There is no write path to SAP. The grant or the withdrawal happens in the customer's own change process, and the next scan is what confirms it.
- It cannot model what the ruleset does not look at. A conflict no rule describes will not appear before or after the change.
- It does not judge whether the person needs the access. It answers whether the access creates a conflict, which is one input to that decision.
- Recent runs are listed, not the whole history. Where older runs are not listed, the screen says so rather than showing a page that looks like a complete record.
¶ Frequently asked questions
¶ Does a what-if run touch the SAP system?
No. It reads a sealed scan that is already held by the platform and works on a copy of that population. No connection is opened and nothing is written back.
¶ Can it show which role to remove to clear a conflict?
Propose the removal and read the answer. Where a conflict arrives by several paths, withdrawing one role often leaves it standing, and that is exactly the case a what-if exists to catch before somebody reports the remediation as done.
¶ Can it model an emergency access window?
Yes, by giving the proposed grant the dates it would be valid between. A grant whose validity window does not cover the scan date is treated the same way a real one would be.
¶ How long does a run take?
It runs the same analysis as a normal scan over a copied population, without the time spent reading SAP. In practice it is a short interactive wait rather than a batch job, and it does not block the scheduled scan of that system.
¶ Is the result stored?
Each run is kept with the scan it was built on, the proposal it applied and the totals it produced, so an approval decision can be traced back to the projection it rested on.