Uncategorized – Confide

Diagram Your Processes
When you think of PCI DSS, you probably don’t automatically think of drawing diagrams. But diagrams are vital to understanding your scope, understanding your environment, and are two of the PCI requirements that may apply to you.

PCI DSS requires three types of diagrams:
- High-level network diagrams.
- Detailed network diagrams.
- Cardholder data flow diagrams.
In this article we’ll talk about what what each of those diagrams are and the kinds of details that they need. While this page focuses on the details from the Report on Compliance (RoC) template, the same approach should be taken even if you are using a Self-Assessment Questionnaire (SAQ).

High-Level network Diagrams

The Report on Compliance (RoC) template details the exact types of information that are expected in a high-level network diagram on page 11. A high-level network diagram is expected to show:
- The overall architecture of the environment being assessed
- A summary of all:
  - Locations,
  - Key systems, and
  - Boundaries between the above
- All connections into and out of the network, including the CDE to other networks, VLANs, or zones
- Includes all critical components within the CDE, such as:
  - POS / POI devices
  - Systems
  - Databases
  - Webservers
  - Other components (as applicable)
- Includes all other necessary payment components.
The high-level network diagram should be the 10,000 foot view of your environment showing all the possible connections into and out of the environment to help you and your assessor to understand how things fit together. This means your high-level network diagram should include things like where your test and development environments are to understand any connectivity to the CDE / production environments.

Detailed Network Diagram

The detailed network diagram takes the high-level view and zooms in to the CDE and the supporting environments with a focus on the environments that are in-scope for PCI. The detailed network diagram needs to show:
- All boundaries of the CDE
- Network segmentation points the tare used to reduce the scope of the assessment
- Boundaries between trusted and untrusted networks
- Wireless and wired networks
- Any other connection points that are applicable to the environment.
While this may seem similar to the high-level network diagram, the diagram is expected to have much more detail to it so that you and your QSA can understand how each communication point functions and how it is secured. This may include detail such as:
- The type of device(s)
- The device interfaces
- Network technologies
- Protocols
- Security controls
With the amount of detail that is required here, you may find that some of this information needs to be in supporting documents. However, if you do use a supporting document, make sure that it is kept up to date and referenced in your network diagram.

It may be possible that your detailed and high level network diagrams are the same if your environment is small. The important thing is to make sure that you have all the required detail in your network diagrams.

Below is an example of a network diagram that may get you started when trying to diagram your own network.

As you can see, it includes information about the servers, the ports and how they connect, the network devices providing segmentation and the wireless networks.

Cardholder Data Flow Diagrams

Cardholder data flow diagrams need to exist for every process where you store, process, or transmit cardholder data so that it is possible to understand the lifecycle of a payment. This means that your cardholder data flow should include everything from the time a customer is able to provide you with a payment, through any processes where you use that card number (for example tokenisation), and when it leaves your environment for further processing, settlement, or fraud activities.

By understanding your cardholder data flows, you can better understand and explain your scope. To understand and explain your cardholder data flows, you need to be able to show not only where cardholder data flows (e.g. where is it stored, processed, or transmitted internally or externally)but also what parts of the cardholder data are involved in the flow (e.g. PAN, SAD, Name, Expiry, etc.) and how it is protected (e.g. TLS, VPN, truncation, application layer encryption, etc.).

This diagram shows an example of one way you can illustrate your cardholder data flows.

It contains information about how data is protected at rest, where it is stored, and what is stored. It also shows how cardholder data is sent from the time a customer provides a credit card number through the transaction process including transmitting the cardholder data out to the payment gateway.

Remember to Include Supporting Systems

PCI DSS is not just the systems that store, process, or transmit cards. It is also the systems that support the PCI DSS requirements. This means you should ensure that your network diagrams also include systems used for patching, antivirus, log servers, file integrity monitoring, admin workstations, and other systems that support PCI. Even though these are not part of the cardholder data environment (or CDE), they are still part of your in-scope environment and your assessor will want to see these on your diagram so they know what systems they will need to review.

Need Help?

Confide can help you with not only understanding your scope, but making sure that your documentation clearly reflects your scope. Contact us to find out how Confide can help.
zuno

September 29, 2026

Uncategorized

PCI Basics
Hosted checkout, iframe or direct post: what each does to your scope

Most organisations we assess have chosen their online payment integration for commercial reasons: what the provider supported, what the developer knew, what shipped fastest. That decision then quietly sets the size of the compliance job for years. It is worth understanding what each pattern does before the next replatform, rather than after.

Full redirect or hosted payment page

