Apache Kafka for financial services

Apache Kafka for financial services: why banks and fintechs run it themselves

A bank, payment firm or fintech that needs real-time events between payment rails, core banking and risk systems can run Apache Kafka itself. Kafka is an Apache Software Foundation project released under the Apache License 2.0, so self-hosting it keeps the event log in infrastructure the firm controls, with no paid edition from the project to buy. The licence sets the software cost; the design, operating and evidence work sits with the firm or the partner it hires, and that work changes once regulators place the platform in scope.

Two regimes reshape the design. Under DORA, which has applied since 17 January 2025, a Kafka cluster that supports a critical or important function falls under ICT risk management, incident handling and third-party rules, so the firm needs a register entry for any outside party that deploys or hosts it, contract terms on data location and data return, and a tested exit plan. Under PCI DSS v4.0.1, any topic that carries cardholder data or sensitive authentication data brings the brokers, Connect workers and their administrators into the cardholder data environment. Practical decisions follow: segregate payment topics onto dedicated clusters, restrict ACLs in the StandardAuthorizer, and confirm with your QSA which clusters are in scope before topic design begins.

DeployOpen plans, builds, documents and supports the Kafka platform inside your own cloud accounts, data centers or restricted networks. It does not issue audit reports, attestations or certifications; your QSA, the auditor for DORA-related reviews and the Swift assessor (where Swift applies) provide those. What the firm should ask a partner for is a written scope covering topic classification, access model, multi-site replication design, retention and backup evidence, and the control evidence each assessor will request. Confirm the current Kafka release line on the official downloads page before you fix versions in the design.

Which financial services requirements shape the Kafka build

This table maps each financial services requirement in the supplied sources to its source and to the Kafka design decision it affects: topics, ACLs, replication and evidence. Read each row as a question to answer in the design document before the cluster is built, and use the evidence column to plan what an assessor will ask to see.

Requirement	What it asks for	Impact on the Kafka build
DORA Article 28(3) register	A register of information covering all contractual arrangements for ICT services, including Kafka support and hosting providers.	Record each self-hosted component, its operator and the providers involved, then keep the register current as versions and contracts change.
DORA Article 28(8) exit strategy	Documented and tested exit strategies and transition plans for ICT services that support critical or important functions.	Keep topic definitions, schemas and consumer offsets portable. Test a plan to move producers and consumers to another cluster or to MirrorMaker 2 replicas.
DORA Article 30(2) contract terms	ICT contracts must state where services are provided and data processed, give advance notice of changes, and cover data return on termination.	Confirm with providers the hosting locations for brokers, backups and mirrored clusters. Name the data stores that hold event copies and retention periods.
PCI DSS scope and v4.0.1	Entities that store, process or transmit cardholder data, or could affect that environment, must meet the 12 principal requirements in v4.0.1.	Decide whether any topic carries card or sensitive authentication data. If so, isolate those topics and their brokers, and restrict them through ACLs and network segmentation.
PCI DSS future-dated requirements	51 requirements of v4.0 became effective on 31 March 2025, so they now apply during assessments.	Plan logging, access review and encryption controls for Kafka as in-scope components, and document how each requirement is met or customized.
Swift CSP controls	Swift users must have the Customer Security Controls Framework controls independently assessed and attest annually in KYC-SA.	If Kafka carries Swift-related messages, map the relevant controls to broker authentication, administrative access and monitoring, and keep the mapping current.
FTC Safeguards Rule MFA	Multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing.	Route administrative access to brokers and the Kafka UI through MFA-backed identity. Record any written exception and its compensating control.
SEC ICFR IT general controls	Program development, program changes, computer operations and access to programs and data are example control areas for SOX 404 assessments.	Keep change records for broker configuration, topic creation and ACL changes. Show who can alter access and how changes are approved and reviewed.
Access control in KRaft	The StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are limited to super users by default.	Define ACLs per topic, group and transactional ID. Confirm that allow.everyone.if.no.acl.found is left at its restrictive default for regulated topics.

Payments, core banking and ledger events on Kafka

Payment initiation, authorization, clearing and status events are often the first flows a bank or payment firm connects to Kafka. Fraud scoring, notifications and reconciliation all consume the same events, but ordering only matters within one payment or one account. Partitioning by a payment or account key keeps related events in order, and it also means a very busy account can concentrate load on a single partition.

