Apache Kafka for SOC 2 audits

Which SOC 2 criteria Apache Kafka helps with in your environment

Apache Kafka gives you specific technical controls under CC6.1, CC6.7, CC7.2 and A1.2, but your organization still owns the policies, identity lifecycle, monitoring operations and recovery testing that an examiner will ask about. If your Kafka platform carries data in scope for a SOC 2 examination, plan the cluster around those four criteria and the security common criteria (CC1 to CC9), which apply to every SOC 2 report. CC6.1 covers logical access security, which for Kafka means ACLs stored in the metadata log under the StandardAuthorizer, along with the authentication mechanisms that identify each client and tool.

CC6.7 covers transmission and movement of information, which maps to SSL/TLS on client, broker and tool traffic. Kafka security is optional, so the decision to disable plaintext listeners and retire unsecured ports belongs in your design record, not in a default setting. CC7.2 asks for monitoring of system components for anomalies, and Kafka only produces the raw signals (broker logs, authorizer denials, metrics). Someone in your organization must decide what counts as an anomaly, who reviews it and how it becomes a security event. A1.2 covers backup and recovery infrastructure, where MirrorMaker 2 can replicate topics, consumer group offsets and ACLs to a second cluster, but a replica is not a tested recovery plan.

DeployOpen plans, configures and documents these controls and prepares the evidence an auditor would sample, but DeployOpen does not issue SOC 2 reports. Only an independent CPA firm can examine your controls and issue a Type 1 or Type 2 report. Before scoping the work, confirm with your examiner which categories are in scope, since availability maps to A1 and the other categories add criteria only when included.

Mapping each SOC 2 criterion to Kafka capabilities and configuration

This table maps four SOC 2 security and availability criteria to what Apache Kafka documents, the settings that make those capabilities enforceable, and what the surrounding platform must supply. Read each row as a boundary: the Kafka column shows what the software gives you, and the last column shows where an assessor will still ask for evidence from outside the cluster. The main takeaway is that Kafka covers the mechanisms for access, encryption and replication, while the policies, reviews, alerting and recovery testing around it remain your responsibility.

Requirement in plain language	Documented Kafka capability	Configuration needed	What the surrounding platform must add
CC6.1: Protect information assets with logical access security software and architectures	SSL or SASL authentication for clients, brokers and tools; StandardAuthorizer stores ACLs in the KRaft metadata log	Enable SASL (for example SCRAM-SHA-512 or OAUTHBEARER) on each listener; set authorizer.class.name to the StandardAuthorizer; keep allow.everyone.if.no.acl.found unset or false	Identity lifecycle for service and human accounts, approval records for ACL changes, periodic access reviews, and privileged super user control
CC6.7: Limit and protect information while it is transmitted, moved or removed	SSL/TLS encryption between clients, brokers and tools; MirrorMaker 2 replicates topics, offsets and ACLs between clusters	TLS on every listener including inter-broker and controller traffic; no plaintext listeners in production; secured MirrorMaker 2 connections	Restriction of who may export or consume data, controls on connectors that copy topics to downstream systems, and records of data movement
CC7.2: Monitor system components for anomalies and evaluate whether they are security events	Kafka exposes broker and client metrics and logs that can show authentication failures and authorization denials (confirm the exact metric names for your version)	Enable authorization logging and forward broker logs; alert on repeated authentication or ACL denial events; retain logs centrally	Central log pipeline, alert routing, documented triage steps, and records showing how anomalies were judged to be or not be security events
A1.2: Maintain backup processes and recovery infrastructure for availability	Replication across brokers within a cluster; MirrorMaker 2 provides cross-cluster replication of topics, offsets and ACLs	Replication factor and minimum in-sync replicas set per topic; a second cluster with MirrorMaker 2 where the design needs it; configuration kept under version control	Backup or copy of configuration and metadata, documented recovery objectives, and restore tests with recorded results, since replication does not protect against bad deletes or corrupt data

How KRaft ACLs answer the logical access question in CC6.1

