How to Choose an IGA Platform That Supports Remediation

A manager revokes a user’s payment-approval access during a review. The campaign closes. The user can still approve payments.

That is the gap to test when choosing an identity governance and administration (IGA) platform. The question is not whether it can flag risky access or record a decision. It is whether your team can make the right change in the application, confirm the risk is gone, and show the evidence. If the change fails, or the access returns, the issue must remain visible and owned.

For organizations with an existing IGA platform, this may be a gap in one critical application rather than a reason to replace the platform. For first-time buyers, it is a requirement to build into the operating model from the start. This guide shows how to evaluate both paths using the same remediation tests.

This is one example of the wider distinction between an identity-governance activity and a demonstrated control outcome. Identity Governance Doesn’t Equal Compliance explains why the population tested, the action taken, and the retained evidence still matter after an access decision is recorded.

What does remediation require?

Identity governance remediation is the controlled response to access that should not remain as it is. The response might be to revoke a permission, change a role, disable an account, correct ownership, change a policy that keeps granting access, or approve a temporary mitigation.

Those are different outcomes. Removing access eliminates the permission. Mitigation leaves some risk in place under an agreed control. Risk acceptance records a decision to tolerate the remaining exposure. An evaluation guide should not label all three “resolved” without showing which occurred.

A useful definition is:

Verified closure is an approved outcome linked to evidence of the resulting access state in the authoritative system or, for an accepted exception, evidence that the exception and its required controls remain valid. A workflow status alone does not establish closure.

Verification does not have to look identical for every application. A connected system might support an automated read after a change. Another may need an application administrator to act and a separate check to confirm the result. What matters is that the method is defined, the result is recorded, and a failed or partial action does not quietly become a closed item.

This distinction applies even to established IGA platforms. SailPoint documents both automatic certification revocation and manual remediation paths, depending on the source and configuration. Its campaign guidance also describes verifying that revoked items have been remediated. Buyers should test their actual sources and configurations rather than assume a review decision, or a connector alone, guarantees removal.

● Find and explain: Identify the account, effective access, application, and policy concern. Show the business capability behind a role name.

● Assign and decide: Establish who can assess the business need, approve a change, perform it, verify it, and accept any residual risk.

● Act: Make the approved change through the appropriate system or controlled manual process.

● Reconcile and verify: Check the resulting source state and the original risk condition. An attempted change is not the same as a successful one.

● Retain evidence and monitor: Preserve the decision trail and look for a regrant, an expired exception, or a rule that recreates the risk.

NIST’s account-management control addresses activities including account modification, disabling, removal, review, and audit records. It is a useful reminder that account governance concerns what happens to access, not only whether someone reviewed it. The specific controls and timing an organization needs must still be set against its own policies and requirements.

The most revealing failures happen between lifecycle steps. A ticket reaches an application team but has no owner. A connector removes one entitlement while an inherited role preserves the same capability. An administrator removes access, only for a lifecycle rule to grant it again. Or an exception is approved “temporarily” with no date to revisit it.

In each case, ask the same question: What would the platform show as open, and who would have to act next? If the answer is unclear, the remediation process is unclear.

What should buyers evaluate?

Begin with the applications and risks that would materially affect your decision. An impressive general-purpose demonstration will not tell you whether a candidate can resolve a segregation-of-duties conflict in your ERP or remove elevated access granted directly inside a SaaS application.

Score the platform and the proposed operating model. Use a 0–4 scale for each criterion: 0 = not demonstrated; 1 = asserted or dependent on an undefined manual process; 2 = workable with significant limits; 3 = demonstrated end to end with clear boundaries; 4 = demonstrated end to end, including failure handling and evidence, for the relevant application. Multiply each score by its weight and divide by four for a total out of 100.

Set non-negotiable thresholds before reviewing vendors. A high overall score should not outweigh a failure to verify closure in a critical application. Record what supports each score: a live demonstration, a documented workflow, a customer reference, or a statement that still needs testing.

Ask for precise answers to these questions:

1. What is the authoritative source for the access displayed, and when was it last read?
2. Can the reviewer see what a role enables below its label, including direct and inherited permissions?
3. Which actions can the platform execute for this application? Which require an API, ticket, administrator, or another product?
4. Does the item remain open after an unsuccessful or partial change?
5. What source-state check establishes that the specific risk is gone?
6. If a rule restores the access, can the team identify and correct that rule?
7. Can reports distinguish removed access from mitigated or accepted risk?
8. What would an auditor receive for one finding, from detection through verification?

Do not equate automation with quality. A manual change performed by the right administrator, independently checked, and tied to a complete record can be more defensible than an automated request whose outcome nobody verifies.

How do you test closed-loop remediation?

Give shortlisted candidates the same scenarios, expected outcomes, and evidence requirements. Include a failed path. A demonstration that only shows a successful access request will not answer the buying question.

For the ERP test, go beneath a friendly role or Responsibility name. The team should be able to explain the underlying capability and relevant organizational scope before choosing a response. If removing one permission would interrupt a legitimate finance process, ask the candidate to show how the owner evaluates alternatives and records the decision. The demonstration should end with a check of the access and risk condition, not with the approval screen.

