Event streaming for PCI DSS: what the framework asks of your topics
If your payments or commerce team sends events that carry primary account numbers through brokers, the scope of your Kafka, Pulsar, NATS or RabbitMQ deployment and the controls you put around it will determine most of the PCI DSS evidence you need. The cluster is only as in scope as the data that reaches it. Whether the platform sits inside the cardholder data environment (CDE), connects to it, or stays entirely outside depends on where PAN enters, where it is stored in topics, and which systems can read it. Decide that boundary before you pick a topology, because it sets the requirements for encryption, access control, logging and retention. PCI DSS is owned and maintained by the PCI Security Standards Council (PCI SSC), and v4.0.1 is the only active version of the standard. Validation happens through a Report on Compliance completed by a Qualified Security Assessor, or through a Self-Assessment Questionnaire, and either one ends in an Attestation of Compliance (AOC). Certificates do not count as validation. Which validation path applies, and which payment brands enforce it, is a question for your acquirer or the brands themselves, since the PCI SSC does not enforce compliance. Confirm the applicable path with them early. DeployOpen plans, builds and documents the streaming controls, and prepares the evidence an assessor will sample. It does not issue ROCs, AOCs or any other attestation; the QSA or your own assessment process does that. Ask any implementation partner to state in writing which controls they configure, which evidence they hand over, and which decisions remain with your assessor.
Which PCI DSS requirements shape the Kafka configuration
This table maps the PCI DSS requirements that most often change how a Kafka cluster is configured to the settings that address them and the evidence an assessor will ask for. Read each row as a question the cluster design must answer before the first card event is published. The main takeaway is that encryption, authentication, authorization and log retention each need an explicit configuration, because Kafka leaves security optional by default.
| Requirement or control | What the cluster must do | Kafka configuration to confirm | Evidence an assessor expects |
|---|---|---|---|
| Requirement 4.2.1, strong cryptography for PAN in transit | Encrypt every connection that carries PAN over open or public networks, accept only trusted certificates and reject fallback to weak configurations | SSL listeners on brokers and clients, with plaintext listeners disabled and client certificates validated against a trusted CA | Listener configuration exports, certificate inventory with expiry and revocation checks, and a scan showing no plaintext port is open |
| PCI SSC FAQ 1491, SSL and early TLS | Do not allow SSL or TLS 1.0 and 1.1, since these do not meet the strong cryptography definition | Restrict the broker and client TLS protocol versions to currently accepted versions and confirm the JVM does not fall back to older protocols | Test results showing failed handshakes for SSL, TLS 1.0 and TLS 1.1, plus the tested client library versions |
| Authentication of clients, brokers and tools | Identify every principal that connects, including applications, Connect workers and administrators, with no shared accounts | SSL client authentication or a SASL mechanism such as SCRAM-SHA-512 or OAUTHBEARER, with one principal per service | Principal list mapped to owners, and credential rotation records for SASL or certificate lifecycles |
| Access control to topics (ACLs) | Allow only named principals to produce or consume card-data topics and deny everything else by default | StandardAuthorizer in KRaft mode, with allow.everyone.if.no.acl.found left false so resources without ACLs stay restricted to super users | ACL export per topic, a short list of super users, and a record of approved ACL changes |
| Requirement 10.5.1, audit log retention | Keep audit log history for at least 12 months, with the most recent three months immediately available for analysis | Retention settings for the audit and access logs that record Kafka authentication and authorization events, kept separate from card-data topic retention | Retention policy, storage configuration, and a sample retrieval of logs from the most recent three months and from a point 12 months back |
| Card data in topics and retention | Limit which topics carry PAN, and set topic retention so PAN is not kept longer than the business need | Topic-level retention and cleanup settings, with PAN-bearing topics isolated and tokenized or masked payloads where possible | Data flow diagram showing which topics carry PAN, and retention settings per topic |
| Cluster placement and scope | Decide whether brokers, Connect and monitoring hosts sit inside the cardholder data environment or are segmented from it | Network placement and firewall rules that limit broker ports to named client networks, with no open listeners on other networks | Current network diagram, firewall rule review, and the scoping decision with its justification |
| Version and patch currency | Run a Kafka release that still receives bugfix releases and keep Java patched | Supported Kafka releases from the downloads page, with Java 17 for brokers and Connect as the upgrade notes require | Version inventory, patch records, and the upgrade plan showing the path from older releases |
Open-source streaming platforms that fit a PCI DSS design
A PCI DSS design for event streaming depends on which broker you choose, how it authenticates clients, and which supporting tools hold credentials and move data. The cards below cover the primary broker, the alternatives to check only if your workload calls for them, and the connector and secrets tooling that sits around the cluster.
Apache Kafka as the primary fit
Apache Kafka is an Apache-2.0 project with no paid edition from the project itself, so license cost is not the decision driver. Supported releases are 4.3.1, 4.2.2 and 4.1.2, and Kafka 4.0 and later run in KRaft mode only, so ZooKeeper-based clusters must migrate first. For PCI DSS, the design work is in TLS on every listener, SASL or OAUTHBEARER authentication, and KRaft ACLs. Confirm each security feature against the exact version you deploy.
Apache Pulsar for multi-tenant needs
Pulsar is worth evaluating when one platform must isolate many teams or business units with separate namespaces and tenants, or when built-in geo-replication is a primary requirement. Each added platform adds a second set of hardening, patching, authentication and log configuration to evidence. Choose Pulsar only if the workload requires those features, and confirm its TLS, authentication and authorization options against the version you plan to run.
RabbitMQ or NATS for messaging
RabbitMQ and NATS suit request-reply and task queue messaging better than log-based replay of card events. If a payment flow only needs point-to-point messages with acknowledgements, a smaller broker may reduce the number of systems in scope. Confirm whether each one supports the TLS versions, client certificate checks and access controls your assessor will test, and whether its audit logs meet your retention plan.
Kafka Connect and its connectors
Kafka Connect moves data between Kafka and databases, files and other systems, and each connector is code that touches cardholder data in transit or at rest. Connectors run with their own credentials and often sit outside the broker's authorization model, so treat each connector as a component in scope. Confirm which connector plugins you will import, where they come from, and how their TLS and credential settings are enforced.
Self-hosted secrets and identity tooling
Broker SASL credentials, OAUTHBEARER token validation and TLS private keys should live in a self-hosted secrets store and identity provider inside your own environment, not in configuration files on broker hosts. Confirm that the identity system can issue the tokens your brokers validate, that secrets rotate without a cluster outage, and that access to key material is logged. Your assessor will ask how each credential is issued, rotated and revoked.
How to sequence the PCI DSS work for a streaming platform
The sequence moves from agreeing scope with the assessor, to placing the cluster, hardening access and retention, and finally to a validated set of evidence the assessor can sample. Each step closes with a check that shows it is finished before the next one starts.
Confirm scope and data flows with the QSA
Your team maps every producer, consumer, connector and support tool that could carry primary account number data, then reviews the map with your Qualified Security Assessor or internal assessor before any cluster is built. The map should show which topics may hold cardholder data, which systems can read them, and which systems could affect the security of the cardholder data environment. Ask the assessor to confirm the scope in writing so later design choices rest on an agreed boundary. This step is done when the data flow diagram and the scope decision are signed off and filed with the project evidence.
Choose the cluster placement
Decide whether the streaming cluster sits inside the cardholder data environment, outside it with strict controls at the boundary, or in a segmented zone that handles only tokenized or non-account data. Placement drives the size of the assessed environment, the number of people with access and the cost of every later control, so the decision should be made by the platform owner, security lead and assessor together. Record the reasoning, including which topics are kept out of the cluster altogether. This step is done when the placement decision, network diagram and segmentation approach are approved.
Set up KRaft with TLS listeners and SASL
Your platform engineers deploy the Kafka cluster in KRaft mode, the only mode in Kafka 4.x, and configure every client-facing listener with TLS and an authentication mechanism from the documented SASL list or mutual TLS. Plaintext and unauthenticated listeners are disabled so that no fallback path remains, and certificates are issued from a managed authority with defined expiry and revocation handling. Confirm that the Kafka version in use is on the supported release list before go-live. This step is done when a connection test shows that unencrypted and unauthenticated connections are refused and that every certificate chain validates.
Configure ACLs and deny-by-default
Define service accounts for each producer, consumer and administrator, then grant topic, group and cluster permissions only where a documented business need exists. Keep the allow.everyone.if.no.acl.found setting at its restrictive default so that resources without an explicit ACL remain limited to super users, and keep the super user list short and reviewed. Store the ACL definitions as code so changes go through review and can be shown to an assessor. This step is done when a sample of denied access attempts is logged and the ACL export matches the approved access matrix.
Configure retention and log export
Set topic retention so that cardholder-bearing topics hold only what the business requires, and configure the broker, authorization and administrative audit logs to ship to a central store outside the cluster. The log store should retain audit history for at least 12 months as required by Requirement 10.5.1, with at least the most recent three months available for immediate analysis. Confirm with the assessor how retention of topic data relates to the cardholder data retention policy, since the two are separate questions. This step is done when a test query returns logs from the earliest and latest days in the retention window.
Validate the controls before assessment
Run an internal validation against each in-scope requirement: confirm TLS versions and cipher settings, test that unauthorized clients are rejected, check that logs contain the expected user, time and action fields, and confirm that segmentation controls block traffic from outside the scope. Where a control is met through the customized approach or a compensating control, document the objective and the evidence the assessor will ask for. Fix gaps and re-test rather than documenting them as accepted. This step is done when the validation report lists each test, its result and the owner of any open item.
Collect evidence for the assessment
Assemble the evidence an assessor typically samples: configuration exports, certificate inventories, ACL matrices, access review records, change tickets for topic and ACL changes, log samples and the validation report. Organize the evidence by requirement so the assessor can trace each claim to an artifact, and confirm with the assessor which samples they will request. Note that DeployOpen prepares systems and evidence for the assessment but does not issue reports or attestations; the Report on Compliance or Self-Assessment Questionnaire and the Attestation of Compliance remain the assessed entity's responsibility. This step is done when the evidence index is complete and the assessor has confirmed it covers the scope.
What assessors sample from a Kafka deployment
This table lists the evidence a QSA or internal auditor typically asks for when cardholder data passes through Kafka topics, and which component or team produces each item. Use it to plan evidence collection before the assessment starts, not during it. The main takeaway is that most items must be generated continuously by the cluster, not assembled by hand at audit time.
| Evidence item | What the assessor checks | Produced by |
|---|---|---|
| Network and data-flow diagrams | Every path PAN takes into and out of brokers, Connect workers, schema registry and consumers, and which segments sit inside the CDE | Architecture team, updated with each topic or connector change |
| TLS configuration | Listeners use TLS only, with no plaintext or mixed listeners carrying PAN, and no fallback to SSL or early TLS | Broker configuration files and client configuration, exported from the cluster |
| Certificate inventory | Each certificate is trusted, unexpired and not revoked, with an owner and renewal record | Internal CA or PKI tooling, plus a broker-side validity check |
| SASL and ACL exports | Only named principals hold SASL credentials, and ACLs grant topic access only to the services that need PAN | Kafka CLI or admin API output, captured from the KRaft metadata log |
| Authorizer configuration | The StandardAuthorizer is enabled and allow.everyone.if.no.acl.found is not set to true, so no resource is open by default | Broker server.properties, plus a test showing an unlisted principal is denied |
| Retention settings and audit logs | Audit log history covers at least 12 months, with the latest three months immediately searchable | Log platform outside the broker, fed by broker, authorizer and admin audit events |
| Access reviews | Named operators and service accounts with access to PAN topics are reviewed at a stated interval, with removals recorded | Identity provider and platform team, with sign-off from the data owner |
| Change records for upgrades | Upgrades, including the move to KRaft and Java runtime changes, are approved, tested and traced to a version | Change management system and deployment pipeline |
| AOC or ROC inputs | Evidence mapped to the requirements that apply, feeding the Attestation of Compliance or the Report on Compliance | Compliance lead and QSA, using the packet assembled from the items above |
What Kafka configuration alone does not satisfy
A correctly configured broker can still leave a PCI DSS assessment short. The cards below cover what tooling cannot decide for you, from scope and assessor judgment to the processes around the cluster that the standard also expects to be in place.
Tooling does not define scope
Whether a cluster is inside the cardholder data environment depends on where PAN is stored, processed or transmitted, and on whether a system could affect the security of that environment. Kafka has no notion of cardholder data, so it will not tell you which topics carry PAN, which consumers copy it into other systems, or which connected systems bring the cluster into scope. Map data flows and topic contents first, then decide the boundary. Confirm the decision with your QSA before the design is frozen.
Tooling does not replace assessor judgment
A QSA reviews how the controls work in your environment, not only whether a setting exists. A TLS listener that is enabled but still accepts plaintext listeners elsewhere can fail a review even though the secure path works. Expect the assessor to ask for the configuration, the change history behind it, and evidence that the same settings apply on every broker and in every environment. Walk through the design with the assessor early instead of assuming a passing configuration scan closes the question.
Key and certificate lifecycle
Requirement 4.2.1 expects only trusted keys and certificates, confirmed valid and not expired or revoked. Kafka will use whatever truststore and keystore you give it, but it does not issue, rotate, revoke or monitor them on your behalf. Define who owns the internal certificate authority, how broker and client certificates are renewed before expiry, how revocation is handled, and how a lapsed certificate is detected before producers start failing in production.
Policies, training and access reviews
Many PCI DSS requirements concern the organization rather than the broker, including written security policies, staff training and periodic reviews of who holds access. ACLs in the cluster metadata log only show what was granted, not whether the grant is still justified. Keep ACL definitions tied to approved owners, review them on a schedule, and retain the approvals. Ask your partner whether these processes are in scope of the engagement or left to your team.
Vulnerability management and incident response
Patching Kafka, Java and the operating system, scanning the platform for vulnerabilities and responding to security events are separate obligations from configuration. Upgrade paths matter here: Kafka supports rolling upgrades only from recent releases, so a cluster left far behind becomes harder to patch. Confirm who tracks security advisories, how fixes are tested and deployed, and who runs the response plan when a broker, credential or topic is compromised.
Compensating controls and customized approach
Where a requirement cannot be met as written, the defined approach allows a compensating control, and entities with robust risk management may use the customized approach to meet the stated objective another way. Both need documented justification, a risk analysis, and evidence that the alternative works over time. Keep the reasoning in writing, agree it with your QSA, and do not assume a Kafka feature is an accepted substitute without that review.
Questions buyers ask before hiring help with PCI DSS streaming
What drives the cost of PCI DSS work on an event streaming platform?
The biggest cost driver is how many systems and data flows touch cardholder data, because each one adds design, configuration, testing and evidence work. The cost components are the assessor's fees (paid to the Qualified Security Assessor, or QSA, for the Report on Compliance or the review of a Self-Assessment Questionnaire), the implementation work (network segmentation, TLS, SASL or SSL authentication, ACLs, log pipelines), and internal staff time for owners and approvals. Work is mostly one-time, such as scoping, hardening and the first assessment, while log storage, certificate renewal, access reviews and the annual assessment recur. Existing controls and evidence maturity move the cost in both directions. Ask any partner for a fixed-scope quote that lists the flows in scope, the connected systems, the environments, the evidence to be produced and the items the client's own assessor must provide.
How long does a PCI DSS streaming engagement take?
Timing depends mainly on the number of data flows, how well they are documented, and whether the cluster must be moved into or out of the cardholder data environment. Work on the cluster is often the shorter part. Data flow mapping, owner sign-off, segmentation changes and the assessor's sampling usually take longer, and the assessment itself follows its own schedule set by the QSA and the payment brands. No duration is given here because no researched figure supports one. Ask for a timeline in the written scope that separates discovery, build, test and evidence collection, and that states which milestones depend on your assessor's availability.
What does our team need to provide before a streaming engagement starts?
The team needs to supply an inventory of every system that sends, stores or receives card data through a topic, along with named owners for each flow and access to the environments involved. Practically, that means:
- A data flow inventory showing producers, consumers, topics, connectors and where payloads are stored
- Named business and technical owners who can approve access rules and retention periods
- Read access to current broker, network and identity configuration, plus a test environment that mirrors production
- Access to logging and SIEM tooling so log retention and review can be verified
- The name of your QSA or internal assessor, and the scope they have already agreed
Can our own team handle PCI DSS for Kafka without a partner?
Yes, a capable internal team can design, configure and document a self-hosted streaming platform for PCI DSS, provided the work is reviewed by a Qualified Security Assessor before it is relied on. The requirements that matter most here are strong cryptography for PAN over networks (Requirement 4.2.1), audit log retention (Requirement 10.5.1) and the access controls that the assessor will sample. The gaps usually appear in documentation, change control and evidence, not in configuration alone. If your team lacks Kafka operations experience or a clear segmentation design, a partner can take on part of the build while your staff keep ownership. Confirm the final scope with your QSA before work starts.
Does moving the streaming platform to a managed service change PCI DSS scope?
It can, and the change is not automatic. A managed service does not remove your obligations for the data you send through it. Your assessor will still ask where cardholder data is stored, processed or transmitted, who can administer the service, and what evidence you hold for the provider's controls. Service providers that can affect the security of the cardholder data environment are in scope under the standard. Before choosing managed or self-hosted, ask your QSA how the provider's responsibility matrix and attestation will be used in your assessment. Self-hosting keeps the broker, its logs and its configuration under your direct control, which simplifies some evidence but adds operational work.
Do DeployOpen or the PCI SSC certify our streaming platform as PCI DSS compliant?
No. The PCI Security Standards Council does not certify systems or issue compliance certificates, and DeployOpen does not issue audit reports, attestations or certifications. Validation comes from a Report on Compliance completed by a Qualified Security Assessor, or from a Self-Assessment Questionnaire, each with an Attestation of Compliance. The PCI SSC states that certificates are not recognized as validation. DeployOpen prepares the systems, controls and evidence that your assessor reviews. Ask any partner to show which parts of the assessment they support and which they leave to the QSA.
What does a fixed-scope quote for PCI DSS streaming work need to include?
A fixed-scope quote should state what is in and out of scope before any work starts. Ask for a written list covering the flows and topics in scope, the brokers and clusters, the environments, the authentication and encryption design, the ACL model, the log retention and review setup, the evidence package, and the assessor interactions the partner will support. Also ask which items recur after go-live, such as certificate renewal, access reviews, upgrades and log storage, and whether ongoing support is a separate retainer. The quote should name the client's responsibilities and the dependencies on the QSA, so that gaps are visible before the engagement starts.
Which PCI DSS version should the streaming design target now?
Design against PCI DSS v4.0.1, which is the only active version after v4.0 was retired on 31 December 2024. The PCI SSC published v4.0.1 on 11 June 2024 as a limited revision with no added or deleted requirements. The Council has run a request for comments toward a next iteration but has announced no release date, so confirm the current version with your assessor before finalizing the design. Ask your partner how the design will be documented so that a future revision can be assessed against it without a full rebuild.
Keeping the streaming platform patched without breaking evidence
PCI DSS expects the software in the cardholder data environment to be supported and changed under control, so a broker cluster that carries card data needs a patch plan that keeps the evidence assessors sample intact. Start by confirming the supported-release policy with your streaming vendor and your chosen distribution. The Apache Kafka project publishes its supported releases on its downloads page, and it makes bugfix releases as needed for supported releases only, so the version you run today may fall out of support sooner than your change calendar assumes. Agree in writing who watches the release feed, how long a security fix may wait, and who approves an out-of-cycle patch.
Plan the upgrade path before you need it. According to the Kafka time-based release plan, rolling upgrades are supported from each release in the past year, the last three releases, to the latest version. The Kafka upgrade notes add two constraints that often surprise teams: Apache Kafka 4.0 supports only KRaft mode, so any ZooKeeper-based cluster must migrate to KRaft before upgrading to 4.x, and brokers require Java 17 from 4.0 onward. Check the broker and client JVM versions across every application that connects, including Kafka Connect, because a Java change can ripple into services outside the streaming team. Record the current versions of brokers, Connect workers and tools in the cardholder data environment inventory before each change.
Every upgrade changes the configuration, the software and often the TLS and SASL settings, so treat the post-change run as a new evidence cycle. Re-collect the artifacts you would show an assessor: the broker and Java versions, the TLS listener settings and the ACL state in the KRaft metadata log, a sample of audit log retention, and the approved change record linking them. Confirm with your Qualified Security Assessor, if you use a ROC, or with your acquirer or payment brand, if you complete an SAQ, which evidence they expect for a patch-driven change in the assessment period. Keeping a pre-upgrade and post-upgrade configuration export under version control makes that comparison quick and defensible.
Deciding whether self-hosted Kafka fits your PCI DSS scope
This sequence turns a vague question about streaming and card data into a documented decision on scope, placement and operating model that an assessor can follow.
Map where primary account numbers appear
Your architecture, integration and data owners list every producer, topic, connector, consumer and downstream store that could carry PAN, along with any field that could hold it indirectly, such as a free-text memo or a log line. The output is a data flow diagram annotated with PAN locations, reviewed by the payments team and the QSA or internal assessor who will sample it. The step is done when each topic has a documented answer to the question of whether cardholder data can appear in its messages.
Decide whether to remove PAN upstream
Before deciding anything about the cluster, decide whether the streaming platform needs PAN at all. Consumers often need only a token, a masked value or a last-four digit to complete a business task, so tokenization or truncation at the producer may keep the cluster out of scope. Involve the payments architect and the card data owner to test each consumer's real need. The output is either a list of topics that will carry tokens or masked values, or a justified list of topics that must carry PAN and therefore need full controls.
Place the cluster in or out of scope
Using the flow map, decide whether each cluster, broker, Kafka Connect worker and tooling host is part of the cardholder data environment. A cluster that stores, processes or transmits PAN is in scope, and a component that could affect the security of that environment may be too. Document the segmentation between an out-of-scope cluster and the cardholder environment, and have the assessor confirm the boundary. The output is a scope statement with a network diagram and a rationale for each system.
Confirm the team can run TLS and SASL controls
Check that operators can configure TLS for every client, broker and tool listener, disable unsecured listeners, and choose SASL mechanisms from the set Kafka documents, such as SCRAM or OAUTHBEARER, with certificate lifecycle management for expiry and revocation. Requirement 4.2.1 expects only trusted keys and certificates, no fallback to insecure versions, and no reliance on SSL or early TLS, which PCI SSC FAQ 1491 says do not meet strong cryptography. The output is a tested configuration baseline and a named owner for certificate rotation, verified against a non-production cluster.
Confirm the team can run ACLs and log retention
Verify that the team can design least-privilege ACLs per topic, consumer group and principal, and that a KRaft cluster denies resources without ACLs unless a permissive setting is deliberately enabled. Confirm that audit and access logs can be retained for at least 12 months with the most recent three months immediately available, as Requirement 10.5.1 describes, and that someone can produce a sample of those logs on request. The output is an access matrix and a log retention design that an assessor can sample.
Choose the operating model for the cluster
Weigh in-house operation, partner-supported operation and a managed service against the skills and staffing you have. Consider who patches Java and Kafka releases on the supported cadence, who answers alerts out of hours, who maintains the evidence, and who is accountable for the cardholder environment boundary when a third party runs infrastructure. A managed service may move some responsibilities to a provider that must be assessed as a service provider. The output is a documented responsibility split and a short list of questions for each option.
Record the decision and evidence plan
Consolidate the flow map, scope statement, control configurations and operating model into one decision record signed by the CISO or payments owner. List the evidence each control produces, such as configuration exports, certificate inventories, ACL reports and log samples, and assign an owner for keeping them current. The step is complete when an assessor can trace every topic with PAN to a scope decision, a set of controls and recorded evidence, and when the team knows which PCI DSS version the assessment will use.
How DeployOpen scopes, hardens and documents a PCI DSS streaming platform
DeployOpen works on event streaming for PCI DSS as a fixed-scope engagement with the scope agreed in writing before work starts. We plan, implement, harden and document a self-hosted Kafka or other open-source broker inside your own data centers or cloud accounts, and prepare the evidence your assessor will request.
How we scope
- Map every topic and consumer that carries PAN or sensitive authentication data, and decide what sits inside the cardholder data environment.
- Agree in writing which cluster components, network segments, clients and log stores are in scope and which are excluded with documented reasons.
- Confirm with your QSA or internal assessor how the scope boundary and data flows will be evidenced before any build starts.
How we build
- Configure TLS on every client and broker listener, disable unsecured listeners, and accept only trusted certificates that are checked for validity and revocation.
- Set SASL authentication and ACLs per topic and principal, and disable fallback to insecure protocol versions or cipher settings.
- Configure audit and broker log retention to meet the twelve-month history expectation of requirement 10.5.1, with recent months kept immediately searchable.
How we hand over
- Deliver configuration baselines, network diagrams, data flow maps and an ACL inventory that map to the requirements in scope.
- Document runbooks for certificate rotation, access reviews, log retention checks, upgrades and incident response for the streaming platform.
- Provide a test record showing TLS, authentication, authorization and log controls working as designed, ready for your assessor to sample.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped in writing.
- Plan version upgrades on the Kafka supported release line so that patches for in-scope clusters are applied on a known cadence.
- Review changes to topics, clients and network paths against the documented scope before they reach production.
