The sanctuary
01In a nutshell #sec_08a1b71d
The Sanctuary allows a resource to be removed from the scope of access reviews — and requires that this exemption be justified, dated, attributed and reviewed.
02The problem #sec_e5c2dc9d
Every recertification campaign encounters resources that have no business being there: a service account that feeds a connector, an archived site kept for legal obligation, a team whose accesses are managed outside the system. Submitting them to a human reviewer produces noise, uses attention, and ultimately degrades the quality of all other decisions.
Therefore, it must be possible to exclude. But exclusion is the natural blind spot of a compliance system: what is out of control is also out of sight. An excluded resource does not appear in any campaign, in any report, in any coverage rate. If exclusion is silent, it becomes the simplest way to make a problem disappear rather than treat it.
This is precisely what an auditor looks for first: not what has been reviewed, but what has not been reviewed, and why.
03The approach #sec_646bb086
Exclusion is not prevented. Exclusion is made costly in transparency.
Banning does not work: a blocked administrator bypasses — he disables the functionality, creates a parallel scope, or gives up launching the campaign. We then lose the trace instead of gaining it.
The Sanctuary therefore takes the opposite approach. Exclusion remains possible, simple and legitimate. But each exclusion leaves a complete footprint, consultable by the auditor, and bears an expiration date . Deterrence does not come from a wall, it comes from the fact that everything is visible.
Three principles follow from this :
1. An exclusion is justified. Codified reason, written justification and identified author are required at the time of creation. The free field is not decorative: it is the sentence that the auditor will read, quoted as is in the file.
2. An exclusion has an end. The review deadline is mandatory. Without it, an exemption set on a Tuesday for three weeks becomes permanent because no one ever reopens it. The product refuses to create this type of hole.
3. An exclusion does not erase. It is lifted — and the lifting is justified in turn. The line remains in the database as a closed cycle. This is what makes it possible to reconstruct a sequence after the fact, including those that no one would want to show.
04How it works #sec_9e591ad2
Setting an exclusion
A dedicated panel guides the selection (platform → service → resource type → object), then asks for the three mandatory pieces of information. The validation button remains inactive until the whole is complete — the constraint is structural, not a simple warning.
Available reasons: out of scope · service account · archived resource · documented exemption · other.
Deadline: 3 months, 6 months, 1 year or free date. The screen announces the reminder date as soon as it is entered.
The life cycle
Each exclusion is a cycle: opened at creation, closed at lifting. A resource can be excluded, reintegrated, then re-excluded — each passage creates its own cycle, and the whole is read as a chronology.
| Action | Effect |
|---|---|
| Set | Opens a cycle (reason, justification, deadline, author) |
| Extend | Pushes back the review deadline — and the trace |
| Lift | Closes the cycle with its own reason; the resource returns to the reviews |
| Delete | Does not exist |
Only exception to indelibility: a line without exploitable object, born of a corrupted import. It has never excluded anything — this is not evidence, it is waste, and it is automatically purged.
The deadline, main signal of the screen
The list of active exclusions is ordered around a single question: which one should have already been reviewed?
- 🔴 Overdue — the entire line is tinted; the History tab bears an alert sticker.
- 🟠 Under 30 days — to be processed soon.
- 🟢 Up to date — nothing to do.
- ⚪️ No deadline — only for lines prior to this rule; impossible to create today.
The history, and what it reveals
The History tab lists the closed cycles, one line per resource, with the exclusion duration and the campaigns that took place during the cycle.
This correlation is the heart of the system. It makes visible a pattern that nothing else shows: a resource excluded just before the launch of a campaign, then reintegrated just after its closure. The file then states it as a dated fact :
⚠️ Lifted on 08/17/2026, 3 days after the closure of the SharePoint Experience campaign — the resource escaped it.
The product does not judge and does not accuse anyone: it exposes the sequence. The interpretation belongs to the auditor.
05Volumetry: a graduated limit #sec_3c647a21
An absolute ceiling makes no sense. Six hundred exclusions in a workspace of eight hundred resources empty the control of its substance; the same six hundred in a tenant of two hundred thousand are anecdotal. The Sanctuary therefore reasons in terms of excluded scope share, and graduates its reaction :
| Level | Threshold | Reaction |
|---|---|---|
| Information | 5 % | The rate is displayed in the screen |
| Alert | 10 % | Amber banner + escalation in the audit posture of the workspace |
| Ceiling | subscription quota | Creation is refused until exclusions are lifted |
Lifted cycles do not consume any quota: history never penalizes current usage.
Bulk import obeys the same rules — reason, justification and deadline apply to the entire batch — and clearly announces what it will not be able to import rather than truncating silently.
06What the auditor finds there #sec_2e9517f9
The screen is opened to him in read-only mode: he consults and exports, he does not set or lift anything.
He finds there, without having to ask: the list of what escapes the reviews and since when, the justification of each exemption in the words of its author, the exclusions whose deadline has passed, the complete history of the back and forth, and the correlation with the campaigns.
The export includes all these elements — reason and justification included. An export of exclusions without the why would have no probative value.
07Proper usage #sec_c198674c
What the Sanctuary is for: service accounts and technical identities, archived resources kept by obligation, scopes governed by an external documented system, validated and dated exceptions.
What it is not for: making a problematic resource disappear while waiting for it to pass, artificially improving a compliance rate, bypassing a disagreement with a reviewer. These uses are not technically blocked — they are simply visible, and that is deliberate.
08To remember #sec_dab7f98b
The Sanctuary does not protect resources: it protects the credibility of the review system. A control that can be exited without leaving a trace proves nothing. By making each exclusion motivated, dated, reviewable, and readable by a third party, it allows to affirm not only what has been reviewed, but also what has not been, why, and until when.