For the SaaS test, establish whether removing a direct assignment would be undone by a group or lifecycle rule. Ask the candidate to show the granting path before taking action. If the access returns, the item should become visible again and lead the team to the cause. Repeatedly removing the permission without correcting the rule that restores it is not a durable outcome.

The failure tests matter just as much as the successful ones. If an API request times out, can the team tell whether the source changed? If one entitlement is removed but a second remains, does the finding stay open? If a manual task passes its due date, who receives it next? Ask the vendor to show the actual statuses, assignments, and evidence produced in each case.

Request an evidence package for one scenario before the demonstration ends. It should connect the initial access state, reason for the finding, decision and approval, action or attempted action, post-action check, exception if applicable, and timestamps. If those pieces live in different systems, ask the vendor to show how your team would retrieve and reconcile them.

A proof of value is warranted when the answer depends on an uncertain integration or application-specific access model. Scope it to one or two priority systems and agree on pass/fail criteria first. For example: “Remove this ERP entitlement, confirm the conflict no longer exists after the next source read, and show what remains open if the removal fails.” That is more useful than a broad pilot whose success is defined as “the platform was connected.”

Use metrics that reflect outcomes, not activity:

Agree on the clocks and denominators before using these measures to compare candidates. Otherwise, one vendor’s “closed” item may be another vendor’s “action requested.”

Where SafePaaS fits?

Start with a buyer-neutral test: identify what your current IGA platform or shortlisted candidate already handles well, then pinpoint the access risks it cannot explain, resolve, or document to your standard.

SafePaaS may add application-level access and risk context to that workflow. Its published IGA material describes gathering access data from an existing IGA, connected applications, manually managed systems, and other provisioning sources. It also describes translating application roles into underlying entitlements, evaluating risk in organizational context, and linking findings to decisions, remediation, mitigation, or risk acceptance. Test those capabilities against your priority applications; do not assume every source supports the same action or verification method.

That context matters when access sits outside the main IGA workflow or a role name conceals the permissions a reviewer needs to assess. It can also help risk owners choose a response and help audit teams follow the decision and evidence trail. The question is whether SafePaaS fills a demonstrated gap while the existing IGA continues to handle the processes it already performs well.

Configuration Monitor helps identify differences between environments and baselines, while Change Tracking records sensitive changes for investigation. Ask how a finding from either product moves through risk assessment, ownership, action, verification, and evidence retention in your proposed setup.

In a SafePaaS telecommunications case study, the customer reports that annual access-assignment costs fell from about $120,000 to near zero and that its SOX review found no Oracle EBS ITGC findings. Those results are relevant to preventive checks and governed access decisions. They do not establish how removal or source-system verification will work in another buyer’s applications.

The route to a decision differs by starting point:

This does not assume a SailPoint limitation. SailPoint documents automated and manual remediation paths; the question is what your deployment does for your selected sources, and whether adding application context or a separate governance layer improves the outcome. SafePaaS positions its federated offering as a way to work alongside an existing IGA rather than replace one by default.

The strongest SafePaaS proof of value for this asset would be narrow and observable: take a permitted test case in a priority ERP application; show the effective access and risk context; route a decision; demonstrate the configured action path; check the resulting access state; and produce the linked evidence record. Repeat with a failed or partial action. If execution or verification depends on a person, another platform, or a specific integration, show that boundary. That is the evidence a buyer needs to decide whether SafePaaS closes their remediation gap.

What should the decision record say?

Do not end the selection process with a feature tally. Record the applications and risks tested, the score and supporting evidence for each criterion, the action and verification boundary for every priority source, the owner of each manual handoff, unresolved limitations, and the reason for the final choice.

A decision record should be able to state, in plain language:

“For this application and risk, the reviewer makes the decision in [system]. [Team or integration] makes the change in [authoritative system]. [Method] checks the resulting state. A failed change remains open with [owner]. [System] retains the evidence. Regrants are detected by [control] at [defined interval].”

If the team cannot fill in that statement for a critical scenario, it has not yet established closed-loop remediation regardless of the number of dashboards, certifications, or tickets in the demonstration.

Is a ticket enough to close a finding? No. A ticket shows that work was assigned or recorded. Closure requires evidence of the resulting access state or a clearly documented, active exception.

Does remediation have to be automated? No. A manual change can be a valid part of the process if it has an owner, is completed within the agreed time, is checked independently, and leaves a usable evidence trail.

What if access is granted again? Detect the renewed risk, identify what granted the access, and address the underlying rule or process where necessary. The prior removal does not make the new finding safe to ignore.

Related resources: First-time buyers can use SafePaaS’s Complete Enterprise Guide to Identity Governance for broader program context. For the difference between review completion and risk closure, see Automated Access Governance: From Review Completion to Risk Closure. For an existing deployment, read Bridging the SailPoint Value Gap and Why Continuous Controls Monitoring Matters After Your SailPoint Implementation.