In KRaft mode, the StandardAuthorizer stores ACLs in the cluster metadata log, so the access rules are replicated with the rest of the cluster state and can be inspected as part of the platform's configuration. The default matters for CC6.1. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Your first design check is to confirm that this setting is false (or unset) in every broker configuration, because a true value quietly turns every unprotected topic into a topic any authenticated client can use. Record the value per cluster and keep the configuration under change control so an auditor can see it has not drifted.

The auditor will test who holds super user rights. Keep the super.users list short, name each entry individually, and map each one to a named role such as a platform administrator or break-glass account, not a shared service identity. Each client maps to a SASL identity: a SCRAM user for SCRAM-SHA-256 or SCRAM-SHA-512, or a Kerberos principal under GSSAPI. Choose one identity per workload so that an ACL entry answers the question of which system did what. Group membership should come from your identity provider and reach Kafka through your Kerberos or OAuth path, not from manually maintained lists on the brokers. Confirm with your team which of these identity paths your environment supports before you write the access model, because the documentation describes the mechanisms but your directory integration is your own work.

Approval and review are where most of the evidence is created. Route every ACL change through a ticket that names the principal, resource, operation and business owner, and have a second person apply it. Because the ACLs live in the metadata log, export the current ACL set on a fixed schedule and compare it against the approved tickets. That comparison gives the operating-effectiveness evidence a Type 2 examination asks for. Ask your auditor which review cadence and sample they expect, and confirm with your security team how super user changes will be reviewed separately, since those rights sit outside ordinary topic ownership.

What evidence each Kafka control produces for SOC 2 auditors

A SOC 2 examination tests whether controls operated, so the organization must collect and retain proof from its Kafka platform for the whole period, not only at audit time. The cards below list the evidence types auditors commonly sample and what the platform team must keep to produce them.

ACL listings and change history

In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log, so the authorization state is recoverable from the cluster itself. Export the ACL listing on a fixed schedule and keep each exported snapshot with its date. Auditors commonly sample a few topics or consumer groups and ask who could access them and when that access was approved. Keep the approval ticket that matches each ACL change, and confirm that allow.everyone.if.no.acl.found is recorded as disabled or as an approved exception. Store exports in write-restricted storage with access limited to the platform and audit roles.

TLS listener configuration and certificate inventory

Kafka supports SSL/TLS between clients, brokers and tools, but security is optional, so an unsecured listener can exist without anyone noticing. Keep a dated export of each broker's listener configuration showing which listeners use TLS and which, if any, remain plaintext. Pair it with a certificate inventory listing subject, issuer, validity dates and the owner of each certificate. Auditors often test whether any listener in the sampled period accepted unencrypted traffic, so retain configuration history rather than only the current state. Record the review that approved each exception.

SASL credential lifecycle records

When clients authenticate with SCRAM, PLAIN, GSSAPI or OAUTHBEARER, the credential lifecycle becomes evidence. Keep records of who created each service or user credential, when it was rotated, when it was revoked, and which team owned it. Auditors typically sample leavers and ask whether their access was removed within the expected window. Compare the directory or identity system's leaver list against active SASL users on the cluster each period. Restrict who can create or alter credentials, and keep the creation and deletion logs in the same protected store as the ACL exports.

Authentication and authorization logs

Broker and authorizer logs show denied and permitted access attempts, which is the basis for the monitoring criterion CC7.2. Forward these logs to a central store that the platform team cannot silently edit, and set retention to the period the organization has committed to in its policy. Auditors may ask for a sample of denied attempts and the follow-up on each. Confirm that the log pipeline itself is monitored, since a silent collector failure leaves a gap in the record. Document which events are alerted on and who triages them.

MirrorMaker 2 replication status and offset checks

For availability under A1.2, MirrorMaker 2 replicates topics, consumer group offsets and ACLs between clusters. Keep periodic replication lag reports and offset checkpoint comparisons, and record any period when replication stopped. Auditors use these records to test whether the secondary site was current enough to meet the recovery expectations the organization has documented. Store the reports with timestamps and the alert thresholds in force at the time. Confirm with your own design which topics are in scope for mirroring, since an unmirrored topic will not appear in these reports.

Restore test records