Key choice: Key by payment identifier when lifecycle order matters, or by debtor account when balance checks depend on account-level order. Each choice changes how evenly load spreads across partitions.
Partition count: Size partitions against peak throughput and the number of consumer instances before go-live. Changing the partition count later alters the key-to-partition mapping for new records, so plan how that change will be handled.
Topic per event type: Separate topics for initiated, settled and returned payments let retention and access rules differ by type, at the cost of more topics to govern.
Consumer idempotency: Consumers should tolerate redelivery. Store a processed-event identifier so a retried message does not trigger a second notification or fraud action.

Check the key, partition count and retention for each payment topic against your peak volume and your dispute window before any producer goes live.

Ledger postings and settlement instructions are where duplicates cost money. A consumer can read a posting, update a balance and then fail before it commits its offset, so the posting may be processed again on restart. Kafka's idempotent producers and transactions prevent duplicate writes into Kafka and allow atomic read-process-write flows inside Kafka, but a balance held in an external database still needs its own safeguard.

Idempotent producers: Set enable.idempotence to true and acks to all on producers that write postings, so retried sends do not create duplicate records. Confirm the default values for the client version you run.
Transactions: For read-process-write flows that stay inside Kafka, give each producer instance a stable transactional.id and set isolation.level to read_committed on consumers. This covers Kafka-to-Kafka steps only.
External side effects: A balance update in a ledger database sits outside any Kafka transaction. Store a unique posting identifier with a uniqueness constraint in that database so a replayed posting fails safely.
Ordering and sizing: Key postings by ledger account so each account's postings stay in order, and size partitions so one busy account does not hold back unrelated accounts.

Test replay, consumer crash and broker failover on a staging ledger, and record which mechanism protects each step in the design document.

Security, access and replication settings that matter in banking

A banking Kafka cluster is only as trustworthy as the controls set on day one: how clients prove identity, how traffic is encrypted, who may touch which topics, and how data reaches a second site. The cards below cover the settings that auditors and risk teams ask about most, and the points where the defaults need an explicit decision.

SASL mechanisms and identity integration

Kafka authenticates clients, brokers and tools with SSL or SASL, and the documented SASL mechanisms are GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Choose one mechanism per listener based on how your identity provider issues credentials, and avoid PLAIN for anything beyond a lab. Confirm how service accounts are rotated, how long-lived secrets are stored, and whether OAUTHBEARER tokens can be validated against your corporate identity provider.

TLS on every listener

Security is optional in Kafka, so a cluster can run unsecured or mix secured and unsecured listeners. In a payments environment, every client, broker and tool listener should use SSL/TLS, and any plaintext listener should be an explicit, reviewed exception. Check inter-broker and controller listeners as well as client ones, and record certificate issuance, rotation and expiry in the same evidence trail as your other cryptographic controls.

StandardAuthorizer ACLs in the metadata log

In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so leaving that key at its restrictive default is the safer baseline. Plan ACLs per topic, consumer group and transactional ID, and review super user membership as part of access certification.

Pluggable authorization with external services

Kafka authorization is pluggable and supports integration with external authorization services. Banks that already manage entitlements in a central policy or identity governance system should decide early whether Kafka ACLs are generated from that source or maintained by hand. Confirm how an external authorizer behaves during an outage, how decisions are logged, and who owns the mapping between business roles and topic permissions.

MirrorMaker 2 for topics, offsets and ACLs

MirrorMaker 2 is built on Kafka Connect and replicates topics with their configuration, consumer groups with offsets, and ACLs between clusters, preserving partitioning. For a second site, this means failover can carry access rules as well as data. Test that replicated ACLs match the intended policy in the target cluster, and document which consumer groups resume from replicated offsets and how duplicate processing is handled during a switch.

Java 17 runtime for brokers and Connect

Since Kafka 4.0, brokers, Kafka Connect and tools require Java 17, while clients and Kafka Streams applications require at least Java 11. Treat the JVM as part of the controlled build: pin the runtime in your image baseline, include it in patch and vulnerability scanning, and confirm that application teams running older clients have a dated plan to move up. Mixed client versions are a common source of surprises during upgrades.

