PCI DSS compliance

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

Is Olympus in scope?

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

But: Olympus can be adjacent to PCI scope. If your app processes payments and Olympus authenticates the operators viewing payment data, Olympus 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.

Olympus helps:

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

In this model, Olympus is out of PCI scope.

When Olympus 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 Olympus (Olympus 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 Olympus's logs reach.
• Use tokenization (Stripe Customer + Subscription pattern, see Cookbook, Stripe subscription gate).

PCI DSS 4.0 requirements that map to Olympus

Self-Assessment Questionnaire (SAQ)

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

If you process cards directly: SAQ D, much more demanding. Olympus 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).

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

Related

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