Replication alone does not show that data can be recovered, so auditors look for restore tests. Keep a dated record for each test: the scenario, the source and target clusters, the topics restored, the time taken, the result and the defects found. Include who approved the test and what was changed afterward. Auditors commonly ask whether tests were run in the period and whether failures were tracked to closure. Store these records alongside the backup configuration they test, and restrict edit rights so the results cannot be revised after review.

Configuration sequence before the SOC 2 examination period starts

This sequence sets the Kafka settings that the SOC 2 control descriptions will rely on, and it leaves a dated evidence trail that shows each control was designed and running before the examination window opens.

Fix the authorization model and super user list
The platform team confirms that the cluster authorizer is the StandardAuthorizer, which stores ACLs in the KRaft metadata log, and records the named super users in the broker configuration. The policy owner approves the super user list, because it defines who can act on every resource in the cluster. Done means the approved list is versioned in your change system and each super user maps to a named individual or a documented service identity. Ask your policy owner which accounts are permitted to hold this role before you write the configuration.
Enable TLS on every listener
The platform team configures SSL/TLS on all client, inter-broker and controller listeners, and removes any plaintext or unsecured listener from the broker configuration. Kafka security is optional by default, so this step must be done deliberately and checked against the running configuration, not assumed. Done means a scan of each listener shows only encrypted endpoints, and the certificate issuance and rotation approach is written down. Keep the scan output, because it is direct evidence for the transmission control.
Choose SASL mechanisms and credential lifecycle
The security engineering team selects the SASL mechanisms the platform will accept from the documented options, such as GSSAPI (Kerberos), SCRAM-SHA-256 or SCRAM-SHA-512, and OAUTHBEARER where an identity provider is in place. It then defines how credentials are created, rotated, revoked and stored, including who can perform each action. The policy owner signs off on the credential lifecycle, since it determines how quickly access is removed when someone leaves. Done means a written procedure exists, and a test account has been created, rotated and revoked with the change recorded.
Enforce the no-ACL default and write topic-level ACLs
The platform team sets allow.everyone.if.no.acl.found to false, or confirms it is unset, so that resources without an ACL are restricted to super users. It then writes ACLs per topic and consumer group, granting each application only the operations it needs. Each ACL should map to a named owner in the topic register. Done means an export of the ACL list matches the register, and a test client without permission is refused on a sample topic. This export is the main evidence for the logical access controls that auditors will sample.
Configure monitoring and log export for anomaly review
The operations team enables authorization and authentication logging, forwards broker and controller logs to a central store, and creates alerts for failed authentication, ACL changes and unexpected administrative actions. The security team defines who reviews these alerts, how often, and how a review is recorded as an event or a non-event. Done means a test failed login appears in the central store and triggers an alert, and the review procedure names an owner. The review records are the evidence for the anomaly monitoring criterion.
Set up MirrorMaker 2 and test the restore procedure
The platform team configures MirrorMaker 2 to replicate topics, consumer group offsets and ACLs to the secondary cluster, and documents the failover and failback steps. The engineers then run a restore exercise on a non-production topic and record how long recovery took and what data was verified. The policy owner approves the recovery objectives that the test is measured against. Done means a dated test report exists with the outcome and any gaps, which supports the backup and recovery criterion for availability.

Who owns each control: Kafka, the hosting platform or the organization

Kafka itself provides the access and transport mechanisms that the common criteria and availability criteria point to. The broker enforces SSL or SASL authentication, applies ACLs stored in the KRaft metadata log through the StandardAuthorizer, and can encrypt client, broker and tool traffic with SSL/TLS. Security is optional in Kafka, so the configuration must be set deliberately, not assumed.

Listener and protocol settings: Which listeners are secured and which SASL mechanism each one uses. Unsecured or mixed listeners must be documented and justified.
ACL definitions: The principals, topics, consumer groups and operations each ACL grants. Confirm allow.everyone.if.no.acl.found is not enabled unless you have a documented reason.
Replication and topic configuration: Replication factors and retention settings that support availability, along with MirrorMaker 2 configuration if cross-site replication is in scope.
Configuration as code: Versioned broker and topic configuration so that changes leave a reviewable history.

Kafka does not decide who should hold a principal, whether a credential is rotated, or whether an anomaly is investigated. Ask your team to export current ACLs, listener configuration and topic settings with a timestamp so the auditor can compare them against the system description.