How multi-site resilience and exit planning work with Kafka

MirrorMaker 2 is the replication path to design and test first, and it copies more than messages. Built on Kafka Connect, it replicates topics with their configuration, consumer groups with their offsets, and ACLs between clusters, and it preserves partitioning so records keep their partition on the target. That gives a standby site the data and access state it needs. It does not give you a single ordered log across sites. Replication is asynchronous, so records acknowledged at the primary shortly before a site loss may be absent at the standby. Offsets are translated through checkpoints rather than being identical, so consumers resuming there may reprocess or skip records depending on checkpoint timing. Transactional guarantees made on the source should not be assumed to hold as a promise about what the standby contains at failover. Confirm the behavior for your Kafka version in the geo-replication documentation.

The failover behaviors that need testing are specific. Run a cutover in which producers reconnect to the standby with their idempotence and transactional settings, then check ledger-facing topics for duplicates and gaps. Start consumer groups from translated offsets and measure how much work is replayed. Confirm that the principals in the standby ACLs can still read and write, since an access gap during an incident is an operational failure of its own. Check that standby retention covers the replay window and that Connect sinks resume without manual repair. Reconcile balances or payment states against the source of record before declaring service restored. DORA Article 28(8) requires documented, tested exit strategies and transition plans for ICT services supporting critical or important functions. The same evidence feeds the register of information under Article 28(3), which records contractual arrangements, including any hosting or support partner you use.

The exit plan covers leaving Kafka as well as failing over within it. Apache Kafka is released under the Apache License 2.0 and the project offers no paid edition, so the cost of moving away lies in the data and integration work: topic definitions and configuration, message and schema formats, consumer offsets, connector configurations and the client code that depends on them. Document where each of these lives, who holds the credentials, and where data is processed, because Article 30(2) requires ICT services contracts to state data location and to cover data return on termination. Confirm the transition steps for each critical flow, such as payment initiation or ledger postings, and rehearse them on a non-production copy. Record who approved the plan, what was tested and what remains open, so supervisors can review tested evidence alongside the written plan.

What auditors and supervisors will ask about the Kafka platform

Does PCI DSS apply to our Kafka cluster if it carries card data?

It applies if the cluster stores, processes or transmits cardholder data or sensitive authentication data, and also if it could affect the security of the cardholder data environment. PCI DSS v4.0.1 is the only active version, published on 11 June 2024, and the future-dated v4.0 requirements have been effective since 31 March 2025. Scoping is the first decision: topics that carry primary account numbers pull brokers, Connect workers, consumers and admin hosts into scope, while topics that carry tokenized or non-sensitive events may not. Confirm the scope with your payment brand or acquirer and your Qualified Security Assessor before you design the network segments and access model.

What is the difference between a Report on Compliance and an SAQ with an Attestation of Compliance?

A Report on Compliance is a detailed assessment written by a Qualified Security Assessor, and a Self-Assessment Questionnaire is a form the entity completes itself. Both end with an Attestation of Compliance on official PCI SSC templates. The PCI SSC states that certificates are not recognized as validation, so an AOC on the correct template is the document to ask for. Which path applies is decided by the payment brands and acquirer, not by DeployOpen or the PCI SSC. DeployOpen prepares the Kafka controls and evidence that the assessor or the self-assessment will rely on.

What must a DORA register of information and ICT contracts contain for Kafka?

DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Article 30(2) requires each ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. For a self-hosted Kafka platform, the open-source license carries no vendor contract, so the register should list the service partners, hosting providers and support arrangements you do contract with. Confirm the entries with your compliance team and competent authority expectations.

What evidence do DORA supervisors expect for a Kafka exit strategy?

Supervisors look for a documented, tested exit plan that shows how the event streams, topic configurations, consumer offsets and ACLs could move to another cluster or platform. Apache Kafka's MirrorMaker 2 replicates topics with configuration, consumer groups with offsets and ACLs between clusters, which is a relevant building block for that plan, but the plan itself must be written and exercised. Ask for a test record showing the transition was run, the time it took in your environment, and the data return steps. Your own legal and risk teams decide what is adequate.

What does Swift CSP independent assessment require for a Kafka-connected payment system?

