If you are struggling with understanding the “Scope” of your cardholder data environment (CDE), refer to the PCI SSC scoping guidance document (https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf). This is to help entities appropriately scope their cardholder data environment for PCI DSS.

Why publish?

Many entities still struggle with determining the scope for various factors, which may include:

  • Many interpretations of adequate segmentation.
  • Motivations for reducing scope.

Why scope is important?

Scoping is still a hot topic. Improper scoping may result in not identifying cardholder data (CHD) or intended/accidental cardholder data leakage. An unidentified cardholder data area is a desirable area for hackers and may lead to a breach.

The scope for PCI DSS includes systems within the cardholder data environment (CDE) that process, store or transmit CHD, connect to the CDE, or impact the security of the CDE.

Conversely, bad interpretations can lead to over scoping which is unnecessary and results in ineffective use of resources.

The first stage is to identify the critical people, processes and technology in-scope. Only then can you apply the relevant PCI DSS requirements. Believe me, this is never ever a trivial exercise and again we emphasise the need for good interpretation.

What is in-scope for PCI DSS?

We can be here for a long time, so I’m just going to summarise the document:

  • CDE system: The system processes, stores or transmits cardholder data (CHD); OR a system is in the same network (e.g. VLAN) as systems that store, process or transmit CHD.
  • Connected-System OR a security-impacting system: Something that connects inside to the CDE, or could impact the security of the CDE.

Sometimes the above may be too generic to apply security controls. Here is a possible category method of what in-scope for your PCI DSS assessment by categorising them:

  • Type 1a (Systems that process, store or transmit CHD): This should be self-explanatory. These are systems whereby cardholder data is present and could be stolen.
  • Type 1b (Systems inside the CDE): These systems are in the same network segments as Type 1 systems and can be used as an attack vector to steal cardholder data.
  • Type 2a (Connected To): Systems directly accesses the CDE via controlled access boundary systems (e.g. firewalls, routers etc.). These systems establish a connection into the CDE or receive communication from the CDE.
  • Type 2b (Connected To): Systems that indirectly accesses the CDE via controlled access boundary systems (e.g. an administrator workstation that indirectly uses a jump server).
  • Type 2c (Impacts Security of CDE): Any system that could impact the CDE, such as systems that control access, segmentation, patch distribution, logging and monitoring tools.

Controlled access

Controlled access from say “zone A” into the CDE does not mean the network is fully segmented. However, this also does not mean every single system component in zone A is in scope! It means that these communications are more secure than uncontrolled systems. These restricted communications should be considered in-scope.

Any segmentation controls to fully restrict access must be penetration tested at least annually as per PCI DSS requirement 11.3.4 to ensure segmentation is still effective.

The following statement is interesting:

“It is important to understand the risks and impacts if connected-to system components are excluded or overlooked from PCI DSS scope.”

The way I read this is if a connected-to system is excluded from PCI DSS scope, the risk and impact should be determined first. Let’s consider this scenario:

  • A large bank whereby there are 15,000+ user workstations all connecting into a virtualised environment.
  • The virtualised environment supports the core banking system (that may process CHD) and non-CHD processing systems.
  • A smaller proportion of 2,000 only access the core banking system via secured applications or secured browser (HTTPS), presented on their desktop via role-based access virtualised system.

The virtualised environment is in-scope as it supports the core banking system and card-processing applications.  Does the 15,000+ workstations connecting into the virtualised environment mean all 15,000+ workstations are in scope?  Maybe “yes” as each workstation is accessing the virtualised environment hosting the CDE, but maybe “no” as controls may be in place to restrict the presentation of access and applications on the desktop where the user role requires it.

Shared services

There are some systems components that may provide a service to the corporate network and CDE. I consider these “management systems”, which provide management or security functions such as:

  • Directory and authentication (Active Directory, LDAP, AAA etc.)
  • SMTP
  • Anti-virus
  • Logging and monitoring
  • Bastion Host/Jumpbox

For this reason, you do not want the full corporate network being able to communicate with these management systems – these management systems / shared services should be in their own management zone:

  • Only those components within the management zone can then connect into the CDE.
  • Corporate LAN can connect to the management zone / shared services.

Administrator workstations are categorised as a “Connected To” device, perhaps see Type 2b above and are in-scope for PCI DSS review.

Who is responsible for determining scope?

We must reminds ourselves that the assessor is independent. The responsibility for determining the scope is the entity being assessed. The entity should confirm the people, process and technology in scope and retain documentation how this was determined. The assessed entity is responsible for annually determining the scope.

The assessor trusts, but verifies this to confirm the scope is defined and documented properly. However, should the scope not be correct, the assessor must work with the entity to determine the correct scope prior to the assessment to determine boundaries and applicable requirements.


Scoping will always be down to interpretation and the scoping guidelines published from the PCI SSC will help. Therefore, the opinions in this document are mine alone. You need to work with your assessor to determine their interpretation of the standard and scoping. Please see key findings below:

  • Connected-to systems has more clarity of what is in-scope. Any systems to be excluded for scope and must be evaluated and risk assessed.
  • Administrator workstations connecting directly or indirectly to the CDE are always in-scope.
  • Important to note no solution eliminates all PCI DSS requirements. The applicability of requirements depends on the system function.
  • Review the types/categories of systems in scope and review third party access against this.
  • All segmentation controls must be penetration tested at least annually.

