Why spreadsheet access reviews fail and how automated campaigns replace them
midPoint can run access certification campaigns fed directly by connectors to Active Directory, LDAP and SaaS systems, so reviewers decide on live entitlements instead of exported snapshots. The effort is mostly connector configuration, cleanup of source data and role modeling, not licensing, because midPoint is published under the European Union Public License and Evolveum states it has no enterprise edition. This page covers the review workflow and the evidence it produces: how campaigns are scoped, how decisions are routed to managers and owners, and how the results are kept. It does not cover joiner and leaver design in general, which has its own treatment elsewhere on this site.
A quarterly spreadsheet review usually breaks in predictable places. Someone exports group memberships from Active Directory, pulls a separate user list from each SaaS application, merges them by hand, and emails the file to managers. Names do not match across systems, nested groups are flattened or missed, and managers approve rows they cannot place. Nobody can show which version of the file a reviewer saw, when a revoke was actually executed, or whether the revoke reached the target system. The auditor then asks for the population, and the team reconstructs it from the same spreadsheets that caused the problem.
Replacing this with a campaign means deciding three things before the first run: which target systems are in scope and which connector reads each one, which owner is accountable for each application or role, and what happens when a reviewer does not respond. Confirm with Evolveum's connector documentation which connectors your target systems need and whether each is supported or community status, since that determines how much custom work you will carry. Then run a test campaign against a copy of the data and check that the revoke, not only the approval, is written back to the target system. The decision log is what an assessor will examine, so it should be exported and re-read before the first real review.
Which requirements a self-hosted review process must meet
This table maps three frameworks to what they mean for a midPoint certification campaign: scope, reviewer assignment, decision recording and retention. Read each row as a question to answer for your own system, and confirm the NIST baseline that applies before scoping the campaign. The main takeaway is that the campaign record, not the review screen, is what an assessor will test.
| Requirement | What it means for the campaign | Evidence an assessor expects |
|---|---|---|
| NIST SP 800-53 AC-2 periodic account review | Define which accounts and entitlements are in each campaign, set the review cadence, and confirm the baseline (low, moderate or high) that selects AC-2 for your system | Campaign definitions, cadence records, completed review cycles and the scope each cycle covered |
| NIST AC-2 manager notification and removal | Notify managers when access is no longer needed and route revoke decisions to provisioning so accounts are actually changed | Notification records, revoke decisions and proof that the target account or entitlement was removed |
| NIST AC-2 termination and transfer alignment | Make sure reviews catch access left behind after a transfer or exit that the joiner, mover and leaver feeds missed | Reconciliation results comparing HR status with active accounts and review outcomes for movers and leavers |
| 45 CFR 164.312 access control and unique user identification | Reviewers certify named, unique accounts, so shared or generic accounts must be in scope and flagged for an owner | Unique identifier mapping between source systems and reviewed accounts, plus owner assignments for shared accounts |
| 45 CFR 164.312 audit controls | Record who reviewed what, when, and what they decided, and make the audit trail reviewable for systems holding ePHI | Audit logs of campaign actions, decision history and a sample of reviewed entitlements with timestamps |
| FTC Safeguards Rule 16 CFR 314.4(c) monitoring and logging | Log activity of authorized users and review it on a defined schedule, including reviewer decisions and changes made after a review | Logs covering campaign activity, change records for revoked access and documented review frequency |
| Decision retention and reproducibility | Keep campaign records, reviewer identities and decisions for the retention period your framework and policy set, and confirm that period with counsel or your auditor | Archived campaign exports, reviewer roster as of the review date and the policy that governed retention |
Which entitlements the campaign has to see
A certification campaign is only as complete as the population it pulls, so the first job is to list every system that grants access and confirm midPoint can read it. For most estates that means Active Directory and LDAP groups, SaaS applications reached through SCIM2 or Microsoft Entra ID connectors, and database tables or CSV extracts for legacy applications that have no directory integration. Midpoint reaches these through the ConnId connector framework, and the documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API), SCIM2 and SCIMv1. Confirm each target system against those documented connectors and the wider integration catalog, where status ranges from supported to community and experimental. Do not assume support for a SaaS product or a homegrown application because a connector exists for a similar one. Ask which connector version and which operations (read only for reviews, or read and write for provisioning) each system needs, because a review that only reads may run on a connector that a provisioning design cannot use.
Before the first campaign, reconcile accounts against the authoritative source. Orphaned accounts (accounts with no owner or with an owner who has left) and uncorrelated accounts (accounts midPoint cannot match to an identity) will either be missing from the review or appear with no reviewer. Both outcomes weaken the evidence, because an auditor who samples the population will find access that was never reviewed. Run a correlation pass, list the uncorrelated and orphaned accounts per system, and decide for each whether to link it to an identity, disable it or assign a named owner. Record the counts and decisions, since they become part of the population evidence. Confirm with each application owner how service and shared accounts are identified, because these are often the accounts that fall outside a standard manager-based review.
How deployment constraints change the review design
When the directory and most SaaS applications already live in a cloud tenant, midPoint is usually deployed in the same cloud account or a private network peered to it. midPoint runs on Linux in a virtual machine or from Docker images, and its native repository is PostgreSQL, ideally on a separate database server rather than the application host. A multi-node deployment needs a sticky HTTP load balancer in front of the nodes, a shared central database, and Quartz for distributed task scheduling, so campaign jobs run once rather than on every node.
- Connector path: The Microsoft Entra ID (Graph API) connector and SCIM2 connectors reach cloud targets over HTTPS, so outbound egress rules and service principal permissions are the main design items.
- Reviewer sign-in: midPoint does not act as an SSO server, so reviewers authenticate to its web interface through an external SSO service, which should be confirmed against your identity provider.
- Campaign scheduling: Quartz handles task scheduling across nodes, so confirm that certification jobs fire once in your multi-node layout.
- Database placement: Keep PostgreSQL on a managed or separate server with backups that match your evidence retention rules.
- Connector coverage: Confirm each SaaS target against the Evolveum connector catalog, since status ranges from supported to community and experimental.
Before you commit, check whether every SaaS application in scope has a supported connector or whether some will need a SCIM endpoint or a custom integration.
Where Active Directory sits behind a segmented network, midPoint usually runs in a management zone with controlled paths to domain controllers and LDAP directories. The PostgreSQL repository and the midPoint nodes stay inside that zone, and the reviewer web interface is published only through a controlled entry point. Multi-node deployments add the sticky load balancer and cache invalidation between nodes over HTTPS, which must be allowed by the segmentation rules.
- Connector path: The Active Directory and LDAP connectors speak directly to domain controllers, so the firewall rules must allow the required ports from the midPoint zone only.
- Service account scope: Use a dedicated account with the minimum rights needed to read entitlements and make approved changes, and document who holds its credentials.
- Reviewer access: Managers and owners reach the review interface through a reverse proxy or load balancer, with SSO and multi-factor authentication enforced at that entry point.
- Cache traffic: Confirm that inter-node cache invalidation over HTTPS is permitted between midPoint nodes.
- Database isolation: Restrict the PostgreSQL server to midPoint nodes and administrators, since campaign decisions are stored there.
Confirm the exact ports, service account permissions and proxy configuration with your network and directory teams before the first test campaign.
In an air-gapped or heavily restricted network, the design changes most in how software and connectors arrive and how reviewers reach the system. Container images or VM images must be moved in through an approved transfer process, and any updates or connector packages follow the same path. midPoint still runs on Linux with PostgreSQL on a separate server, but every dependency must be inventoried so it can be rebuilt and verified inside the enclosure.
- Software delivery: Plan a controlled import of Docker images or VM images and of the Java runtime version midPoint requires for your release, so upgrades stay repeatable.
- Connector reach: Connectors such as LDAP and Active Directory only work inside the enclosure, so every source system must be local to it, and SaaS connectors may not be usable at all.
- Reviewer access: Reviewers may need to sign in from a separate reviewer network or jump host, and that path needs its own authentication and logging.
- Release planning: Choose a long-term support line where possible, because each upgrade must pass through the transfer process.
- Evidence storage: Campaign records and exports should be retained inside the enclosure under the same retention rules as the rest of the audit data.
Ask your implementation partner and internal teams to confirm the transfer process, the Java and PostgreSQL versions supported for your release, and which connectors work without outbound access.
Which open source platforms fit this review workflow
A user access review needs three things working together: an identity governance engine that runs the campaign, connectors that read entitlements from each target system, and a way to authenticate reviewers and protect the credentials those connectors use. The cards below cover the components that fit this workflow and the boundaries you need to confirm before committing to a design.
midPoint for certification campaigns
midPoint is the identity governance engine that builds the review population, assigns reviewers to managers or resource owners, records each decision and applies revocations. It is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition, so the license terms do not depend on a feature tier. Before scoping, confirm that every target system you need to review has a supported or community connector in Evolveum's integration catalog, and test how the connector reports entitlements that are nested or inherited.
ConnId connectors for entitlement sources
Review quality depends on the entitlements midPoint can see. The documented connectors include LDAP, Active Directory, Microsoft Entra ID through the Graph API, SCIM2, CSV and DatabaseTable. SaaS applications often need SCIM2 or a custom scripted connector, and each one should be tested for group membership, application roles and disabled accounts. Ask the partner to show a reconciliation report from each source before the first campaign launches, so reviewers do not certify an incomplete picture.
Keycloak for reviewer sign-in
midPoint manages identities but does not act as an SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML, although its own user interface can authenticate against an external SSO service. Keycloak is a common choice for that role, because it supports OpenID Connect and SAML 2.0 and can federate Active Directory or LDAP. Confirm which login flow, MFA method and session timeout managers and resource owners will use when they approve reviews, since those choices form part of the evidence an auditor will ask about.
OpenBao for connector credentials
Each connector authenticates to a target system with a service account, and those credentials are the most sensitive part of the review pipeline. OpenBao, licensed under MPL-2.0, can store and distribute these secrets so they are not kept in midPoint configuration files. Use it only if your environment needs centralized secret rotation for these accounts. Confirm with your security team who owns the key material, how rotation interacts with connector restarts, and whether the license terms fit your procurement policy.
Infisical as an alternative secret store
Infisical is an alternative for teams that want secrets, certificates and access managed in one platform. Its license is MIT except for content in ee directories, which falls under a separate enterprise license, so confirm which directories your deployment would actually run before relying on the MIT terms. Choose Infisical over OpenBao only when your secret-store evaluation favors its features and the enterprise boundary is acceptable to your legal team. Either way, the review workflow needs the same answer: where the connector credentials live and who can read them.
Rollout phases and the output of each
The sequence moves from knowing what access exists, to cleaning it up, to proving the campaign works on one population before the first full cycle replaces the spreadsheet with evidence an auditor can re-perform. Each phase closes with a named artifact so the next one has a clear starting point.
Inventory systems and entitlements
Your IGA team, with the system owners for each in-scope application, lists every target system that holds access to the population under review: directories, SaaS tools, databases and file shares. For each one, they record how accounts are created, who approves access today, and which entitlements carry financial, regulated or administrative weight. The output is an entitlement inventory with a named owner per system. It is done when every spreadsheet currently used for review maps to a system in the inventory, and any system without an owner is escalated.
Reconcile and clean orphaned accounts
Before any reviewer sees a decision, the team compares accounts in each target system with the authoritative HR or contractor source. Accounts with no matching person, shared or service accounts without an owner, and accounts belonging to leavers are flagged for disposition. Owners confirm or remove each flagged item. The output is a reconciled account list with a documented disposition for every exception. Reviewers should not inherit a population that still contains unexplained accounts.
Define the role or entitlement model
Working with application owners, the team decides which access is granted through roles and which through individual entitlements, and names each role with its purpose and approver. This is the point where reviewers learn what they are approving, so role names must be understandable to a manager. The output is a signed-off role or entitlement catalog, with the review scope for each role written down. Sign-off by the business owner and the control owner closes this step.
Build and test connectors in non-production
The platform team configures midPoint connectors for each in-scope source, such as LDAP, Active Directory, SCIM or Microsoft Entra ID where those connectors are documented for the target, and confirms each connector's supported status before relying on it. They run read-only imports first, compare the results with the inventory from phase one, and then test the write paths in a non-production copy. The output is a connector test report with reconciliation counts and a list of known gaps. Do not proceed to production until the owners of each connected system accept the report.
Run a pilot campaign on one population
The team chooses one bounded population, such as a single application or department, and runs a complete certification cycle in midPoint: the campaign definition, reviewer assignment, decisions, revocations and reporting. Reviewers and managers test the workflow, and the team checks that revoked access actually disappears in the target system. The output is a pilot results memo listing defects, reviewer questions and corrected settings. A campaign is not ready for scale until a revocation has been verified end to end in the target.
Launch the first full campaign
The campaign covers the full in-scope population with the corrected definition and reviewer routing. Reviewers decide, escalations go to the named owners, and the team tracks completion and revocation tasks through to the target systems. Remediation items are closed with a confirmation from each system owner. The output is a completed campaign with decisions and remediation status recorded. It is done when no decision is open without an owner and every revocation is confirmed in the system where access was removed.
Retain the decision log as evidence
The team exports the campaign definition, population snapshot, reviewer identities, each decision with its justification, timestamps, and remediation confirmations, then stores them under the retention rules agreed with compliance. They confirm that the export can be re-run or read without the original administrator. The output is an evidence package and a short procedure describing how the next campaign will produce the same records. Ask the auditor which artifacts they expect before the first formal assessment, since requirements differ by framework.
Evidence auditors ask for and the component that produces it
This table maps the records auditors typically request from an access review cycle to the midPoint component or connector log that produces each one. Read it as a checklist for designing the campaign so every decision can be re-performed later, and note that DeployOpen prepares these records for assessment but does not issue audit opinions or attestations.
| Evidence record | What it shows | Produced by in midPoint |
|---|---|---|
| Campaign definition | Scope, reviewers, review cadence, and the rules that decided who reviews what | Certification definition objects, versioned and kept with the campaign history |
| Population extract | Which accounts and entitlements existed at the start of the review, with a timestamp | Campaign snapshot of resource objects, plus the source connector run that loaded them |
| Connector and sync logs | Proof that the source data was read completely and when | Resource reconciliation task reports and connector logs for LDAP, Active Directory, Entra ID and SCIM targets |
| Reviewer identity and decisions | Who decided, what they decided, and when, for each item | Certification work items and decision history, tied to the reviewer's midPoint identity |
| Revocation tasks | Which access was removed after a revoke decision, and whether removal reached the target system | Remediation tasks and provisioning audit records, with the connector result for each target |
| Completion and escalation report | Share of items decided, late items, and how escalations were handled | Campaign statistics and reports, plus notifications sent to reviewers and owners |
| Change history for roles and rules | What role or policy logic was in force when a decision was made | Object audit trail for roles, policies and configuration, confirmed against your change records |
What buyers ask before automating access reviews
How much effort does automating access reviews with midPoint take?
The effort depends mostly on how many systems feed the campaigns, how clean the source data is, and how many reviewers are involved. Each connected system needs its own connector configuration, attribute mapping and testing, and each one adds reconciliation work when account names, owners or group structures differ across directories. Data quality is often the largest variable: orphaned accounts, shared accounts and unowned groups must be resolved before a first campaign produces decisions anyone can trust. Reviewer population matters too, because a campaign routed to a few hundred managers behaves very differently from one routed to a handful of application owners. Ask any partner for a written breakdown of connectors, data cleanup, role modeling and reviewer routing before accepting a figure.
What do we need from our directory and application owners?
You need named owners for each target system who can confirm which accounts and entitlements are legitimate, and a directory team that can grant a read-only service account with the scope midPoint needs. For Active Directory and LDAP, that means agreeing which OUs and groups are in scope and who approves changes to the service account. For SaaS applications, owners must confirm how entitlements are represented, whether API access is available on your plan, and who can answer questions about roles that no longer match job titles. Owners also decide what a reviewer may approve, so they should sign off on the review scope before the first campaign launches. Ask your partner to document each owner, their decision rights and their escalation path in the scope agreement.
Can an internal team run midPoint access reviews without a partner?
An internal team can run midPoint, but the first implementation usually requires skills that are scarce: Java and PostgreSQL operations, connector configuration, identity data modeling and familiarity with how auditors test reviews. midPoint uses the ConnId connector framework and PostgreSQL as its native repository database, so the platform team must be able to operate both, including upgrades and backups. Evolveum also sells support subscriptions, which address product bugs, and separate platform subscriptions for feature work, so you can combine internal operations with vendor support. Many teams start with a fixed-scope implementation to model roles and connect the first two or three systems, then take over operations once runbooks and campaign procedures are written. Confirm your team's skills against the scope before deciding.
How do midPoint upgrades affect running certification campaigns?
Upgrades affect campaigns because a version change can alter how reviews, connectors or the database schema behave, so you should plan them around open campaigns rather than during them. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, which gives teams a stable base for multi-year audit cycles. midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.9 support ends 18 October 2026, so any deployment still on 4.9 needs a planned move. Before each upgrade, test a complete campaign in a non-production environment, confirm connector compatibility with each target system, and back up the repository database. Record the version in effect for each campaign so the evidence explains which platform produced each decision.
Does midPoint licensing add cost to an access review program?
midPoint's license does not add a per-user or per-module fee, because Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses. The repository is licensed under the European Union Public License (EUPL-1.2), with Apache 2.0 as a secondary license, so licensing terms should be reviewed by your legal team if you distribute modified code. Your costs instead come from infrastructure, including the application servers and PostgreSQL database, connector and role-modeling work, data cleanup, and staff time for reviews. Vendor support is optional: Evolveum's Product Support subscriptions cover product bugs with an 8x5 next-business-day or 24x7 SLA, and its Platform Subscriptions add feature development. Ask Evolveum for current subscription pricing, because the public page does not list prices.
What evidence does an auditor expect from a midPoint access review?
An auditor typically expects a complete population of accounts in scope, evidence that each reviewer decision was made by the right person, and a record of what happened after each decision. The campaign should show who was asked to review which entitlements, when, what they decided, and whether revocations were carried out in the target system. Retain campaign definitions, reviewer lists, decisions with timestamps, exports of the population at review start, and remediation tickets or connector logs that confirm removals. Your control owner should also document the review cadence and escalation for reviewers who do not respond. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors decide whether the evidence is sufficient.
Which access review cadence do regulators and frameworks expect?
Frameworks set the minimum intent rather than a single cadence, so the right frequency depends on the regulation, the system's risk and your own policy. NIST SP 800-53 control AC-2 requires organizations to review accounts periodically and to define that period themselves, and it is selected for the low, moderate and high baselines. Sector rules add their own expectations, such as payment card and financial frameworks that set specific review intervals for certain accounts. Confirm the frequency in your control documentation with your compliance lead and external auditor before configuring campaigns. midPoint can schedule campaigns at the interval you set, so the configuration should mirror the written policy.
Questions to ask an implementation partner
Start with connectors. Ask which midPoint connectors the partner has deployed in production, not only in a lab, and for which target systems. The documented set includes LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1, and the wider ConnId catalog ranges from supported to community and experimental status. Ask for the status of each connector they propose, the account counts they have reconciled through it, and how they handle SaaS applications that only expose a vendor API. Any connector marked community or experimental should be listed in the statement of work with a named owner for its maintenance.
Next, ask how orphaned and excess accounts are cleaned up before the first campaign. A credible answer names the reconciliation run, the correlation rules used to match accounts to identities, the list of accounts with no owner that the partner expects to find, and the sign-off step where your application owners decide what gets disabled. Ask who approves the cleanup and how the decisions are logged. Also ask how reviewer escalation and delegation are configured: which timeout triggers escalation to the next manager, whether reviewers can delegate and who may approve a delegation, and what happens when a reviewer leaves. Ask the partner to show these settings in a test tenant, not only describe them.
Then ask how decisions are retained and exported for an assessor. Confirm where campaign results, reviewer identities, timestamps and remediation tickets are stored, how long they are kept, and whether an assessor can re-run a sample without access to the live system. Ask how campaigns are tested before launch, including a dry run against a copy of the data and a check that every in-scope account appears exactly once in the review population. Finally, ask how upgrades between midPoint releases are planned. Confirm the current long-term support line and its end date on the midPoint releases page, which release the partner will target, and whether they test upgrades on a staging copy of the database with your connectors before production.
How DeployOpen scopes review automation in your environment
The sequence below turns a spreadsheet-based review process into a written, fixed-scope plan that names the sources, connectors, reviewers and evidence before any midPoint configuration starts. Each step ends with a document or check you can hold the work against.
Share your current review process and artifacts
You send DeployOpen the current quarterly review workbook, the list of systems whose access is reviewed, the names of the owners who sign off, and any prior audit findings about access reviews. DeployOpen reads these with your compliance lead and writes down which accounts, entitlements and reviewers the spreadsheets cover today, and which ones they miss. The step is complete when you have a written inventory of in-scope systems and a list of open questions for your team to answer.
Confirm authoritative sources and target connectors
Your identity, HR and application owners confirm which directory or system is the source of truth for people and which ones hold entitlements that need review. DeployOpen checks each target against the connectors midPoint documents, including LDAP, Active Directory, Microsoft Entra ID through the Graph API, SCIM2 and CSV, and flags any system that would need a custom or community connector. You receive a connector matrix listing each system, its connector status and the access data to be pulled. Confirm each connector's status with Evolveum and in your own test environment before it is scoped as supported.
Define campaign scope, reviewers and decision rules
Together with your access governance owner, DeployOpen defines what each certification campaign covers, who reviews each population (for example, line managers for employees and named owners for shared or privileged accounts), what happens when a reviewer does not respond, and which decisions count as revoke, keep or modify. The output is a written campaign specification that lists reviewer assignment logic, decision options and the records each decision must leave behind. Your sign-off on this document is required before configuration begins.
Agree the deployment model and hosting
DeployOpen confirms where midPoint and its PostgreSQL repository will run, whether on Linux virtual machines or from Docker images, and how many nodes are needed. Multi-node designs use a sticky HTTP load balancer, a shared central database and Quartz for task scheduling, so DeployOpen documents these choices alongside your network, backup and access constraints. You receive a written architecture note and a list of the platform versions in scope. Confirm the midPoint release line with your upgrade policy before the build starts, since 4.8 is a long-term support release and 4.10 is a feature release.
Set the fixed scope and written deliverables
DeployOpen drafts a fixed-scope proposal from the inventory, connector matrix, campaign specification and architecture note. The proposal lists the systems in scope, the deliverables (configured connectors, campaign definitions, reviewer routing, test results and runbooks), the acceptance checks and the assumptions your team must meet, such as access to test accounts and named reviewers. Scope, deliverables and timelines are agreed in writing before work starts, and any change goes through a written change request. The step closes when both parties sign the scope document.
Build, test and collect evidence during the engagement
DeployOpen configures the connectors and campaigns in a non-production environment, runs a reconciliation of pulled entitlements against the source systems, and tests reviewer routing, escalation and revocation with sample accounts. Each test produces a record that shows the input population, the decision and the resulting change, which is the kind of evidence an assessor will ask to re-perform. DeployOpen prepares these records and the runbook, but an independent auditor or certification body decides whether they meet a given requirement. The step is complete when the test log is accepted by your team.
Hand over, then continue under a support retainer
At go-live, DeployOpen transfers configuration documentation, the operations runbook, backup and restore steps and the evidence procedure to your operations and compliance staff. After go-live, ongoing support, upgrades and continuous testing are available as retainers, which cover planned midPoint release upgrades, connector maintenance when a source system changes and help running each new campaign. Your team confirms in writing which retainer tasks it wants, what response expectations apply and how support requests are logged, because DeployOpen publishes no SLA for these services. The engagement closes when the handover checklist is signed.
How DeployOpen builds and supports access review automation
DeployOpen plans, implements, integrates, hardens, documents and supports midPoint inside your own infrastructure, so certification campaigns, connector feeds and decision records stay under your control. Each engagement starts from a written scope that defines which sources, target systems and review campaigns are in and what evidence they must produce.
How we scope
- Inventory the review population: which directories, SaaS applications and business owners sit inside each campaign
- Agree in writing which entitlements are certified, at what granularity, and which reviewers decide each one
- Confirm the connectors required for Active Directory, LDAP and each SaaS target, including any community or experimental status
- Define the evidence an assessor will request, such as campaign records, reviewer identities, decision timestamps and remediation tickets
How we build
- Deploy midPoint on your Linux hosts, virtual machines or containers with PostgreSQL as the repository database
- Configure certification definitions, reviewer routing to managers and application owners, and escalation for unanswered items
- Test campaigns end to end in a non-production environment, including revocation tasks that remove access after a rejected decision
- Document configuration, connector settings and runbooks so your team can reproduce and audit the setup
How we hand over
- Hand over configuration as versioned artifacts with a written description of each campaign and its owner
- Train the administrators and reviewer coordinators who will run each quarterly cycle without DeployOpen involvement
- Provide a campaign evidence procedure that explains where decisions, approvals and exports are stored and retained
- Agree the upgrade approach for midPoint release lines and confirm which support subscription, if any, you will hold with Evolveum
How we support
- Offer ongoing support, upgrades and continuous testing under a retainer agreed in writing
- Review connector health, failed revocations and stalled campaigns on a schedule set in the retainer
- Plan midPoint upgrades, including long-term support line timing, and test them before production changes
- Keep the review documentation current when sources, owners or target applications change
