0

The Problem

I have two systems.

System A - E-commerce application that handles (does not store cc) customer credit data during purchase.

System B - Invoicing system for these transactions (does store cc).

System A is pre-launch, will be low volume and we plan on doing an SAQ-D eventually.

System B is currently PCI compliant.

System B has a rest API that accepts cc information for handling invoicing (CC data enters, but is not returned).

The Question

In this case I believe the current PCI status of system A has no bearing on system B.

The security of system B's API is naturally in scope. The security of the calling system (remember this is inbound cc data transfer only) is not relevant.

Agree or disagree?

Improve this question
2
  • What if system A caches CC data to disk, which it is likely to do from time to time. Wouldn't it then come into scope for PCI?
    – Geir Emblemsvag
    Commented Nov 5, 2021 at 5:42
  • Yes, but not for the PCI scope of B right? Which has its own scoped AOC.
    – mconlin
    Commented Nov 5, 2021 at 12:44

2 Answers 2

Reset to default
1

The core question is whether System A is

connected to or, if compromised, could impact the CDE (for example, authentication servers)

(v3.2.1 p10 scoping)

In this case I'm assuming system B is your current CDE. To some degree, system A is connected to system B as it can call the API. If your argument is that there is sufficient other controls and there is only the ability for system A to call the API and so system B is isolated from system A, you would need to validate that by penetration testing (requirement 11.3.4). Then yes, the status of A does not affect B.

A small point is that it is entities that have to validate PCI DSS compliance, not systems.

Improve this answer
1

Even though system A doesn't store card data, it very much sounds like it processes and transmits it. So it will most likely be in scope for SAQ-D. This needs to be done before the system starts accepting card details, not "eventually".

This could probably be be a separate PCI scope from system B (although if both systems are owned by the same organisation, you're probably just making more work for yourself that way).

So while it may not impact on whether or not System B is PCI compliant, it will impact on whether your organisation is PCI compliant - and that's the more important issue. If you get compromised and end up losing card details, saying "one of our systems is PCI compliant" isn't going to fly.

Improve this answer
1
  • Yes and I totally understand your point about org and multi scopes etc.. but in the context of simplifying this question I am leaving out the bigger picture. So you agree that B's status is not impacted by the status of A.
    – mconlin
    Commented Nov 5, 2021 at 12:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .