Category: Governance & Compliance

Compliance Reporting

Also known as: compliance report

Simply put

Compliance reporting is the process of creating documents that show an organization is following the rules it must obey, such as government regulations, industry standards, and its own internal policies. These reports gather evidence to demonstrate adherence and can be used to disclose activities that may violate those requirements. In an identity and access context, they typically help prove that access to systems and data is being managed according to applicable standards.

Formal definition

Compliance reporting is the formal, often recurring, process of identifying, documenting, and disclosing an organization's adherence to regulatory requirements, industry standards, and internal policies, producing artifacts that verify whether an entity meets required controls. Within IGA, compliance reporting typically draws on governance activities such as provisioning records, access reviews and certifications, and segregation-of-duties evaluations to evidence that entitlements are appropriate and controlled; the specific standards, frameworks, and report formats vary by regulatory context and deployment. This is a governance and administration concern focused on demonstrating adherence over time and is distinct from runtime access enforcement mechanisms (for example PDP/PEP decisioning or token validation), which are out of scope for this term.

Why it matters

Organizations operating identity and access systems are subject to a range of external regulations, industry standards, and internal policies that require them to demonstrate that access to systems and data is appropriately controlled. Compliance reporting is the mechanism by which an organization produces concrete evidence of that adherence, transforming otherwise scattered governance activity into formal artifacts that can be presented to auditors, regulators, and internal stakeholders. Without such reporting, an organization may be following its access controls in practice but be unable to prove it when challenged.

In an IGA context, compliance reporting matters because access-related risk accumulates quietly over time: entitlements drift, users accumulate permissions across role changes, and segregation-of-duties conflicts can emerge unnoticed. Recurring reports that draw on provisioning records, access reviews and certifications, and segregation-of-duties evaluations give an organization a documented basis to show that entitlements remain appropriate and controlled. This evidentiary function is especially important in regulated sectors such as healthcare, where compliance reporting is a formal process of identifying, documenting, and disclosing activities that may violate applicable requirements.

It is worth being precise about scope. Compliance reporting demonstrates adherence over time; it does not itself enforce access at runtime. The specific standards, frameworks, and report formats vary considerably by regulatory context and deployment, so a report that satisfies one framework may not satisfy another. Treating compliance reporting as a substitute for effective runtime enforcement, or assuming a single report format is universally sufficient, would misstate its role.

Who it's relevant to

Compliance Officers

Compliance officers own the process of identifying applicable regulatory requirements, industry standards, and internal policies and producing the formal reports that disclose the organization's adherence. They rely on compliance reporting to assemble evidence and, where applicable, to disclose activities that may violate requirements.

Identity Governance Leads

Those responsible for IGA depend on compliance reporting to demonstrate that entitlements are appropriate and controlled over time. They ensure that governance activities, provisioning records, access reviews and certifications, and segregation-of-duties evaluations, generate the artifacts that reporting draws upon.

Auditors and Assessors

Internal and external auditors use compliance reports as the documented basis for verifying whether the organization meets required standards, regulations, or guidelines. Because report content and formats vary by framework, auditors assess whether the produced evidence maps to the specific requirements in scope.

Security Architects and IAM Engineers

Architects and engineers design and operate the identity and access systems whose governance outputs feed compliance reporting. They are responsible for ensuring that provisioning, review, and segregation-of-duties data is captured in a form suitable as evidence, while recognizing that reporting is distinct from the runtime enforcement they also build.

Inside Compliance Reporting

Access Certification Records

Documentation of periodic access reviews, typically produced by IGA processes, showing who reviewed which entitlements, the outcome (approved, revoked, or flagged), and the reviewer's attestation. These records demonstrate that access rights were validated against business need.

Segregation of Duties (SoD) Evidence

Reports identifying toxic entitlement combinations and confirming that conflicting privileges are not held by the same principal, or that documented mitigating controls exist. This is an IGA governance concern rather than a runtime enforcement one.

Provisioning and Deprovisioning Logs

Records of identity lifecycle events, account creation, modification, and removal, often sourced from provisioning connectors or SCIM operations, used to evidence timely access changes for joiners, movers, and leavers.

Authentication and Access Event Logs

Runtime audit trails capturing authentication attempts and authorization decisions. Depending on configuration, these may originate from PDP/PEP enforcement points, identity providers, and directory or token validation events, and are typically distinct from lifecycle governance data.

Policy and Entitlement Snapshots

Point-in-time captures of role assignments (RBAC), attribute or policy definitions (ABAC/PBAC), and effective entitlements, used to show what access configuration existed at a given moment for a control period.

Control Mapping to Frameworks

Cross-references linking identity data to specific control objectives or regulatory requirements, allowing auditors to trace a control to its supporting evidence. The applicable frameworks depend on the organization's regulatory scope.