Swift users must have the Customer Security Controls Framework controls independently assessed and attest compliance annually in the KYC-SA application. The v2026 framework has 32 controls, of which 26 are mandatory and 6 advisory. A Kafka platform matters when it sits in the path of Swift messaging or the systems that feed it, so the access control, logging, patching and segregation evidence for those hosts must be ready. DeployOpen can prepare configuration evidence and controls, but the independent assessor and Swift's attestation process determine whether the requirements are met.

How do SEC IT general controls apply to a Kafka platform that feeds financial reporting?

SEC Release 33-8810 names program development, program changes, computer operations and access to programs and data as example IT general control areas for SOX Section 404 assessments. If Kafka carries ledger or general ledger events, each area needs evidence: change records for broker and Connect configuration, privileged access logs for the KRaft controllers, job and replication monitoring, and approvals for topic and ACL changes. Your external auditor decides which controls are in scope and whether they operate effectively. DeployOpen can design the change workflow, access model and logging so that the evidence can be produced on request.

Does the FTC Safeguards Rule require MFA for engineers who administer Kafka?

Yes, for non-bank financial institutions under FTC jurisdiction, 16 CFR 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. Kafka administrators, Connect operators and anyone with broker or console access fall within that wording, so the access path to these systems needs MFA at the identity provider or bastion layer. Apache Kafka's own security features authenticate clients and tools with SSL or SASL, but they do not replace MFA for human administrators. Ask your Qualified Individual to document the approach.

Rollout phases for a financial services Kafka platform

This sequence moves a self-hosted Kafka platform from regulatory scoping to a handed-over, evidenced service in a deliberate order, so each phase confirms the inputs the next one depends on. Durations for each phase are set in the written scope, after the boundaries and environment are known.

Scope data and regulatory boundaries
Map which topics will carry payment, ledger, customer or cardholder data, which regulations apply to each flow (for example PCI DSS for cardholder data and DORA for ICT risk and third-party arrangements where the entity is in scope), and which systems will consume the events. Confirm with compliance and legal which entities are in scope, and record the data classification per flow. Done means a signed scope document listing in-scope flows, data categories, hosting locations and named owners, so later design choices can be traced back to it.
Select version and runtime against upgrade notes
Choose a supported 4.x release from the Kafka downloads page, and confirm it against the upgrade notes for your runtime. Kafka 4.0 and later run in KRaft mode only, and brokers and Connect require Java 17, so any ZooKeeper-era or older KRaft cluster needs a planned path first. Your team confirms the JVM, operating system and container base images the vendor build will use. Done means a written version record, a tested runtime image and a documented upgrade path for the next release line.
Build KRaft cluster and security baseline
Bootstrap the KRaft controllers and brokers in the environment you control, with TLS on every listener and an authentication mechanism chosen from the documented SASL options or mutual TLS. Configure the StandardAuthorizer with deny-by-default behavior, and keep allow.everyone.if.no.acl.found disabled. Store secrets outside configuration files and enable audit logging of administrative actions. Done means a baseline configuration reviewed by the security team, with a test showing an unauthorized client is refused.
Run pilot topics with ledger consumers
Start with a small number of non-production or shadow topics carrying representative ledger and payment events, and connect the consumers that will depend on them. Verify ordering within partitions, producer idempotence and transactional behavior where ledger postings need exactly-once effects, and confirm that consumers recover correctly after restarts. Done means the ledger and reconciliation owners sign off on message counts, ordering, replay results and the retention settings for each pilot topic.
Test cross-site replication and failover
Configure MirrorMaker 2 between the primary and recovery sites, which replicates topics with their configuration, consumer group offsets and ACLs while preserving partitioning. Run planned failover and failback exercises, measure what data is missing or duplicated after switchover, and document the consumer offset translation steps. Done means recorded test results against the recovery objectives agreed in the scope, and a runbook that operations staff have executed at least once.
Collect evidence for assessors
Gather the artifacts an assessor or supervisor will request: the scope and data flow inventory, configuration baselines, ACL exports, access review records, change logs, backup and restore results, incident and failover test reports, and the register entry for the Kafka platform as an ICT service. Confirm with your assessor which formats they accept. DeployOpen prepares this evidence but does not issue audit reports or attestations, which come from independent auditors or certification bodies. Done means an indexed evidence folder mapped to the control requirements in scope.
Hand over runbooks and operating model
Transfer the platform to your operations team with runbooks for routine tasks, upgrades, certificate rotation, topic onboarding, incident response and failover. Agree the support model, whether internal only or backed by a retainer, and confirm escalation paths. Run a knowledge transfer session and observe the internal team completing a supervised change. Done means signed handover documents, named operators for each runbook, and a dated plan for the next Kafka release review.

