Make financial access
decisions explainable.

Give every access decision a business reason

A finance application role can allow someone to view a report, maintain supplier details or authorise a transaction. Those permissions carry different responsibilities. A useful identity governance process explains the difference to the person approving access and preserves the records needed to understand the decision later.

easyIGA is software for requesting, approving and reviewing access to your organisation’s applications. It uses midPoint as the underlying identity governance platform. Business participants work with understandable requests, while specialists configure the roles and integrations that determine the changes in connected systems.

For a bank, insurer or other financial organisation, the evaluation should begin with a real control question. Choose one application and the access that its owner needs to govern. Establish the authorised approver, the applicable policy and the evidence expected from a completed operation. This keeps the discussion grounded in a process that the organisation can test.

For the application owner, a useful access process starts with a recognisable responsibility. Someone who owns financial reporting should be able to assess a reporting role without decoding every directory group behind it. easyIGA connects that business decision to the configured midPoint workflow. The illustrative examples below follow a request through approval, target-system execution and later review, showing where each participant contributes and which records help explain the result.

Follow a request through the finance team

Consider a fictional employee joining a reporting team. They need access to a reporting application but do not need the permissions used to approve payments. A technical group name alone may not make that distinction clear to either the employee or the manager.

The first task is to give the request a business description. easyIGA's catalogue gives employees and managers a readable starting point. Your implementation maps that description to the configured role. The organisation decides which roles can be requested and which people have authority to approve them.

At the decision stage, the approver reviews the request and the configured policy results. The interface should help them understand the access being requested without making them administer midPoint. Microsoft Teams is an approval channel; the supported workflow and evidence fields for your proposed release should be shown during the demonstration.

After approval, midPoint carries out the configured change. easyIGA presents the recorded outcome. That last stage matters because an unavailable application, incomplete identity record or integration error can prevent an approved decision from becoming usable access.

During a walkthrough, ask the employee and the manager to explain the process in their own words. Can the employee tell what they are requesting? Can the manager identify the responsibility they are accepting? Can the operator find the reason a change has not completed? These observations provide a better assessment of usability than a general claim that a screen is simple.

Define conflicts in terms of financial responsibilities

Segregation of duties concerns combinations of access that your organisation has decided should remain separate. A common evaluation example is the ability to maintain a payee and authorise the associated payment. The actual rule depends on your applications and control design; it is not a universal policy that a website can prescribe.

easyIGA shows the evaluated result of midPoint's configured exclusion policies at approval time. The approver can see a conflict known to midPoint configuration before deciding. This makes the policy result part of the decision rather than a separate document that the approver must remember to find.

Your specialists must still identify the relevant roles and maintain the exclusion rules. Available functionality and planned functionality remain distinct. Configured policy conflicts are evaluated and shown at decision time. Rule authoring and simulation inside easyIGA are planned and should not be treated as current purchase scope without separate release confirmation.

Test the rule with more than one path to the same permission. If an application can receive access through an inherited role or a directory group, the implementation must account for that model. A demonstration using one carefully chosen role does not establish that every permission combination is covered.

Also decide who owns a policy change. A restructured payment process can alter the meaning of existing roles. Document the business owner, the specialist responsible for configuration and the test that demonstrates the intended result. The product can display a configured policy result; the organisation remains responsible for deciding whether that policy represents its control.

Review existing access with enough context

An access review asks a manager or application owner whether permissions remain justified. Completion of the review is not the same as a well-supported decision. Reviewers need a comprehensible description of the access and relevant evidence about the person and the history.

easyIGA presents available context alongside the access under review. Last use, granted by and approved by are useful fields when the connected systems and captured approval history supply them. Each answers a different question. Recent activity does not automatically justify a permission, and the current manager is not necessarily the person who authorised it originally.

easyIGA records the requester and captured approval steps for requests made through the product. Access granted outside easyIGA is identified separately, using the creation details recorded by midPoint. Historical records may lack an approver or grantor; missing information is shown explicitly.

For an evaluation, include access granted through the expected process and access with incomplete history. Ask the reviewer what they can conclude from each record. Where evidence is insufficient, agree the investigation route instead of treating the absence of information as a reason to approve automatically.

