Four reasons to treat PCI DSS 3.2 as a mandate rather than a best practice
Be proactive instead of reactive. It’s better to be safe than sorry. Fortune favors the prepared. These sayings resonate with us because they ring true. It’s advice we want to follow.
That brings us to the topic of Payment Card Industry (PCI) Data Security Standards (DSS). We’re currently in the best practice period with PCI DSS 3.2 until February 1, 2018, when 3.2 becomes the law of the land in PCI world. Until then, organizations aren’t required to comply with 3.2. The current mandate is 3.1.
In an era known for talk of deregulation, why would you run toward a new, yet-to-take-effect, mandate? In short, 3.2 changes address the weaknesses of 3.1. Specifically, there are four reasons why you should treat PCI DSS 3.2 as a mandate, instead of a best practice.
Protecting cardholder data is continuous, not a once-a-year compliance activity
One of the drivers for 3.2 was the fact that many in the payment card industry were treating requirements as a once-a-year compliance activity. A lot can change in a year’s time, which can result in vulnerabilities with customer data. 3.2 addresses this by ensuring security controls are in place following a change in a cardholder data environment (requirement 6.4.6).
Hackers love having time to do their criminal activity
In terms of PCI DSS standards, there wasn’t a sense of urgency for service providers to report on failures of critical security control systems. Any delays in detecting or reporting give more time to hackers to do their thing. A faster response to addressing vulnerabilities in the security control system shores up defenses before hackers can act. PCI DSS 3.2 solves this in 10.8 and 10.8.1.
Reviewing and reporting on security policies and operational procedures
Most data breaches are traced to human error. Company personnel and employees of third-party service providers who handle cardholder data must follow policies and procedures. PCI DSS 3.2 ensures this with new requirements like multi-factor authentication, quarterly reviews, and penetration testing. Evidence of compliance like audit logs and policy reports must be collected and presented at the PCI DSS assessment.
Master the new mandate with a GRC platform
If PCI DSS 3.2 sounds like more work heaped on top of current work, it might be because of the way your company complies with PCI DSS. Using spreadsheets, word-processing, emails, and other manual methods for compliance is more time-consuming and challenging than it needs to be. A GRC platform is designed for compliance tasks like PCI DSS 3.2, as it provides functionality to perform gap analysis to determine exactly what’s needed to comply, as well as to automate many compliance processes. A GRC platform can also help you manage third-party risk and ensure audit-ready status.
Until February 1, 2018, you can continue complying with PCI DSS 3.1 and treat 3.2 as a best practice. But given what’s at stake — cardholder data, your company’s good name, customer trust — it’s wiser to be proactive, safe and prepared.
March 1, 2019 is the deadline for covered entities to comply with the final phase of 23 NYCRR 500. Is your organization ready?
A business unit wants to hire a vendor that doesn’t meet policy standards and requests an exception. Approve or deny the exception request? Learn strategies about improving policy exceptions.
2019 is just around the corner, and if 2018 has taught us anything, it’s that the business of compliance and risk management is more challenging than ever.