Common questions

Answers to the questions practitioners most commonly ask about Compliance Reporting.

Is compliance reporting the same as running access certifications?

No. Access certifications (or reviews) are an identity governance and administration (IGA) activity in which reviewers attest that a principal's access is still appropriate. Compliance reporting is the broader practice of producing evidence, which may include certification results, but also provisioning history, segregation-of-duties violations, and policy exceptions, to demonstrate control effectiveness to auditors or regulators. Certifications typically feed compliance reports, but the report itself is the evidence artifact, not the review activity that generates part of it.

Does compliance reporting enforce access controls or prevent violations in real time?

Generally no. Compliance reporting is an after-the-fact, evidence-oriented governance concern; it documents what access existed, who approved it, and where policy was violated. Runtime enforcement, decisions made by a policy decision point (PDP) and applied by a policy enforcement point (PEP), or token validation at access time, is a separate concern. A report may reveal that a segregation-of-duties conflict occurred, but preventing that access at request time is the job of enforcement components, not the reporting layer. In most deployments the two are complementary rather than interchangeable.

What data sources are typically needed to produce IAM compliance reports?

Depending on the environment, reports usually draw on directory data (for example LDAP or an identity store), provisioning and deprovisioning records, SCIM or connector-based account changes, access certification outcomes, segregation-of-duties conflict findings, and access request approval trails. Many deployments also incorporate authentication and authorization logs. Because sources vary by vendor and architecture, part of implementation is normalizing these into a consistent schema so a report can correlate an account, its owner, its entitlements, and the approvals behind them.

How should reports distinguish between provisioned access and access actually used?

These are different signals and typically come from different systems. Provisioned (granted) access reflects entitlements recorded in IGA and directory sources, while used access reflects runtime authentication and authorization events from application or enforcement logs. Correlating the two can support least-privilege analysis, for example flagging entitlements that were never exercised, but doing so depends on the availability and retention of usage telemetry, which varies by deployment. Reports should label each clearly rather than presenting granted access as evidence of use.

How can segregation-of-duties (SoD) violations be represented in a compliance report?

SoD reporting typically requires a defined set of conflicting entitlement or role combinations, then an evaluation of principals against those rules. A report generally lists detected conflicts, the affected identities, the entitlements involved, and any documented exceptions or mitigating controls with their approvers. Because SoD rules are policy definitions maintained in IGA, the accuracy of the report depends on how completely those rules are modeled; gaps in the ruleset can leave conflicts undetected, so scope and rule coverage should be stated in the report.

What supports the integrity and auditability of compliance reports themselves?

Auditors typically expect that report contents can be traced to underlying records and that those records were not altered. In practice this involves reliable, time-stamped source logs, clear data lineage from source to report, and retention aligned to the applicable requirement. Note that report integrity depends on the trustworthiness of the source data and its handling; a signed or exported report attests to its contents at a point in time but does not by itself validate the accuracy of the systems that produced the underlying entries. Specific integrity mechanisms vary by tooling and configuration.

Common misconceptions

Compliance reporting is primarily a runtime access enforcement function.

Most compliance reporting draws heavily on IGA concerns, provisioning history, access certifications, and SoD analysis, which are governance and lifecycle activities. Runtime enforcement data such as PDP/PEP decisions and token validation is complementary but distinct, and blending the two can obscure what a given report actually evidences.

A successful access certification proves that access was correctly authorized at runtime.

Certification attests that an entitlement was reviewed and deemed appropriate at review time; it does not by itself demonstrate how authorization decisions were enforced during actual access. Runtime authorization evidence typically comes from separate enforcement and audit logs.

Signed audit records and tokens included in reports guarantee the data is confidential.

Signing provides integrity and origin assurance but not confidentiality. A signed JWT or log entry is not encrypted unless additional measures are applied, so sensitive attributes in compliance evidence may still require separate protection depending on configuration.

Best practices

Separate governance evidence (provisioning, access reviews, certifications, SoD) from runtime enforcement evidence (authentication events, authorization decisions, token validation) so each report clearly states what it demonstrates.

Map each report to the specific control objectives or regulatory requirements it supports, and document which data source satisfies each control to enable auditor traceability.

Capture point-in-time snapshots of role assignments and policy definitions for each reporting period, since effective entitlements can change and after-the-fact reconstruction is often unreliable.

Retain provisioning and deprovisioning logs alongside certification outcomes to evidence timely joiner, mover, and leaver processing rather than relying on current-state data alone.

Protect the confidentiality of sensitive attributes in compliance evidence with appropriate encryption or access controls, recognizing that signing alone provides integrity but not confidentiality.

Validate that report data sources are consistent and reconcilable, for example, that identity records, directory entries, and event logs align, and flag gaps rather than presenting incomplete evidence as complete.