How to run a proof of concept for an identity lifecycle management tool

Write down the problem in terms an auditor would recognize: recent audit findings, leavers who kept access, applications that are never reviewed. Then turn each one into a pass criterion. 'Finds every local admin account in application X' is testable. 'Improves visibility' is not.

Agree the scope, the data the vendor may access, where that data is processed and how it is deleted afterwards. Deployment details are not always on public pages; for several tools on this site we note that they are not described. Ask for architecture and data-handling documentation before granting access to any application.

• One connected SaaS application, as a baseline the tool should handle easily.
• One on-premises or legacy application with its own user store.
• One custom-built application with no connector and no SCIM endpoint.
• One application you know contains local admin, service or break-glass accounts.
• If you can, one application nobody has registered in your inventory, to test discovery.

The last three are where the tools on this site differ most. Our coverage ledger records what each vendor describes for applications with no connector.

Before the vendor connects anything, extract the account list from each test application yourself: from its admin console, its database or its API. Reconcile it against your HR records and mark every account as current, leaver, unmatched or non-human, following the account reconciliation lesson. This baseline is the answer key. A tool that reports fewer accounts than your baseline has missed some; one that reports more has found something you did not know about, which is worth checking by hand.

Not every tool does every stage. Discovery tools such as Orchid Security describe discovery, analysis and evidence and hand provisioning and reviews to your IGA, so test those stages through the integration with the platform you run. IGA platforms such as Saviynt or SailPoint Identity Security Cloud should be tested on every stage for the applications they connect, and on how they onboard the ones they do not.

• Coverage: the share of baseline accounts the tool found, per application.
• Time to deprovision for the test leaver, per application. See the leaver timing lesson.
• Effort: the hours your team spent on connectors, exports and tickets during the test.
• Evidence quality: whether your internal audit team accepts the export as it is.

• Testing only on the vendor's demo tenant or on applications the vendor chose.
• Letting the scope grow to dozens of applications. Depth on five tells you more than a shallow pass on fifty.
• Scoring on the demo instead of the pass criteria you wrote first.

The buyer's checklist lists the questions to send vendors before a proof of concept, and the calculator helps shortlist on your own priorities.