The customer leaves your site, enters their card details on a page served entirely by your payment provider, and returns once the payment is authorised. Card data never touches your systems, and the page they type into is not yours.

This is the lightest option, and for many merchants it is the difference between a short self-assessment questionnaire and a much longer one. It is not a free pass. You still control the page that sends the customer onward, and that page is in scope.

Embedded iframe or hosted fields

The form appears inside your page, but the fields themselves are served from the provider’s domain. Your site never receives the card number, yet your page hosts the container it sits in and every script that runs alongside it.

The card data may never reach your servers, but the page that frames it is still yours to protect.

This pattern is where we see the most misplaced confidence. Teams assume the iframe removes them from scope entirely. It does not, and v4.0 made that explicit.

Direct post or full API integration

Your application receives the card details and passes them to the provider. You are now storing, processing or transmitting cardholder data, which puts your web servers, your application, your logging and often a good deal of your internal network inside the cardholder data environment.

There are legitimate reasons to work this way, usually around checkout experience or unusual payment flows. It is the most demanding option, and it should be a deliberate choice rather than an inherited one.

What v4.0 changed for all three

Version 4.0 introduced requirements aimed squarely at payment page skimming. Whichever integration you use, if you serve the page a customer enters their card into, you are expected to know what scripts run on it, to authorise them, and to detect unauthorised changes.

Maintain an inventory of every script on your payment pages, with a written justification for each.Detect unauthorised change to the payment page as received by the browser.Confirm your provider’s responsibilities in writing, and keep the evidence.

Where to start

Work out which of the three patterns you are actually running. We regularly find organisations who believe they are on a hosted page and are not, usually because a second checkout path was added for a campaign and never removed. A short scoping conversation settles it, and the answer changes what you have to evidence.

zuno

August 28, 2026

Uncategorized

E-commerce

CCWs, Custom Testing, and INFIs – Oh My!

In June 2023, the PCI Security Standards Council introduced a new document that you’ll need
to know about called “Items Noted for Improvement” which is a worksheet and attestation form
you’ll start seeing as part of your version 4 assessments. But when this was released we
realised that this was a good opportunity to demystify the differences between:

Defined Testing (DT)
Customised Approach (CA)
Compensating Controls (CCWs)
Items Noted for Improvements (INFIs)

Most assessments will include defined testing and INFIs. Some assessments will include
compensating controls, and we expect that very few organisations will complete the work
required to use the customised approach.

In this post, we will go over some of the basic features of each of these items and help you
understand how each can be used and when they should be used.

Defined Testing

When we talk about defined testing, we are talking about the requirements and testing
procedures that are part of PCI DSS. These testing procedures have been defined by the PCI
SSC for how they expect each of the requirements to be tested. This is your “classic” PCI DSS
requirement.

Defined tests can have a few different findings:

In Place
In Place with CCW
Not Applicable
Not in Place

In the original release of PCI DSS v4.0, there was a new finding called “In Place
with Remediation”. That’s no longer a finding, but it’s successor is the INFI.

You’ll also see that there’s a reference to Compensating Controls.

There’s no reference to the Customised Approach because this is a change in how the testing is done rather than how the results are reported.

Customised Approach

The Customised Approach is new to PCI DSS v4.0. This gives organisations the opportunity to
approach the PCI DSS requirements in a different way by using the objective.

But there are a few caveats to this that the PCI SSC calls out which are also the reasons why
we don’t expect to see the Customised Approach used too often.

It can only be used if you are completing a Report on Compliance (RoC) – you cannot use
it with a Self-Assessment Questionnaire (SAQ).
The controls that are implemented must meet or exceed the security provided by the
requirement in the defined approach.
The amount of documentation and effort required to validate the customised approach will
be greater than what’s required for the defined approach.
It is intended only for risk-mature entities with a “robust risk-management approach to
security, including but not limited to, a dedicated risk-management department or an
organisation-wide risk management approach”

There are also some requirements that the Customised Approach cannot be used for.

If you meet the criteria for considering using the Customised Approach, then you’ll need to complete:

Risk assessment annually for each customised approach used
Controls Matrix based on Appendix E1
Targeted risk analysis based on Appendix E2

That long with evidence of the validation of the customised approach is provided to the QSA
who in turn develops their own testing and validation procedures. And at the end of the day,
there could be things that could derail the custom approach if your compliance-accepting entity
(usually the acquiring bank or the card schemes) pushes back.

Compensating Controls

Compensating controls (CCWs) have been around for a long time. Compensating controls are meant to be used as a proactive way to meet a requirement when you cannot meet the requirement. But there are a few things that need to be in place to use a compensating control:

