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.
NSCC members face a new compliance requirement: cybersecurity confirmation. It sounds easy, complete a form, but risk is high. Here’s guidance.
Compliance departments are seriously challenged these days. As business swirls in response to COVID-19, compliance has taken a back seat. That can lead to trouble—violations, fines or both—due to missing deadlines. Management, in a questionable move, may ask compliance to do something taboo. Instead of reading a half empty glass post designed to help compliance deal with these challenges, they instead get a half full glass post that is brimming with optimism for compliance’s role during COVID-19.
Learn about how HIPAA Compliance plays a role in protecting against cybercriminals.