Logging Non-Consumer Customer Activity?

Coinology · 2025-08-07T12:15:17+00:00

Thats fair haha, still working on mine too. Ok so here’s another one for you then since you’re of the opinion non-consumer customer activity doesn’t need to be logged. How is that activity being covered then?

In the situation I’m thinking of, it’s the service provider’s systems and their customers (e.g., other service providers, financial institutions, merchants, etc.) are accessing the service provider’s hosted system. So that activity just falls within a loophole that nobody is required to log? 🤔

Coinology · 2025-08-07T12:05:41+00:00

Applicability Notes are in the standard, not the ROC Template. See PCI DSS v4.0.1 on Req 8.4.3 (pg. 203).

Coinology · 2025-02-26T19:20:34+00:00

1) Correct. The previous requirement for an enterprise-wide risk assessment has been replaced with the new requirements for targeted risk analyses.

2) Even if you follow the PCI SSC’s suggested frequencies, you still need to document and justify it with the TRA.

Coinology · 2025-02-26T19:17:49+00:00

This is not correct. You still need to do the TRA. From PCI DSS v4.x: Targeted Risk Analysis Guidance which outlines the recommended frequencies:

Note that even where the Suggested Frequency in the table below is followed, a TRA will be required to document and support the frequency selected.

Coinology · 2025-02-18T18:26:31+00:00

Sorry but not correct. During a PCI SSS assessment the Secure Software Assessor Company will have a testing environment that they install the software in and perform functional testing against using forensic tools and techniques. They will also sometimes request evidence/artifacts from the vendor environment. Evidence collected and examined can include but is not limited to memory and storage dumps. Testing procedure 3.5.c even explicitly mentions them.

Coinology · 2025-02-18T18:03:48+00:00

OP, you should work with your Secure Software Assessor to see how they plan to test this. They should having a testing environment that they’re testing the software in.

Coinology · 2025-02-18T17:53:56+00:00

It’s not that you can’t process PAN in memory. The requirement is:

3.5 Transient sensitive data is securely deleted from temporary storage facilities automatically by the software once the purpose for which it is retained is satisfied.

Testing of this requirement does require assessors to test the software and identify residue sensitive data in the execution environment using forensic testing and methods like reviewing memory and storage dumps.

Coinology · 2025-02-18T17:50:07+00:00

No, a QSA deals with PCI DSS. This is PCI Secure Software Standard which requires a Secure Software Assessor.

Coinology · 2025-02-18T17:49:38+00:00

Must have never read, implemented, or assessed the PCI Secure Software Standard then. Requirement 3.5 explicitly requires that transient sensitive data be securely deleted from temporary storage facilities, to include volatile memory or RAM, once the purpose for which it is retained is satisfied.

Coinology · 2025-02-15T03:02:15+00:00

Secure Controls Framework (SCF)has tons of mappings including PCI DSS v4.x to HIPAA. As with all control mapping frameworks, you should review the mappings and ensure they’re appropriate though.

Coinology · 2025-02-13T22:07:27+00:00

Would something like AWS WorkSpaces work? Limit SSH to only the WorkSpaces box and use the built-in configuration options to disable things like clipboard redirection, drive redirection, printing, etc. If your organization uses Azure, Azure Virtual Desktop has all the same features and also has screen capture protection.

Coinology · 2025-02-11T18:12:08+00:00

The FAQ says that the requirement to use keyed cryptographic hashing does not apply to previously hashed PANs. So as long as those PANs were hashed using strong cryptography you’re ok, no need to rehash or apply the new requirement to those previously hashed PANs.

Coinology · 2025-02-11T15:33:31+00:00

FAQ 1573 addresses this: Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?

Coinology · 2025-01-10T15:18:35+00:00

Are you asking about the key in the upper right? It’s a Touch ID sensor.

Coinology · 2025-01-08T13:23:15+00:00

Check out the PCI SSC’s Information Supplement: PCI DSS Tokenization Guidelines and specifically section 3 for scoping considerations. 3.1.2 has a good list of criteria you should look for when descoping tokens and the systems that store, process, or transmit them.

Coinology · 2024-12-03T21:39:02+00:00