You must have a business or technical constraint for why you cannot meet the
requirement (not wanting to is not a valid business or technical constraint)
You must go “above and beyond” the original PCI DSS requirement
You cannot use a control that is already applicable to the technology as a compensating
control (for example, if the system already requires MFA, you can’t use MFA as a
compensating control).

The important thing to note is that compensating controls are meant to be proactive. It is not
something that should be used as a reaction or remediation activity for a historical failure. A
compensating control is a “proactive development of mitigating actions”.

A Compensating Control can never be used with the Customised Approach.

Items Noted for Improvement

If you’ve ever had your QSA find something that needed to be fixed before they would sign off
on the AoC, this is the sort of thing you’ll now see in an INFI. When PCI DSS v4.0r1 was rolled
out in December 2022 it removed “In Place with Remediation” and the PCI SSC flagged that
something new would be coming in 2023.

That something new was released in June 2023 and is referred to as INFIs. An INFI is
something that is noted as needing correction at the time of the assessment that the
organisation then fixes.

Examples of the types of things that would be included in INFIs include but are not limited to:

A few people who still need to complete their security awareness training
A policy/standard that is missing something that’s required for PCI DSS or that’s missing
entirely
A network change that needs to be made because it was missed as part of a regular
review process (for example, if the QSA is reviewing the firewall configuration and
identifies a rule that is no longer needed or that increases the scope).

There are two new pieces of documentation you’re likely to see during an assessment:

INFI Worksheet
INFI Worksheet Acknowledgement and Attestation

The documents are required as part of any Report on Compliance and recommended as part of SAQs.

INFI Worksheet

The worksheet outlines any of the findings where a control hasn’t been fully met. What this actually means is that a finding can be identified by either the QSA or the “Assessed Entity” (this just means the organisation that is being assessed).

The worksheet will only be completed if there are INFIs – if you’ve done everything to the letter for the last 12 months, you might never see this document!

As part of the worksheet, in order for the requirement to be met, the organisation needs to:

Identify what caused the failure.
Describe the corrective action(s) taken to fix the issue so that it is now in place.
Describe the corrective action(s) taken by the entity to prevent the failure from
reoccurring.

The key thing to note is that this is not a “get out of jail free” card – it is possible that there may still be controls that could be considered as “Not in Place”.

INFI Worksheet Acknowledgement & Attestation

Regardless of whether any INFIs were identified during the assessment, you will receive an
acknowledgement form that includes your sign-off and acknowledgement that:

The worksheet (as applicable) has been received,
That the cause(s) of the failures have been addressed, and
The corrective preventative actions have been implemented.

We recommend that this document is signed by the same person who would sign the
Attestation of Compliance.

Can You Combine These?

At this stage (July 2023), we know there are some reporting approaches that can be combined
and others that cannot. We think that INFIs will span the breadth of testing procedures because
there could be a control failure as part of a compensating control or the customised approach.
But if this changes, we will update the information.

	Defined Test	Custom Approach	Compensating Control	INFI
Defined Test	—	Yes	Yes	Yes
Custom Approach	Yes	—	No	Yes?
Compensating Control	Yes	No	—	Yes?
INFI	Yes	Yes?	Yes?	—

Summary

To summarise the information provided above, we’ve put some of the key information into the
table below. You can use this to work out what might be right for you to use in your
assessments.

	Defined Approach	Custom Approach	Compensating Control	INFI
Who Identifies?	PCI SSC	Assessed Entity	Assessed Entity	Assessed Entity OR QSA
How Common?	Very Common	Very Rare	Common	Almost Every Assessment
Purpose	Sets out the expected testing and requirements for PCI DSS.	Allows an organisation to meet a PCI DSS requirement in a way that does not strictly follow the defined requirement.	Allows an organisation with a business or technical constraint to meet the requirement by implementing controls that go above and beyond the original control.	Identifies one or more items that require corrective action before the assessment is complete before the requirement can be considered in place.
Proactive or Reactive?	Proactive	Proactive	Proactive	Proactive
Level of Maturity Required	Basic	Very Mature	Basic	Basic
Short or Long Term?	Ongoing	Likely Long Term	Short or Long – Depends on Constraint	Short Term + Long Term Remediation to prevent recurrence
Assessment Types Applicable	ROC SAQ	ROC	ROC SAQ	ROC SAQ (Recommended)
Key PCI Document(s)	PCI DSS v4.0	PCI DSS v4.0 Appendix D (PCI DSS v4.0) Appendix E (PCI DSS v4.0)	PCI DSS v4.0 Appendix C (ROC) Appendix B (SAQ)	INFI Instructions & Worksheet

Need Help?