What drives the cost and effort of a regulated Kafka build

A regulated Kafka build is priced by how much regulated data flows through it, how many systems it touches and how much evidence the institution must produce. The six cards below separate the one-time build work from the work that recurs after go-live, so you can compare quotes on the same basis.

Scope of regulated data flows

Each topic that carries cardholder data, account data or customer identifiers widens the design: encryption, access rules, retention and the data-flow diagrams that assessors ask for. Ask the partner to list every topic and producer or consumer that touches regulated data, and to state which ones sit inside the cardholder data environment. A small number of clearly bounded flows usually costs less to build and to assess than a platform where regulated and non-regulated events share brokers. This is a one-time design cost that grows with each new flow added later.

Core and payment system integrations

Every connection to a core banking ledger, payment switch, card processor or fraud engine needs a producer or consumer, schema agreement, error handling and reconciliation logic. Each integration is a separate build item, and integrations to systems you do not own often carry the longest lead times. Ask for a per-integration estimate that names the system, the direction of flow and whether the vendor's own connector is reused. Integration work recurs whenever a partner system changes its API or message format.

Identity and access integration

Kafka authenticates clients with SSL or SASL, and the documented SASL mechanisms include GSSAPI (Kerberos), SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Connecting these to your workforce directory, service account lifecycle and secrets store adds design and testing effort. Confirm who approves ACL changes, how service credentials rotate and whether the chosen mechanism matches your existing identity provider. Most of this work is one-time, but credential rotation and access reviews recur every cycle.

Number of sites and replication design

Running a primary and a recovery site, or an active-active pair, adds broker capacity, network links, failover runbooks and tests of each switch. MirrorMaker 2 replicates topics, consumer group offsets and ACLs between clusters, but the replication topology, offset translation and failback procedure are design decisions that must be documented and tested. Ask how many clusters are planned, which direction replication runs and how failover is exercised in a test window. Testing and runbook upkeep recur with every platform upgrade.

Evidence and testing depth

Assessors and supervisors want proof that controls operate, not just that they were designed. The effort depends on how much evidence is collected: ACL exports, configuration baselines, access reviews, restore test records and penetration test reports. Ask the partner which evidence artifacts are produced by default, which must be built, and who reviews them. DeployOpen prepares systems, controls and evidence for assessments, but independent assessors issue any report or attestation, so confirm that boundary in the statement of work.

Ongoing retainer support

After go-live, the platform needs patch and upgrade cycles, monitoring, capacity reviews, certificate rotation and periodic failover tests. These are recurring costs, usually handled through a retainer rather than a fixed project. Ask what the retainer covers, response expectations, how upgrades are scheduled around change freezes and whether testing is included or billed separately. Confirm the terms in writing, because supervisory expectations for ongoing ICT operations continue after the build is finished.

Questions buyers ask before hiring help for Kafka in financial services

What does outside help for a regulated Kafka build cost, and what drives the price?

The price follows from the written scope, not from a list, and DeployOpen does not publish a price list. The main cost components are architecture and design, the build of brokers and clients in your environment, identity and access integration, cross-site replication, testing, and the evidence pack your compliance team needs. Costs rise with the number of topics and consuming systems, the number of sites, the amount of cardholder or customer data flowing through, and how much of the control evidence must be produced. Ask each bidder to separate one-time build work from recurring items such as upgrades, monitoring support and retained testing. Ask for the assumptions behind each line, including which of your systems are in scope.

How long does a regulated Kafka build take, and what sets the timeline?

