Key Takeaways:
- Access certification confirms whether a user's access is appropriate for their role. It does not confirm whether customers whose data sits in those systems have consented to the processing being performed.
- For regulated enterprises running separate IGA and CIAM platforms, this is an architectural gap that cannot be closed by improving the certification process.
- The gap surfaces most visibly during GDPR accountability audits, financial services examinations, and within the certification campaign itself when reviewers have no visibility into consent state.
- A converged platform where consent governance and workforce access governance operate on the same policy engine eliminates the need for manual reconstruction by producing the cross-domain audit trail natively.
The access certification campaign closed on schedule. Every access right was reviewed. Managers completed their attestations. The evidence package is audit-ready.
Then the examiner asks a question the campaign was never designed to answer.
For the analysts in your customer data team, have the customers whose records they can access consented to that internal processing?
The IT governance lead pulls the certification records. The most recent campaign is documented and current. Access was reviewed, validated against business need, and recertified where appropriate. But what the certification record shows is whether each analyst's access is appropriate for their role. It does not show whether the customers whose data sits in those systems have consented to internal data processing by those analysts. This is the access certification consent governance gap: two different questions, one of which the campaign answered, and one of which nobody has answered.
This is not an uncommon scenario. It is, increasingly, the scenario that surfaces when financial services examiners and GDPR supervisory authorities turn their attention to customer data access governance. And for regulated enterprises running separate IGA and CIAM platforms, it is a gap that cannot be closed by improving the certification process. The gap is architectural.
What Access Certification Does, and What It Does Not
Access certification confirms whether a user's access is appropriate for their role. It cannot confirm whether customers whose data that user can access have consented to the processing being performed.
Access certification is a governance discipline with a clear and well-established scope. It ensures that access rights are periodically reviewed, validated against current business need, and revoked when no longer appropriate. Executed well, it answers a specific question: does this user's role still justify their current access to this system?
This is a critical control. It prevents privilege creep, surfaces orphaned and over-permissioned accounts, and provides the documented evidence trail that regulators and auditors expect to see when they review an organization's access control framework.
For most enterprise applications, this scope is sufficient. When a certification reviewer is validating access to an HR system, a financial reporting platform, or an internal operational tool, the question of whether access is appropriate for the role is the right question to ask. There is no customer whose consent is at stake.
For applications containing customer personal data, a second question exists that the access certification process cannot answer: are the data subjects whose records this user can access currently consented to that processing under the applicable legal basis?
This question is not a natural extension of access certification. It requires visibility into consent state, which lives in the CIAM layer, not the IGA layer. An access certification reviewer approving an analyst's access to a customer behavioral data repository can confirm that the access aligns with the analyst's role. They cannot confirm from within the IGA workflow whether the customers in that repository have consented to the specific processing purpose the analyst's team is performing. The certification process has no mechanism to surface that information, because the consent records exist in a different system with a different data model.
For enterprise applications that do not contain customer personal data, this limitation is irrelevant. For regulated enterprises in financial services, insurance, healthcare, and government managing customer data under GDPR, DPDP, or comparable frameworks, it is a compliance gap built into the architecture of how identity governance and customer identity management are operated.
The Three Ways the Gap Surfaces Under Examination
The access certification consent governance gap does not announce itself during normal operations. It surfaces under examination when the cross-domain question is asked and the cross-domain answer cannot be produced.
Three scenarios recur with particular regularity.
The GDPR accountability audit
A supervisory authority conducts a review of the organization's Records of Processing Activities. They identify internal analytics processing of customer personal data and request evidence that the processing is consent-authorized under GDPR Article 5(2).
The access certification records demonstrate that internal access to the customer database is governed, reviewed, and current. The CIAM consent records demonstrate that customers have provided consent for specified purposes. What neither document shows is whether any specific analyst access event involved data that was within the scope of valid customer consent at the moment of access. The IGA records and the CIAM records exist in parallel, not in integration. Correlating them to answer the specific question the supervisory authority is asking requires manual reconstruction across two systems that were not designed to produce a joint answer.
Under GDPR Article 5(2), the accountability principle requires the organization to be able to demonstrate compliance with the data processing principles. The inability to produce evidence of consent-authorized access at the event level is not a documentation gap. It is an accountability finding.
The financial services examination
An OCC examiner or PRA supervisor reviews customer data access controls as part of an IT general controls assessment. The access certification campaign is documented, current, and executed against a defined methodology. The examiner acknowledges the program.
Then the question shifts. The examiner asks how the organization ensures that data accessed by internal users falls within the scope of customer consent granted at account opening or updated subsequently. The governance team can demonstrate that access is reviewed and appropriate for role. They cannot demonstrate, from the IGA records alone, that access events were evaluated against current consent state at the time they occurred. The consent records are in the CIAM platform. The access records are in the IGA platform. No system holds the cross-domain answer.
For financial services organizations subject to OCC, FFIEC, or PRA oversight, the expectation that customer data access is governed within the scope of customer consent is not new. What has changed is the specificity with which examiners are asking for evidence that the governance controls actually enforce this rather than describe it.
The certification campaign itself
A reviewer is completing an access certification for an analyst on a product development team. The analyst has access to a customer behavioral data repository used for product analytics. The reviewer confirms that the access is appropriate for the analyst's role and function. The certification passes.
The customers whose behavioral data the analyst can query consented to data processing for account servicing purposes. The consent record in the CIAM platform does not include product development analytics as an authorized processing purpose. The IGA platform has no visibility into this. The certification workflow presented the reviewer with the access right, the role justification, and the option to certify or revoke. It did not present the consent scope of the data being accessed, because that information lives in a system the IGA platform has no connection to.
The certification is complete. The compliance violation continues. The next audit is when the organization finds out.
Why Separate Platforms Cannot Resolve This
The consent dimension is absent from IGA workflows not because IGA vendors have overlooked it, but because it requires information that IGA platforms were not designed to hold or evaluate.
IGA platforms are built around identities, roles, and entitlements. They know who has access to what systems, whether that access is appropriate for the user's role, and when access was last reviewed. This is the complete scope of what access certification requires when the certification is operating within the workforce identity domain.
Customer consent state is a CIAM concern. It lives in the customer identity platform, structured around data subjects, processing purposes, consent timestamps, and revocation events. It is a different data model serving a different governance function.
When these platforms are separate systems from separate vendors, there is no native mechanism through which the access certification reviewer can see, within the IGA workflow, whether the access being certified is consent-authorized. An integration can be built to read consent records from the CIAM platform and surface them in the IGA workflow as a reference. But this integration produces a read-only view, not an enforced control. It adds implementation complexity, requires ongoing maintenance as both platforms evolve, and does not change the fundamental architecture: the authorization decision at the moment of access is evaluated against role entitlement only. Consent state is not a policy condition at authorization. It is a record that sits in a different system and must be correlated manually when an examiner asks.
Building a cross-platform integration is addressing the symptom. The underlying issue is that the governance architecture was not designed with the consent dimension of customer data access in scope from the start.
What a Converged Platform Changes
A converged platform eliminates the consent governance gap by making consent state a policy condition at the authorization layer, producing the cross-domain audit trail natively rather than requiring manual reconstruction.
When customer consent governance and workforce access governance operate on the same policy engine rather than on separate platforms from separate vendors, the structure of the gap changes.
In a converged platform, consent constraints defined in the CIAM layer are visible to and enforceable by the IGA layer. An access certification reviewer working through a campaign that includes access to customer personal data can see, within the certification workflow, whether the access being certified falls within the scope of current customer consent. Access to customer data that exceeds the consent scope applicable to the data being accessed can be flagged during the certification cycle, not discovered afterward during an audit.
More significantly, the authorization decision at the moment of access evaluates both the user's role entitlement and the applicable consent state. This is the difference between a governance record that describes intended policy and a governance architecture that enforces it. When both evaluations happen at the authorization layer and are recorded in a single audit trail, the cross-domain answer that examiners and supervisory authorities ask for exists natively in the system rather than requiring manual reconstruction across two separate record sets.
This does not require replacing all existing IGA or CIAM tooling. It requires that the platform governing the intersection between internal access and customer data, specifically the authorization decisions and audit trail for access to customer personal data, operates from a single policy engine where consent is a first-class governance input rather than a separate concern managed elsewhere.
The Self-Assessment Worth Running Before the Next Campaign
One diagnostic test identifies whether the consent dimension is present or absent from the certification process before the next campaign begins.
Pick any access right in the campaign scope that grants a user access to customer personal data. Ask: within the certification workflow, is there a mechanism that shows whether that access is within the scope of current customer consent for the processing being performed?
If the answer is no, the consent dimension of the organization's access governance is outside the certification process. The campaign will certify who has access. It will not certify whether that access is consent-authorized. For regulated enterprises operating under GDPR, India's DPDP Act (Digital Personal Data Protection Act, 2023), or financial services supervision, that gap is not a future risk. It is a finding that exists now, waiting for the audit cycle that surfaces it.
OpenIAM's approach to closing this gap, including how a converged platform enforces consent as a policy condition at authorization and produces the cross-domain audit trail, is covered in detail on the Governance and Consent in CIAM page. For financial services organizations evaluating how this applies within their specific examination context, CIAM for Financial Services covers the sector-specific consent governance requirements in detail.
Frequently Asked Questions
What is the difference between IGA and CIAM consent governance?
IGA governs internal user access to systems, confirming whether access is appropriate for a user's role and when it was last reviewed. CIAM consent governance manages customer consent state, determining whether current consent authorizes a specific data use. When these platforms are separate, neither can produce the cross-domain answer that connects them: was this access event within the scope of valid customer consent at the time it occurred?
Does access certification cover customer consent authorization?
No. Access certification confirms that a user's access rights are appropriate for their role and business need. It does not confirm whether the data subjects whose records the user can access have consented to the specific processing being performed. For regulated enterprises managing customer data under GDPR, DPDP, or comparable frameworks, this is a compliance gap that access certification cannot close without visibility into consent state from the CIAM layer.
Why can IGA platforms not enforce customer consent?
IGA platforms evaluate access rights against role requirements and business need, which is the complete scope they were designed for. Customer consent state is a CIAM concern structured around data subjects, processing purposes, and consent events, and IGA platforms were not built to hold or evaluate it. When these platforms are separate, consent state is not a policy input at the authorization layer unless they are converged on a shared policy engine.
What do auditors ask about customer data access consent?
Auditors increasingly ask whether internal access to customer personal data was within the scope of customer consent at the time the access occurred. When IGA and CIAM systems are separate, producing this answer requires manual reconstruction across two record sets. When they operate on a converged platform, the cross-domain audit trail exists natively and can be produced without reconstruction.