Skip to content
Cleanup and review

Every account is explained, or it is retired.

Guard cleanup and access reviews reconcile who holds access in Atlassian against the people and systems that should, then keep it that way with a recurring review that produces evidence. Atlas Bench runs the reconciliation across Guard and your identity provider, puts every unexplained account in front of an owner, and sets up the review your team runs afterwards.

Guard cleanup that reconciles licensed users against the people and systems that should exist, and a recurring access review that keeps the count and the permissions defensible after the project ends.

identity owner expires one owner recorded, five unaccounted L1 L2 L3 L4

The problem

A licensed user count that exceeds headcount is the most common first finding and the least understood. The gap is rarely people who left. It is structure: directory groups that grant more than their names suggest, accounts deactivated in the identity provider but never suspended in Atlassian, duplicates carried over from an acquisition, and integration users nobody owns.

Cleanup on its own does not hold. Without a review that someone owns and runs on a cadence, the count drifts back before the next renewal, and every account that drifted is also an identity an agent can be given or inherit.

What the work is

Account reconciliation

Guard users joined against the identity provider and the HR record. Accounts with no directory match, deactivated people who still resolve to an active Atlassian account, and people in more groups than their role explains all fall out of the join.

Guard cleanup and true-up

Reconciling licensed users against actual users, retiring what is dormant, and making the count defensible before it is renewed.

Deprovisioning that removes access

Deactivation in the identity provider suspends the Atlassian account the same day. Configured, then tested with a real leaver, because a connection set up to create but not to suspend is the most common cause of the gap.

Duplicates and orphaned accounts

Duplicate identities from mergers and personal accounts resolved to one per person with history preserved, and integration and service users traced to an owner or retired.

Access reviews and evidence

A recurring review that produces an artifact an auditor accepts, with an owner recorded for every group and every exception.

Running the review

Reviewers, cadence, and what happens when a reviewer does nothing, decided up front. The first cycles run with your team, and the review can continue under managed support once it holds.

How it runs

  1. Reconcile

    1 to 2 weeks

    Exports from Guard, the identity provider, and the HR system joined on email. Every mismatch is listed with its likely cause, and nothing is changed yet.

  2. Clean up

    2 to 4 weeks

    Owner decisions collected, then accounts suspended, merged, or retired in a controlled sequence. Deprovisioning is fixed and tested, and the licensing position is trued up before renewal.

  3. First review

    2 weeks

    The review procedure designed with the people who will run it, the first cycle completed alongside them, and the evidence format agreed with whoever audits it.

What you get

  • A reconciliation report listing every mismatch between Guard, the identity provider, and the HR record, with its cause and the owner decision
  • A cleaned licensed user base and a true-up position ready for renewal
  • Deprovisioning from your identity provider configured and tested end to end
  • A resolution log for duplicate, orphaned, and integration accounts
  • An ownership register naming an owner for every group and every exception
  • An access review procedure covering cadence, reviewers, and escalation
  • The first review cycle completed with your team, and the evidence it produced

Questions we get

Can we just remove the inactive users?
You can, and the count will drift back, because the structure that produced it is unchanged. Removing inactive users is one step of the cleanup, not the cleanup.
Will cleanup lock out someone who is working?
No account is removed without an owner decision. Accounts are suspended before they are deleted, and changes that affect login are applied outside working hours, so a mistake is a quick reversal rather than an incident.
Do we need Okta for this?
You need an identity provider that owns provisioning and deprovisioning end to end. Okta is the one we see most, and the approach works with any provider that does SCIM properly. Atlassian Guard is the Atlassian side of the connection either way.
How often should access reviews run?
As often as your audit regime requires, and never less often than your renewal cycle. The procedure is designed so a cycle costs reviewers hours rather than weeks, which is what keeps it running after the project ends.
How is this different from identity and access?
Identity and access designs the architecture: SSO, SCIM, the group model, and Agent SSO readiness. This engagement cleans up what has already accumulated and keeps it clean. It often runs first, because the licensed user count is the problem that is already visible.
What does this have to do with agents?
Every account nobody can explain is an identity an agent can be given or inherit. Rovo, Forge apps, and MCP connections act as a user or through one, so an estate that cannot explain its human accounts cannot explain its agents either.

Find out who can reach what.

Fixed scope. The assessment starts at the identity layer: human and non-human access, the accounts nobody owns, and what has to be true before an agent gets one. You get the findings, the ownership gaps, and the order to close them in.