What Kafka does not cover for SOC 2 and what you must add

Kafka provides ACLs, TLS, metrics and replication, but it does not decide whether a control operates. The cards below cover the components around the cluster that typically supply anomaly analysis, log independence, encryption at rest, access lifecycle, recovery testing, change control and vendor patching, and the checks to confirm in your environment.

Anomaly detection and alert logic

Kafka emits JMX metrics and broker logs, but it does not decide what is anomalous or whether an event is a security event. CC7.2 expects the organization to analyze anomalies, so a monitoring stack such as Prometheus with Alertmanager, or a SIEM, must define alert rules for unexpected authorization failures, sudden consumer group changes, under-replicated partitions and unusual producer rates. Check that every alert has a named owner, a triage runbook and a recorded disposition, since the auditor will sample those records.

Independent monitoring of broker audit logs

Authorization decisions made by the StandardAuthorizer appear in broker logs that the cluster itself can write. For CC7.2 and CC6.1 evidence, ship those logs to a store that platform administrators cannot edit, such as a central log platform with write-once retention. Confirm which authorizer log entries your Kafka version emits, how long they are kept, and who can read or delete them.

Encryption at rest

Kafka's TLS covers data in transit between clients, brokers and tools, but segment files on disk are not encrypted by Kafka itself. The surrounding platform must supply volume or filesystem encryption, with key custody in a key management service or hardware security module. Confirm the encryption approach for broker volumes, backup copies and the snapshots of any cluster hosts, and document who holds the keys.

Identity lifecycle and joiner-mover-leaver

SCRAM users, Kerberos principals and OAUTHBEARER identities are created and removed outside Kafka, and the ACLs granted to them persist until someone changes them. Your identity provider or directory must drive account creation, role changes and removal, and a periodic review must compare active principals with the HR roster. Confirm how a departing engineer's service credentials and ACL entries are revoked, and how quickly that happens.

Backup and recovery testing under A1.2

Replication across brokers protects against broker failure, but it does not protect against a bad deletion, a corrupted topic or a faulty configuration that replicates everywhere. A1.2 expects backup processes and recovery infrastructure to be operated and monitored, so you need copies outside the cluster, such as MirrorMaker 2 to a separate cluster plus object storage backups, and documented restore tests. Confirm the restore procedure, the test frequency and the evidence each test produces.

Change management for configuration

Broker properties, topic settings, ACLs and quotas change through admin tools and configuration files, and Kafka does not record who approved a change. Store configuration in version control, route changes through reviewed pull requests, and apply them through a pipeline such as GitOps tooling so each change has an approver and timestamp. Confirm how emergency changes are handled and whether direct admin-client edits are blocked for production.

Vendor and patch management

Kafka is Apache-2.0 software with no paid edition from the project, so your organization owns patching of the broker, the JVM, the operating system and any connectors or plugins. Track the supported release list on the downloads page, schedule upgrades within the supported window, and record each patch decision. Confirm who monitors the security advisories for every component, and how fast a critical fix reaches production.

What SOC 2 work on Kafka costs, takes and needs from your team

What drives the cost of a SOC 2 readiness project on Kafka?

The main cost driver is how many Kafka clusters, environments and surrounding systems fall inside the system description, because each one needs configuration, evidence and testing. Other drivers include the number of trust services categories in scope beyond the common criteria, how much identity and logging infrastructure must be built or changed, whether backup and cross-site replication already exist, and how many controls lack a documented owner today. Ask for a written scope that lists each cluster, listener, identity source, topic class, monitoring tool and backup target, plus the deliverables for each control area. Separate one-time work (design, configuration, runbooks, evidence baseline) from recurring work (access reviews, evidence collection, upgrades, retainers) so the quote shows what continues after the engagement ends.

How long does SOC 2 preparation on Kafka take?

Duration depends mostly on how much of the control environment already exists, not on Kafka alone. A team with working SSO, centralized logging, tested backups and documented access reviews needs far less preparation than one starting from unauthenticated listeners and shared credentials. The observation window for a Type 2 report is set by the auditor and the period agreed in the engagement, and it runs after controls are in place. Ask for a written timeline with dependencies, including which steps wait on identity provider changes, certificate issuance or change approvals. DeployOpen does not publish timelines, so the schedule should come from the scope you agree in writing.

