How open source identity governance supports HIPAA access management
A covered entity or business associate with a workforce that changes often needs to show that access to ePHI is authorized, modified and removed on time. midPoint can automate the joiner, mover and leaver workflows behind these access management standards, but HIPAA sets no certification, and the policies, reviews and evidence remain the organization's responsibility. The HHS Office for Civil Rights has said no Security Rule standard requires certifying compliance, so a midPoint deployment supports compliance without proving it on its own. The access standards at 45 CFR 164.308(a)(4) cover authorizing access, granting access and establishing and modifying a user's right of access, and the termination procedures at 164.308(a)(3)(ii)(C) cover ending access when employment or another arrangement ends. The access authorization and access establishment and modification specifications are addressable, so the organization must assess whether each is reasonable and appropriate, implement it or document why not and adopt an equivalent measure. Confirm that decision in writing with your compliance lead for each specification, because midPoint configuration cannot make that call for you. The Security Rule also requires unique user identification and audit controls that record and examine activity in systems holding ePHI. In midPoint, that means each identity should map to one person across source and target systems, and every provisioning change should be traceable to a request, approval or source event. NIST SP 800-66 Rev. 2 maps these standards to key activities and sample questions, and it is a useful checklist for the assessment.
Before go-live, confirm three things with your privacy and security officers: which systems are in scope for ePHI, which HR or credentialing source is authoritative for clinicians, residents, contractors and agency staff, and how quickly termination must take effect under your own policy. Then test the leaver path end to end in a non-production environment, including disabling accounts in every connected target system, and keep the run logs. Expect the review cadence and the evidence set to be defined by your policies, not by midPoint defaults. Ask any implementation partner to show how a sample leaver record, its approvals and its removal across systems can be exported as one evidence package.
Which HIPAA access requirements midPoint automates and how to configure each
This table maps each HIPAA access requirement to the midPoint configuration that supports it and the evidence an assessor will ask for. Read it as a checklist: the first column names the rule, the other columns show what to configure and what to keep on record. The main takeaway is that midPoint automates provisioning and review, but the access authorization decisions and the addressable choices still need written policy from your organization.
| Requirement | What midPoint configures | Evidence to keep |
|---|---|---|
| Access authorization policy (164.308(a)(4)(i) and (ii)(B)) | Role model per application or workstation, with entitlements bound to roles and approval rules for each role | Approved role catalog, owner for each role, and the written access authorization policy |
| Access establishment and modification (164.308(a)(4)(ii)(C)) | Joiner and mover rules driven by the authoritative HR source, with approval workflows for changed access | Request and approval records, provisioning logs, and the modification history for each user |
| Scheduled review of access rights (164.308(a)(4)(ii)(C)) | Certification campaigns on a set cadence, routed to managers and application owners, with revocation applied automatically | Campaign definitions, reviewer decisions, and records showing revoked access was removed |
| Termination of access (164.308(a)(3)(ii)(C)) | Leaver trigger from HR status change, disabling accounts across connected systems, and removal of role assignments | Termination timestamps, connector results per system, and exceptions for accounts that failed to disable |
| Unique user identification (164.312(a)(1) and related unique user identification) | One identity object per person with unique identifiers mapped to each target system, and no shared accounts provisioned | Identity uniqueness rules, account-to-person mapping reports, and a list of any shared or service accounts with owners |
| Audit controls (164.312 audit controls) | Logging of provisioning, certification and assignment changes, retained in a location the access team cannot edit | Audit log exports, retention settings, and sample reports that show who changed access and when |
| Addressable decisions (164.306(d)(3)) | Configure the automated measures your assessment supports and record any measure you decide not to implement | Written assessment for access authorization and access establishment, documented reasons, and the equivalent alternative measure chosen |
| Connector coverage | Connectors for each system holding ePHI, with a documented list of systems managed manually | Inventory of ePHI systems, connector status per system, and manual procedures for any system outside automation |
Which open source platforms fit this HIPAA access workflow
A HIPAA access workflow needs one system that decides who should have access to ePHI, systems that enforce authentication, and secrets handling and logging that let you prove it. The cards below separate those jobs so you can see which platform owns each step and where the handoffs sit.
midPoint as the lifecycle engine
midPoint holds the joiner, mover and leaver rules, approvals and access decisions that the HIPAA access authorization and modification standards call for. It is licensed under the European Union Public License 1.2 or later, and Evolveum states there is no enterprise edition, so the license cost is zero. Its repository runs on PostgreSQL, ideally on a separate database server. Check which ConnId connectors your target systems need, including LDAP, Active Directory and Microsoft Entra ID, and confirm each one's support status before you commit to a design.
Keycloak for sign-on and authentication
Keycloak handles single sign-on, OpenID Connect, OAuth 2.0 and SAML 2.0 for the applications that clinicians and staff use. It authenticates people but does not create or remove accounts on its own, so it must receive identities from midPoint or another source. Confirm how the directory it federates with, such as Active Directory or LDAP, stays in step with midPoint so a terminated user cannot still sign in through a cached session or a stale federation link.
Division of responsibility with midPoint
midPoint is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth 2.0, OpenID Connect or SAML, although its own interface can sign in against an external SSO service. Document this split in your access control design so an auditor can trace each account to a provisioning decision in midPoint and each login to a sign-on event in the SSO server.
OpenBao or Infisical for service account secrets
Integration accounts, API tokens and certificates used by midPoint connectors are themselves privileged access paths to ePHI. Store and rotate them in OpenBao or Infisical rather than in configuration files. OpenBao is licensed under MPL-2.0, while Infisical uses MIT except for content in ee directories under a separate enterprise license. Confirm which features your version needs before you select either one.
Wazuh or Security Onion for audit logs
The HIPAA audit controls standard requires activity in systems that hold ePHI to be recorded and examined. Wazuh (GPL-2.0 core) or Security Onion (Elastic License 2.0) can collect midPoint, Keycloak and directory logs so you can review provisioning and login events together. Verify that each product collects the log sources you need and that your retention settings meet your own policy, because log storage is a recurring cost.
How joiner, mover and leaver workflows map to HIPAA access standards
The core of the HIPAA mapping is a single chain: an HR system of record triggers midPoint, midPoint assigns or removes roles, and connectors push those changes to the systems that hold ePHI. A hire creates the identity and assigns the baseline roles that 45 CFR 164.308(a)(4)(ii)(B) asks you to define for access to ePHI. A job change triggers role recalculation, so prior access is removed as part of the move rather than left behind. A termination disables accounts across the EHR, file shares and cloud applications, which is the procedure 45 CFR 164.308(a)(3)(ii)(C) requires. Illustrative example: a nurse moves from a med-surg unit to a billing team. The HR change recalculates her roles, the chart-access role is removed in the EHR through its connector, and the billing role is added only after the new manager approves it.
Manual approval remains in three places, and your policy should name them. First, access that is not in a pre-approved role, such as break-glass or elevated EHR roles, needs a documented approver in midPoint's request workflow, which supports the access authorization decision in 45 CFR 164.308(a)(4)(ii)(B). Second, the mapping of roles to clinical functions is a human decision that the HIPAA Security Rule expects you to document and review under 164.308(a)(4)(ii)(C). Third, any target system without a supported connector will be handled by a ticket and a named administrator, and that path needs the same evidence as the automated one. Confirm with your IGA partner which of your target systems have connectors in your midPoint version, since the connector status varies between supported and community or experimental.
Before go-live, test the leaver path end to end. Confirm that the HR termination date drives the disable action, that disablement reaches every ePHI store including local accounts that are not in the directory, and that the time between the HR change and the removal is recorded in midPoint's audit trail. Because the Security Rule is addressable for access authorization and access establishment, your risk analysis should state why each automated step is reasonable and what alternative covers any gap. Ask your partner to show these records in a test run, because an assessor will look for the same evidence.
Sequence for a HIPAA-scoped midPoint rollout
The sequence moves from defining which systems hold ePHI and how access is authorized, through cleaning up existing accounts, to automated termination triggers that can be tested and evidenced. Scope and timing are agreed in writing before work starts, and each phase closes with a check the covered entity can keep.
Define the ePHI system inventory and authorization policy
The covered entity or business associate lists every system, application, database and file share that stores, processes or transmits ePHI, and names an owner for each. Compliance, privacy and the system owners then write the access authorization policy that governs who may be granted access, on what basis, and who approves it, consistent with the access authorization standard in 45 CFR 164.308(a)(4). The step is done when the inventory and policy are approved and every in-scope system has a named owner and approver.
Clean up orphaned accounts in scope
Before automation touches anything, the team pulls account and entitlement data from each in-scope system and compares it with the HR record of current workforce members. Accounts with no matching person, shared or generic accounts, and dormant access are listed for owner review and either disabled, reassigned or documented. Starting from a known population means midPoint does not inherit stale access on day one. The step closes with a signed-off exception list and a baseline report of accounts that will be managed.
Build the role model from approved access
Roles are drafted from the access that owners have confirmed is needed for each job function, then grouped into clinical, administrative, support and privileged categories. Each role is tied to the systems and entitlements it grants and to the approver who may request it. This is the practical form of the access authorization and modification policies that the Security Rule expects an entity to document and review. The step is complete when the role catalog is approved and the mapping from roles to target-system entitlements has been tested in a non-production midPoint environment.
Connect the authoritative source and first connectors
The HR system or other authoritative workforce source is connected to midPoint, and the first target connectors are configured for the systems in scope. midPoint uses the ConnId connector framework, and the connectors that fit the environment (for example LDAP, Active Directory or a database-backed application) must be confirmed against the connector documentation and tested. Joiner, mover and leaver rules are configured and run against test accounts. The step is done when test accounts show correct creation, role change and disablement, and the results are logged.
Run the first access review
The first certification campaign is run for the in-scope systems, with system owners or managers reviewing the access their people hold. Reviewers approve, revoke or flag entitlements, and midPoint records each decision, the reviewer and the date. Items revoked in the review are removed in the target system and the removal is checked. The review shows whether the role model fits actual work, and it produces the first set of access review records the covered entity can present. The step closes when all decisions are complete and open revocations are confirmed.
Cut over termination triggers
Once the review is complete, automatic removal of access on workforce departure is switched on for the in-scope systems. The team runs controlled leaver scenarios, including immediate termination and contractor end dates, and confirms that access to ePHI is removed in every target system. Procedures for manual escalation are documented for cases where a connector cannot complete a removal. The step is done when leaver tests pass in every in-scope system and the termination procedure, the test results and the runbook are on file.
What auditors and OCR ask for as HIPAA access evidence
This table maps each piece of HIPAA access evidence to the Security Rule requirement it supports, the component that usually produces it, and where teams tend to have gaps. Read it as a checklist to confirm with your compliance lead, since HIPAA has no certification and OCR judges whether your records show the policies were followed. Retention periods for each record must be set with counsel.
| Evidence item | Requirement it supports | Component that produces it | Where gaps usually appear |
|---|---|---|---|
| Documented access authorization policies | 45 CFR 164.308(a)(4)(i) and (a)(4)(ii)(B) on authorizing and granting access to ePHI | Written policy and role model maintained in midPoint, linked to the policy owner's approval | Roles exist in midPoint but the written policy does not describe who approves them |
| Approval records from access requests | 45 CFR 164.308(a)(4)(ii)(C) on establishing and modifying a user's right of access | midPoint access request and approval workflow records, with approver identity and timestamp | Access granted through tickets or direct edits in target systems that bypass midPoint |
| Provisioning and deprovisioning logs with timestamps | 45 CFR 164.308(a)(4)(ii)(C) on establishing, documenting and modifying access | midPoint task and audit records, plus ConnId connector logs showing each target system change | Connector failures or manual changes in EHR or file shares that never reach the audit trail |
| Termination records tied to HR events | 45 CFR 164.308(a)(3)(ii)(C) on terminating access when employment ends | HR-sourced leaver events processed by midPoint, with removal results per target system | HR records entered late, so removal dates do not match the employment end date |
| Periodic review decisions | 45 CFR 164.308(a)(4)(ii)(C) on reviewing a user's right of access | midPoint certification campaign decisions and reviewer comments | Reviews run on paper or in spreadsheets with no record of the reviewer's decision |
| Unique user identifiers | 45 CFR 164.312(a)(1) on unique user identification | Stable user identifier in midPoint and the authoritative HR source, carried to target systems | Shared or generic accounts in clinical or legacy systems with no owner recorded |
| Authentication and access logs | 45 CFR 164.312 on audit controls and person or entity authentication | Keycloak event logs for sign-in and admin actions, forwarded to the SIEM | Keycloak events kept on the node only, or retention shorter than the policy requires |
| Audit log review and retention settings | 45 CFR 164.312 on audit controls that record and examine activity in systems with ePHI | SIEM retention and alert records, with exports of midPoint and Keycloak logs | No documented review cadence, or logs rotated before the retention period set with counsel |
Common questions about HIPAA access management with open source IGA
Does HIPAA require certification for access management?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private certifications. HHS also says such certifications would not prevent it from later finding a violation. What HHS examines is whether your access authorization, establishment and modification, and termination procedures exist, are followed and are documented. The Office for Civil Rights enforces the Security Rule through complaint investigations, compliance reviews and audits, so your evidence should show how the rules operate in practice. Ask any vendor or partner that offers a HIPAA certification what it actually covers before relying on it.
What do we need from our own staff for a midPoint HIPAA project?
The work needs three kinds of input from your organization. HR owns the authoritative data on hires, role changes and terminations, which midPoint uses to drive joiners, movers and leavers. System owners confirm which applications hold ePHI, who may request access to them and what each role should allow. Compliance and security leaders make the policy decisions that the Security Rule requires you to document, such as who approves access, how often reviews happen and how fast access must be removed when employment ends. Engineering staff handle directories, networks and credentials for each target system. Ask any implementation partner to list these roles and the decisions they expect you to make before the scope is agreed.
Can our team run midPoint for HIPAA access management without a partner?
It is possible for a team with identity engineering skills, but it requires sustained effort. midPoint is open source under the EUPL-1.2 with no enterprise edition, so there is no license fee to pay. The work lies in connector configuration, role modeling, reconciliation of existing accounts, testing of leaver scenarios and producing evidence for reviews. Evolveum offers paid support subscriptions and professional services, and DeployOpen implements, integrates, hardens and documents self-hosted platforms within your own environment under a fixed scope. Assess your team's experience with directories and provisioning, the number of ePHI systems in scope and your capacity to maintain the platform after go-live.
What drives the cost of open source IGA for HIPAA?
Because midPoint has no license fee, cost comes from people and infrastructure. The main drivers are the number of target systems that need a connector, the complexity of your role model, the amount of data cleanup needed before go-live, and the hosting and database design. Ongoing costs include operations, upgrades and support. Support tiers vary: Evolveum's Product Support subscriptions offer 8x5 next-business-day or 24x7 SLA options, and its Platform Subscriptions add feature development. The Evolveum support page lists no prices, so ask vendors for current figures. For a DeployOpen quote, ask for a written scope that lists each connector, each role family and each cleanup task.
How long does a HIPAA-focused midPoint rollout take?
Duration depends on scope, and no fixed timeline applies to every organization. The biggest variables are the number of ePHI systems, whether HR is the authoritative source with clean data, how many directories must be reconciled and how many roles must be defined from existing access. A narrow scope covering one HR feed and two directories will take far less time than a rollout covering electronic health record roles, clinical applications and third-party systems. Ask any partner for a phased plan with a written scope and milestones, and confirm which systems are included in the first release.
How do midPoint LTS versions affect upgrade planning?
midPoint publishes long-term support releases and feature releases with different support windows, so the version you choose sets your upgrade cadence. According to the midPoint releases page, 4.8 (Curie) is a long-term support release supported until October 17, 2028, while 4.10 (Braille) is a feature release supported until November 26, 2027, and 4.9 support ends October 18, 2026. Plan upgrades before a version leaves support, test connector behavior and role mappings in a non-production environment, and document each change for your change records. Confirm the Java and PostgreSQL requirements for the target release before scheduling the upgrade.
Which midPoint systems are needed to support termination procedures?
Termination procedures require that access to ePHI ends when a workforce member's employment or other arrangement ends. midPoint can handle this when HR sends a termination event and connectors remove or disable accounts in each target system. Your evidence should show the time between the HR event and each removal, and any exceptions. midPoint is an identity management system rather than an SSO server, so pair it with a server such as Keycloak to stop sessions that rely on federated sign-in. Confirm that each target system has a connector or a documented manual step, and test leaver scenarios before go-live.
What tooling alone does not satisfy under HIPAA
midPoint can enforce and evidence access decisions, but the Security Rule also asks for policies, people, contracts and judgment that no software product supplies. The cards below mark the gaps an identity governance project leaves open and the checks to make before go-live.
Written risk analysis and policies
The Security Rule expects a documented risk analysis and written policies for authorizing access to ePHI, granting it and modifying it. midPoint can implement the roles and rules, but the policy defining who may approve which role, and the risk analysis that justifies it, must be written and kept current by your organization. Check that the access authorization policy names owners for each role and that the workflow in midPoint matches the written text.
Workforce security training
Access authorization is only as good as the people approving it. Managers and resource owners who certify access need to understand what they are approving, and workforce members need to know how to report access they should not have. Training records are not produced by midPoint, so plan a separate record for each approver and reviewer and confirm how often training must be refreshed under your own policy.
Business associate agreements
When a vendor hosts, supports or administers a system holding ePHI, the relationship typically requires a written business associate agreement. A partner that deploys or supports midPoint may need access to that environment, so the contract should define what they may see, how their access is provisioned and removed, and how incidents are reported. Ask legal counsel to confirm which parties in your architecture need an agreement.
Pending Security Rule revision
HHS proposed a major Security Rule revision on January 6, 2025 (90 FR 898). As of October 2026 no final rule has been published, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. Track the rulemaking and the proposed changes to access controls, since designs built now may need revision once a final rule issues.
Physical and transmission safeguards
midPoint's access decisions do not secure the workstations, data center rooms or network paths that carry ePHI. The Security Rule requires physical safeguards for facilities and devices, and transmission security for ePHI in motion. Confirm how midPoint, its PostgreSQL database and the connectors to directories and applications are protected in transit and at rest, and who can physically reach the servers that hold these records.
Judgment behind addressable decisions
Access authorization and access establishment and modification are addressable, so your organization must decide whether each is reasonable and appropriate. If it is not, the decision and the equivalent alternative must be documented. A tool does not make that call. Record why automated approval is or is not used for particular roles, and keep those records with the risk analysis so an assessor can follow the reasoning.
What a covered entity must confirm before starting
Before any midPoint design work, the covered entity should confirm which systems hold electronic protected health information, because the access rules in 45 CFR 164.308(a)(4) apply to those systems and to nothing else by default. Build a written inventory of each EHR, billing, scheduling, imaging, file share and reporting system that stores or transmits ePHI, and name the business owner who approves access to each one. Include shared mailboxes, remote access tools and backup consoles, since each can be a path to ePHI. Confirm also whether business associates, such as billing vendors, transcription services or cloud hosts, need their own accounts in your systems or whether they are reached through a named service account, because that decides which identities midPoint must govern and how their access is reviewed.
Next, confirm what the HR system can export and how reliably. Joiner, mover and leaver automation depends on the authoritative source knowing employment status, department, job code, manager and termination date, and on whether contractors, agency staff and residents appear there at all. Ask HR and the EHR administrators for a sample extract and check it for missing manager fields, duplicate records and status values that do not match your access policy. The termination procedure required by 45 CFR 164.308(a)(3)(ii)(C) depends on this data, so a gap in the feed becomes a gap in your evidence. The documentation burden is the reason to settle these questions first. The HIPAA civil money penalty table in 45 CFR 102.3 sets ranges from $145 per violation (no knowledge) to $2,190,294 per violation (uncorrected willful neglect), with a calendar-year cap of $2,190,294, for penalties assessed on or after January 28, 2026. Those figures are the reason to be able to show, for each system, who decided access, when it was changed and when it was removed. For a starting reference, NIST SP 800-66 Rev. 2 is a useful informational guide that maps each Security Rule standard to key activities and sample questions, and HHS does not treat it as legally binding. Use its questions to test your own inventory before a partner scopes the work.
What drives the cost of this implementation
Is midPoint itself a cost for a HIPAA access management program?
midPoint has no license fee and no enterprise edition, because Evolveum publishes every line of its code under open source licenses. The cost sits in the work around it: connector configuration, role modeling, data cleanup, infrastructure to run the platform, and any support subscription you choose. Evolveum funds development through subscriptions, training and professional services, so a support subscription is optional rather than a licensing requirement. Ask any partner to separate software cost, one-time implementation effort and recurring operating cost in the quote.
Which parts of the cost are one-time and which recur?
One-time costs usually include discovery, connector build and testing for each source and target system, role modeling, cleanup of existing accounts, joiner, mover and leaver rule design, and the documented procedures HIPAA expects. Recurring costs include infrastructure hosting, database and backup operations, patching and upgrades, connector maintenance when target applications change, access certification cycles, and support. Ask the quote to show each group separately, so you can see what continues after go-live and who carries it.
How does connector work change the price of a midPoint deployment?
Connector work is often the largest variable, because each target system needs its own account mapping, attribute handling, and testing. midPoint's ConnId framework documents connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, and further connectors with varying support status. Costs rise with the number of EHR, scheduling, billing and clinical applications, with custom APIs, and with connectors marked community or experimental that you may need to harden. Ask which connectors are supported, which are community maintained, and which will be built.
Why does role modeling and data cleanup add so much effort?
Role modeling converts the access that exists today into roles that clinical managers and compliance staff can review. Cleanup removes orphaned accounts, duplicate identities and excess entitlements before the first load, which is where most schedule risk appears in healthcare environments with agency and rotating staff. Effort rises with the number of departments, shared accounts, legacy directories and the quality of the HR data feeding midPoint. Ask the partner how they will profile existing access and how many review rounds the quote assumes.
What infrastructure costs should I expect to pay for?
Infrastructure covers the application servers, a PostgreSQL database on a separate server, load balancing for multi-node deployments, backups, and non-production environments for testing. midPoint recommends Java 21 for version 4.10 and older and Java 25 for 4.11 and later, and it can run on Linux in a virtual machine or from Docker images. Costs depend on whether you host in your own data center, a cloud account you control, or an air-gapped network, and on how many environments you keep. Ask the quote to list each server, its sizing assumptions, and who pays for the cloud or hardware.
Which support subscription levels should I budget for?
Evolveum offers Product Support subscriptions for resolving product bugs, with an 8x5 next-business-day or 24x7 response level, and Platform Subscriptions that add feature development and roadmap influence. The support page lists no prices, so the figure must come from Evolveum directly. Choose the level based on how many hours of coverage your clinical operations need and whether you expect to request features. Confirm the release you will run, because midPoint 4.8 is a long-term support release supported until 17 October 2028, and 4.9 support ends 18 October 2026.
What should I ask for in a quote for this work?
Ask for a written scope that lists each source system, target system and connector, the role model deliverable, the joiner, mover and leaver rules to be built, and the cleanup activities with their volumes. Request a separate line for testing, documentation of access authorization and termination procedures, training for administrators, and handover. Ask which items are fixed scope and which are billed on change requests, what assumptions the timeline depends on, and what recurring support is excluded. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list.
Can our own team run this without an implementation partner?
A capable internal team can run the platform once it is built, but first-time connector work, role design and HIPAA-aligned documentation take experience and sustained time. The main hidden costs of doing it internally are learning the midPoint data model, handling connector upgrades, and keeping evidence current for the Security Rule reviews. Assess your staff against those skills and against the time available before go-live. Ask a partner to price a split model, where they build and hand over, and your team operates it with a retainer for upgrades and testing.
How DeployOpen scopes and delivers HIPAA-scoped identity governance
DeployOpen plans, implements, integrates, hardens, documents and supports midPoint inside your own cloud accounts, data centers or air-gapped networks. The work is fixed-scope, so the written scope sets which HR sources, target systems and joiner, mover and leaver rules the HIPAA access evidence will cover.
How we scope
- Agree in writing which HR sources, clinical and non-clinical systems with ePHI, and connectors are in scope.
- Map each access authorization, access modification and termination step to the Security Rule standard it supports.
- Confirm which addressable specifications you have assessed, implemented or documented as alternatives, and who signs off.
How we build
- Deploy midPoint on infrastructure you control, with PostgreSQL and the Java runtime version matched to your chosen release.
- Configure ConnId connectors, role definitions and termination workflows, then test each leaver path against a non-production copy.
- Run security testing on the deployment and document the configuration, access model and logging for your review.
How we hand over
- Deliver runbooks for provisioning, certification campaigns, emergency deprovisioning and access reviews your staff will run.
- Provide evidence packs that show who approved each access grant, when it changed and when it was removed.
- Walk your compliance and security teams through the records so they can answer assessor and OCR questions directly.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Plan midPoint version upgrades around the release lifecycle and test each change before it reaches production.
- Ask us to refresh connector mappings and access reviews when HR systems, EHR roles or clinical units change.
