the reorg nobody deprovisioned

A 300-person tech company goes through a reorg on the first Monday of Q1. The CEO sends the announcement on Friday afternoon. The new org chart is published in Notion. Over the weekend, managers adjust direct reports in the HRIS. Slack channels get renamed. A few email aliases are updated. By Monday morning, the company has a new structure.

From an HR standpoint, the reorg is complete. Reporting lines are correct. Titles are updated. Compensation bands match the new roles. The new quarterly planning is already scheduled.

From an IAM standpoint, almost nothing has happened. The HRIS pushed title changes to the identity provider, which updated display names and, in a minority of cases, department attributes. A handful of managers requested new permissions for people whose scope expanded. Approximately no one requested removals for people whose scope contracted.

Ninety days later, the shape of who-can-access-what in the company is the same as it was before the reorg, plus a layer of additional grants from the expansions, minus essentially nothing. The reorg happened on paper. The access graph absorbed it by addition only.

This is the mover problem, applied at scale. Movers, employees who change roles without leaving the company, are the single largest generator of access creep in any mature organization. Reorgs are mass mover events. Every quarter or two, a mature company runs one. Every one of them dumps additional permissions into the access graph while clearing almost nothing. Five years of reorgs, running two to four per year, produces the access surface most companies actually have.

reorgs change reporting; they don’t change access

The identity provider in most mid-sized companies is wired to the HRIS for a specific set of attributes. First name, last name, email, job title, department, manager, employment status. When an HR record changes, those attributes flow through to the IdP. Group memberships in Active Directory or Okta are sometimes tied to department attributes, so a department change triggers some movement. Most other permissions, the ones granted in individual SaaS applications, in permission sets inside specific tools, in custom groups maintained by team admins, sit entirely outside that sync.

When an employee’s title changes from Senior Engineer to Engineering Manager, the HR record updates. The IdP updates the title. Some groups tied to department may update. Salesforce permissions do not update, because Salesforce permissions were maintained manually by the RevOps admin in 2023 and never attached to role-level automation. GitHub org membership does not update, because GitHub membership was added case-by-case by the person who made the original request. AWS IAM roles do not update, because those were assigned through a ticketing process two years ago and have no connection to the HRIS. SharePoint permissions do not update, because SharePoint permissions are a separate universe entirely.

The title change takes effect in the two systems where it is wired to take effect. In the thirty or forty other systems where the employee has access, the title change is irrelevant. Their permissions in those systems continue to reflect what they had before the reorg, not what they have now.

The multiplicative effect: if the reorg moves fifty people across a 300-person company, and each person has accumulated permissions across thirty systems, there are fifteen hundred (employee × system) pairs where an access adjustment would theoretically be appropriate. In practice, the number of adjustments that actually happen is in the low double digits. The rest of the pairs drift out of alignment, quietly, all at once.

what a reorg updates, and what it leaves behind

updates on its own

driven by the HR record

• Job title and department in the identity provider
• Manager field and reporting line
• Groups tied to department, sometimes

stays as it was

nobody owns the change

• Permissions inside the CRM and data tools
• Repository and project access from the old team
• Shared drives, channels and admin roles from the old job

the expansion-only pattern

Every reorg has a predictable pattern in the identity provider logs. The two weeks immediately following the announcement generate a spike of access requests. Managers and new scope owners request permissions for people who now need them.

The spike is one-sided. Nearly every ticket in it is a grant, “please add Sarah to the finance Slack channel for her new scope,” “please give David admin on the data warehouse now that he’s leading analytics.” Very few tickets are revocations. Nobody writes a ticket saying “please remove Maria’s admin on the data warehouse because she’s no longer leading analytics.” The reason is mechanical: Maria, who lost scope, has no incentive to reduce her own access, and her former manager has no reason to remember that Maria used to have admin on the data warehouse, let alone file a ticket to remove it.

The expansion-only pattern is structural. The cost of the grant is felt by the person who needs the access, they file the ticket because they can’t do their new job without it. The cost of the revocation is felt by nobody, because no individual in the company experiences the consequences of Maria continuing to have unused admin on the data warehouse until the day someone exploits it.

Multiplied across fifty moved employees and thirty systems, every reorg shifts the access graph in one direction. The graph becomes strictly more permissive relative to current roles. Over five reorgs, the gap between “what people’s current scope requires” and “what people’s current access provides” opens wide enough to drive a truck through.

