Identity governance RFP questions

They start from live entitlement data, not from the org chart. A partner extracts account and group memberships from each target system, such as Active Directory, LDAP, and the SaaS and database connectors in scope, then clusters users who hold similar sets of access. Each cluster becomes a candidate role, and the partner records how many users and entitlements sit behind it. The output should be a candidate role list with membership counts, the entitlements each role contains, and the users who hold access outside any candidate role. Ask to see a sample of this output from a prior engagement, with identifiers masked, before you accept any role count.

Business roles describe a job function that a manager or HR system recognizes, such as accounts payable clerk. Technical roles bundle entitlements in a target system, such as a database reader group or an application permission set. A good partner keeps the two layers apart so that business roles are assigned to people and technical roles are assigned to business roles or directly to accounts. Ask how the partner records this layering in midPoint, which object types hold each layer, and how a change to a technical role propagates to every business role that includes it. A model that puts both layers in one flat list usually becomes hard to certify.

The role owner should be the person accountable for deciding whether the role's entitlements are still appropriate, usually a business manager for business roles and a system owner for technical roles. The partner should propose owners during the workshops, and the client should confirm each name in writing. Ask where the owner is stored in midPoint, how the owner receives certification tasks for their roles, and what happens when that person leaves. Ownerless roles should appear on an exception list that the client reviews before go-live, rather than being assigned to the IGA team by default.

Validation checks the catalog against the access that people actually hold and against the business. A partner should run a comparison that shows, for each role, how many current accounts would gain or lose entitlements if the role were assigned, and it should list users who would lose access they use. Business owners then sign off on the roles they own, and the sign-off is captured with a date and a version of the catalog. Ask for the validation report template, the sign-off record, and the rule for re-validating roles when a target system changes. Ask also how exceptions are approved and kept, since those exceptions are the first thing an auditor will examine.

The main red flag is a role model promised before the partner has examined live access data. A proposal that lists roles by department or job title, with no entitlement extraction or overlap analysis, is a guess that will need rework. Other warning signs include no named method for clustering, no count of users left without a role, role catalogs that mix business and technical roles without explanation, and sign-off described as a single review at the end of the project. Ask for a worked example, labeled as illustrative, that shows how an unexpected entitlement would be handled. Vague answers here usually predict delays in certification later.

The effort depends on the number of target systems, the number of accounts and entitlements, the quality of the data, and how many business owners must attend workshops. No duration is given here because the scope has to come from your environment. Ask the partner to break the estimate into extraction, analysis, workshops, sign-off and rework allowances, and to state which assumptions it depends on, such as the number of applications with usable group data. Most engagements are fixed-scope, so the written scope should name the systems and the number of role review rounds included.

Yes, many teams can, provided they have someone who understands both the directory data and midPoint's object model, and they have business owners available for sign-off. midPoint is open source and has no enterprise edition, so the software itself carries no license fee. The costs are the staff time, the analysis work, and the support you choose to buy, which Evolveum offers as Product Support or Platform Subscriptions without published prices. Ask a partner to show you where it would save you time, such as the extraction scripts and validation reports, and to confirm which parts of the work your team would still own after handover.

The deliverable should include the role catalog with versions, the owner for each role, the source data and extraction date for each analysis, the overlap and exception reports, and the signed approvals. An auditor will want to trace a role from its definition to the people assigned to it and back to the approval that allowed it. Ask the partner to confirm that the catalog can be exported in a form you can retain, and that every change after go-live is recorded with the approver. Compliance readiness depends on these records, but the certification itself is issued by an independent auditor or certification body, not by the implementation partner.

The cost follows the work, not a license fee, because midPoint is open source and Evolveum states it has no enterprise edition. The main drivers are the number of target systems and connectors, how much role modeling the business needs, how clean the source data is, the infrastructure the platform runs on, and the support level chosen afterward. Connector count matters because each target system needs its own mapping, testing and error handling. Role modeling and data cleanup grow with the number of applications and the messiness of existing access. Ask any partner to break the quote into these components so you can see what each one buys.

One-time work covers scoping, requirements, role design, connector build and testing, data cleanup, migration of existing access, and go-live. Recurring work covers infrastructure, operations, monitoring, patching, connector maintenance when target applications change, periodic access certification campaigns, and any support subscription. Evolveum offers Product Support subscriptions for product bugs and Platform Subscriptions that add feature development, and these are priced separately from the implementation. Ask the partner which items sit in each column and how the ongoing support is priced, since the Evolveum support page lists no prices.

Identity governance depends on client people more than on tooling. You will need HR or other authoritative source owners who can explain joiner, mover and leaver events, system owners who can confirm entitlements and mappings for each target application, and business reviewers who will make access decisions in certification campaigns. You also need a sponsor who can settle conflicts about role definitions and approval rules. Ask the partner to list these roles by name, the hours each is expected to commit, and the decisions that must be made before build starts.

Yes, a capable internal team can run midPoint, but it needs skills across Java-based application operation, PostgreSQL administration, connector development for each target system, identity data modeling and audit reporting. midPoint runs on Linux or from Docker images and uses PostgreSQL as its native repository, so the platform itself is accessible. The harder part is sustaining connectors and role logic as applications change. Assess your team against those skills, and ask a partner to show which tasks they would hand over and how they would document them so your staff can take the platform over.

Timelines depend on the number of sources and targets, the quality of existing access data, the complexity of the role model and how quickly your reviewers and system owners respond. DeployOpen's fixed-scope engagements are agreed in writing before work starts, and the scope, deliverables and timeline are set out in that document. Do not accept a timeline that is not tied to a written scope with named deliverables. Ask the partner what assumptions the timeline depends on, and what happens to dates if a connector or data source turns out to be harder than expected.

Ask for a written scope that lists each target system and its connector type, the authoritative sources, the joiner, mover and leaver rules, the role model approach, the access request and approval flows, the certification campaigns and their cadence, and the audit outputs. Request separate line items for discovery, data cleanup, connector build, testing, migration, go-live, documentation, training and post-go-live support. Ask which items are assumptions and which are firm, what the client must provide, and how change requests are priced. DeployOpen does not publish a price list, so a quote follows from the written scope.

The most common risks are orphaned accounts and excess access that surface only during cleanup, role models that become unmanageable when they are built from existing access without review, and connectors that fail silently when a target application is upgraded. Ask how the partner will profile existing accounts before go-live, how role candidates will be validated with system owners, and how connector failures will be detected and reported. Also ask how the scope handles audit evidence, since reviews that cannot be re-performed create risk during an assessment.