Flexible recertification decisions beyond approve or reject

Editorial analysis by NHI Mgmt Group, based on content published by Nexis: “Flexible Recertification Decisions: Beyond Approve or Reject”.

At a glance

What this is: This is a Nexis lunch-and-learn about making recertification decisions more flexible by adding a third workflow outcome to campaigns.

Why it matters: It matters because IAM and IGA teams need recertification flows that reflect real governance decisions, not just approve-or-reject binaries that can distort review outcomes.

👉 Read Nexis's Lunch & Learn on flexible recertification decisions

Context

Recertification is an identity governance control that asks reviewers to confirm, revoke, or otherwise resolve access decisions. In practice, many programmes force every review into two outcomes even when the business question is more nuanced than yes or no.

This session is about adding a third option to recertification campaigns and wiring that choice into its own follow-up process. For IAM and GRC teams, the governance issue is not only whether access remains valid, but whether the workflow can represent the decision that was actually made.

Because the content is a live platform walkthrough, the main topic is workflow design rather than a breach, threat pattern, or incident response case. The useful lens is how certification logic, routing, and ownership change when the process is no longer binary.

Key questions

Q: How should teams design recertification campaigns when approve or reject is not enough?

A: Design the campaign around the decisions reviewers actually make, not around a forced binary. If a case needs deferral, exception handling, or extra validation, give it a separate state with one documented follow-up path so governance evidence stays accurate and operational work does not disappear into an approval that was never real.

Q: What breaks when recertification workflows only allow approve or remove?

A: They collapse nuanced governance into a false binary, which can distort audit trails and produce misleading certification evidence. Reviewers may approve a case they do not fully endorse or remove access before the right follow-up is complete, so the workflow no longer reflects the decision that was actually made.

Q: How do teams know whether a recertification workflow is too rigid?

A: Look for repeated manual exceptions, reviewers using approval as a placeholder, or access cases that keep returning outside the normal review path. Those are signs the workflow cannot represent the organisation’s real decision pattern and needs an additional governed state.

Q: Should IAM and GRC teams use a third recertification state for every campaign?

A: No. Use it only where the governance decision genuinely needs a separate path and a distinct operational follow-up. If the extra state is not tied to a specific outcome, it adds complexity without improving recertification quality or accountability.

Background and context

Why binary recertification workflows break down

Recertification engines often model decisions as approve or remove because those are easy to automate and report on. The problem is that access reviews frequently surface outcomes that are conditional, deferred, delegated, or require a separate business process. A third option creates an explicit state in the workflow, which prevents teams from misusing “approve” as a placeholder for “not yet decided” or “needs another control.” That matters in IAM and IGA because the workflow itself becomes part of governance evidence, not just a routing convenience.

Practical implication: map real review outcomes before you configure certification logic so the workflow can capture them explicitly.

How a third recertification path changes governance evidence

When a review outcome routes to a distinct follow-up path, the certification record can preserve both the reviewer decision and the required next action. That is different from a simple approval, where the trail often ends at affirmation, and different from removal, where the action is immediate and final. In governance terms, the third path can represent exception handling, remediation, or additional validation without collapsing those states into one another. For audit and access certification, that improves traceability because the record shows what decision was made and what process was triggered next.

Practical implication: preserve the decision state and the downstream action separately so auditors can distinguish governance intent from execution.

Workflow branching in recertification campaigns

Workflow branching lets the campaign route a special decision into a separate chain of tasks, approvals, or notifications. Architecturally, that means the certification campaign is no longer a single linear review event but a decision tree with different post-review states. This is useful when the review result needs human follow-up, when a manager cannot make a final call alone, or when the access owner must supply additional evidence. The design challenge is to keep the branch specific enough that it does not become a catch-all for uncertain decisions.

Practical implication: define the third option narrowly, with one documented downstream path, so it does not become a governance dumping ground.

NHI Mgmt Group analysis