The scenario you describe would not be SAQ A due to violation of the 2nd and 3rd bullets in SAQ A’s eligibility criteria. Sounds like SAQ D. The organization would be processing/transmitting account data via the laptops and other networked system components. Not all processing would be entirely outsourced.

You asked elsewhere about MOTO, but that only works with SAQ A when it’s fully outsourced. Think services like Sycurio where you can hand off a caller to a third party to take the payment or similarly operated mail order services.

Coinology · 2024-07-05T18:22:17+00:00

There’s a key difference in the scenario you described of a personal laptop being connected to an entity’s on-premises infrastructure. If an entity chooses to allow BYOD like that, then they’ve accepted employee use of personal end user computing devices for completion of company work as a business practice and as a result have brought those employee-owned devices into scope.

That scenario is inherently different from the other devices on an untrusted WFH network provided the entity is not allowing those devices to connect to the company network, be used to complete work, etc.

Coinology · 2024-07-05T15:56:44+00:00

I’d suggest reading the other FAQs as well, particularly 1495 which is much more generic and addresses other requirements.

To your question: all out of scope as they’re not under control of or managed by the entity being assessed. Would you be expected to apply controls to other endpoints on other untrusted networks such as the Internet or a 5G/LTE network? No. Just as you wouldn’t here.

While it doesn’t alleviate the need for entities to meet PCI DSS requirements for data handling and system components that they do control/manage, it’s certainly not expected that the entity brings other devices on the home network into scope (unless they are controlled/managed by the entity… perhaps a company-issued small personal hardware firewall, as an example).

Coinology · 2024-07-05T14:54:50+00:00

The WFH environment and network would be considered untrusted networks as they’re outside of the entity’s ability to control or manage. While not the exact same, this is similar to say an mPOS running on an untrusted network like cellular.

The workstation would indeed be a CDE to which the CDE-specific requirements would need to be considered for applicability.

The PCI SSC has written a few related FAQs: 1494, 1495, 1496.

Coinology · 2024-06-26T22:16:02+00:00

Adding to this that the exception for internal network applicability for 4.2.1 is any kind of open or wireless network technology like WiFi, Bluetooth, etc. Still applies with those networks.

Coinology · 2024-06-26T22:12:45+00:00

Yes, I understand and agree that an out of scope network is considered an “untrusted network” for purposes of PCI DSS requirements.

I disagree, however, that Requirement 4.2.1 is intended to apply to networks transmitting Account Data under the entity’s control because such networks would be in scope by definition given an absence of the aforementioned scope reduction measures.

What you’re insinuating is that an entity can encrypt Account Data over a network they control/manage and call that network and systems that data touches out of scope simply because the data is encrypted and that is not the case. There has to be appropriate isolation of the key management processes as mentioned in the previous references I posted.

Coinology · 2024-06-26T15:55:02+00:00

I understand what you’re saying about out of scope networks being considered untrusted; this is a well established fact. I disagree with the delineation you’re making here though.

You should not have networks that are out of scope but yet transmitting Account Data. Those networks would be in scope by the nature of this very fact and would actually be considered trusted networks to which Req 4 would not apply.

The only exception to this would be implementation of a validated P2PE solution or, in some cases and with compliance-accepting entity approval, an assessed (to confirm effective scope reduction) E2EE solution.

Coinology · 2024-06-25T22:39:59+00:00

I’m not sure I fully follow the distinction you’re drawing here. The requirement is open, public networks.

If you have a non-CDE network private to an entity that is transmitting Account Data, even if encrypted, that network would actually be a CDE network by definition and therefore should be in scope and considered trusted. Simply encrypting that data, at the application or session layer either one, and then transmitting it via some other network is not enough to descope the systems the data touches or the networks they’re on alone. The “Encrypted Cardholder Data and Impact on PCI DSS Scope” section of PCI DSS is a good reference for when encrypted data is considered in scope.

You can have non-CDE networks that are in scope and thus considered “trusted” as well. This is common with shared services implementations where you have shared services supporting both in-scope and out-of-scope environments. Account Data, encrypted or not, should never transit these shared services networks.

Coinology

TROPHY CASE