Book a discovery call

  • CCWs, Custom Testing, and INFIs – Oh My!

    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—YesYesYes
    Custom ApproachYes—NoYes?
    Compensating ControlYesNo—Yes?
    INFIYesYes?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 SSCAssessed
    Entity    		Assessed
    Entity    		Assessed Entity
    OR QSA
    How
    Common?    		Very
    Common    		Very RareCommonAlmost Every Assessment
    PurposeSets 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?    		ProactiveProactiveProactiveProactive
    Level of
    Maturity
    Required    		BasicVery MatureBasicBasic
    Short or
    Long Term?    		OngoingLikely Long
    Term    		Short or Long
    – Depends on Constraint    		Short Term +
    Long Term Remediation to
    prevent
    recurrence
    Assessment
    Types
    Applicable    		ROC

    SAQ    		ROCROC

    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

    , ,

  • The Risk Assessment is Dead, Long Live the Risk Assessment

    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

    ,

  • Version 4 SAQs are Out – What’s New

    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

    ,

  • Service Providers – What is Changing in PCI DSS v4.0?

    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

    , ,