Follow a removal decision into the target application. An audit sample should be able to distinguish the reviewer's decision from the outcome of the removal operation. If the result is unknown or pending, the control owner needs to know how that case is tracked. This is the point where a review process becomes connected to operational follow-through.

Make staff moves and temporary access explicit

A person moving between financial teams can keep permissions that no longer belong to their role. Adding the new team's access without examining the previous access leaves the organisation with a growing set of permissions that may be difficult to explain.

midPoint provides the identity lifecycle and provisioning foundation. Your specialists configure authoritative sources and the rules that connect identity changes to target systems. easyIGA gives business participants the surrounding request and review experience. The outcome depends on the quality of the source information and the scope of the integration.

Choose a mover case for the pilot. Write down the access required before and after the change. Identify the permissions that should be removed, the permissions that should remain and any exception that needs a fresh decision. The test should make each category visible rather than judge success only by the new account being present.

Temporary assignments need a similar approach. A cover arrangement, project or external engagement can create a legitimate short-term need. If the configured process uses an end date, demonstrate how that date reaches the relevant policy and what happens when it is extended. The existence of a date in an HR system does not prove that application access will expire.

When a source record is incomplete, define responsibility for correcting it. An access workflow should not invent a manager or silently bypass an approval because an organisational record is missing. A visible exception gives the team an opportunity to repair the process and understand the effect on the requested access.

Treat DORA as a control context

DORA addresses digital operational resilience in the financial sector. Article 9 of Regulation (EU) 2022/2554 includes access restrictions and procedures for administering access rights. IGA can support the logical-access part of the organisation's control environment; buying a product does not establish compliance.

Translate the control question into an evaluation. Which application is in scope? Who can authorise the role? What does the configured workflow record? How does the organisation establish that the target change occurred? The answers should be specific enough for the control owner to examine a sample.

Keep broader resilience work separate. The identity workflow does not replace business continuity arrangements, incident management or third-party risk assessment. A product walkthrough can demonstrate an access decision and the records around it, but it cannot conclude that an institution has satisfied every applicable obligation.

For evidence preparation, agree the required records before configuring a report. A useful record connects the identity and permission to the decision and the outcome where that information is available. Retention, access to the records and treatment of missing history also need operating decisions.

The easyIGA DORA page provides a related starting point. Your compliance and legal teams should determine applicability and the exact control interpretation. A scoped demonstration then lets them assess whether the product supplies the evidence needed for the particular workflow they are examining.

Understand how easyIGA and midPoint work together

midPoint already provides identity management and governance capabilities. midPoint handles configured identity data, roles and changes to connected systems. easyIGA builds on that foundation rather than replacing it.

The division matters to a financial organisation with an existing identity team. Specialists retain responsibility for midPoint configuration and integrations. Managers and application owners use the business-facing request and review workflows. A product comparison should show what each participant actually does, not suggest that the same work has disappeared from the system.

Compare an existing midPoint process with the proposed easyIGA experience using the same role and target application. Ask a manager to examine an ordinary request and one containing a known conflict. Ask the operator to locate an incomplete target change. This makes the additional product value observable without claiming that midPoint lacks those underlying governance mechanisms.

The midPoint overview and connector catalogue provide technical background. Confirm the exact application version and supported operations with your integration team. A connector can require configuration or extension for the specific permissions you want to manage.

Evolveum's financial-services page describes use cases for midPoint. For easyIGA, the next step is to examine the business workflow with your own application owner and identity team. Use a reporting or approval role they recognise, include a configured conflict and follow the resulting change. That gives each participant a concrete basis for comparing the proposed experience with the process they use today.

Compare IGA licensing on the same basis

midPoint has no software licence fee. Some midPoint capabilities, such as simulations, high availability clustering or a database other than PostgreSQL, need an Evolveum subscription, which we arrange and include in your quote. easyIGA is a commercial product. The published model is an annual subscription per governed identity, with deployment included within an agreed scope. Final tier prices and the contracted capability set need confirmation before purchase.

