How open source identity governance supports PCI DSS requirement 7
Requirement 7 of PCI DSS expects access to cardholder data and the systems around it to be limited by need to know, with that limit visible in records an assessor can examine. Identity governance produces most of that evidence: a documented role model, approvals for privileged access, scheduled review campaigns and the decisions taken in them. The assessor, not the tool, decides whether your environment meets the standard. Your job is to make sure the records exist, are complete and can be reproduced for the assessment period. The requirement is organized around 7.2, which covers the access control model, least-privilege assignment, approval of privileges and reviews, and 7.3, which covers the access control system itself, including deny-all as the default. Requirement 7.2.4 requires a review of all user accounts and privileges, including third-party and vendor accounts, at least every six months. Requirement 7.2.5.1 sets review frequency for application and system accounts through the targeted risk analysis under 12.3.1. Requirement 7.2.6 limits direct queries of stored cardholder data to responsible administrators. PCI DSS v4.0.1 is the only active version, and the PCI Security Standards Council does not enforce compliance; the payment brands decide who must validate.
Confirm three things before you design the model. First, which version and assessment type applies to your entity, using the PCI SSC standard page as the starting point. Second, which accounts count as in scope, including vendor, service and application accounts that a midPoint connector would not see by default. Third, how your assessor will sample the review population. Those answers determine the role catalog, the connector list and the campaign calendar. Ask your QSA or assessor to confirm the evidence format they expect before the first campaign runs.
Which PCI DSS 7 sub-requirements identity governance must cover
This table maps each part of PCI DSS Requirement 7 to what midPoint and the SSO server must do, and what an assessor will look for. Read it as a build checklist: each row names the configuration that satisfies the control and the evidence to keep. The main takeaway is that 7.2.4 reviews and deny-by-default provisioning depend on a role catalog and clean source data, not on the review tool alone.
| Sub-requirement | What midPoint and the SSO server must do | Evidence an assessor expects |
|---|---|---|
| 7.2.1 and 7.2.2 access control model and least privilege | Define a role catalog mapped to job functions, with each role carrying only the entitlements it needs; assign access through roles, not direct grants | Documented access control model, role catalog with owners, and assignment rules tied to job classification |
| 7.2.3 approval of privileges | Route every privileged role or entitlement request through a midPoint approval workflow naming the approver, with the approval recorded before provisioning | Approval records linking each privileged grant to an approver and business reason |
| 7.2.4 six-monthly user access reviews | Run certification campaigns at least every six months covering all user accounts, including third-party and vendor accounts, and remediate revocations in midPoint | Campaign records, reviewer decisions, remediation tickets, and management acknowledgement of results |
| 7.2.5 and 7.2.5.1 application and system accounts | Inventory service and system accounts as their own identity type with owners; set their review frequency from the targeted risk analysis under 12.3.1 | Account inventory, owner assignments, and the targeted risk analysis that sets the review interval |
| 7.2.6 query access to stored cardholder data | Grant direct query rights only to a small administrator role; route other user queries through applications and programmatic roles | Role definitions showing direct query rights limited to responsible administrators |
| 7.3.1 and 7.3.2 access control system scope and job-based permissions | Confirm the access control system (midPoint plus the SSO server and target connectors) covers every in-scope system component and maps permissions to job function | Vendor documentation and configuration exports showing scope and role-to-permission mapping |
| 7.3.3 deny all by default | Configure provisioning so no entitlement exists unless a role or approved request grants it; keep connectors from creating default access | Configuration settings showing default-deny behavior and test results for an unassigned user |
| Orphaned and out-of-band accounts | Reconcile target systems against the identity store on a schedule and flag accounts with no owner for review | Reconciliation reports and the disposition of each orphaned account |
Which open source platforms fit each part of the design
A PCI DSS Requirement 7 design needs an identity governance layer that records who holds which access and why, an authentication layer that enforces who can sign in, and evidence sources that show the access was used. The platforms below each cover one of those jobs, and the choices between them depend on your directories, target systems and scope.
midPoint for governance and approvals
midPoint is the identity governance and administration layer that holds role definitions, approval workflows, certification campaigns and the connectors that provision accounts into target systems. It stores its data in PostgreSQL, which is its native repository database, and its EUPL-1.2 license comes with no enterprise edition, so the license cost is zero while connector work, role modeling and support remain. For Requirement 7.2.4 reviews, confirm that midPoint has connectors for every system in your cardholder data environment, including vendor and third-party accounts.
Keycloak for sign-in and federation
Keycloak is the single sign-on and authentication layer that issues tokens for applications and federates users from Active Directory or LDAP. It is licensed under Apache-2.0, and its current release is 26.8.1. Confirm that your production database is on the supported list, which includes PostgreSQL 14 to 18, and choose one of the documented high availability designs, both of which need a synchronously replicated database.
authentik or ZITADEL as alternatives
authentik (MIT, with an enterprise directory under a separate license) and ZITADEL (AGPL-3.0) cover similar SSO and MFA ground to Keycloak and are worth a comparison if your team already runs one of them. midPoint works with any SSO server through standard protocols, but the pairing must be tested. Check each candidate against your MFA requirements, your database and clustering model, the license of any enterprise features you need, and whether your access reviews require SCIM or a supported midPoint connector.
Wazuh or Security Onion for access logs
Requirement 7 is easier to defend when access decisions and their use can be seen in one place. Wazuh (GPL-2.0 core) and Security Onion (Elastic License 2.0) can collect authentication logs from directories, SSO servers and operating systems, and alert on changes to privileged groups. They do not decide who should have access, so treat them as evidence sources for review outcomes and anomaly checks. Confirm that the log sources you need can be forwarded to them.
Release planning and upgrade path
midPoint 4.8 (Curie) is the long-term support release, supported until 17 October 2028, and midPoint 4.10 is a feature release supported until 26 November 2027. A PCI DSS review cycle lasts years, so plan the midPoint and Keycloak upgrade path against these support windows. Confirm the Java version each release requires, since midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older.
How the identity layers meet the access control system requirements
Requirements 7.3.1 to 7.3.3 ask for an access control system that covers all system components, enforces permissions assigned by job classification and function, and is set to deny all by default. For a midPoint-based program, the assessor will not accept midPoint alone as that system. Evolveum states that midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. So the access control system is the combination of midPoint (which decides who should hold which entitlement), the SSO server that authenticates and issues tokens, and the permission models inside each target system that enforce those entitlements. Document this chain explicitly in the scope statement, and confirm which component is the system of record for each cardholder data environment (CDE) application.
The SSC's expected testing for these sub-requirements is to examine vendor documentation and configuration settings of the access control system. Expect the assessor to ask for the product documentation for midPoint, the SSO server (for example, Keycloak, whose supported versions and production configuration are documented on its own site), and each CDE target system, plus exported configuration showing that the default posture is deny. Confirm with each vendor which settings govern default-deny behavior and where they are recorded, such as a realm or client policy, a connector mapping that grants no entitlement without an approved assignment, or a target application's default role. Keep the exported configuration under version control so the state at assessment time can be shown.
For each target system in the CDE, prove four things: the system is in the access control scope, its permissions are mapped to roles defined by job function, unassigned identities receive no access, and the midPoint connector and target-side settings agree. A practical check is to take a sample of accounts in the target system and trace each entitlement back to an approved midPoint assignment or a documented break-glass exception. Any account that exists in the target but not in midPoint is a finding to resolve before assessment. Consider which systems cannot be configured by midPoint at all, such as local operating system or database accounts, and record how those are governed under the Requirement 7.2.5.1 review instead of leaving them out of scope.
What the QSA asks for and which component produces it
This table maps the evidence a Qualified Security Assessor is likely to request for Requirement 7 to the component that produces it, whether midPoint, a connector, Keycloak, a log platform or the entity's ticketing system. Read each row as a question to confirm with your QSA before you design the evidence trail, since the accepted format and sampling method are assessor decisions.
| Evidence item | Requirement reference | Producing component | Confirm with the QSA |
|---|---|---|---|
| Approved role catalog with job-function definitions | 7.2.1, 7.2.2, 7.3.2 | midPoint role and organization objects, exported with the approval history | Whether a versioned export or a screenshot of the role catalog is accepted |
| Approval records for each privilege grant | 7.2.3 | midPoint access request and approval workflow records, linked to the ticketing system where approvals happen outside midPoint | Which approver roles the assessor expects and how out-of-band approvals are linked |
| Six-monthly certification campaign results with management acknowledgment | 7.2.4 | midPoint certification campaign reports, plus a signed or recorded management acknowledgment kept with the campaign | The sample period, the acknowledgment format and how removals are shown as addressed |
| Entitlement pulls from target systems used in reviews | 7.2.4 | ConnId connectors (LDAP, Active Directory, database or SCIM) that read live target account data | Whether the assessor needs proof of the connector read covering third-party and vendor accounts |
| Review records for application and system accounts | 7.2.5, 7.2.5.1 | midPoint certification campaigns for service accounts, with the review frequency taken from the targeted risk analysis | Whether the targeted risk analysis under 12.3.1 is accepted as the frequency source |
| Deny-by-default configuration exports | 7.3.1, 7.3.3 | Keycloak realm and authorization configuration exports, and midPoint policy settings | Whether vendor documentation plus configuration screenshots or exports are the expected testing evidence |
| Query access lists for stored cardholder data repositories | 7.2.6 | Database account and role listings from the connector, with ticket references for direct query rights held by administrators | How direct query rights are shown and whether application-only access is evidenced by configuration |
| Log of changes to privileged access | 7.2.3, 7.2.4 | Security log platform or midPoint audit records of grants and removals, retained for the period the assessor samples | Retention length and format the assessor will sample from |
What identity tooling alone does not satisfy
midPoint and a connected SSO server can produce the account inventory, approvals and review records that Requirement 7 depends on, but they do not decide the access model, the risk analysis or the assessment outcome. The cards below cover the controls that sit outside the identity platform and the people who must own them.
Targeted risk analysis for account reviews
Requirement 7.2.5.1 leaves the review frequency for application and system accounts to a targeted risk analysis under Requirement 12.3.1, so the platform cannot pick that cadence for you. Ask who writes the analysis, which accounts it covers, and how its result is written into the midPoint review schedule. Confirm that the frequency in the analysis matches what the campaigns actually run.
Defined or customized approach decision
Each requirement is met either through the defined approach or, for entities with robust risk management, the customized approach, which achieves the stated objective in a different way. A customized design needs documented evidence that the objective is met, and that decision is made before the identity design is fixed. Record which approach applies to each requirement so the assessor sees the choice and its rationale.
Documented policy and procedures
Role definitions, approval rules for privileges and the six-monthly review procedure must exist as written policy that staff follow, not only as configuration in midPoint. Assessors compare the documents with what the system did in the period under review. Check that the access control policy names the owners of each role, the approvers, and the steps for acting on inappropriate access found in a review.
Third-party and vendor account inventory
Requirement 7.2.4 covers vendor and third-party accounts as well as employee accounts, and vendor accounts are often created outside HR-driven sources. Build an inventory of these accounts, with the sponsoring internal owner for each, before the first review. Ask whether vendor accounts in directories and applications can be matched to a contract or sponsor, and who signs off the six-monthly result.
Manual systems outside connectors
Systems without a supported ConnId connector, such as legacy applications, mainframes, terminal servers and shared admin consoles, still need accounts reviewed. Either a connector is built and tested, or a documented manual process produces the same population, approval and removal evidence. Confirm which in-scope systems have no connector and who runs the manual reviews on a fixed schedule.
Cardholder data repository query controls
Requirement 7.2.6 limits direct queries of stored cardholder data repositories to responsible administrators, and everyone else must go through applications or programmatic methods based on role. A midPoint role that grants database access is not enough on its own. Check the database roles, query tools and reporting paths, and confirm that they are included in the review population.
ROC or SAQ with AOC
Assessment is documented on a Report on Compliance completed by a Qualified Security Assessor, or on a Self-Assessment Questionnaire, each with an Attestation of Compliance. Only the QSA or the entity signs these documents, and the identity platform does not produce them. Certificates are not recognized as validation, so do not rely on a vendor or implementation certificate in the assessment file. Ask your QSA or acquirer which document applies to your entity.
What buyers ask before hiring help with PCI DSS identity governance
What drives the cost of an open source identity governance project for PCI DSS?
Cost is driven by the work around the software, not by a license fee, because midPoint is published under the EUPL-1.2 with no enterprise edition, according to Evolveum. The main components are connector work (one for each target system such as Active Directory, LDAP, Microsoft Entra ID or a database), role modeling from existing entitlements, cleanup of orphaned and excess accounts, infrastructure for the midPoint and PostgreSQL servers, and ongoing support. Connector count and role complexity are the largest variables. Ask any partner for a fixed-scope quote that lists each connector, each role family, the cleanup scope and the support terms separately, and identify which items are one-time and which recur.
How long does a PCI DSS identity governance implementation take?
The timeline depends on how many systems hold cardholder data environment accounts, how clean the existing directories are, and how many sources of truth feed provisioning. No duration is set in this page's research, so treat any number a vendor gives as a claim to test. Ask for a written phase plan covering role definition, connector build, data cleanup, a pilot review cycle and the first documented six-month review. Agree in writing what the client must deliver in each phase, because delays most often come from late data access rather than from the software.
What does the client need to provide for the engagement?
The client must supply three groups of people and access. HR data owners provide the authoritative joiner, mover and leaver feed. Application owners confirm which roles and privileges exist in each system and who may approve them. Security and compliance staff set the review cadence and sign off on evidence. Engineers need service accounts and read access to directories and target systems, and the QSA or internal assessor should be consulted early on the evidence format they expect. Confirm these commitments, named individuals and their available hours before work starts.
Can our team run PCI DSS identity governance without a partner?
Yes, if your team has the skills to model roles, operate Java and PostgreSQL services and build or maintain ConnId connectors. midPoint is open source and its documentation covers installation, connectors and system requirements. The harder parts for most teams are the role model, the approval design and producing review evidence that an assessor can re-perform. Consider a partner for the first implementation and knowledge transfer, then decide whether to keep support in-house. Evolveum also sells support subscriptions with an 8x5 next-business-day or 24x7 SLA, which is a separate purchase from implementation work.
Which 7.2.4 review cycle should we run for user accounts?
Requirement 7.2.4 requires all user accounts and privileges, including third-party and vendor accounts, to be reviewed at least once every six months, and it has been mandatory since 31 March 2025. Plan a formal review every six months at minimum, covering every account in scope. Use the same cycle to address inappropriate access and to record management's acknowledgment of the results. Review frequency for application and system accounts under Requirement 7.2.5.1 is different: it is set in a targeted risk analysis under Requirement 12.3.1, so document that analysis and its chosen interval separately.
How would a PCI DSS v4.0.1 update or a future version change our work?
PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision with no added or deleted requirements, and v4.0 was retired on 31 December 2024. The PCI SSC ran a request for comments from 3 June to 20 July 2026 for the next iteration, and as of October 2026 it had announced no release date. Ask your partner to map each control to its requirement number so that wording changes can be traced to a specific control, and to keep a change log for role definitions and review evidence. Do not assume a future version will leave Requirement 7 unchanged until the SSC publishes it.
Who decides whether we must validate PCI DSS, and what evidence does an assessor expect?
The PCI SSC does not enforce compliance. The individual payment brands decide which entities must validate and run any enforcement programs. Validation is documented on PCI SSC templates, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance. Certificates are not recognized as validation. For Requirements 7.3.1 to 7.3.3, the expected testing is to examine vendor documentation and access control system configuration, so keep the configuration exports and documentation alongside review records. DeployOpen prepares systems, controls and evidence for assessments but does not issue reports or attestations.
What should we ask a partner before signing a PCI DSS identity governance scope?
Ask how the partner will define roles that map to Requirement 7.3.2 job classification, and how approvals for privileges under Requirement 7.2.3 will be recorded. Ask which midPoint connectors they have already deployed and how they will handle orphaned accounts before go-live. Ask how the six-monthly review and the 7.2.5.1 review will be run and evidenced, and how they will test the deny-all default under Requirement 7.3.3. Request named engineers, a written list of client dependencies and a statement of what is excluded from scope.
What to confirm with your QSA and payment brand before building
Before you design the identity governance workflows for Requirement 7, confirm who decides what counts as validation. The PCI SSC does not enforce compliance. The individual payment brands decide which entities must validate and run any enforcement programs, so your acquirer or the relevant brand should confirm your validation level and reporting route. Your Qualified Security Assessor (QSA) or self-assessment scope then determines which systems, accounts and access paths must appear in the evidence. Ask both parties to agree the cardholder data environment boundary in writing before you model roles, because a wider boundary means more connectors, more accounts and more reviews.
Next, decide with your QSA whether you will meet the requirements through the defined approach or the customized approach. The customized approach is available only to entities with robust security and risk management, and it requires a different evidence set, including a documented description of how the stated objective is met. Also confirm which PCI SSC template applies, either a Report on Compliance completed by a QSA or a Self-Assessment Questionnaire with its Attestation of Compliance, since the evidence you collect for Requirement 7.2.4 reviews differs between them. For Requirement 7.2.5.1, agree with your QSA how the risk analysis under Requirement 12.3.1 will set the review frequency for application and system accounts, and which accounts are in that population. Start with the PCI DSS standard page and the current SAQ templates on the same site to check the wording against your environment.
How a PCI DSS 7 identity program is rolled out
The sequence moves from defining which systems are in scope to handing an assessor a set of role definitions, approvals, access reviews and remediation records that show need-to-know access is enforced and checked. Each step closes with a artifact that the next step depends on.
Scope the cardholder data environment
Start by mapping every system that stores, processes or transmits cardholder data, plus any system that could affect its security, such as directories, jump hosts and administrative consoles. The QSA or internal assessor, the security lead and the system owners sign off on the boundary. Done means a documented scope statement and a system list that every later step references, so no account is reviewed against an incomplete population.
Inventory user, vendor and system accounts
Pull account lists from each in-scope system, including local accounts, service accounts and third-party and vendor accounts, and match them to a named owner or an accountable team. Identity engineers load the authoritative HR and vendor-management sources into midPoint and flag accounts with no owner. Done means a reconciled inventory that shows every account, its owner and its target system, which is the population Requirement 7.2.4 and 7.2.5.1 reviews will test.
Define roles and approval rules
Document the access control model, then translate job functions into roles that grant only the entitlements each function needs. Security, application owners and business managers agree which privileges need a second approver and which can be granted by a manager. Done means an approved role catalog and an approval matrix in midPoint, each role traceable to a written business justification, which supports the least-privilege and privilege-approval expectations of Requirement 7.2.
Connect target systems through connectors
Configure midPoint connectors for the directories and applications in scope, and set up the sync direction for each one so that changes flow through the approved roles rather than by hand. The engineering team tests reads and writes against non-production copies first. Done means each connector passes a documented reconciliation run, with its results and any mapping exceptions recorded for the assessor.
Clean up orphaned and excess access
Compare the reconciled entitlements with the approved roles and remove accounts without an owner, dormant accounts and privileges that exceed the role definition. Where removal is not immediate, record a documented exception with an owner and a decision date. Done means an exceptions log that shows each finding, the action taken and who approved it, so the first review starts from a known baseline.
Run the first six-monthly access certification
Launch a certification campaign that covers all user accounts and privileges, including third-party and vendor accounts, and route each item to the responsible manager or owner. Reviewers keep, modify or revoke access, and the platform records each decision and the reason. Done means completed decisions for every item, revocations carried out in the target systems, and a management acknowledgment of the results, which is the evidence Requirement 7.2.4 asks for.
Run application and system account reviews
Using the review frequency set in the targeted risk analysis under Requirement 12.3.1, review application and system account access, including the privileges of service accounts and access to repositories of stored cardholder data. Confirm that direct queries are limited to responsible administrators. Done means a dated review record for each account group, with the risk analysis that sets its frequency attached, which addresses Requirements 7.2.5.1 and 7.2.6.
Hand evidence to the assessor
Assemble the scope statement, role catalog, approval records, connector configurations, certification results, exception logs and management acknowledgments into one evidence folder mapped to each sub-requirement. Confirm with your QSA or assessor which samples they will draw and in what format they want records. Done means an evidence index that lets the assessor re-perform the review from source data. The assessor, not DeployOpen or midPoint, decides whether the controls satisfy the standard.
How DeployOpen scopes, delivers and supports PCI DSS identity controls
DeployOpen is a Chainscore Labs company that plans, builds and runs self-hosted open source identity platforms inside your own environment. The cards below cover how an engagement is scoped, how the evidence is prepared for your assessor, and how the platform is kept supported after go-live.
Scoping the cardholder environment
Before design starts, the team agrees which systems fall inside the cardholder data environment, which directories and HR sources feed midPoint, and which applications and service accounts need review under Requirement 7.2.5.1. A written scope fixes these boundaries, so the quote reflects the actual number of connectors, roles and target systems. Ask your QSA or internal assessor to confirm the scope before work begins.
Role model and approval design
DeployOpen builds the role definitions, approval paths and deny-by-default access model that Requirements 7.2 and 7.3 expect, then configures midPoint to enforce them. Each role is tied to a documented job function and an owner who approves privileges. Ask for the role catalog and approval matrix as deliverables so your assessor can examine them directly.
Hardening and platform operations
The midPoint platform, its PostgreSQL repository and any SSO layer such as Keycloak are installed, hardened and documented in your infrastructure, whether cloud, data center or air-gapped. Configuration baselines, access to the admin interface and backup procedures are written down as part of delivery. Confirm which hosting model and change control your organization requires before scoping.
Evidence for six-monthly reviews
DeployOpen prepares the records that show each six-month review of user accounts and privileges, including campaign scope, reviewer decisions, remediation of inappropriate access and management acknowledgment. The goal is evidence an assessor can re-perform, not a report. DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certificates, so ask who on your side signs the assessment.
Fixed-scope agreements and quotes
Most engagements run under fixed-scope agreements with scope, deliverables and timelines agreed in writing before work starts. A quote follows from that written scope, so the scope document is the main lever on cost. DeployOpen does not publish a price list. Ask for the quote to separate design, connector work, data cleanup and testing, and to state any assumptions about your source systems.
Retainers for ongoing support
After go-live, the platform still needs upgrades, connector maintenance, review campaigns and evidence refreshes. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, which keep these recurring tasks from falling to a single administrator. Ask how upgrade windows are planned against the midPoint release cycle and which support tier covers production incidents.