Finally, even if your environment may in principle seem a typical environment, your scope is likely to be different because of different people, processes and technology. What is your scope? I will put on my QSA hat on and say “It depends”!

Did you find this post useful? Feel free to share and link to this article.

You Need Documentation?

You Need Documentation?

A gap assessment is reviewing how a system or process is against your checklist/benchmark, in order to identify any gaps.

Whenever doing a gap assessment, in my experience there is always going to be one general area a company is almost certainly lacking.  It’s that dreaded word (and not just dreaded by programmers only)… Yes, it’s documentation!

NOTE: My apologies to programmers. I used to be (and I still am though scrappy now) a programmer. I know how you feel. I felt the same way. I hated documentation. But I’ve seen the light being on the other side of the fence and it’s for the greater good. Trust me.

Companies are generally missing documentation and whenever doing PCI-related assessments documentation is key. We have a problem.

Never fear, this is easier to fix that expected as in many cases the companies are doing things in a PCI DSS (or other PCI-type assessment) compliant manner, but it’s just not documented. Often, I find they do not understand the difference between a policy, process and procedure and don’t know where to begin.

PCI policies, processes and procedures?

PCI DSS v3.0 is great as it clearly spells out in the reporting requirements whether a documented policy, or documented process/procedure is required. My suggestion is you do them all in a certain order as follows:

  •  Write your policy: Business rules and guidelines – the high level objectives you want to meet. Don’t include the how (process/procedure).
  • Write your process: These are the activities to produce a specific output.
  • Write your procedure: These are the underlying tasks that result in your process being fulfilled.

I still do not understand, can you give me an example?

As an example:

Policy: All system components must be hardened according to their respective hardening guides.

So let us assume you have firewalls. You need your own firewall hardening guide.

  • Process: Prevent internal addresses coming from the outside.
    • Type command XXXXXXXXXX (task/procedure)
    •  Type command XXXXXXXXXX (task/procedure)
  • Process: Remove the default password.
    • Type command XXXXXXXXXX (task/procedure)
    • Type command XXXXXXXXXX (task/procedure)

There are many ways to write your documentation, and I’d encourage you to split them into appropriate documents.

NOTE: In the past I’ve seen some companies just have few large documents just to satisfy PCI DSS – please split the documents up that is workable for your business.


Your document is not intended to be read by everyone. The document has an intended audience, so make it clear by writing an introduction. For example:

“The scope of this document applies to firewall administrators.”

Roles and Responsibilities?

Of course, PCI DSS wants to know the roles and responsibilities. For example:

“Firewall administrators are responsible for applying this hardening document to all firewalls prior to installation into the production environment. All firewall administrators will need written approval before installing any firewall into the production system. Firewall administrators are required to test all firewalls after making changes to firewalls.

The owner of this document is the <insert title> who will ensure this document is kept up to date.”


You need to demonstrate that you update documents at specific times as addressed by the PCI DSS. There are some ways to meet this. I strongly encourage you to use a versioning table. Consider including:

  • Version
  • Last modified date
  • Changes made
  • Reviewed/approved

You will then be able to demonstrate how frequently it was reviewed:

Hint: Stick in a policy somewhere to confirm the frequency:

“This document will be reviewed every x months”

(where x is the frequency required)

So, what is the benefit of this framework?

  • Confirms roles/responsibilities: Personnel know who is responsible for what device/process/system.
  • Mitigates ambiguity in configuration: Follow the step by step procedures as detailed in the documents and in principle your system components should be hardened to the same level.
  • Faster implementation: Often, you can copy/paste the commands into your system components and execute the command. This reduces human error/typos.
  • Reviews: You can demonstrate required review periods and updates made according to your business or changes to the standards.


In summary, documentation is a key element to passing an assessment. Documentation determines correct business objectives, correct and consistent configuration, clear roles and responsibilities and also Business As Usual (maintain compliance by following compliant practices in a timely manner).

This is not an easy task to do, but once you got it, you won’t need to rewrite it again! But remember, documents will need to be demonstrated to be reviewed at various times throughout the year in order to maintain compliance.


  • Document your policy
  • Document your procedure
  • Document your tasks to meet your procedure(s)
  • Include a scope section
  • Include a roles/responsibilities section
  • Include a version table
  • Document the frequency to review and update the document.

Once you have written your documents (and had them checked), go and relax. You deserve it!

If you still need policies, simply subscribe to my newsletter. Then get in contact.




Which PCI DSS SAQ is Right For Me?

Which PCI DSS SAQ is Right For Me?

So has your acquirer/merchant bank has asked you to complete a Self-Assessment Questionnaire (SAQ)? Are you confused which SAQ to complete? Don’t know where to start?

… Don’t worry. You’re not alone!

Since PCI DSS 3.0, there has been further SAQs introduced, which can add further confusion.