If you need help developing your compensating controls or custom approaches or just
validating your PCI DSS compliance, talk to us to see how we can help you. We can help
demystify PCI DSS.

Helena Kuwabara

July 5, 2023

Uncategorized

General, PCI DSS v4, Reporting

The Risk Assessment is Dead, Long Live the Risk Assessment
PCI DSS has recently changed the way that we have to do risk assessments. You may recall
that in the past we had an article about how to complete a risk assessment for PCI DSS but
everything is about to change in version 4.0.

In version 4 of PCI DSS the focus changes from a broad risk assessment that has to follow a
standardised risk approach such as OCTAVE, IS 27005, or NIST SP800-30 to set of “targeted
risk assessments” or TRA. The TRAs are focused on a combination of periodic tasks as well as
specific risks that PCI cares about and which could affect your PCI DSS compliance the most.
Examples of some of these specific risks are:
- TLS configurations and cipher suites
- Encryption key algorithms and strength
- Hardware and software that no longer supports your PCI compliance or is going “End of
  Life”
From that list you’ll notice that PCI DSS is really focusing in on the things that you need to stay aware of and plan for as part of your ongoing compliance.

Now, this doesn’t mean that the old risk assessment is no longer helpful, and you don’t have to stop using your old risk assessment methodology as long as it supports the new risk assessment requirements. So standard, accepted methodologies like ISO still remain very valuable to a structured approach to risk.

In this post we are going to talk a bit more about how you can improve your approach to risk, and things you might need to consider for how you maintain these new risk assessment requirements.
Periodic Task TRAs

Throughout PCI DSS v4.0 you will see quite a few mentions of risk assessments to show how
you determined the frequency of a periodic task. For example, you will need to ensure you have
a risk assessment that results in defining how often you should inspect your payment terminals.

Sounds simple, right? But here’s where things get bit complex. The reason I say that things get
complex here is because you might have different systems with different levels of risk. Building
on that initial example of inspecting your payment terminals, you might have a combination of
attended terminals which sit with one of your frontline staff. You might also have unattended
payment terminals that sit out in a car park, for example. Sure, not everyone will have multiple
types of payment terminals. But this just gives an example of why we might need to not just rely
on a single TRA to be able to meet your PCI compliance. You might have to know enough about
your environment to know when you need more than one to determine different frequencies,
based on different risks.

Example of a Periodic Task

Take your payment terminals that sit with your frontline staff. If they’re behind a secured desk or
there’s always somebody watching over them. Maybe there is a reason to inspect them a little
bit less frequently. But what about those ones that somebody might not be watching over? What
about that payment terminal that sits at the back of the car park and isn’t covered by your
standard CCTV that you used to make sure that nobody is doing anything dodgy in the car
park? Well, maybe these are the kind that you need to take a look at a little bit more regularly
just to make sure that somebody hasn’t tampered with something that is a low hanging fruit.

And so from these two examples, what you see is that they don’t have the same risk profile.
One might be much more likely to be tampered with than another. So applying the same
methodology for both might not be what you want to do. That’s not to say that you couldn’t
examine them all daily or multiple times a day. But you might have scenarios where you will
want to consider the risk for the periodic performance of task differently based on either the
system / process or the likelihood of an event occurring if there is a significant difference that
you want to account for.

What’s Included in a TRA for a Periodic Task?

So what do you need to include in your TRA? You need to include:
- the assets that are being protected,
- the threats that you are protecting those assets against,
- the factors that contribute to the likelihood or impact of that threat being realised
The result is a documented analysis that determines and justifies how frequently you are
performing the task in order to prevent that threat from being realised.

These TRAs need to be reviewed at least once every 12 months to make sure that they are still
accurate and up to date. And that means that if you need to update them, you need to do that
as part of your annual review.
Customised Approach TRAs

The customised approach is certainly not for everyone. The customised approach is only
available if you are doing a full report on compliance with a QSA meaning you cannot do the
customised approach as part of an SAQ. If all you do is an SAQ. You don’t need to read this
section at all.

The customised approach has a very specific way that you need to complete your risk
assessment. A risk assessment needs to be completed for each and every requirement that you
do a customised approach for and you have to make sure you document all the information in
Appendix E2 of PCI DSS v4.0 or you can use the table right out of that appendix.

Because we expect that few people will take the customised approach, this is where we will
leave it for now. But watch for a specific post about the customised approach in the future.

Hardware and Software Risk Reviews

