A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at pcidss@pkfmalaysia.com and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!