Can our internal team configure Kafka for SOC 2 without a partner?

Yes, many platform teams can configure the Kafka settings themselves, since the relevant controls are documented in the Kafka security overview and authorization documentation. The harder work is usually outside Kafka: defining who owns each ACL, proving that access reviews happen, retaining evidence in a form the auditor can sample, and keeping the description of the system accurate as clusters change. Assess your team against those tasks rather than against the Kafka commands. A partner is most useful when the internal team lacks time, has not operated TLS or SASL authentication before, or needs an independent check before the auditor arrives.

What does a SOC 2 Kafka project need from our security, identity and platform teams?

Each team owns a distinct part of the evidence. The identity team supplies the directory or identity provider that issues Kafka principals, plus the joiner, mover and leaver process that drives ACL changes. The security team defines the certificate authority, TLS policy, log retention, alert routing and the criteria for anomaly review. The platform team runs the brokers, controllers, backups, change pipeline and upgrade process. Ask the written scope to name an accountable person in each team, the approval path for changes, and the systems that must be available for interviews and walkthroughs. Missing ownership is one of the most common reasons evidence gaps appear late.

Does DeployOpen issue a SOC 2 report for our Kafka platform?

No. DeployOpen does not issue SOC 2 reports, attestations or certifications. A SOC 2 report is issued by an independent CPA firm after an examination of your organization's system and controls. DeployOpen can plan, implement and document the Kafka controls, prepare the evidence those controls produce, and support your team during the examination. Ask the auditor early which evidence samples and system description details they expect, so the work is built to that request. Ask us in writing to confirm exactly which deliverables fall outside audit responsibility.

What is the difference between a SOC 2 Type 1 and Type 2 report for Kafka evidence?

A Type 1 report covers the description of the system and whether controls were suitably designed as of a specific date. A Type 2 report adds an opinion on whether those controls operated effectively over a period. For Kafka, a Type 1 readiness focus is on design artifacts: ACL models, listener policies, retention settings and backup design. A Type 2 focus adds recurring evidence: access review records, authorization change tickets, alert history, replication status and restore test results across the whole period. Plan evidence collection from the start of the period, because controls not evidenced during that window cannot be reconstructed later. Confirm the report type and period with your auditor before scoping.

What should a written SOC 2 Kafka scope include before we request a quote?

A useful scope lists the trust services categories in scope, the Kafka clusters and environments, the listeners and client types, the identity sources, the monitoring and logging tools, the backup and replication design, and the specific criteria each deliverable addresses. It should state the evidence format, the handover method and who approves each control design. It should also name exclusions, such as applications that produce or consume topics, and state what happens if the auditor requests additional evidence. Ask the proposal to separate fixed deliverables from optional items and to show which recurring services are priced separately. Most engagements are fixed-scope, so write down assumptions before work starts.

How DeployOpen scopes, configures and documents SOC 2 controls on Kafka

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache Kafka. For SOC 2 work, we prepare the Kafka platform, its access, encryption, monitoring and recovery controls, and the evidence they produce, while the independent CPA firm performs the examination.

How we scope

Agree in writing which Trust Services Criteria categories and Kafka clusters fall within the system description
Map each in-scope criterion to a named Kafka control, owner and evidence source before build starts
Confirm with your CPA firm which period, report type and evidence samples they will request

How we build

Configure KRaft clusters with SSL or SASL listeners, StandardAuthorizer ACLs and default-deny settings for resources without ACLs
Set up central logging of authorization, administrative and client connection events with alerting for anomalies
Test ACL denial, TLS enforcement and MirrorMaker 2 failover in a non-production environment with recorded results

How we hand over

Document each control with its configuration, owner, operating procedure and the evidence it generates
Deliver a system description draft and evidence index so your team and auditor can trace controls to sources
Provide runbooks for access reviews, restore tests and change records so routine evidence is produced without rebuilding it

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends
Review Kafka upgrades and configuration changes against the documented controls before they reach production
Confirm with your auditor how any retainer work will be reflected in the evidence for each review period