¶ Scheduled SoD Scans and Failed Runs
Segregation of duties scans in the RedRays Security Platform run on a stated cadence in an explicit timezone, and a run that cannot reach its SAP system records a failed scan with a reason rather than leaving a gap that reads as a quiet night.
Two things make scheduled analysis worth having over an annual project: the numbers have a date on them, and the absence of numbers is visible. The second is the one products get wrong.
¶ How often should segregation of duties be re-analysed?
More often than the audit asks for, because the point is to see change while it is still cheap to undo.
| Cadence | When it fits |
|---|---|
| Nightly | Landscapes with active role development, or during a remediation programme when yesterday's fix should be visible today |
| Weekly | The common steady state. Fast enough that a new conflict is found in the week it was introduced |
| Monthly | Stable landscapes with a controlled change process |
| Quarterly | The minimum that supports a periodic access review, and the floor most audit calendars assume |
Re-analysing after a transport that touches roles is worth more than any fixed interval, because that is when conflicts arrive. The cost of a scan is a batch read and an analysis run, not a project, which is what makes a short interval practical.
¶ How is a schedule defined?
By choosing a cadence from a closed set: daily, weekly on a chosen day, monthly on a chosen day, quarterly, or every N days. Deliberately not a cron expression. Nobody can validate a cron string in a form, and nobody can render one back as a sentence somebody is willing to sign off.
The next run time is computed in an explicit named timezone rather than in server local time, so a customer who asks for 02:00 gets 02:00 all year. Three behaviours are pinned rather than left to chance:
- On the night the clocks go forward and the chosen time does not exist, the run stays on the same date, shifted, instead of skipping to the next day.
- On the night the clocks go back and the chosen time happens twice, the run does not happen twice.
- A monthly schedule set for the 31st runs on the last day of a shorter month rather than skipping that month.
A run is due when the schedule is enabled and its next run time has passed. There is deliberately no additional check that the current hour and minute match the requested one: that is a one-minute window, and if the scheduler thread is busy during that minute the nightly run vanishes for a day.
¶ What happens when a scheduled scan cannot run?
It leaves a failed scan with a reason. A hole in the scan history is itself an audit finding, so the history has to show that an attempt was made and what stopped it.
Three consequences follow, and each one exists because the alternative reads as good news.
| Behaviour | Why |
|---|---|
| A failed run appears in the history with no result, never as a result of zero | It did not find nothing. It did not finish. |
| A failed run does not replace the dates on the system row; it is added underneath as a last attempt | The previous counts keep the day they were true of. What is withdrawn is the implication that something is refreshing them. |
| Every occurrence records its outcome on the schedule: last status, the error as one sentence, and how many runs have failed in a row | A schedule that can only say "next run 03:00" looks equally healthy whether last night worked or whether four nights failed on the same expired password. |
The same principle governs the system register. A system whose connection has stopped answering stays in the list with its last numbers beside it, because those numbers are still true of the day they were taken.
A system that has stopped answering keeps its last numbers and the date they were true of, rather than dropping quietly out of the register.
¶ How are retries handled?
On a short ladder that belongs to the night rather than to the schedule: a few minutes, then longer, then longer again, giving up when the next scheduled occurrence is due. One row per occurrence, holding its slot and retrying, rather than a row per attempt.
One case never retries. A rejected credential is not retried at all, because SAP locks an account after a small number of failed logons and a retry ladder walking past that limit takes the customer's own scanning account down. A connection that timed out or was refused is a different case and does retry.
There is one live scan per system, held with an expiring lease so that a run whose process died does not block that system forever. A scan whose lease is gone is reported rather than silently reclaimed: reclaiming on age alone means declaring a healthy long-running scan dead and freeing the lock under a live read of a production system.
¶ Limits
- This is scheduled analysis, not continuous monitoring. The chip on a system row never says "live", because all a row knows is what the last scan did.
- An extract-based system has nothing to schedule, and its row says so instead of showing an empty schedule that reads as though something were due.
- Notifications carry counters and a link, never attachments. A pack of names and authorisations sent by mail, with no access control and no way to revoke it, is the wrong answer rather than a missing feature.
- Nothing here decides remediation. The schedule decides how quickly a change becomes visible.
¶ Frequently asked questions
¶ What happens to open cases and decisions between scans?
They persist. A decision is keyed on the system, the user and the rule, and outlives the scan that raised it, so a nightly cadence does not reset anybody's triage work.
¶ Will nightly scans put load on production?
The read is a batch read of administration tables rather than a business workload, and it runs in whatever window the customer chooses. Sizing on a specific landscape is measured during a proof of concept rather than promised in advance.
¶ Can two scans of the same system run at once?
No. One live scan per system, enforced with a lease, which is also what stops a second run starting against production while the first is still reading.
¶ How do we notice a schedule that has been failing?
The schedule carries its last status, the error sentence and a consecutive-failure count, and the scan history shows the failed attempts. Neither is folded away into the next-run time.