The request usually arrives as a list from an auditor or a compliance team: show who can read each Kafka topic that holds customer data, show who actually read or changed those topics over the review period, and show how sensitive fields are protected when engineers inspect messages. For European teams the list has grown since the EU Data Act started to apply on 12 September 2025 (Regulation (EU) 2023/2854, Article 50). Answering it starts with knowing what Kafka records by itself, because that is less than most auditors expect.
What Apache Kafka records on its own
Kafka’s built-in authorizer controls access with ACLs. Each ACL allows or denies a principal an operation on a resource from a host, and the current set can be listed with the kafka-acls.sh tool that ships with Kafka (Apache Kafka documentation, Authorization and ACLs). That listing is the ACLs in force at the moment the command runs. The Kafka ACL guide covers the syntax.
The only per-principal record of access decisions is the authorizer’s own log. The broker writes authorization decisions to a dedicated logger, which the default configuration sends to kafka-authorizer.log at INFO level:
kafka.authorizer.loggerThe level matters because of how the authorizer logs each outcome. A denied request that the client explicitly asked for is logged at INFO. An allowed request is logged only at DEBUG. Both behaviours are in the authorizer source (StandardAuthorizerData.java, Apache Kafka 4.1.0) and the default logger level is in the broker’s shipped logging configuration (config/log4j2.yaml, Apache Kafka 4.1.0).
With the defaults, Kafka therefore records failed attempts but not successful ones. An allowed topic deletion, config change or ACL change leaves no line in the authorizer log, and Kafka has no separate audit log of administrative operations. Raising the logger to DEBUG records allowed requests too, but it also records the authorization of routine produce and fetch traffic, so the log grows quickly and still does not say what a request contained.
The evidence an audit asks for
The evidence requested for a Kafka platform usually covers four items. The descriptions below are what Kpow’s governance features provide for each one. These are Kpow Enterprise features; they are not in Community Edition.
- An export of the access policy. Kpow’s role-based access control scopes each rule to a cluster, topic, consumer group, connector or schema subject, and every action can be explicitly allowed, denied or staged for approval, with deny rules overriding allow rules. The policies are defined in a YAML file, so the policy in force is a versioned file you can hand to the auditor. The ServiceNow walkthrough shows one of these files, along with a request-and-approval flow for temporary access that leaves a ticket trail.
- An audit log, and how long it is kept. Every user action in Kpow is logged with who made the request, what it contained, and whether RBAC allowed or denied it. The log is available in the Kpow UI, as a webhook, or as a plain Kafka topic, and the complete trail in that topic is retained for as long as you configure. Retention is therefore the topic’s retention setting, which is the number to give the auditor.
- The masking configuration. Kpow redacts sensitive fields in Data Inspect results without changing the underlying Kafka data. Each field can be fully redacted, replaced with a SHA-512 hash or partially revealed, including fields nested inside Avro, Protobuf or JSON, and masking is enforced server-side so the unmasked value never reaches the browser or the API response. Knowing which fields need masking is a classification question, and lineage support in Factor Platform surfaces PII-tagged schema fields for that purpose.
- The SSO role mapping. Kpow takes roles from your existing identity provider (Okta, Microsoft Entra ID, AWS SSO, Keycloak, or any LDAP, SAML or OAuth2/OIDC provider), so the mapping from directory groups to Kafka permissions is the same one the auditor already reviews for other systems.
The same access control, data masking and audit log features are described for regulated teams on Kpow for financial services and Kpow’s governance page.
Where the EU Data Act fits
The Data Act lays down harmonised rules on making product data and related service data available to the user of a connected product, on data holders making data available to data recipients and to public sector bodies, and on switching between data processing services (Article 1(1)). Three parts of the text bear directly on a Kafka platform:
- Access by design. Connected products and related services must be designed so that product data and related service data, including the metadata needed to interpret them, are accessible to the user by default, in a comprehensive, structured, commonly used and machine-readable format (Article 3(1)). This obligation applies to products and services placed on the market after 12 September 2026 (Article 50). If that data flows through Kafka, the topics that carry it are part of the answer.
- Technical protection measures. A data holder may apply appropriate technical protection measures, including smart contracts and encryption, to prevent unauthorised access to data, including metadata (Article 11(1)). Kafka ACLs, RBAC policies and field masking are technical measures of this kind, and the evidence list above is how a team shows they are in place.
- Switching and governmental access. Providers of data processing services must enable customers to switch to another provider or to on-premises infrastructure (Article 23), and must take technical, organisational and legal measures to prevent international governmental access to non-personal data held in the Union where it would conflict with Union or national law (Article 32). These apply to teams that provide Kafka as a service to customers, not to every team that runs it internally.
The European Commission’s Data Act explained page is the plain-language summary of the rest of the Regulation.
Practical steps for engineers
- Export the ACLs and RBAC policies in force, and keep them under version control so the policy on any past date can be shown.
- Decide whether the authorizer log’s default of recording denials only is enough, and if it is not, put a tool-level audit log in front of administrative actions.
- Set and document the retention of whatever audit log you rely on, and check it covers the audit period.
- List the topics that carry personal or connected-product data, and confirm masking rules cover their sensitive fields.
- Map identity-provider groups to Kafka roles in one place, so a leaver removed from the directory loses Kafka access too.
Governance tools for Kafka in financial services are compared in Kafka governance tools for financial services.
To help you navigate this transition, you can try Kpow Enterprise, which includes RBAC, data masking and the audit log, for free.
Experience firsthand how Kpow’s secure, transparent, and flexible Kafka management capabilities can simplify compliance and enhance your streaming operations. Try Kpow Enterprise for free.
Sources (and further information)
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex
- Data Act explained, European Commission, accessed 22nd September 2026
- Authorization and ACLs, Apache Kafka documentation
- StandardAuthorizerData.java, Apache Kafka 4.1.0 source
- config/log4j2.yaml, Apache Kafka 4.1.0 source
Governance is one part of running Kafka well. The complete guide to Kafka covers the rest.