Access reviews people finish, and auditors accept the first time.
We design and run identity governance programs on SailPoint, Saviynt and Microsoft Entra ID Governance, from the first connector to the certification campaign your auditor actually reads.
HR systemhires · moves · exitsDirectoryAD · Entra ID
02 · Governance
IGA platformSailPoint · SaviyntRoles and SoD rulesbirthright · toxic combos
03 · Applications
ERP and financeSAP · Dynamics 365CRMSalesforceData platformSnowflake roles
04 · Evidence
Access reviewsmanagers · ownersAudit evidencewho · what · when
SailPointSaviyntMicrosoft Entra IDOkta
in short·15-second read
Identity governance and administration (IGA) decides who should have access to what, grants it automatically when people join or move, removes it when they leave, and proves all of that to an auditor.
Cohash designs IGA programs, builds the connectors and roles, runs certification campaigns, and upgrades platforms like SailPoint IdentityIQ when new versions ship.
you probably need this if
Auditors ask who approved an access grant, and the only answer is in somebody's email.
People who changed roles still carry access from their last two jobs.
Leavers keep working accounts for days because deprovisioning waits on a ticket.
terms on this pageEntitlementdefinitionA specific permission or access right a person holds in a system, such as the ability to post journal entries in a finance app.explained in a field note →Certification campaigndefinitionA scheduled review in which managers or owners confirm, person by person, whether each one should keep the access they hold.explained in a field note →ConnectordefinitionThe integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.explained in a field note →
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Identity Governance & Administration, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · identity governance &…3 open
openAuditors ask who approved an access grant, and the only answer is in somebody's email.
recurringPeople who changed roles still carry access from their last two jobs.
blockedLeavers keep working accounts for days because deprovisioning waits on a ticket.
exposure
Joiner, mover, leaver automationConnectors and application…Certification campaign designRole and entitlement modelingSeparation of dutiesPlatform upgrades and migrations
startrehearsehandover
Discovery
Design
Build in waves
Run and hand over
we are here
ready to hand over
We book the production window knowing exactly which objects changed, with a runbook…
Managers get fewer line items, and they can read them.
Transfers trigger a defined removal step, and existing excess access is cleaned up in…
Application onboarding backlog ranked by risk and audit scope
chapter 01 · where it hurts
Why teams reach out
Auditors ask who approved an access grant, and the only answer is in somebody's email.
People who changed roles still carry access from their last two jobs.
Leavers keep working accounts for days because deprovisioning waits on a ticket.
chapter 02 · what we change
How we solve it
Joiner, mover, leaver automation
Connectors and application onboarding
Certification campaign design
Role and entitlement modeling
Separation of duties
Platform upgrades and migrations
chapter 03 · how it runs
Our approach
Discovery
Design
Build in waves
Run and hand over
chapter 04 · where you end up
What changes
We book the production window knowing exactly which objects changed, with a runbook we've already rehearsed and a rollback ready.
Managers get fewer line items, and they can read them.
Transfers trigger a defined removal step, and existing excess access is cleaned up in reviewed batches instead of one risky sweep.
Application onboarding backlog ranked by risk and audit scope
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
HR-driven provisioning and deprovisioning, with birthright access defined per role and department. Movers are where most programs leak access, so we design that flow first.
Getting applications into governance is most of the work. We order them by risk and audit scope, and build an onboarding pattern your own team can keep running once we've gone.
Campaigns sized so reviewers can actually make decisions. Each line item has context, the defaults are sensible, and revocations get carried out instead of only recorded.
Roles mined from real access data, cleaned up with the business owners, and kept small enough to maintain. Entitlement descriptions written so a manager understands what they're approving.
Toxic-combination rules for finance, HR and privileged systems are checked when someone requests access, rather than discovered in the next audit.
We take IdentityIQ through each GA release, including the 9.0 move to Jakarta EE. Sometimes migrating to Identity Security Cloud is the better call, and when it is, we do that instead.
capability 01 / 06in production
Joiner, mover, leaver automation
HR-driven provisioning and deprovisioning, with birthright access defined per role and department. Movers are where most programs leak access, so we design that flow first.
Getting applications into governance is most of the work. We order them by risk and audit scope, and build an onboarding pattern your own team can keep running once we've gone.
Campaigns sized so reviewers can actually make decisions. Each line item has context, the defaults are sensible, and revocations get carried out instead of only recorded.
Roles mined from real access data, cleaned up with the business owners, and kept small enough to maintain. Entitlement descriptions written so a manager understands what they're approving.
We take IdentityIQ through each GA release, including the 9.0 move to Jakarta EE. Sometimes migrating to Identity Security Cloud is the better call, and when it is, we do that instead.
We pieced these together from Identity Governance & Administration situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
IdentityIQ 8.4 with 400 custom rules, two plugins and a 9.0 upgrade to plan
composite · not a client story
Beforethe situation
Roughly 400 BeanShell rules written by several integrators over the years, two custom plugins that call javax.servlet classes, and an internal audit in March that samples leaver revocations.
What we dothe work
Run SailPoint's 9.0 pre-check against every rule, workflow, form and plugin, and sort the findings into mechanical fixes and real rewrites. Retire rules that nothing references. Port the plugins to jakarta.* and rehearse the upgrade on a cloned database with timed steps.
Afterwhere you end up
We book the production window knowing exactly which objects changed, with a runbook we've already rehearsed and a rollback ready. The March audit samples leavers on the upgraded platform.
case file 02
Certification campaigns that managers finish in under ten minutes
composite · not a client story
Beforethe situation
Quarterly manager reviews show up with several hundred line items each, entitlement names like APP_GRP_0412, and no record of what was decided last quarter. Every campaign closes on time. Almost nothing gets revoked.
What we dothe work
Write plain-language descriptions for entitlements in the applications audit samples most. Route privileged entitlements to application owners and leave the rest with managers. Allow auto-approval only for birthright access already granted by role.
Afterwhere you end up
Managers get fewer line items, and they can read them. A revoke becomes a provisioning task that actually closes. Auditors see decisions with reviewer comments, where they used to see one bulk approve.
case file 03
Workday feeds IdentityIQ, but transfers never remove anything
composite · not a client story
Beforethe situation
A transfer in Workday updates department and manager in IdentityIQ overnight. Nothing removes the previous role's entitlements, so people who moved twice still hold finance and HR access from earlier jobs.
What we dothe work
Define a mover event keyed on job profile and cost center change, keep old access for a short agreed overlap, then send a targeted review to the previous manager. Run the same logic in report mode against current identities before cleaning up the backlog.
Afterwhere you end up
Transfers trigger a defined removal step, and existing excess access is cleaned up in reviewed batches instead of one risky sweep.
Identity data flows from HR into the governance platform, which applies role and separation-of-duties rules, provisions access to applications and sends review work to managers and owners.
We don't start a step until the last one has produced something you can check.
step 01
Discovery
First comes measurement. We count the applications in scope, look at your identity sources and data quality, and read the open audit findings. Only then do we write a plan or an estimate.
step 02
Design
Target lifecycle flows, role approach, connector backlog and campaign design, agreed with your IAM team, HR and audit.
step 03
Build in waves
We onboard applications in prioritized waves and test each one against real joiner, mover and leaver scenarios before it goes live.
step 04
Run and hand over
The first certification campaigns run with both teams in the room. After that we hand over runbooks, train your people, and they take it from there.
you keep
What you're left with
We write these for your Identity Governance & Administration setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
plan01
Application onboarding backlog ranked by risk and audit scope
yours to keep
design02
Joiner, mover and leaver flow designs signed off by HR and IAM
yours to keep
code03
Connector configurations and a repeatable onboarding pattern
yours to keep
code04
Certification campaign templates with reviewer guidance
yours to keep
document05
Separation-of-duties rule set for in-scope systems
talent and delivery · identity governance & administration
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
due diligence · identity governance & administration
Questions to ask any partner, including us.
Put these to anyone bidding on your Identity Governance & Administration work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you find custom code that still imports javax packages before we book the 9.0 window?
IdentityIQ 9.0 implements Jakarta EE 10, so plugins, connectors and custom Java that reference javax.* need rewriting. SailPoint's pre-check flags conflicting BeanShell in rules and workflows, but someone still has to fix and retest them.
Q2
How will you measure our identity data quality before quoting a timeline?
Connector count drives less IGA effort than missing manager links, duplicate HR records and orphan accounts do. Discovery should profile your authoritative sources and put numbers on all three.
Q3
Which mover rule would you build first, and what exactly does it remove?
Joiner and leaver flows are well understood. Movers are where access piles up, and the answer shows whether the partner has built one that actually revokes.
Q4
How do you prove a certification revocation really happened in the target app?
Many campaigns record a revoke decision that turns into a manual ticket nobody closes. Ask how closed-loop remediation is checked on the next aggregation.
Q5
How many of our existing rules would you retire rather than migrate?
Older IdentityIQ estates carry rules nothing calls. Porting them to 9.0 or rebuilding them in Identity Security Cloud costs time, so an inventory of unreferenced objects should come before any estimate.
01What's the difference between IAM and IGA?
IAM is the broader discipline of controlling access, including sign-in, single sign-on and MFA. IGA is the governance part. It decides who should have which access, automates granting and removing it, and produces the evidence that it was reviewed.
02How long does an IGA implementation take?
It depends mostly on how many applications you need to connect and how clean your identity data is. We give a timeline after a short discovery that measures both, rather than quoting a number before we've seen your estate.
03Should we upgrade IdentityIQ or move to Identity Security Cloud?
Either can be right. Stay on IdentityIQ 9.0 and you remain on-premises with a modernized platform. Move to Identity Security Cloud and the infrastructure work goes away, though customizations are built differently there. We go through your customizations, hosting limits and roadmap first, then recommend.
04Do you only work with SailPoint?
No. We implement Saviynt and Microsoft Entra ID Governance as well. We also often connect governance to Okta, Entra ID or Ping on the access management side.
05Can you take over an IdentityIQ estate another integrator built?
Yes. We start with a review of rules, workflows, custom connectors, plugins and how they're deployed. You get a list of what's unused, what's risky and what blocks the next upgrade before we change anything.
06Do service accounts and AI agents belong in our IGA platform?
Usually, as owned identities that get reviewed. The hard part is discovery and ownership data, which our non-human identities pages cover. Once that exists, SailPoint, Saviynt and Entra ID Governance can all certify them.
related
Often paired with
Projects on Identity Governance & Administration usually end up touching one of these, so they're worth a look.