In the beginning…

A lot of merchants do not realise why their acquirer is asking for your SAQ. So let’s recap a little behind the scenes of what is going on, so you, as the merchant have a little more insight into the reasons why SAQs are being asked for.

As a merchant, you have agreed a contract with your merchant bank (the “acquirer”). Somewhere in that contract it is likely to state you will satisfy/maintain PCI DSS compliance.

It’s a FINE time… don’t you think?

Acquirers must report on a frequent basis the security position of all their merchants to the payment brands (VISA, MasterCard, JCB, Discovery and Amex). If they cannot report this security position to the brands, then your acquirer may receive a financial penalty (basically a big fine). So hopefully you can see that it is your acquirer’s best interest to get this information from you to avoid the fine!

  Payment Brand >>> Acquirer >>> Merchant

Your acquirer may have a right to pass this fine onto you, the merchant and therefore you may have had warning letters to say you must report your status, otherwise you may get fined. Does this sound familiar?

So hopefully you can see the first problem – your acquirer does not know your security posture. To do this, you must complete your SAQ, which reports to them your security posture – in short, how PCI DSS compliant you are. The second question is which SAQ are you eligible for? We discuss them below.

HINT: The main risk is to processing, storing or transmitting of cardholder data electronically. This means cardholder data traversing electronically through your networks and therefore the more that you do electronically over your network, the harder is the SAQ.  If you store cardholder data electronically, then this data is at a higher risk of being stolen – if you store cardholder data electronically, go to SAQ D (if you are eligible to fill out a SAQ).

SAQ A – “the outsourcing model”

In short, this applies to Card-Not Present (CNP) merchants (e-Commerce or mail order/telephone order) who have fully outsourced ALL cardholder data processing functions to a PCI DSS compliant service provider.  This means you do not process, store or transmit any cardholder data at all on your merchant systems or merchant premises.

Examples may include:

  • Football clubs who have outsourced all payment functions to a call centre or other third parties to take payment.
  • An online store who has outsourced all online payment functions to a PCI DSS compliant service provider*.

* Be careful as it could be SAQ A/EP depending on how it is processed online – ask your acquirer or a Qualified Security Assessor (QSA) for help.

SAQ A/EP – “Payment taking outsourced, but we host the website bit”

Introduced under PCI DSS v3.0, this applies to e-Commerce merchants who rely on third parties for payment taking, but you have a website that could impact the security of the payment taking (someone can hack your web machine and change where payments are taken or how payments are taken). Like SAQ A, this means you do not process, store or transmit any cardholder data at any point on your merchant systems or merchant premises.

Example is you own the web machine, host the website, but maybe you do a “silent order post” (silent order post is a long discussion outside of this post)

SAQ B – “Ye Olde Plain Ol’ Telephone System (POTS)”

I love this one. Classic one whereby you process card data via:

  • A standalone payment terminal that connects to your telephone line to process payments.
  • Or in the rare occassion your payment terminal does not work you use an imprint machine (remember those machines whereby you physically get the card and create a carbon copy for example)?
PCI DSS imprint machine

The imprint machine “Ker-chunk”

 SAQ B/IP – “The Networked Terminal”

In short, the telephone terminals are being replaced with those terminals you plug into your network (IP-based terminals). This means you do not store cardholder data electronically.

Examples include lots of retailers such as supermarkets. Because the terminals are connected to networks, these terminals tend to process data very quickly.

SAQ C – “The payment application SAQ”

Self-explanatory. you use payment applications to process cardholder data. This excludes payment applications through Internet browsers… that’s the next one, SAQ C/VT. Also note your systems do not store cardholder data electronically.

SAQ C/VT – “The Virtual Terminal”

This is where you enter cardholder data one at a time through a Internet-based browser application/website. The application/website is hosted by a PCI DSS compliant service provider. Also note your systems do not store cardholder data electronically.

P2PE-HW – “Silver bullet for de-scoping”

Well maybe it is not the silver bullet, but many merchants look to this, as they simply do not feel the overhead of maintaining a collection of PCI DSS controls is pragmatic for their business. In essence, if you use a terminal that has been P2PE validated then the bits between your terminal and your payments processor may be deemed “out of scope” and therefore the long list of associated PCI DSS controls are no longer applicable*. Also note your systems do not store cardholder data electronically.

NOTE: P2PE requirements comes with its additional requirements that may be difficult to maintain.

SAQ D – “you’re a rogue”

This is where you don’t fit in to the other SAQs. It’s most likely that you’ll be storing cardholder data).

The main discussions I hear from merchants is a misunderstanding between SAQ A to SAQ A/EP. If this sounds familiar, seek advice from your acquirer and/or a QSA. There are ways to drop you down from SAQ A/EP to SAQ A and actually you can apply specific actions relatively quickly to achieve this, but the question is whether a business is open minded to change how the website works.

I hope you understand the reporting obligations of the acquirers to the payment brands and why they keep asking you to complete a SAQ. 

Phew! That’s pretty much the end of this long post. Well done if you’re still reading this. I hope you received some value out of this. If you have, share this website link with others.