An offline extract can be uploaded to the RedRays Security Platform and analysed for segregation of duties exactly as a live SAP connection would be, producing a full scan that is badged permanently as an imported extract and states per rule what the extract was able to answer.
Some landscapes cannot be reached. An air-gapped production system, a system belonging to a company being acquired, an auditor's extract handed over as a spreadsheet, or a role design being reviewed before it is built. All four are legitimate, and all four deserve the same analysis rather than a lesser one.
Yes, and it is marked as imported for its whole life. It runs the same analysis, produces the same evidence, seals the same way, carries the same case layer, and appears in the same registers. What differs is provenance, and provenance is recorded because a number taken live out of production and a number taken from a spreadsheet somebody emailed are not the same evidence.
Imported scans are also kept on their own series in the trend chart. A line drawn from a live scan to an imported one would suggest a change in the landscape where there was a change in the source.
Three grains are supported, and the grain is declared in the bundle rather than inferred from which files happen to be present. Inference is how a bundle that is missing a file quietly becomes a weaker analysis without anybody noticing.
| Grain | What it carries | What it supports |
|---|---|---|
| A | The authorisation values themselves, plus user-to-role assignments | Full evaluation of rules written over authorisation objects and fields |
| B | Role-to-transaction mappings, plus user-to-role assignments | Rules whose conditions can be met from transaction-level data |
| C | User-to-transaction mappings, with no roles | Transaction-level rules only, and no role path in the evidence |
The bundle is one archive of CSV or Excel files whose names and columns match the expected layout. Organisational values have a defined place in the layout, so organisational separation still applies where the extract carries it.
The honest answer is: it depends on what is in it, and the product computes that rather than describing it in a manual.
| Missing from the extract | Effect on the result |
|---|---|
| Account attributes such as lock status and account type | Conflicts on locked accounts and on reference-user templates can no longer be held back, so the result overstates by those rows |
| Reference-user links and directly assigned profiles | Access that arrives by those paths is invisible, so the result understates by the conflicts only reachable that way |
| The authorisation instance | The single most consequential omission. A condition that requires several fields on one object can no longer be evaluated at all, and rules that need it are marked as not evaluable rather than answered wrongly |
| Assignment validity dates | Lapsed and future-dated grants cannot be told apart from live ones |
| Names and departments | The population cannot be distributed to line managers for review |
The authorisation instance case deserves the detail. If a bundle carries no instance identifier, there are two ways to guess and both are wrong. Treating all of an account's authorisations as one instance glues unrelated grants together and invents access nobody holds. Treating each row as its own instance makes any multi-field condition unsatisfiable. Both errors are invisible in the result, so the import refuses to answer those rules instead of picking one.
A per-rule verdict computed from the uploaded data before anything is created: full, partial or not evaluable, with the authorisation objects and fields that are missing named on each partial rule.
It is deliberately per rule and not a single coverage percentage. One number would let somebody sign off a scan in which a critical rule was never evaluated at all. A partial verdict with no list of what is missing is a complaint rather than a finding, so the list is always attached.
Every fact the scan rests on is then carried on the result as measured, partial or not supplied, and a count that rests on a fact nobody supplied is drawn as a dash rather than a zero. See what a finding does and does not claim.
In two steps, on purpose. The first parses the bundle, validates it and computes coverage, and creates no scan. The second is an explicit commit that creates the scan. A bundle that fails validation therefore never occupies the slot reserved for a live scan on that system, and nobody has to clean up after a bad file.
Validation is row by row, and every rejected row is reported with its file, its sheet, its row number counted the way a spreadsheet counts, the column, the value, a code and a sentence saying what is wrong. Bulk-loading first and discovering a bad row afterwards fails the whole file with one unhelpful message.
They sit in the same registers and can be read side by side, but they are not joined into one trend line, and the coverage of each is stated. Comparing totals across different sources without reading the coverage is how a difference in evidence becomes a claimed improvement.
Yes. An import is a full scan, so decisions, mitigations, access reviews and the export pack work over it in the same way.
Yes. An extract of a proposed design can be analysed the same way, which is a cheaper place to find a conflict than production.