The last thing that you want to find out during one of your PCI assessments is that the
operating system you are using has suddenly gone end of life or is no longer supported. This
means that you will not be able to meet PCI compliance unless you are able to figure out a way
to use a compensating control or maybe you end up scrambling to quickly upgrade. But we
know that a lot of risks come from using out of date hardware and software because they can
no longer receive security patches. So to lessen this risk a little bit, PCI wants to make sure that
you are proactively identifying when there is hardware or software that might pose a risk to your
environment.

At least once a year, you need to review all of your hardware and software to make sure that it
continues to receive security fixes from their vendors promptly. You also need to make sure that
all of your technologies continue to support, and they don’t preclude your PCI DSS compliance.
What does this actually mean? This is that sort of scenario where, for example, your hardware
might not support the minimum number of characters for a secure password. Or it could be
where the database solution that you are using supports only disc encryption but not column
level encryption.

You should also be updating your hardware and software risk document anytime there’s an
announcement about a hardware going “end of life” or being no longer supported by the vendor.
And at the end of the day, what you’re going to need to do is have a plan that’s been approved
by senior management to remediate these technologies that won’t support your PCI compliance
anymore. Does that mean that you have to replace them immediately? Probably not. But you
will still need a plan, and there’s a good chance that if they won’t meet your PCI compliance
now, you’ll still end up doing a compensating control until that plan has been fully implemented.

Cryptography Risk Reviews

One of the other types of risk assessments that you’ll need to take a look at in PCI version 4 is
around the cryptographic cypher suites and protocols that you are using in your environment.
This includes the encryption that you are using to protect the data in transit, as well as when it
is stored or at rest. As a starting point, this means that you have to understand and have an
inventory of all of the cryptographic cypher suites and protocols that are in use. That inventory
also needs to include the purpose and where it is used. Just like hardware and software, you
need to be actively monitoring industry trends.

Changes to encryption should not be a surprise. Organisations like NIST announce deprecation
and disallowed configurations several years in advance. For example, NIST announced in 2019
that three-key TDEA is deprecated through 2023 and disallowed after 2023 for encryption of
data.

And the reality is, if we’re talking about encrypting card holder data at rest, you might need a
few years to be able to change your encryption if the algorithm or key strength you use is being
deprecated or disallowed.

And once again, just like your hardware and software, you need to have a documented strategy
to respond to anticipated changes in cryptographic. Vulnerabilities as well. The most likely
scenario that you’re going to encounter here is changes to TLS configurations. Cypher Suites
for TLS are regularly updated and identified when there are weaknesses. In mid-2022, we saw
a number of cipher suites starting to result in failed ASV scans. So you will almost always see
changes to TLS configurations come through in your vulnerability scans. We understand that
sometimes you can’t change your cypher suites right away because your customers need to be
able to use them. But that’s where you need to be aware of where they are used and what the
actual risk is so that you can come up with a migration plan to protect your customers and
minimise your risk.
How do you Document Your Risk Assessments Now?

So there’s a good chance that how you document your risk assessments is going to change.
The overarching organisational risk assessment doesn’t often lend itself nicely to being able
to identify the frequency that a task is being performed at. So what this means is you’re probably
going to have to change the way that you document your risks a little bit.

One approach to looking at this could be to take a look at the template in Appendix E2 of the
PCI DSS standard. In saying that this template does not necessarily translate identically to what
you will need in a TRA. However, Sections 1, 3, 4, and 5 of this appendix do provide a
reasonable starting point for how you can get started. These sections cover:
- The control you’re performing
- Wha the threat is that you’re protecting against
- What the likelihood of “mischief” occurring is
- What the impact is if that “mischief” occurs
- How often you need to perform the control to reduce the likelihood and impact (and it’s
  helpful to also include information about how performing it at this frequency would result in a lower frequency or impact) – this must be justified
- Sign off by an appropriate member of the organisation who is accepting the risk of
  performing the control at the defined frequency
- The date that the TRA has been completed – and if you’re simply reviewing it and it
  doesn’t need an actual update each year, make sure that you include the date it was last
  reviewed as well.
This isn’t the only way to do it and there is a bit of flexibility – unless you are doing a
customised approach, in which case the information that needs to be captured via Appendix E2
all needs to be present in whatever format you decide to use.
How Do You Organise Your Risk Assessments?

And after all this, what you’re probably going to notice is that you’ve gone from one, maybe two
risk assessment documents to a half dozen, a dozen, maybe even more in a very complex
environment. And that means that you’re going to have to have a process to actually track your
risk assessments. We would strongly recommend that you do something to track each and
every one of your risk assessments, including:
- the PCI requirement it relates to,
- the system(s) it applies to,
- who is responsible for the system / risk assessment,
- the date that it was completed/reviewed, and
- the date that the next review is.
This goes back to what I mentioned earlier in the article where I said that you might have
multiple risk assessments for a single control and those risk assessments might have multiple
owners for the systems. each of these risk assessments might have been done at a slightly
different date which means that they might have different review dates. And if you want to keep
on top of all these risks, you need to make sure that you can quickly and easily identify that all
of your risk assessments have been completed and reviewed at the required (annual)
frequency
Will Everyone Have to Do All these TRAs?

