PCI DSS compliance

The Payment Card Industry Data Security Standard regulates entities handling cardholder data (PAN, CVV, etc.).

Is Ionize in scope?

Generally, no. Ionize handles auth, not payment-card data. PAN/CVV should never touch Ionize.

But: Ionize can be adjacent to PCI scope. If your app processes payments and Ionize authenticates the operators viewing payment data, Ionize is on the perimeter of the Cardholder Data Environment (CDE).

Scope reduction

PCI DSS encourages scope reduction, keep Cardholder Data (CHD) out of as many systems as possible.

Ionize helps:

• Stripe, Adyen, Braintree handle PAN directly. They tokenize.
• Your app stores only the token, not the PAN.
• Ionize authenticates your app's users, who see masked data (last 4 digits, etc.).

In this model, Ionize is out of PCI scope.

When Ionize is in scope

• If you store any PAN in identity traits (don't).
• If you process raw cards through your app and your app shares auth with Ionize (Ionize is then on the boundary; auditor scopes "connected systems").
• If audit logs contain PAN.

To avoid:

• Don't store payment data in Kratos traits.
• Don't log payment data anywhere Ionize's logs reach.
• Use tokenization (Stripe Customer + Subscription pattern, see Cookbook, Stripe subscription gate).

PCI DSS 4.0 requirements that map to Ionize

Self-Assessment Questionnaire (SAQ)

Most companies file SAQ A (e-commerce, all CHD outsourced) or SAQ A-EP (partial outsourcing). Ionize typically lets you stay at SAQ A.

If you process cards directly: SAQ D, much more demanding. Ionize is then part of your CDE; controls multiply.

Reducing identity-attack risk on payments

Even with PAN tokenized, account takeover lets an attacker:

• Place fraudulent orders.
• Access existing payment methods.
• See order history (data leak).

Ionize's brute-force protection, MFA, breach-check directly mitigate this.

Related

• Security, Threat model
• Security, Brute-force protection
• Cookbook, Stripe subscription gate