Continuous governance

The ninety days between reviews

An entitlement granted the day after a review sits unexamined for a quarter. What watches in between.

Every connected app is read every 2 hours: who holds an account, what that account can do, and when it was last used. A read of the app itself, not an assumption from what was last provisioned.

That cadence is the whole point, because a review is periodic by nature, and everything between two of them is unwatched. An entitlement granted the day after a cycle closes sits unexamined for 89 days, and the review that eventually sees it is looking at something 3 months stale.

That is the structural limit of certification as a control. It is a snapshot, and the thing it governs is a film.

Governance after the fact tells you what went wrong last quarter. The point of doing it continuously is to find out while it is still cheap.

What actually runs

Every connected app is read every 2 hours: who holds an account, what that account can do, and when it was last used. A read of the app itself, not an assumption from what was last provisioned, because those two drift and the drift is where the findings are.

Those reads are correlated against the systems that hold the truth about people. The HRIS says who is employed and who left. The IdP says who can authenticate and which groups they are in. Access with no matching employment record is a different problem from access with no matching group, and telling them apart needs all 3 sources at once.

What it looks for

Orphaned accounts. Terminated in the identity source, still holding accounts in apps. The offboarding that did not finish, and usually the biggest category on a first scan.

Overprovisioned accounts. More access than the role accounts for, whether accumulated across role changes or granted once and never removed.

Third-party accounts. External people holding access, which are the least reviewed because they belong to no manager's team.

Zombie accounts. Live credentials nobody has used in months.

New privileged accounts. Somebody gained admin since the last scan, which is worth knowing in hours rather than at the next quarter.

Separation of duties violations. Per app and per rule, because the conflicting pair in Salesforce is not the one in NetSuite.

Findings arrive as an inbox

Das Action Center in Iden mit 23 offenen Findings, links die Kategorien (verwaiste Accounts 10, überprovisioniert 7, Drittanbieter 4, Zombie 1, neu privilegiert 1, dazu zwei SoD-Prüfungen bei null) und rechts die verwaisten Accounts, jeweils mit dem Offboarding-Datum und der Anzahl noch gehaltener Applikationen.

Findings als Eingang. Links Kategorien und Anzahl, rechts die Warteschlange, zwei Kategorien stehen schon auf null. Angelina wurde vor drei Tagen offgeboardet und hält noch sechs Applikationen.

Inbox zero is the design goal, and that is a choice rather than a metaphor. A dashboard shows a number and asks you to feel something about it. An inbox gives you a queue with an end, and the end is reachable.

Two details in that screen are the actual design.

Age is on every row and the recent ones are marked. Angelina was offboarded 3 days ago and still holds 6 apps; Manoj was offboarded 8 months ago. Those are different problems. Ranking by count alone buries the one that happened yesterday under twenty-five that came with the estate.

Nothing blames you for what you inherited. Findings that existed when Iden first connected are marked as inherited and kept out of the open count. A tool that opens by telling an admin about 300 failures they did not create is a tool they stop opening.

Clearing a finding is not always removing access

Three ways to close one, and only one of them is a deletion.

Fixed at source. The access is gone and so is whatever granted it, so the finding does not return next scan.

Excepted, with an expiry. This is correct, here is who says so, and here is until when. A named exception with a date is a governance artefact. An ignored finding is not.

Reviewed. Somebody looked, decided, and recorded it. An admin often cannot remove access because a business owner says no, and crediting the decision rather than the deletion is what keeps the queue honest.

That is what makes inbox zero reachable. If clearing a row always meant deleting something, the queue would never empty and nobody would try.

What this does to the quarterly cycle

It does not replace it. Most frameworks want a named person attesting on a schedule, and continuous checks do not satisfy that on their own.

What changes is what arrives in the campaign. A reviewer opening one that continuous checks have already cleaned sees judgement calls at a volume they can read, instead of 400 rows of which 390 are obviously fine.

That is the only reliable way to make an attestation mean something.

What still needs a person

Thresholds. How long unused is too long, which apps warrant tighter checks, what counts as overprovisioned in your organisation. Defaults get you started and will be wrong in ways only you can see.

And the exceptions. Every one of them is somebody deciding that access which looks wrong is correct, and that decision cannot be automated without becoming a rubber stamp with extra steps.

Frequently asked questions

No. Most frameworks want a periodic attestation by a named person. What it does is make that cycle small, because the obvious problems have already been cleared.

It depends entirely on your thresholds, and the first fortnight is loud because it is finding a backlog rather than a flow. After that, most findings resolve automatically and only judgement calls route to a person.

Orphaned accounts, grants no policy explains, privilege creep across role changes, service accounts with no owner, and access unused past whatever threshold you set.