Thankfully, not everyone will have to do each type of risk assessment / TRA.For most
organisations you’ll need to do a TRA for the tasks that you perform at a “periodic” frequency.
But that might still mean you’re doing at least several risk assessments every year. And for
many of the SAQs, including a risk assessment will be quite a new requirement.

For more complex organisations such as those using SAQ D (merchant or service provider) or
completing a Report on Compliance (merchant or service provider), you’ll likely be looking at all
the types of TRAs – possibly excluding the one for the Customised Approach.

Need Help?

Where do you start? If need help with PCI DSS, risk assessments, or how you can start
meeting the controls in PCI DSS v4.0, Talk to us to see how we can help you.
Helena Kuwabara

August 19, 2022

Uncategorized

Governance, PCI DSS v4
Version 4 SAQs are Out – What’s New
It’s finally happened – on April 1st NZ time, PCI DSS v4.0 was released, and then on April 28th
we saw the Self-Assessment Questionaries released. In this post we cover at a high level
what’s changed and what stays the same.

What Stays the Same

The good thing about the SAQs is that the actual SAQs types have stayed the same – so odds
are good that if your payment channels haven’t changed, you’ll still be looking at the same
report type. We still have all the same SAQ names that you’re used to hearing about and no
new SAQ types have been added.

But that’s about where the similarities end. Sure, there are plenty of requirements that stay the
same, but we know those aren’t the things that people are interested in.
What’s Changing
SAQ D (Service Providers)

The biggest changes that are coming are for service providers. We will be covering this in more
detail in a separate post. Service providers in v4.0 will have a more in-depth reporting process
– gone are the days of just tick boxes, and a summary of the reporting is now required.

SAQ A

For those of you who complete SAQ A, you can expect to see some changes to which
requirements you have to comply with. Overall, a few more controls have been added that we
have always considered as basic security controls. This includes ASV scanning (not previously
required) and more monitoring of servers and code (new requirements for e-commerce
merchants).

SAQ A-EP

SAQ A-EP sees more updates to requirements as well as new requirements being added.
Things like phishing and more robust management of user accounts are featured in the updated
SAQ A-EP. It also includes the same monitoring of servers and code mentioned in SAQ A. And
one thing that people will need to be aware of is the new requirement around the integrity of the
MFA system – start thinking now about whether your MFA provider has an attestation of
compliance and if they don’t already have one for that service, hopefully they will have one
before this requirement comes into force.

SAQ B & B-IP

We’ve combined these SAQs in this post because neither of them gains any of the
requirements new to PCI DSS v4.0.

SAQ P2PE

SAQ P2PE loses a requirement in Version 4.0! The only thing new to add is a requirement
around storage of SAD prior to authorization. This is the SAQ that stays the most the same out
of all of them.

SAQ C

SAQ C picks up more requirements than some of the other SAQs. In version 4.0 it also includes
antivirus updates, TLS management updates, anti-phishing updates, passwords are longer, and
MFA will apply to all access to the CDE, not just admin access to the CDE. There is a much
greater focus on authentication systems, including management of service accounts and the
integrity of MFA systems. Automated log tools will now be required and certain “periodic”
requirements will need to have a targeted risk assessment completed. Overall, SAQ C is one of
the bigger changes to the SAQs.

SAQ C-VT

C-VT adds a few more requirements in version 4 – antivirus scanning gets expanded to include
continual behavioural analysis, Anti-phishing gets added and password lengths increase in line
with the other SAQs that include password length requirements.

SAQ D Merchants

Unlike SAQ D for Service Providers, SAQ D for Merchants stays the same in how reporting is
handled. No additional sections have been added to the SAQ. All of the new requirements from
v4.0 (excluding those that are specific to service providers) are included in SAQ D for
merchants.
Summary

Overall, many of the updates are iterative with most SAQs only adding a handful of new
requirements. The biggest change for the SAQ is with SAQ D (Service Provider) which takes an
entirely new approach to how service providers completing a SAQ are required to report.

