When someone leaves, so does their access.
The riskiest hour in access governance is the one after someone resigns. Driply knows every tool they hold, schedules the removal against a deadline you set, and records each one as it is confirmed.
Last day
7 tools to remove
+4 hours
5 confirmed removed
Due tomorrow
2 still outstanding
Disabling the email account feels like offboarding, and it is the easy part. What outlives someone is the long tail: the standalone login to a billing tool, the design seat that still bills, the repo access that was never behind single sign-on. Because Driply already knows every tool a person holds, offboarding starts from a complete list rather than a memory, runs against a deadline, and leaves proof that each account was actually removed.
Orphaned access is the failure nobody notices
An account left behind produces no error, no alert, and no complaint. It sits there costing a license and holding data until an audit, an incident, or an invoice finds it, which can be a year later.
The reason is structural rather than careless. Access accumulates through many small decisions across many tools, and no single person holds the whole picture at the moment it matters. Offboarding from memory reliably misses whatever was granted longest ago.
Start from the full list
The register already knows every tool the person holds and at what level, so offboarding opens with the complete picture instead of the tools somebody happens to remember.
Scheduled against the last day
On Business, an HR manager schedules the offboarding for the leaver’s final day and Driply raises it on the date. It then tracks what is still outstanding against the completion window your policy or ISMS commits to, and reminds the people who can act before that deadline is missed.
Hand over what they owned
If the leaver owned tools, those tools surface in the same flow so ownership is reassigned rather than quietly vacated. A tool without an owner is how the next request stalls.
The result, A departure that ends in a clean register, not a year of quiet exposure.
Removal you can prove, not just assert
Each removal is confirmed by the person who performed it, and that confirmation is written to the append-only log with a timestamp. "We remove access within one business day" stops being a sentence in a policy and becomes a claim with a trail behind it, which is exactly what an auditor and an enterprise customer both ask to see.
When Google Workspace or Slack is connected, a person disappearing from the directory surfaces in Driply as someone to offboard, so a departure that was handled in the identity provider does not silently skip the rest of the stack. The connectors are read-only: they tell you what is true, they never change it.
Scheduling a departure is exactly the kind of power that should not be self-serve, so the HR Manager role is deliberately bounded: an HR manager can schedule an offboarding for an employee, but never for an admin or another HR manager. The role that plans the lifecycle cannot be used to remove the people who supervise it, and it carries no admin rights over the rest of the workspace.
As everywhere, Driply records and prompts. Your admin or the tool’s owner performs the actual removal in each tool, and attests to it. Driply never writes to your tools, which is also why an offboarding here can never half-execute against a system it does not control.
Driply documents and proves access. It doesn’t provision or revoke inside your tools, and by design never writes to them. You stay in control of the actual access.
Questions, answered.
- Does Driply delete the accounts?
- No. It produces the complete list, tracks the deadline, and records each confirmed removal. Your team performs the removal in each tool, which keeps Driply out of write access to your systems entirely.
- How do we know nothing was missed?
- The list comes from the register rather than from memory, and the offboarding is not complete while any tool is outstanding. What remains is visible against the completion window the whole time.
- Who can schedule an offboarding?
- An admin, or an HR manager on Business and up. HR schedules it against the leaver’s last day and Driply raises it on the date. An HR manager cannot schedule one for an admin or for another HR manager, so the role that plans departures can never be turned on the people who oversee it.
- What about someone who left last year?
- Access reviews and grant expiry are how you find historic leftovers: expiries flag access that has outlived its purpose, and a review campaign walks the register tool by tool so orphaned grants surface and get removed.