New to IGA & SailPoint: Seeking Advice on Governance Group Cleanup

SailPoint Human Fabric (SHF) SHF Discussion and Questions
1

Hi All,

I’m new to the IGA space and recently started working with SailPoint. My background is in CyberArk PAM, so identity governance concepts such as governance groups are fairly new to me.

I’m curious how experienced SailPoint practitioners handle governance group cleanup. As environments mature, I imagine governance groups can become outdated, lose ownership, or no longer serve a valid purpose.

For those managing SailPoint today:

  • How do you identify governance groups that should be cleaned up?
  • How often do you review them?
  • Is the process manual or automated?
  • What governance controls do you have around group ownership and maintenance?

I’d love to learn from your experiences and understand what has worked well (and what hasn’t).

Thanks for your guidance!

2

Hey Amirdhavarshan, welcome to SailPoint community! Coming from CyberArk, think of this like reviewing vault/safe ownership, just applied to approval routing.

Identifying candidates for clean-up

  • Pull all groups via API/search and check where they’re actually referenced — as owner on Roles, Access Profiles, Entitlements, or as approver in Workflows/Certs.
  • Zero members, or all members deactivated/terminated.
  • “Orphaned” groups that were never decommissioned/used.

Review cadence

  • Quarterly, aligned with our certification campaign.

Manual vs. automated

  • Detection is automated (scheduled script via API generates a cleanup-candidate report). Deletion is manual review — group references aren’t always visible in the UI, so we validate via API before removing anything.

Ownership controls

  • No group created without a named owner + documented purpose (enforced via intake process).
  • Owner changes/departures trigger a review of everything they own.
  • Simple naming convention (GG-<Function>-<Purpose>) keeps things traceable.

One tip from a PAM background: “unused” isn’t always “safe to delete” — a group can be silently referenced in workflow approval logic without an obvious dependency. Trace usage before cleaning, not just membership.

3

Hello @Amir700

One approach I’ve found useful for governance group management is the ISC Governance Connector: Integrating SailPoint with Identity Security Cloud Governance.

It works as a loopback connector, allowing you to bring governance groups , user-levels permissions information through a configured source as entitlements.

From there, you can use the standard ISC lifecycle and governance capabilities to automate processes such as:

  • Governance group assignment and removal

  • Lifecycle-based cleanup

  • Access certifications

  • Other governance operations based on your requirements

Thanks

4

Hi @baoussounda ,

Good day. Hope you are doing well.

Thank you for the suggestion. I will explore this approach and see how it works.

Best Regards,
Amirdhavarshan M A

5

Hi @suraj_gorle ,

Good day. Hope you are doing well.

Thank you very much for the suggestion. I actually tried a similar approach by scanning all Governance Groups and checking their associations through APIs. This included separate API calls to identify references in entitlements, workflows, and other related objects.

However, I was not confident enough to conclusively determine whether a Governance Group could be safely deleted. While the discovery process helps identify some associations, Governance Groups can potentially be referenced in multiple areas such as Access Profiles, Sources, Entitlements, Workflows, Separation of Duties (SoD) policies, and other configurations. Because of these various dependencies, I am still not fully confident that a Governance Group is safe to delete or disable based solely on the information gathered through discovery.

Another challenge is that we currently do not have a well-defined naming convention for Governance Groups, which makes the analysis even more difficult.

Thank you again for the suggestion. I truly appreciate your input and will continue exploring this approach further.

Best Regards,

Amirdhavarshan M A

6

Welcome back, Amirdhavarshan.

For cleanup, I would first check:

GET /workgroups/v1/{workgroupId}/connections

ISC currently tracks connections for ACCESS_PROFILE, ROLE, SOD_POLICY, and SOURCE.

For deletion:

POST /workgroups/v1/bulk-delete

Groups with tracked connections are returned as inUse and are not deleted.

I would still check entitlement approvals, workflows, and certification campaigns for the Governance Group ID, since those are not in the documented connection types.

My flow would be:

connections empty → check other references → business confirmation → bulk-delete

The lack of a naming convention should not block this because the checks use the group ID.

7

Hi @Amir700 ,

In our ISC environment, we manage Governance Groups through a Governance Connector and treat them as entitlements. This gives us a structured way to govern ownership, reviews, and lifecycle management directly within SailPoint rather than relying on manual cleanup. Happy to share more details if you are interested in the setup.