We will go into more depth on these SAQs in the coming weeks, so look out for more
information which will also be linked below:
- SAQ D (Service Provider)
- SAQ A (More Information Coming Soon)
- SAQ A-EP (More Information Coming Soon)
- SAQ B (More Information Coming Soon)
- SAQ B-IP (More Information Coming Soon)
- SAQ P2PE (More Information Coming Soon)
- SAQ C (More Information Coming Soon)
- SAQ C-VT (More Information Coming Soon)
- SAQ D (Merchant) (More Information Coming Soon)
Need More Information?

If you’re wondering how PCI DSS version 4 will impact your existing PCI compliance, we can
help you proactively develop a roadmap to move from version 3.2.1 to version 4.0. At Confide
we love talking about PCI DSS and understanding how security and compliance can fit into the
way that organisations do things. Contact us for more information.
Helena Kuwabara

May 13, 2022

Uncategorized

PCI DSS v4, Reporting
Service Providers – What is Changing in PCI DSS v4.0?
Service providers have always had a slightly different focus in PCI DSS because as a service
provider you have the ability to impact your customers’ PCI DSS compliance and overall
security. Whether that’s through providing certain managed services like managed firewalls or
data centres, your customers expect you to be able to demonstrate that certain requirements
are met. The easiest way to do this is by completing your own PCI DSS compliance (rather than
being included in multiple customer assessments).

However, the way that service providers need to report is changing with PCI DSS version 4.0.
The report type that needs to be completed is not changing for service providers (you still need
to complete either SAQ D – Service Providers or a Report on Compliance (ROC)).

In this post we will focus on SAQ D for service providers, but don’t worry, we will be publishing
more information about the RoCs and service provider requirements separately.
New Reporting Format

The biggest change for service providers who are using SAQ D (Service Provider) is that there
is a much greater level of reporting needed. In PCI DSS v3.2.1 SAQ D (Service Provider)
looked the same as the other SAQs (just with a lot more requirements). But now, the SAQ is
much more like a mini-RoC with each requirement needing an explanation of how the finding
was reached.

Along with each requirement having a summary of the findings, the SAQ also now requires:
- Network diagrams
- Information about any storage of account data
- Information about any storage of sensitive authentication data (SAD)
- Information about each of the system components included in the scope
- Results of quarterly ASV scanning
This is all information that you would see in a full RoC.

Unlike the RoC, SAQ D (Service Provider) does not have any ability to do custom testing – so if
you want to do custom testing you will have to complete a RoC with a QSA.
What Do These Changes
Actually Mean?

Things are changing quite a bit in version 4.0 for service providers.
- Expect to spend more time on the process – all of the testing processes need to be
  followed and reported on, expect to have to interview people and review systems.
- Expect to need to have someone who understands PCI DSS so that the answers provided
  make sense (PCIP, ISA, QSA)
- Expect to have to have cross-functional participation for completing the report – not
  everyone will have the expertise to assess the questions, and you’ll have to make sure
  that the roles involved understand why they need to be involved
- If your report is not easy to understand or is not comprehensive, there may be more
  queries from your merchants who are relying on your compliance because they may not
  understand what you have explained
- If your report is well written, easy to understand, and comprehensive, you stand a chance
  to benefit from fewer queries because their questions have already been answered
Overall, SAQ D for Service Providers is adding some complexity, but will benefit merchants in
the long run who will gain a far greater understanding of how their security is being managed.
Are You a Service Provider?

If you’re a service provider and you need help figuring out this new reporting format or what the
new reporting means for you, Confide can help. We’ve worked with many service providers in
NZ to help them achieve PCI DSS compliance. Contact us to find out how we can help you
become PCI DSS compliant against PCI DSS v4.0.
Helena Kuwabara

May 6, 2022

Uncategorized

PCI DSS v4, Reporting, Third Party Service Providers
Rapid Requirements: Responsibility Matrix
Supporting Your Customers

As a service provider, your customers are always looking for more information about which
requirements they are responsible for and which ones you’re responsible for. Some service
providers have provided responsibility matrix documents, others have provided their AoC,
others have provided other documents.

But in v4.0, there’s a new requirement which sets out how third party service providers (TPSPs)
need to support their customers’ compliance.
- 12.9.2: TPSPs must provide either:
  
  PCI DSS compliance status information for any service performed on behalf of
  customers AND
  
  Information about which requirements are the responsibilities of the customer, the
  TPSP, and which are shared.
An AoC doesn’t always give customers enough detail to be able to know how the
responsibilities for each of the requirements split out, so the SSC suggests in their guidance
that good practice would be to provide customers with a responsibility matrix that identifies all
relevant PCI requirements, and indicates who is responsible for each, including which
requirements have shared responsibility.
Need Help Developing a
Responsibility Matrix?

