PCI DSS 4.0.1 and HIPAA Compliance Checklist for Kafka and Redis

They are in scope when your own scoping says so, and that decision belongs to you and your assessor. PCI DSS v4.0.1 applies to the people, processes and system components that store, process or transmit cardholder data and sensitive authentication data (together, account data), and to components that have unrestricted connectivity to them or could affect their security. A broker that carries payment events, or sits on a network segment with the cardholder data environment, is therefore in scope even if no card number is ever written to a topic. The HIPAA Security Rule applies to electronic protected health information held or transmitted by a covered entity or business associate, so a topic, cache, backup or snapshot that contains ePHI is in scope wherever it runs. HIPAA calls its three groups of controls the administrative, physical and technical safeguards, and the tables below cover all three for a broker.

Two things shrink the work. Keep account data and ePHI out of the broker where you can, by tokenising before you produce or cache it, and segment the brokers from everything that does not need them. Two cautions apply to all the tables that follow: a row is a check that supports a requirement, not proof that you meet it, and requirement wording changes between versions.

Allow only the listeners and ports you have approved and written down, remove plaintext and default credentials, and encrypt administrative access. These four checks cover PCI DSS requirements 1, 2.2 and the configuration standards behind them.

Neither product encrypts stored data for you, so make the data unreadable before it is written. PCI DSS 3.5.1.2 says disk-level or partition-level encryption counts on its own only for removable media; on other media the account number must also be made unreadable another way. That rules out relying on an encrypted volume alone for a primary account number in a topic or a cache.

Every person and application gets its own identity with the least privilege its job needs, enforced through role-based access controls, authenticated with a strong mechanism and reviewed every six months. Requirements 7 and 8 drive most findings on brokers, because the defaults are open.

Log every access and administrative action, ship the logs off the host, keep 12 months with the latest three immediately available, and review them daily with automated tooling. Neither product gives you this out of the box.

Patches for critical vulnerabilities must be installed within one month of release under requirement 6.3.3, and other severities follow your own risk ranking. Version 4.0.1 removed the words "high-security" that v4.0 had in 6.3.3, so check your assessor's reading before you plan a window for high-severity fixes.

Unique identification, authentication, access authorization and audit controls all apply to a broker that holds ePHI. In the tables below, "addressable" does not mean optional: under 45 CFR 164.306(d) you assess the specification and either implement it or document why an equivalent alternative is reasonable. In January 2025 HHS proposed removing the required and addressable distinction (90 FR 898); as of 28 October 2026 no final rule has been published, so the Security Rule text in force is the 2020 text cited here.

Encrypt in transit, add your own protection at rest, and design the cluster so an acknowledged write survives a failure. Encryption at rest and in transit are both addressable specifications (164.312(a)(2)(iv) and 164.312(e)(2)(ii)), so document your decision either way.

Put the brokers in your risk assessment, sign a business associate agreement with any provider that can reach ePHI, and keep your documentation for six years. These rows are process duties, so the Kafka and Redis columns are the same.

Every safeguard in the Security Rule comes down to one duty: ensure the confidentiality, integrity and availability of all electronic protected health information (ePHI) you create, receive, maintain or transmit (45 CFR 164.306(a)(1)). A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a covered transaction (45 CFR 160.103). If protected health information (PHI) passes through a Kafka topic or sits in a Redis cache, the brokers are part of that duty. The Rule sorts its standards into administrative (164.308), physical (164.310) and technical (164.312) safeguards, and the technical safeguards are the ones you set in the broker.

• Access control. Assign every person and application a unique identity, document emergency access, and consider automatic logoff and encryption (164.312(a)). The Rule does not name role-based access control, so show how your ACLs give each role the permissions it needs and no more.
• Audit logging. Record and examine activity in systems that hold ePHI (164.312(b)), and review audit logs, access reports and security incident reports on a schedule (164.308(a)(1)(ii)(D)). Log access attempts, both allowed and denied, and ship the logs off the broker.
• Authentication. Verify that a person or entity is the one claimed (164.312(d)). The Rule does not require multi-factor authentication (MFA) by name. If you use MFA for administrative access, record it as one of the measures that meets this standard.
• Transmission security. Guard against unauthorized access to ePHI sent over a network (164.312(e)(1)), which is why every listener, replication link and client connection needs TLS.
• Risk analysis and remediation. Assess the risks and vulnerabilities to ePHI, then implement security measures that reduce them to a reasonable and appropriate level (164.308(a)(1)(ii)(A), (B)). Track each gap you find through remediation, set a remediation timeline in your own policy, and keep the record.
• Business associate agreement (BAA). A covered entity may let a business associate handle ePHI only after obtaining satisfactory assurances, in the form of a BAA, that the information will be safeguarded (164.308(b)(1)).

The Rule gives you flexibility of approach: you may use any security measures that reasonably and appropriately implement the standards, taking into account your size, complexity, capabilities, costs and risks (164.306(b)). So these lines show what to document, not a single required configuration. Text checked against 45 CFR Part 164, Subpart C (eCFR) and 45 CFR 160.103 on 28 October 2026. Whether your estate is in scope, and what satisfies your assessor, is a decision for your compliance team.

Collect the same six items for every cluster, dated, so the assessor sees a pattern and not a one-off:

1. The written configuration baseline and a diff of the running configuration against it.
2. The listener and port inventory with the business reason for each (1.2.5).
3. An export of ACLs and users with the date of the last review and the approver (7.2.4).
4. The certificate inventory and expiry dates (4.2.1.1).
5. Log samples showing a denied request and an administrative change, and the retention setting (10.2, 10.5.1).
6. The patch record: advisory, risk ranking, date released, date installed (6.3.3).

AceMQ operates and supports the brokers; it does not assess or attest your compliance, which is your QSA's or auditor's job. For Kafka and Redis estates AceMQ's published evidence for these estates is a written patch and CVE record per advisory, incident and change history, and a written root cause on every P1. The compliance page states a 72-hour target for critical CVEs with a record per advisory, which sits inside the one-month window in 6.3.3. AceMQ supports 160+ customers, has been in business more than 10 years, handles 40+ Severity 1 incidents a year and responds to a P1 in 15 minutes, 24/7.

AceMQ is the wrong choice if you need a PCI assessment, a HIPAA risk analysis or legal advice, or if your brokers are fully hosted by a cloud provider that supplies its own attestation. In that case the provider's evidence matters and the work above shrinks to configuration of your own topics and clients. Regular AceMQ support contracts run $24,000 to $72,000 a year by SLA, scope and deployment.

Requirement numbers and wording come from PCI DSS v4.0.1 (June 2024, PCI Security Standards Council document library) and from 45 CFR Part 164 Subpart C at the eCFR. Version 4.0 was retired on 31 December 2024, and the requirements that were future-dated became mandatory on 31 March 2025. Product behaviour was checked against the Apache Kafka security documentation (release 4.4), the Redis security documentation and the Valkey security documentation on 28 October 2026. Valkey follows Redis for the ACL, TLS and protected-mode behaviour in this checklist, but we did not check its ACL LOG fields, so confirm them for your version.

This page is a configuration checklist, not legal advice or an assessment. Scope, compensating controls and sign-off are decisions for your qualified security assessor or compliance team.