Access that follows
the work at each site.

Keep access aligned with the work at each site

An engineer supporting a refinery, an external maintenance specialist and an office employee need different access. Their responsibilities can change when a project ends or a person moves between sites. The identity programme needs to connect those changes to the permissions in the applications they use.

easyIGA gives employees and managers a readable way to request, approve and review application access. midPoint supplies the underlying identity governance platform and carries out the configured changes in connected systems. The people responsible for a business decision can take part without administering midPoint themselves.

For oil and gas, begin with a process whose ownership is clear. A maintenance planning application or a project document system can provide a useful first scope. Identify the people who need access, the site or project context and the person authorised to approve it. Then establish which target records confirm that the access actually changed.

A site sponsor needs to understand why an external specialist needs a project application. An identity administrator needs to know which role should change and whether the target accepted the operation. easyIGA connects those perspectives in the request and review workflow. The illustrative scenarios below cover the applications around site work, including the ownership and integration choices needed where corporate IT meets operational technology.

A turnaround project exposes the access lifecycle

Consider an illustrative maintenance turnaround that brings external specialists to a site for a defined period. The project team knows who is expected, but the access process also needs to know what each person is allowed to do. A name on a contractor list is not a complete permission decision.

Start with the source of the identity information. Decide whether the contractor record comes from a workforce system, an approved external-worker register or another authoritative source. Establish the sponsor and the information needed to distinguish this person from somebody with a similar name. The implementation should not rely on a casual email as a permanent identity record.

Next, describe the access in terms the project owner understands. The role might concern maintenance planning or a defined document collection. easyIGA's catalogue provides a business-facing starting point, while the configuration maps the approved role to the target permissions. The catalogue description must explain the real scope.

At the end of the project, the organisation needs a decision about access that remains. A contractor may leave completely or continue on a different engagement. Removing every account and leaving every permission are both poor substitutes for an explicit lifecycle rule. Define the new relationship and the permissions that follow it.

Use this scenario in the pilot from beginning to end. Demonstrate the initial request, its approval and the recorded result. Then change the assignment and inspect the old permissions. This reveals the handovers between project management, identity administration and the application owner.

Make the site owner part of the decision

A central IT team may maintain the systems without knowing why a contractor needs access at a particular site. The site manager may understand the work without knowing the technical name of the required role. The workflow should let each person contribute the information they actually own.

easyIGA presents requests through business-facing workflows. The configured policy determines the relevant decision path. An organisation can use that structure to make access approval an accountable business task rather than an informal instruction passed between teams.

Before configuration, agree who can approve each role and what happens when that person is absent or no longer responsible. The implementation should demonstrate the supported handling for the proposed release. Do not assume an untested delegation or escalation rule simply because an approval button exists.

For a site-specific role, the approver needs an accurate description of the application access. The description should avoid implying that permission in one application grants a broader operational authority. A maintenance record system and permission to work on equipment are separate matters unless your approved process explicitly connects them.

Include a request with incomplete sponsor information in the evaluation. The team should be able to recognise the problem and route it for correction. A missing business owner is an operating issue that needs resolution, not a reason to invent a decision maker or treat the request as automatically authorised.

Handle disconnected targets as an operational fact

Some environments cannot provide continuous connectivity to every relevant system. Even a normally connected target can be unavailable during maintenance. An identity decision made centrally does not prove that an isolated destination has already received and applied the change.

easyIGA distinguishes verified, pending, failed and unknown outcomes. That helps the organisation separate a completed decision from a confirmed operation. The available confirmation depends on the connector and the target's behaviour. It should be assessed for each system in scope.

Agree what a pending change means operationally. If access is intended to end, the responsible team needs to know whether the target has applied the instruction and what controls apply while confirmation is unavailable. The appropriate response depends on the system and the organisation's procedures; it cannot be reduced to a universal website promise.

A useful test intentionally includes a destination that is unavailable. Observe the recorded state, the information available to the operator and the behaviour after connectivity returns. Confirm how duplicate or repeated operations are handled in the configured integration. Record the actual result instead of assuming that a retry policy resolves every failure.

Reporting should preserve this distinction. Counting all approved removals as completed removals can conceal unfinished work. A clear view of outstanding operations gives the site and application owners a basis for follow-up. It also prevents a business approval from becoming misleading evidence about the current state of a target account.

Draw the IT and OT boundary before connecting systems

Operational technology supports physical processes. An identity-governance discussion should establish which applications and administrative interfaces are appropriate integration targets and which remain outside the scope. The presence of an identity connector is not permission to automate changes in a sensitive operational environment.

Begin with the asset owner and the operating requirements. Identify the effect of an account or permission change. Determine how that change is tested, approved and reversed if necessary. The identity implementation must follow the organisation's change-control process and the constraints of the target system.

For a first phase, the scope may be limited to corporate and workforce applications around the operation. Maintenance planning, document access and supplier collaboration can have clear business owners without implying direct control over a production controller. The choice must follow the organisation's assessment, not a generic industry diagram.

midPoint provides mechanisms for configured identity integration. easyIGA supplies business-facing decisions around the supported workflow. Neither description establishes that a particular industrial system is compatible, that a connection is safe or that application governance replaces a specialist OT security programme.

Keep the boundary visible in the acceptance record. State which systems were connected, which operations were demonstrated and which remained manual or out of scope. A diagram should show the actual approved relationship between layers. Avoid a broad cloud of application logos that suggests every operational interface has already been integrated.

Review access by project and responsibility

A contractor can finish a project while their employer remains an active supplier. A permanent employee can move to another site while retaining permissions associated with the previous role. Access reviews help an accountable person reconsider those permissions against the current responsibility.

easyIGA presents access under review with the available evidence. Last use, granted by and approved by depend on the connected sources and captured approval history. A reviewer should understand which facts are present and which remain unavailable.