A procurement comparison should begin with populations. Determine how employees, contractors and service accounts are counted. A large number of technical accounts can change the scope even when the employee count remains stable. Ask how the proposed model treats growth and inactive records rather than assuming that every supplier uses the same definition.

Next, compare functionality and delivery. List the applications, required operations and environments. Identify migration work and data cleanup. State the support responsibilities and acceptance criteria. Two offers with similar recurring prices can represent materially different work if one includes only an initial connector setup and the other includes a larger migration.

Use the organisation's own figures to estimate operating effort. Record the time spent handling an access request, preparing review evidence and resolving exceptions. Separate time actively worked from time spent waiting for a decision. Improvements in either can matter, but they should not be counted as the same financial saving.

The pricing page and calculator support a scoped discussion. They do not provide a universal saving or a substitute for a written offer. Include transition and renewal terms in the comparison, then assess the demonstrated workflow alongside the cost.

Connect legacy applications without hiding the limits

A financial organisation may operate long-lived applications alongside newer cloud services. The identity design needs to establish how access is represented in each target. It might be an application role, a directory group or a combination of permissions with a business meaning.

Start with an inventory of the operations you need. Reading accounts is different from changing permissions. Creating an account is different from disabling it. Confirm how the integration reports failures and what information is available to verify a successful change.

The implementation must also address changes made outside the normal request process. Reconciliation can compare the configured identity view with target information, but the available data and the chosen policy determine what can be concluded. A discovered account should not automatically acquire an invented business approver.

In the pilot, include a target that returns useful confirmation and one with a more limited interface. Agree how operators handle each. If a manual step remains, record the responsibility and the evidence expected from it. A partial integration can still be useful when its limits are understood; it becomes misleading when those limits are hidden behind a uniform success label.

Consider the support model over time. An application upgrade can alter the relevant interface or permission structure. Assign ownership for connector testing and role maintenance. This is part of the operating cost and should be visible in the evaluation rather than discovered after the initial launch.

Choose a deployment model your team can operate

Self-hosting is the default easyIGA deployment model. The organisation operates the solution on its own infrastructure and within its chosen jurisdiction. For organisations without suitable infrastructure, an EU-hosted deployment operated by our team is available on request.

The location of a deployment is only one part of the decision. Establish the responsibilities for updates, monitoring and recovery. Determine who can administer the service and how access to evidence is controlled. The operating agreement must match the environment you intend to use.

For an operated option, request the relevant service and data-processing terms as part of due diligence. Do not infer an agreed service level, subprocessor list or recovery commitment from the phrase EU-hosted. Those details need explicit documentation for the proposed service.

For self-hosting, include internal effort in the business case. Your team may already operate the required infrastructure, but the new service still requires ownership. Decide how configuration changes are reviewed and how a failed integration is escalated. An accountable operator is as necessary as an accountable business approver.

Use the deployment information and security page to frame those questions. The outcome of the discussion should be a list of responsibilities and acceptance evidence, not a general assurance that the chosen hosting model resolves every risk.

Prepare a focused evaluation with your control owner

Bring one application and a small set of representative roles to the walkthrough. Include an ordinary request, a conflict and a role change. Use synthetic identities initially so the discussion does not require sharing real customer or personnel data.

Let the business owner define what the approver needs to understand. Let the technical team identify what the target can confirm. The evaluation should connect those two perspectives. A request that is easy to approve but impossible to trace to a target outcome leaves an important question unanswered.

Record the exact release and configuration demonstrated. Note which evidence fields were present and which remained unavailable. Planned functionality should be identified separately. This makes the findings useful to procurement and prevents a future roadmap item from becoming an accidental acceptance condition for the current product.

Our team's 14+ midPoint deployments are implementation experience, separate from easyIGA adoption. Use that experience as a reason to discuss the technical fit, then assess the product through a concrete demonstration. No customer result or financial saving is implied by the examples on this page.

Request a 30-minute walkthrough with our team. The next useful step is to examine your access decision, its policy context and the recorded outcome, then agree whether a scoped evaluation can answer the remaining questions.