Confide can help you document a responsibility matrix that you can provide to your customers.
We’ve worked with many service providers and understand how responsibilities might not
always be straight forward. Talk to us to see how we can help you.
Helena Kuwabara

April 1, 2022

Uncategorized

Third Party Service Providers
PCI v4.0 by the Numbers
What’s New in Version 4?

There’s a lot of new things in version 4. In fact, there are 64 new requirements that you might
be looking at by 31 March 2025.

53

New
Requirements for
Merchants

64

New
Requirements for
Service Providers

13

New
Requirements
Applicable When
You Use v4 (by
March 2024)

51

New
Requirements in
Full Force 31
March 2025

Along with new requirements, version 4 brings extended guidance as part of the Standard itself.
Overall, the length of the Standard increases from 139 pages to 360 pages. But what this really
means is that in addition to the requirements it also has:
- Customised approach objectives if you’re doing a RoC and looking at a customised testing
  approach
- Applicability notes to explain how the requirement applies to people, processes, or
  systems when further clarification is needed
- Information about the purpose / objective of each requirement
- Recommendations for good practice
- Further sources of information
- Definitions of key terms
The Security Standards Council has put a lot of work into adding as much clarification and help
as possible to the Standard.
Need Help?

Whether you’re using PCI DSS v3.2.1 or v4.0 we always work to help make sure that you can
understand the Standard and work to help see how we can fit your processes into the Standard.
Talk to us to see how we can help you.
Helena Kuwabara

April 1, 2022

Uncategorized

General
Rapid Requirements: Let’s Define “Periodic”
How Often is Periodic

The term “periodic” is not new to PCI DSS. But in Version 4, we see a new approach that wraps
more governance around the meaning of periodic in Section 7 of PCI DSS V4.0. Periodic
becomes a measure that is unique to every organisation

Governance plays a big role in this because:
- 12.3.1: Every periodic requirement must have a frequency defined that is supported by a
  risk assessment.
How many requirements will you have to define the frequency of? It’s probably a lot more than
you thought!
- 5.2.3.1: Periodically evaluate systems that are not at risk for malware
- 5.3.2.1: If periodic malware scans are used the frequency needs to be defined
- 7.2.5.1: Evaluate access by application and system accounts periodically
- 8.6.3: Change passwords / passphrases for system accounts periodically
- 9.5.1.2.1: Perform periodic inspections of POI devices
- 10.4.2.1: Perform periodic log reviews of systems that do not require daily log review
- 11.3.1.1: Address all other vulnerabilities (beyond high / critical) from vulnerability scans
  periodically
- 11.6.1: Perform change and tamper protection on modification to the HTTP headers and
  contents of payment pages at least every 7 days or periodically
- 12.10.4: Train personnel responsible for responding to security incidents periodically
Each of these requirements will need to have it’s own targeted risk assessment which means that there will be a lot more oversight and governance required even when it comes to defining how often you perform certain requirements!
Need Help With Targeted Risk
Assessments?

We can help you understand the risks and what we see as best practices when it comes to
determining the frequency of periodic tasks. Talk to us to see how we can help you.
Helena Kuwabara

April 1, 2022

Uncategorized

Governance

High-Level network Diagrams

Detailed Network Diagram

Cardholder Data Flow Diagrams

Remember to Include Supporting Systems

Need Help?

Full redirect or hosted payment page

Embedded iframe or hosted fields

Direct post or full API integration

What v4.0 changed for all three

Where to start

Defined Testing

Customised Approach

Compensating Controls

Items Noted for Improvement

INFI Worksheet

INFI Worksheet Acknowledgement & Attestation

Can You Combine These?

Summary

Need Help?

Periodic Task TRAs

Example of a Periodic Task

What’s Included in a TRA for a Periodic Task?

Customised Approach TRAs

Hardware and Software Risk Reviews

Cryptography Risk Reviews

How do you Document Your Risk Assessments Now?

How Do You Organise Your Risk Assessments?

Will Everyone Have to Do All these TRAs?

Need Help?

What Stays the Same

What’s Changing

SAQ D (Service Providers)

SAQ A

SAQ A-EP

SAQ B & B-IP

SAQ P2PE

SAQ C

SAQ C-VT

SAQ D Merchants

Summary

Need More Information?

New Reporting Format

What Do These Changes Actually Mean?

Are You a Service Provider?

Supporting Your Customers

Need Help Developing a Responsibility Matrix?

What’s New in Version 4?

Need Help?

How Often is Periodic

Need Help With Targeted Risk Assessments?

What Do These Changes
Actually Mean?

Need Help Developing a
Responsibility Matrix?

Need Help With Targeted Risk
Assessments?