The duration depends on the agreed scope, and it is fixed in the written scope before work starts. The largest drivers are the number of sites and whether cross-site replication is needed, how many payment, ledger or core banking systems must connect, the speed of access approvals and network changes inside your bank, and how long your risk and compliance reviews take. Dependencies on your change board and third-party contract reviews often matter more than the build itself. Ask for a plan with named milestones, the decisions that must close before each milestone, and the review gates your regulators or assessors expect to see.

What must the bank provide to a Kafka implementation partner?

The bank provides the people and decisions that only it can supply. You need a solution architect who owns the topic and data model, an identity owner for SSO, directory and service accounts, a network owner for routing, firewall and DNS changes between sites, and a compliance owner who can state which controls apply and which evidence is needed. You also need access to the cloud accounts, data centers or air-gapped networks where the cluster runs, and a named person who approves production changes. Confirm these roles early, because a missing owner usually delays the build more than any technical issue.

Can our own engineering team build a Kafka platform for payments in-house?

Many teams can run Kafka in-house, but the question is whether they have the skills and time for the whole lifecycle. Kafka is licensed under Apache-2.0 and the project itself offers no paid edition, so the cost is staff time, infrastructure and supporting tooling. The skills needed include KRaft cluster operations, TLS and SASL configuration, ACL design, monitoring, backup and replication, and the documentation auditors read. Assess your team against that list, plan for at least one person who can own the platform after go-live, and decide whether a partner is needed for the design, the first build, or ongoing support. A hybrid model, where the partner builds and your team runs it, is a common choice.

Does running Kafka make us DORA or PCI DSS compliant?

No. Kafka is a software component, and neither DORA nor PCI DSS certifies a product. DORA, Regulation (EU) 2022/2554, applies to financial entities and requires you to manage ICT risk, incidents, resilience testing and third-party arrangements, and the exit strategies and contract terms for ICT services. PCI DSS applies to entities that store, process or transmit cardholder data or could affect that environment, and it is assessed through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance. Kafka can support some controls, such as TLS, authentication and authorization, but the surrounding policies, monitoring, testing and evidence are your responsibility. DeployOpen prepares systems, controls and evidence for assessments, but does not issue audit reports, attestations or certifications. Independent assessors and competent authorities make those determinations.

How are Kafka upgrades and ongoing support handled after go-live?

Upgrades follow the project's release plan and upgrade notes, and they must be planned rather than applied on release day. The Kafka project supports rolling upgrades from each release in the past year to the latest version, and Kafka 4.0 supports only KRaft mode, so any ZooKeeper-based cluster must migrate first. Supported releases listed on the downloads page are 4.3.1, 4.2.2 and 4.1.2. Ask any partner how it tests each upgrade in a non-production copy, how it handles client compatibility, and how rollback is handled. Ongoing support, upgrades and continuous testing are available as retainers, and their scope should be written down alongside the build.

What should we ask a partner to show before signing a Kafka statement of work?

Ask for a written scope that lists sites, topics, consuming systems, security controls and deliverables, along with the acceptance tests that close each phase. Request the design for authentication, authorization and encryption, the cross-site replication approach, and the backup and recovery plan. Ask which evidence will be handed over, such as configuration records, access reviews, test results and runbooks. Confirm how changes to the scope are priced and approved, and who owns the cluster after the engagement ends. Finally, ask how the exit and data return plan would work if you change providers, since DORA expects those terms to be documented for ICT services that support critical or important functions.

What to ask a partner before you sign a Kafka statement of work

Start by asking how the partner maps DORA and PCI DSS evidence to the Kafka deployment. Ask for the list of artifacts they will hand over, and for each one, which requirement it supports and who owns the control afterward. For DORA, that means the register of information entries for the Kafka platform and its hosting, the exit strategy and transition plan that Article 28(8) requires for ICT services supporting critical or important functions, and the contract terms in Article 30(2) covering locations and data return. For PCI DSS, ask which brokers, Connect workers and client hosts fall inside the cardholder data environment, and how they will document that scope. Confirm in writing that the partner prepares evidence only and that your assessor or auditor issues the conclusions. DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or attestations.

