Access reviews and offboarding

Find access that should have been removed, and confirm independently that it actually was.

Guides · 2 min read

Offboarding fails quietly. The identity provider gets deactivated on someone's last day because that's the account everyone remembers. The cloud console user, the code-repository seat, the monitoring login that was never wired into SSO — those survive, because nothing forces anyone to look at them again.

How detection works

Connect an identity provider and RegShield builds a workforce roster from it. Connect other systems and it records the entitlements observed in each. When someone marked inactive in your directory still holds live access somewhere else, that becomes a task — one per system, so each can be revoked and verified independently.

How confirmation works

You remove the access in the system itself. On a later sync, RegShield observes that the entitlement is gone and closes the task with a timestamp.

RegShield never holds a credential that can grant or revoke anything. This is a product decision, not a missing feature. An auditor wants independent verification that access was removed, which is stronger evidence than a tool asserting it removed the access itself — and a compliance platform holding write access into every customer's cloud would be a far more attractive target than the problem it solves.

What this needs from you

  • An identity provider connected, so there's a roster to compare against.
  • The systems you care about connected, so entitlements can be observed.
  • For AWS, a read-only permission to enumerate IAM users and their attached policies.

More in Guides

Policies and approvalAdopt from templates or write your own, take a policy through review, and keep a versioned approval record.Reports and the audit binderReadiness reports, the SOC 2 system description, and a one-click export of everything an auditor asks for.Team and rolesInvite people, what each role can do, and how account activity is recorded.
← All documentation