the legacy permission from the project that dissolved

A specific failure mode worth naming: the project-specific grant that outlives the project.

A team gets spun up for a strategic initiative. It runs for eighteen months. During that time, members of the team accumulate access to all the systems the project touches, a specific Salesforce dashboard, a specific Notion workspace, a specific data warehouse schema, a specific S3 bucket. The access is scoped to the project by intent. Nobody scopes the access to the project by configuration, because configuring project-scoped access in most systems is harder than just adding the person.

The project ends. The team dissolves. Members go back to their original reporting structures, or move to new roles, or leave the company. Their access to the project systems, all of it, remains in place, because nothing in the company knows that the project ended in a way that would trigger cleanup. The Notion workspace is still there, orphaned. The Salesforce dashboard is still there, unused. The S3 bucket is still there, holding whatever data the project generated.

Five years later, an access audit finds twelve people with admin on a Notion workspace called “Project Phoenix” that was archived three years ago. Nobody at the company currently remembers what Project Phoenix was. Nobody can authorize removing the access, because no current manager owns the decision. The access sits there because no process handles the “project ended” event, even though the “project ended” event is one of the most common events in the company.

Every reorg is a bulk dissolution of projects. Every project dissolution leaves behind its access graph. The reorg announcement celebrates the new structure. The access graph of the dissolved structure remains fully operational.

what a reorg-aware identity program looks like

A functional identity program treats reorgs as first-class events. The pattern that works has three specific moves.

The first move is pre-reorg access snapshots. Before the reorg takes effect, IT or security captures a snapshot of the current permission graph for every person being moved. The snapshot is the baseline against which post-reorg state will be measured. Without it, the post-reorg question “what did this person have that they no longer need?” is unanswerable, because nobody has the before state.

The second move is role-change triggered reviews. When an employee’s title or department changes in the HRIS, the IdP does not merely update the attribute. It generates a work item, a review task assigned to the new manager, asking: here is everything this person has access to right now. Here is what their previous role implied they needed. Which of these items should they keep in their new role? The manager’s response drives revocations, not just grants.

The third move is time-bound reorg permissions. Grants made in the two weeks following a reorg, the expansion spike, carry a default 180-day expiration. If the access is still required at the end of 180 days, it can be renewed. The default is to expire. This inverts the normal drift toward permanence. Each reorg becomes a natural pruning event, because the grants it created have an end date built in.

None of these three moves is technically difficult. All of them are organizationally difficult, because they require explicit attention to an event, the reorg, that the organization otherwise treats as a leadership announcement rather than a security operation.

the reorg is also an opportunity

The frame most security programs use for reorgs is defensive. The reorg generates access drift; the security team’s job is to minimize the damage. This framing misses something.

A reorg is also the single best natural moment in the company’s calendar to reduce access. Employees who are already changing roles, already expecting to learn new systems, already adjusting to new scope, are the employees for whom access changes feel normal. Revoking access during a quiet quarter feels like the security team interfering. Revoking access during a reorg feels like part of the reorg.

The companies that realize this run their reduction work on the reorg cadence. Every quarterly reorg is paired with a quarterly pruning. The expansion spike is matched with a revocation sweep, informed by the pre-reorg snapshots and the role-change reviews. Net effect on total access: flat or slightly negative, against an unpruned baseline that is always strictly positive.

This changes the long-run trajectory. A company running unpruned reorgs has an access surface that grows monotonically through each reorg. A company pairing reorgs with pruning has an access surface that oscillates around a stable baseline. Over five years, the two are not in the same universe.

the exercise

Pull the list of everyone whose role or department changed in the last twelve months. This is typically available from the HRIS in one query. Call the number N.

For each of those N people, pull their current access across the top five systems where your company holds sensitive data. CRM, data warehouse, code repositories, wiki, file storage, whatever the top five are for you.

For each person, ask: is their current access consistent with their current role? Not their previous role. Their current one.

The answer, for most of the N people, will be “no, they still have at least some access from their previous role that is not required for their current one.” For a meaningful fraction, the answer will be “substantial residual access from the previous role that could be removed today without operational impact.”

Remove it. Then do the same exercise the next quarter for the next set of movers.

The reorg already happened. The access graph hasn’t caught up. It won’t catch up unless someone makes it.