Ask where every component will run, which regions hold topic data and backups, and how the partner will give advance notice of any change to those locations. Ask for the exit plan in writing before signature: how topics, consumer offsets and ACL definitions would be exported, and what a cutover to another cluster would look like. Then ask for the failover test plan: which broker failures, rack or site losses and MirrorMaker 2 switchovers they will run, what the pass criteria are, and whether they will test that replicated consumer group offsets and ACLs resume as expected on the secondary cluster. For access control, ask them to demonstrate, on a test cluster, that resources without ACLs are denied unless allow.everyone.if.no.acl.found is set, and to show how each service principal is limited to the topics it needs.

Ask who holds the super user credentials, the controller and broker certificate authorities, and the SCRAM or Kerberos administrative accounts on the day after handover, and how each one is recorded and rotated. Your team should hold break-glass access in a vault you control, with the partner's access removed or time-limited. For fixed-price work, ask the partner to list the assumptions behind the price: the number of clusters, sites, environments, topics and connectors, the identity provider integration, and the number of evidence reviews. Ask which changes trigger a change order and what the rate is for work outside scope. Ask which costs are one-time, such as build and test, and which recur, such as upgrades, patching and retained support. A quote should name each of these components separately.

How DeployOpen scopes and delivers a financial services Kafka platform

This sequence turns a financial services Kafka requirement into a written scope, a build inside your own accounts or data centers, and a set of controls and evidence your assessors and supervisors can review, with retainers available afterward.

Confirm the regulatory perimeter and workloads
DeployOpen and your compliance, risk and payments teams first identify which entities, payment flows and ledgers are in scope for DORA, PCI DSS, Swift CSCF or SOX-relevant controls, and which Kafka topics carry cardholder data, personal data or financially significant events. Your team confirms which regulator supervises each entity, because that determines the evidence set. The output is a scoping memo that lists each topic and its classification, so no later design decision is made against an assumed boundary.
Agree the written scope and deliverables
DeployOpen drafts a fixed-scope proposal that names the Kafka version and deployment target, the KRaft topology, the number of sites, the authentication and authorization model, the integrations, the testing and the documentation deliverables. Your procurement, legal and security leads review it, including where services are provided and data processed, and the exit and data return terms your contracts need under DORA. The output is a signed scope with acceptance criteria for each deliverable.
Design the platform and its controls
DeployOpen designs the cluster layout, partition and retention plans, TLS and SASL listeners, ACL model, secrets handling, cross-site replication with MirrorMaker 2, and logging. Each control is mapped to the framework requirement it supports, so the design reads as evidence rather than configuration. Your architects review and approve the design record, and the output is an approved architecture and control matrix that names the owner of each control.
Build inside your accounts and data centers
DeployOpen deploys the platform into cloud accounts, data centers or restricted networks you control, using infrastructure-as-code and version-controlled configuration that your team can read and retain. No client data or credentials leave your environment during the build. The output is a reproducible environment where every change is traceable to a reviewed commit and an approved change record.
Test resilience, access and failover
DeployOpen runs functional, security and failover tests against the build, including broker failure, controller failover, ACL enforcement, TLS verification and a replication failover exercise between sites. Results are recorded with the test scenario, the expected outcome, the actual outcome and the remediation. Your risk owners sign off on the exit criteria. The output is a test report that also serves as evidence for operational resilience reviews.
Document controls and hand over evidence
DeployOpen delivers runbooks, the architecture record, the control matrix, the access review procedure, the backup and restore records, the exit and transition plan, and the list of third parties involved. Your team receives the evidence set in a structure that matches the assessment you expect, such as ROC preparation for PCI DSS or the DORA register inputs. DeployOpen prepares this material, but independent auditors, assessors and supervisors decide what it proves. The output is a documented handover accepted by your control owners.
Train operators and transfer ownership
DeployOpen runs knowledge transfer sessions with your platform, security and operations staff, covering day-two tasks such as partition changes, certificate rotation, access reviews, upgrades and incident response. Ownership of each runbook and each control moves to a named role in your organization. The output is a signed transfer record and a list of open items with owners and dates agreed in writing.
Maintain through retainers
After handover, DeployOpen can support upgrades along the documented Kafka upgrade path, patching, and continuous testing under a retainer agreed in writing. Your team decides which activities stay in-house and which go to the retainer, and the retainer scope lists the response expectations, reporting cadence and evidence refreshed each cycle. The output is a maintained platform whose controls and evidence stay current with each Kafka release and each assessment cycle.