Flexible recertification is a governance model, not just a workflow convenience. Binary certify-or-remove logic assumes every access review can be reduced to a final yes or no at the moment of review. Real IAM and GRC programmes often need a third state for deferral, exception handling, or additional validation, and that state should be visible in the control record. The practitioner conclusion is that certification design must reflect governance reality, not reporting simplicity.

The value of a third decision path is in preserving decision quality. When teams force unresolved cases into approve or reject, they distort audit evidence and weaken the meaning of the review itself. A distinct follow-up path keeps the original reviewer intent intact while allowing the right downstream process to run. The practitioner takeaway is to treat the decision taxonomy as part of access governance architecture.

Recertification workflows expose whether an IAM programme can model nuance. Many organisations can run review campaigns, but fewer can represent conditional outcomes without manual workarounds. That gap matters because governance maturity is not measured by the volume of reviews alone, but by whether the process can express what reviewers actually decide. The practitioner implication is to test certification states against real review scenarios before scaling campaigns.

Recertification exception state: The most useful concept here is a separate workflow state for decisions that are neither approval nor removal. It gives IAM and GRC teams a controlled way to preserve nuance, route follow-up, and maintain auditability without collapsing governance judgment into a binary. The practitioner conclusion is to design for decision states, not just outcomes.

What this signals

Decision states matter more than review volume: recertification programmes become more trustworthy when they can represent unresolved, conditional, and exception cases explicitly instead of forcing everything into approval or removal. That shifts maturity from campaign throughput to governance fidelity.

A third option also changes how teams think about ownership. If the review outcome is not final, the workflow must show who owns the next action and what evidence is required before the case closes.

For practitioners

• Define a third recertification outcome Document the real cases where reviewers need something other than approve or remove, then map those cases to one explicit workflow state.
• Separate decision state from downstream action Record the reviewer decision and the follow-up process as different elements so audit evidence does not blur intent and execution.
• Limit the third option to a narrow use case Give the custom state a clear purpose, such as exception handling or additional validation, and avoid using it as a generic holding pen.
• Test the workflow against real review scenarios Run sample campaigns with conditional, deferred, and unresolved access cases to verify that the workflow branches correctly.

Key takeaways

• Recertification controls lose fidelity when they force every review into a binary outcome, especially where the real decision requires deferral or exception handling.
• A separate workflow state can preserve reviewer intent and route follow-up work without collapsing governance evidence into a misleading approval.
• Teams should test certification logic against actual review scenarios so the workflow can represent the decision pattern the business really uses.

Key terms

• Access Recertification: Access recertification is the periodic review of user or account permissions to confirm that access is still justified. It is useful, but it is not enough on its own because it reacts after entitlements already exist, which is why lifecycle governance must reduce the volume of exceptions before review time.
• Certification Campaign: A certification campaign is a structured access review in which owners confirm whether an identity still needs its permissions. For NHIs, the review must include purpose, actual usage, privilege scope, and ownership because role-based human review logic does not map cleanly to automation.
• Database Branching: Database branching is the practice of creating an isolated copy of a database schema so changes can be tested without affecting production. Teams use it to develop features, validate schema updates, and review deploy requests safely. It reduces the risk of breaking live workloads during iterative development.
• Governance Evidence: The records that prove a control existed and operated when needed. For AI programmes, that usually means logs, approvals, review outcomes, and lifecycle artefacts that show who owned the system, what it accessed, and how it was retired.

What to expect at the briefing

Nexis's full Lunch & Learn covers the operational detail this post intentionally leaves for the source:

• A live setup of a customizable third recertification decision in the NEXIS Platform
• Workflow branching details showing how the third option gets its own follow-up process
• A practical use case for applying the third state in IAM and GRC campaigns
• Short live demonstration context from the NEXIS Hacks lunch-and-learn format

👉 The full Nexis session shows how the third option is configured and routed in the workflow.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.