Resources

PCI DSS
PCI DSS Steps to Completion

Published On: November 20th, 2020Categories: PCI DSS

What Does It Take to Become PCI Compliant? | PCI DSS Steps to Completion

Has anyone ever walked you through the steps that take place during a PCI assessment? It has been my experience that knowing what you are getting into helps smooth out the surprises and (hopefully) lowers the anxiety that is associated with externally driven compliance. In an earlier blog entry on pitfalls, I discussed some of the big-ticket items we see that end up as non-compliant. Now I want to walk you through the steps of an assessment so you can get an idea of how it will flow and to prepare you before you take the first step off the precipice.

15 Step PCI Compliance Checklist: Get yourself ready with the basics.

The Boy Scouts have a motto, “Be Prepared” which is appropriate in this case. The last thing you need is for the assessor you just paid a bunch of money to walk in and immediately tell you that you’ll never pass if you don’t have the basics done. By the basics, I mean you have completed and in hand:

  1. Validated scope – both what is in scope and verified what is out of scope is truly out of scope
  2. Data repositories – know where it is stored and how it is protected
  3. An annual risk assessment
  4. High level network diagrams
  5. Connectivity diagrams
  6. Dataflow diagram
  7. Systems Inventory
  8. Policies and Procedures
  9. List of critical hardware/software
  10. External penetration test – initial test, any remediation done and a subsequent passing retest
  11. Internal penetration test – initial test, any remediation done and a subsequent passing retest
  12. If a service provider, required periodic segmentation testing
  13. External vulnerability tests – four quarterly tests at 90-day increments, remediated with passing retests
  14. Internal vulnerability tests – four quarterly tests at 90-day increments, remediated with passing retests
  15. A list of subject matter experts within your company who can answer to the PCI DSS requirements

Most QSAs are going to make sure you have this list done. If you do not, you will most probably be non-compliant.

At a high level, PCI boils down to three things.

  • Adequate policy/procedures.
  • Compliant applied configurations/processes/results.
  • Proof to the assessor you are doing what you say you do.

Jump in. Your assessor is going to start with evidence of the list of 15 above and then gather other evidence for the other requirements. Evidence can come in a big zip file, a USB thumb drive or through an online portal, but one way or another, we have to populate the 836 fields in the PCI DSS Report on Compliance template, so the evidence needs to be given to the qualified security assessor, QSA. One way to do that is give the QSA the policy and procedures and let them work on that while you gather the rest of the evidence. Know this—some responses cannot be gathered ahead of time. It has to be observed in place by the QSA (more on that later).

What Does It Take to Become PCI Compliant? | PCI DSS Steps to Completion

Once the QSA has taken in all the evidence they can, they will schedule an onsite with you.

In these days of Covid-19, the onsite has morphed into a virtual onsite, where possible. The onsite has multiple goals.

  • First, it’s to do all the physical security requirements that cannot be done without walking through and observing them.
  • Second, the onsite compresses the request/response cycle.

What I mean is there is a request from the QSA to demonstrate compliance to a given requirement and the subsequent response by you can take an extended amount of time.

Through an onsite, the QSA can ask you:

  • What you are doing to be compliant.
  • You can show how you are doing so to the QSA and be done.

Last, as I mentioned above, some parts of the PCI DSS compliance are to be witnessed in place. The PCI DSS RoC template literally says, “Observe…” and that is what they want the QSA to do.  A follow on to that is interview questions. There are places throughout the RoC where we must interview personnel to provide responses for compliance. If done during the onsite, those interviews can be done reasonably quick and then you do not have a string of meetings for weeks while you coordinate schedules.

Once the onsite is complete, the QSA will write the RoC.

All your evidence and all the observations are put down in the RoC template. Where there is additional evidence needed, the QSA will reach out to you for input. This is where you have a chance to head off a non-compliant RoC. If as a product of the up-front evidence gathering, onsite, and analysis you discover you have a non-compliant requirement, the QSA will generally allow for a remediation period to address the non-compliant items. If you can remediate the issue prior to the end of the assessment, the QSA will re-assess the non-compliant items to determine if they have been properly remediated and are now compliant. The key caveat here is that not all things can be “fixed.” By that, I mean some evidence, like missing a vulnerability scan, cannot be remediated and may or may not qualify for a compensating control. We simply cannot bend the laws of physics and go back in time to change a missing scan. Nor may it be possible to remediate an item when there is a process failure. For instance, if there is no change management process in place, there is nothing you can do to create one in the past.

Finishing up. Once the RoC and the attestation of compliance, AoC, are done, they go into a PCI SSC mandated quality assurance phase.

What is envisioned here is that another set of eyes review the evidence, review the narratives written by the QSA, and suggest corrections where necessary. That may mean the QSA comes back to you for more evidence. Do not be alarmed, it is just part of the process. The report must stand on its own because it is a “Point in time” report. At the end of the QA phase, the report is finalized, which officially ends the assessment. At this point, you are left with the report for your use and the AoC for distributing to other entities who want to know if you are compliant or not. A word of caution; you should never be distributing your RoC to any outside firm who wants to make sure you are compliant. You may be asked by your acquiring bank for your RoC, but in many cases all they want to see is the AoC.

In closing, the steps above should ideally take around three months from start to finish. I have found it takes longer just because of the time it takes one or two people trying to amass the required evidence, which leads me to encourage business as usual processes (again). Business as usual is the drive by the PCI SSC for entities to bake into their day to day operations the PCI DSS requirements. The result is that instead of the assessment being a major ramp-up and cathartic event like the last game of the World Series, it becomes an annual demonstration of compliance. I’ve seen some firms successfully put in governance, risk and compliance tools to help facilitate the evidence gathering. The idea being that some additional work to put in the GRC tool pays off in the long run to help lower the impact of conducting an assessment. However, you work the assessment, it shouldn’t take an extended amount of time to conduct from start to finish. If it does take more than 4-5 months, then the evidence will start to age, and the validity or accuracy of the assessment goes down. Its been my experience if it takes an extended period, the entity is either not ready, not focused, or not compliant.

_____________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

_____________________

Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years.

Written by Drew Cathey

Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years. Coming from a background in telecommunications IT operations, he has held positions in engineering, project management and IT security. Drew holds degrees in biology, engineering and an MBA in Information Technology management along with PMP, CISSP, CISA and QSA certifications. He resides in St. Petersburg, FL with his two children and enjoys running, bicycling and tennis.