For a project review, define the population and the application scope first. The project owner may be able to judge document access but not a technical service account supporting an integration. Assigning both to the same reviewer without explanation can create a completed campaign with weak decisions.

A useful sample includes someone who moved site, a contractor whose assignment ended and a permission with incomplete history. These are illustrative cases, not claims about automatic detection in easyIGA. Show how the proposed release presents each record and how the reviewer reaches a decision.

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.

Keep service accounts attached to a responsible team

An account used by a scheduling interface or a reporting job can remain necessary after the employee who originally configured it leaves. Treating every account as an employee account can therefore create the wrong removal decision. Non-human identities need their own ownership and purpose information.

Start by identifying the application or process that depends on the account. Establish the team responsible for it and the permissions it needs. Confirm how credentials and runtime privileges are managed by the relevant security controls; this page does not claim that easyIGA replaces a privileged-access vault or a secrets-management system.

An identity-governance evaluation can examine how the account is represented and how responsibility is reviewed. The proposed workflow should make the distinction between a human match and a service owner understandable. A suggested person match is not automatically proof that the account should follow that person's employment lifecycle.

Choose one representative technical account for the demonstration. Describe what would break if it were disabled and who is authorised to decide on a change. Ask how the record remains accountable when the responsible team changes. This exposes a different lifecycle from an ordinary employee departure.

The orphaned-account and non-human identity page provides more context. Verify the current release's workflow and integration coverage before adding it to purchase scope. A clear ownership process is useful even when some evidence requires investigation, provided the uncertainty is visible.

Use the midPoint foundation with clear responsibilities

midPoint is an open source identity management and governance platform. Its configuration connects identity sources to roles and target-system operations. easyIGA adds the business-facing experience for requests and access decisions around midPoint.

For an existing midPoint team, this offers a way to evaluate the additional user experience without assuming a replacement of midPoint. Keep the same application and role in the comparison. Ask the business participant to complete the supported task and ask the specialist to explain the underlying configuration and exception path.

The connector catalogue is a starting point for integration research. Assess the exact system version, authentication method and required operations. A target may expose accounts while representing some permissions through a separate interface. That distinction affects both scope and evidence.

Technical specialists still own the mappings and policy configuration. A readable request form does not repair inconsistent source data or establish a safe role model. Include those tasks in the delivery plan so business usability is supported by an identity model that the organisation understands.

Evolveum's oil-and-gas page provides sector context for midPoint. Bring that technical foundation together with an easyIGA walkthrough of your chosen site application. The sponsor can assess the access description, the application owner can check the responsibility it represents and the identity team can confirm how the configured change reaches the target. Each participant then has a clear part in accepting the proposed process.

Choose evidence that the site can actually use

An audit request often arrives after the operational event. If the organisation has not agreed which records to retain, reconstructing the decision can require searching several systems and speaking to people who have already changed roles.

Define the evidence requirement alongside the workflow. The person, the requested access and the decision are relevant, but so is the recorded result. An approved request that never reached its target should remain distinguishable from a verified change.

For the evaluation, ask the control owner to select a sample. Follow it from the business request to the available history and the target result. Check the demonstrated export in the proposed release rather than assuming that every screen field appears in every export format.

Retention and access to evidence are operating decisions. Determine who can retrieve records, how long they are needed and what sensitive information they contain. A source field should not be collected simply because a connector can read it. Its purpose in the control should be understandable.

NIS2 includes access control policies within its cybersecurity risk-management requirements. Applicability and the relevant national rules need assessment by the organisation. See the official NIS2 text. An identity workflow supports a defined part of the control environment; it does not establish wider regulatory conformity or site resilience by itself.

Compare the total scope of delivery

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 has a commercial subscription model, published as an annual charge per governed identity with deployment included in agreed scope. Obtain a current written offer for the actual populations and capabilities required.

In oil and gas, the scope should explain how sites, environments and contractor populations are counted. A single corporate application can have several instances with different operating arrangements. Clarify whether the proposed delivery covers each instance and how access ownership is maintained across them.

Include data cleanup and migration responsibilities. A contractor register with inconsistent identifiers can require work before it becomes a reliable identity source. An old role catalogue may need business review before it can be presented as readable access choices. Those activities should be visible in the project plan.

Consider ongoing operation as well as initial configuration. Identify who maintains connectors after target upgrades, who resolves failed operations and who updates role definitions when work changes. An included deployment is not an unlimited commitment to every future integration.

Use the pricing model and the cost calculator with your own figures. Measure the current handling work and compare it with a pilot of the same process. Do not treat a hypothetical reduction in staff time as a guaranteed cash saving. A defensible business case keeps assumptions and measured results separate.

Prepare for operation before expanding the rollout

Start with a bounded application scope and an accountable owner. Document the source data, requested roles and target operations. Agree what the business participant should see and what the operator should do when the process cannot complete.

Self-hosting is the default for easyIGA. An operated EU-hosted option is available on request. Choose the deployment model through your own infrastructure and security requirements, then define the support and recovery responsibilities. A deployment location alone does not establish the service's availability or suitability for a restricted environment.

Run the ordinary path and the exception paths before adding more sites. Include an incorrect source record, an unavailable application and a role change that removes old access. Record the behaviour of the actual release and configuration. Use synthetic identities until the organisation has approved the use of real data.

After the pilot, decide what evidence supports expansion. It should include the business users' ability to understand the request and the operators' ability to resolve exceptions. A successful demonstration of one application should lead to a scoped next step, not an assumption that all targets are equivalent.

Request a product walkthrough with a non-sensitive example from your own work. The discussion can then focus on the access decision, the systems involved and the evidence needed to move from an attractive interface to an operational process.