GDPR 101 Part 2: What are the Requirements of GDPR?

Learn the basics about the EU’s General Data Protection Regulation.

Gary Glover
VP of Assessments
CISSP, CISA, QSA, PA-QSA
Part 2 of our 3-part GDPR 101 blog series is based on our GDPR 101 Webinar and will cover the “what” of the GDPR: its terms, requirements, and the individual data subject rights it names and protects.

GDPR 101 Part 1: Should I Be Worried? helped set up a framework for your approach to GDPR compliance. Our 3rd installment in this blog series will offer practical tips to get you started on your own GDPR compliance journey.

Terms and Definitions in the GDPR

First up, the difference between data controllers and data processors.

Not all organizations involved in the processing of personal data have the same roles or levels of responsibility.

  • Data Controllers: Entities or individuals that need to process personal data in order to do business. They determine the purposes for which and the manner in which the personal data is processed. The data controller must exercise control over the data processing and ultimately carries the responsibility for its security.

  • Data Processors: Processors take and/or process personal data on behalf of the Controller. 


Other important GDPR terms to know:

  • Supervisory Authority: An independent public authority established by a member state to represent the people and oversee/monitor businesses.

  • Personally Identifiable Data (PII)/Personal Data: any information relating to a data subject, which could identify them directly or indirectly. Besides names, addresses, etc., personal data can refer to identification numbers, or even to one or more factors specific to physical, physiological, mental, economic, cultural or social identity.

  • Pseudonymisation: amending data so that it is no longer identifiable except with a key. Sometimes takes the form of a coded data set and works a bit like encryption. Does not apply to data that is rendered anonymous. Pseudonymisation may not always put data out of scope for GDPR, but it can allow the relaxing of some provisions for using data for secondary purposes, like historical or research purposes. 

  • PII/Personal Data Breach: A security breach leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored, or otherwise processed.


What are the requirements of the GDPR?


Data Mapping and Tracking
The first step in GDPR compliance is to discover and clearly document all of the PII/personal data that flows into and out of your organization. To do this, you will need to understand the processes that use PII and conduct internal interviews. Once you know where and what you’re looking for, a good data discovery tool can help. The next step is to document what the personal data is, where it comes from, and where it flows. Documentation includes data flow and network diagrams, as well as process descriptions.

INFOGRAPHIC: How to Find and Secure Unencrypted PII

Communicating Privacy Information
GDPR has core principles about communicating with those you get personal data from. This communication could occur between you and the data subject themselves, or you and an entity providing you with previously collected personal data.

Privacy notices must be more transparent, using clear and plain language, and be easily accessible and easy to understand for any of your customers. This communication will need to explain things such as your lawful basis for getting their data, how long it will be kept, and what their rights are regarding the data you are processing or storing.

Subject Access Requests
The time limit to comply with data subject access requests (DSAR) has been reduced from 40 days to one month. If you handle a large number of access requests, consider how to deal with requests more quickly.

In most cases, you’ll not be able to charge the customer for the time you use to complete the request. You can refuse or charge for requests that are manifestly unfounded or excessive. If you do refuse a request, you must tell the individual why and that they have the right to complain to the supervisory authority and to a judicial remedy. You must do this without undue delay and at the latest, within one month

Processing Data Lawfully
You will need to explain your company’s need to obtain the personal data, including the lawful basis for gathering and processing it. Document this information and update your privacy notice to explain it.

Consent to Process Data
Gathering data needs to include a clear “opt-in” step from data subjects. You will not be able to inform customers through an automatic pop up or “fine print” only. Consent must be obtained. Review how you seek, record, and manage consent, and maintain clear privacy notice documentation.

Consent for Children
Organizations must have processes in place to verify data subjects’ ages. For children, your privacy notice must be written in simple language the child can understand. At present, the GDPR states that you must obtain parental or guardian consent for any data processing activity of a subject younger than 16 in the EU.

Data Breaches
Establish policies and procedures to detect, report, and investigate a personal data breach (e.g., Incident Response Plan.) You must report personal data breaches to your SA within 72 hours after awareness of the breach. If individuals face an adverse impact, contact individuals directly. Failure to report a breach when required to do so could result in a fine in addition to the fine for the breach itself.

Data Protection Officers
You will need to designate a Data Protection Officer (DPO) to be responsible for data protection compliance if your organization is:

  • A public authority or body (except for courts acting in their judicial capacity)

  • An organization carrying out regular and systematic monitoring of data subjects on a large scale

  • An organization processing a large scale of special data categories—health records—(as detailed in Article 9) and personal data relating to criminal convictions and offenses (as detailed in Article 10)


But even if you don’t fall into one of these categories, we highly recommend designating a DPO. Your DPO will need knowledge, support, and authority to carry out their role effectively.

SEE ALSO: GDPR Frequently Asked Questions

Data Protection by Design
GDPR makes “data protection by design and default” an express legal requirement. This one statement itself can create a myriad of data protection and security requirements that are not specifically defined by the GDPR but are well known in the data security industry.

You may already be familiar with many of them if you undergo PCI DSS, ISO 27000, SOC, or other security assessments.

Data Protection Impact Assessments 
Data Protection Impact Assessments (DPIAs) are essentially a formal Risk Assessment process like that defined in NIST 800-30.  You will need to conduct DPIAs when specific risks might affect the rights and freedoms of data subjects. For example, when a new technology is deployed, a profiling operation will impact individuals significantly, or when there’s a large-scale processing of special categories of data.

This impact assessment will use information gathered from your data mapping exercise as well as information about all the systems and networks used to process data. This process is critical to implementing the “data protection by design and default” philosophy.

Security Considerations
The concept of “data protection by design and by default” leads to the need for a lot of security controls to be applied to your systems, processes and people involved in dealing with sensitive personal data.

Based on our experience in the security industry, here are a few of the major areas that will need attention. Each of these bullets could be expanded into more system or process requirements, but we will not go into that here.  If you want to be GDPR compliant, you will need to have documented evidence that your systems embody the principle of “data protection by design and by default.”

WEBINAR: Understanding the New Multi-Factor Authentication Supplement

What rights does GDPR name and protect?


Right to erasure: Individuals may request to have personal data erased. This right is also sometimes called “the right to be forgotten.” Other data security standards (such as HIPAA) may overrule the right to erasure in certain circumstances; it’s best to consult with a legal advisor regarding these possible scenarios.

Right to be informed: Keeping data subjects informed is key to transparency under the GDPR. You must let them know your purposes for processing their personal data, your retention periods for that personal data, and who the data will be shared with. This is known in the GDPR as “privacy information.”

Right of access: Data subjects have the right to access their personal data and supplementary information. The right of access also states that individuals should be aware of and verify the lawfulness of the processing.

Right to rectification: The GDPR includes a right for individuals to have inaccurate personal data rectified or completed if it is incomplete.

Right to restrict processing: In certain circumstances, individuals have the right to request the restriction or suppression of their personal data. Restricted processing means the data can be stored, but not used.

Right to data portability: You may be required to provide the personal data in a structured, commonly used and machine-readable format. This right only applies to personal data an individual has provided to a controller, where the processing is based on the individual’s consent or for the performance of a contract, and when processing is carried out by automated means.

Right to object: Individuals may object “on grounds relating to their particular situation” to data processing—even if it’s based on legitimate interests or the performance of a task in the public interest/exercise of official authority (including profiling). They have a right to object to direct marketing (including profiling), as well as to processing of their data for purposes of scientific/historical research and statistics.

Rights related to automated decision making including profiling: this right includes additional rules to protect individuals if a data controller is carrying out solely automated decision-making that has legal or similarly significant effects on them. You can only carry out this type of decision-making where the decision is: necessary for the entry into or performance of a contract; or authorized by Union or Member state law applicable to the controller; or based on the individual’s explicit consent.

Who enforces GDPR?

There are general supervisory authorities (SA), for example the Information Commissioner’s Office in the UK, but it’s a good idea to start finding out who your specific SA is. The SAs are responsible for issuing fines.

GDPR 101 blog series
Watch for our third and final installment of our GDPR 101 blog series. In it, we will cover the “how” of GDPR: the important steps you’ll need to take and the resources to help you take them.

Also check out our “GDPR 101 Part 1: Should I Be Worried” blog post. It’s an important introduction that will helps set the stage for how you should think about and approach GDPR compliance.

Gary Glover (CISSP, CISA, QSA, PA-QSA) is Director of Security Assessment at SecurityMetrics with over 10 years of PCI audit experience and 25 years of Star Wars quoting skills. May the Force be with you as you visit his other blog posts.

What are the 12 requirements of PCI DSS Compliance?

The 12 PCI Requirements, plus resources to help address them. 


The PCI DSS (Payment Card Industry Data Security Standard) is a security standard developed and maintained by the PCI Council. Its purpose is to help secure and protect the entire payment card ecosystem.

Breaches and data theft are unfortunately common, and negatively impact all payments parties in different ways—from retailers to consumers to banks—so the need for PCI compliance has never been greater.

INFOGRAPHIC: A Quick Look at PCI DSS Compliance

No matter where you are in your PCI compliance journey, you'll need a reference to help organize your thoughts and get headed in the right direction. We hope this article will serve as your “jumping off point” as you start to address the requirements of the PCI DSS.

For more detailed information and interactive IT task checklists, check out our 2018 Guide to PCI DSS Compliance. 

Before diving into the PCI requirements, you will want to start by determining which SAQ applies to your business. While most requirements will stay the same, there are some differences in the work you’ll need to do based on your SAQ.

1: Protect your system with firewalls 


The first requirement of the PCI DSS is to protect your system with firewalls. Properly configured  firewalls protect your card data environment. Firewalls restrict incoming and outgoing network traffic through rules and criteria configured by your organization.

You’ll want to install both hardware firewalls and software firewalls. Both provide a first line of defense for your network. Hardware firewalls are the more robust security option. They can protect an entire network and segment its internal areas. Hardware firewalls are typically more expensive, take time to properly configure, and need to be maintained and reviewed regularly.

Software firewalls are cheaper and easier to maintain. They are meant to protect a single host from internal threats—commonly those from employees’ mobile devices, which can move in and out of the secure environment. If an employee clicks on a link in a phishing email, a software firewall should prevent malware infection.

SEE ALSO: Compliance with PCI Requirement 1: Basics of Managing Your Firewall


2: Configure passwords and settings 


You shouldn’t keep vendor-supplied defaults around. Out-of-the-box devices, such as routers or POS systems, come with factory settings like default usernames and passwords. Defaults make device installation and support easier, but they also mean that every model originates with the same username and password. Default passwords are simple to guess, and most are even published on the Internet.

The problem is that third parties sometimes install hardware or software and leave merchants unaware that their entire system is protected by an easy-to-find/crack password. Vendors might also purposely leave weak or default passwords to make service easier. But, that’s like leaving your front door unlocked just to make life more convenient.

Fulfilling requirement 2 involves inventorying and then properly configuring all security settings on all systems and devices. You will need to assign someone to compile and review this information.

SEE ALSO: PCI Requirement 2: How to Get Compliant

3: Protect stored cardholder data


According to requirement 3, stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). The problem is many merchants don’t know they store unencrypted primary account numbers (PAN).

Not only must card data be encrypted, the encryption keys themselves must also be protected. For example, using a solid PCI DSS encryption key management process will help keep you from storing the key in the “lock” itself.

To fulfill this requirement, you need to create and document a current cardholder data (CHD) flow diagram for all card data flows in your organization. A CHD flow diagram is a graphical representation of how card data moves through an organization (see example). As you define your environment, it’s important to ask all organizations and departments if they receive cardholder information, and then document how their answers may change card data flows.

You should regularly run a data discovery tool like PANscan or PIIscan. These tools help identify the location of unencrypted PAN and other sensitive information, so you can securely delete or encrypt it. 


SEE ALSO: PCI Requirement 3: What You Need to be Compliant

4: Encrypt transmission of cardholder data across open, public networks 


For requirement 4, you need to know where you send cardholder data. Here are common places where primary account numbers (PAN) are sent:
  • Processors 


  • Backup servers 


  • Third parties that store or handle PAN 


  • Outsourced management of systems or infrastructure 


  • Corporate offices 



You then need to use encryption and have security policies in place when you transmit this cardholder data over open, public networks.

A note about SSL and early TLS web encryption: based on vulnerabilities in web encryption, the PCI Security Standards Council has released policy stating that you need to transition from SSL and early TLS to secure versions of TLS by June 30, 2018.

SEE ALSO: PCI Requirement 4: Securing Your Networks

5: Use and regularly update anti-virus software


Anti-virus software needs to be installed on all systems commonly affected by malware. Make sure anti-virus or anti-malware programs are updated on a regular basis to detect known malware. Maintaining an up-to-date anti-malware program will prevent known malware from infecting systems.

Be sure you or your POS vendor are regularly running your software’s anti-virus scans.

You should also keep up to date on current and existing malware threats. Using outside sources, such as vendor/anti-virus threat feeds, merchants can find out about emerging malware and attacks on systems. Then you can configure systems to alert and report on suspicious activity, such as new files added to known malware directories or unauthorized access attempts.

SEE ALSO: PCI Requirement 5: Protecting Your System with Anti-Virus

6: Regularly update and patch systems


Applications will never be perfect, which is why manufacturers frequently release updates to patch security holes. These patch updates can also be time sensitive. Once a hacker knows they can get through a security hole, they pass that knowledge on to the hacker community, which will then exploit the weakness until the patch has been updated.

Quickly implementing security updates is crucial to your security posture. Patch all critical components in the card flow pathway, including:
  • Internet browsers 


  • Firewalls 


  • Application software 


  • Databases 


  • POS terminals 


  • Operating systems 



Be vigilant and consistently update the software associated with your system. Requirement 6.2 states merchants must “install critical patches within a month of release” to maintain compliance. Don’t forget to update critical software installations like credit card payment applications and mobile devices. To stay updated, ask your software vendors to put you on their patch/upgrade notification list. 


SEE ALSO: PCI Requirement 6: Updating Your Systems

7: Restrict access to cardholder data by business need-to-know


To fulfill requirement 7, you need a role-based access control (RBAC) system, which grants access to card data and systems on a need-to-know basis. Configure administrator and user accounts to prevent exposure of sensitive data to those who don’t need this information.

PCI DSS 3.2 requires a defined and up-to-date list of the roles (employees) with access to the card data environment. On this list, you should include each role, the definition of each role, access to data resources, current privilege level, and what privilege level is necessary for each person to perform normal business responsibilities. Authorized users must fit into one of the roles you outline.

SEE ALSO: Keep Employees on a Need-to-Know Basis: A Look at Requirement 7

8: Assign a unique ID to each person with computer access


According to PCI DSS requirement 8, user IDs and passwords need to be sufficiently complex and unique. You should not use group or shared passwords.

However, your system security should not be based solely on the complexity of a single password. No password should be considered “uncrackable,” which is why, as of February 1, 2018, all non-console administrative access (remote access) to in-scope systems requires multi-factor authentication.


SEE ALSO: Combatting Weak Passwords and Usernames

9: Restrict physical access to workplace and cardholder data


Employees may think physical security only applies after hours. However, most data thefts (e.g., social engineering attacks) occur in the middle of the day, when staff is often too busy with their various assignments to notice someone walking out of the office with a server, company laptop, phone, etc.

You are not allowed to store sensitive information like payment card data out in the open. For example, many hotels keep binders full of credit card numbers behind the front desk, or piled on the fax machine, for easy reservation access. Unfortunately, this collection of files not only makes life easier for employees but gives criminals easy access to this information.

SEE ALSO: Employee Security Training Tips: Social Engineering

Requirement 9 states that you must physically limit access to areas with cardholder data, as well as document the following:

  • Who has access to secure environments and why they need this access 


  • What, when, where, and why devices are used 


  • A list of authorized device users 


  • Locations where the device is and is not allowed 


  • What applications can be accessed on the device 




You will also need to implement automated lockout/timeout controls on workstations, periodically inspect all devices, and most importantly—train your staff regularly about physical security, policies and procedures, and social engineering.

SEE ALSO: PCI DSS Requirement 9: Upping Your Physical Security 

10: Implement logging and log management


We found that in 2017, non-compliance with requirement 10 was the most common contributor to data breaches. Logs are only useful if they are reviewed.

System event logs are recorded tidbits of information regarding actions taken on computer systems like firewalls, office computers, or printers. To fulfill requirement 10, you must review logs at least daily to search for errors, anomalies, and suspicious activities that deviate from the norm. You’re also required to have a process in place to respond to these anomalies and exceptions.

Log monitoring systems, like Security Information and Event Monitoring tools (SIEM), can help you oversee network activity, inspect system events, alert of suspicious activity, and store user actions that occur inside your systems.

SEE ALSO: PCI Requirement 10: Logging and Log Management 

11: Conduct vulnerability scans and penetration tests


Your data could be left vulnerable due to defects in web servers, web browsers, email clients, POS software, operating systems, and server interfaces. Yes, fulfilling requirement 6 (installing security updates and patches) can help correct many of these defects and vulnerabilities before attackers have the opportunity to leverage them.

 But in order to be sure you’ve successfully patched these vulnerabilities, you need to be able to find them and test them. For that you need to perform regular vulnerability scanning and penetration testing.

A vulnerability scan is an automated, high-level test that looks for and reports potential vulnerabilities. All external IPs and domains exposed in the CDE are required to be scanned by a PCI Approved Scanning Vendor (ASV) at least quarterly.

A penetration test is an exhaustive, live examination designed to exploit weaknesses in your system. Just like a hacker, penetration testers analyze network environments, identify potential vulnerabilities, and try to exploit those vulnerabilities (or coding errors). Basically, these analysts attempt to break into your company’s network.

Requirements for frequency and type of penetration test will vary depending on your SAQ, business size, environment, systems, etc.

SEE ALSO: PCI Requirement 11: Vulnerability Scans and Penetration Tests

12: Documentation and risk assessments 


The final requirement for PCI compliance is to keep documentation, policies, procedures, and evidence relating to your company’s security practices.

If you perform a PCI audit, you’ll quickly pick up on the fact that there’s a big emphasis on your documented security policies and procedures. During an assessment, QSAs will typically verify that specific requirements are defined in company policies and procedures. Then, they’ll follow predefined testing procedures to verify that those controls are implemented in accordance with the PCI Data Security Standard and with written company policies.

You will need to include the following information in your documentation:
  • Employee manuals 


  • Policies and procedures 


  • Third-party vendor agreements 


  • Incident response plans 



The second part of requirement 12 is to perform an annual, formal risk assessment that identifies critical assets, threats, and vulnerabilities. This requirement will help you identify, prioritize, and manage your information security risks.

SEE ALSO: PCI DSS Requirement 12: Leverage Policy to Improve Security

The process of reaching PCI compliance takes time and can seem like an overwhelming list of demands, but it’s ultimately what will make the difference between a failed cyber-attack on your business and a cyber-attack that sinks your business.

Guides, checklists, and templates will help you and your IT teams complete day-to-day tasks associated with each requirement, and security professionals can advise you on more complicated issues. 

If you're interested in a PCI Audit or other security services, contact us here.

Takeaways from Our 2018 PCI Guide

Important lessons from the SecurityMetrics 2018 Guide to PCI DSS Compliance. 

Our 2018 PCI Guide is out and already helping businesses understand the Payment Card Industry Data Security Standard (PCI DSS) and simplify their own compliance journeys.

Merchants use our PCI Guide both as a desk-side PCI reference and as a tool to direct and track their organizations’ internal PCI compliance efforts. But, there’s also another side to the Guide. Our ultimate goal is to help you secure data and protect your business, so we’ve included highlights from our own research in the Guide to give you a clearer picture of how compliance and security work together.

Download the SecurityMetrics 2018 PCI Guide here.

This post will cover some of the most important takeaways from our Guide, so you can apply these lessons to the everyday operations of your business.

Forensic Data from 2017 Investigations

Our PCI Forensic investigators (PFIs) have been helping businesses analyze and recover from suspected data breaches for over 15 years. In the process, they’ve witnessed the rise and fall of popular cyber-attack trends as well as collected a trove of useful forensic data that can be used to inform your data security implementations.

What we found regarding the average breached merchant:

  • The average organization was vulnerable for 1,549 days. 

  • Cardholder data was captured for an average of 237 days. 

  • Cardholder data was exfiltrated for an average of 264 days. 

  • 45% of organizations were breached through insecure remote access. 

  • 39% of organizations had memory-scraping malware installed on their system. 

WEBINAR: Lessons Learned from 2017 Forensic Investigations

In general, we see that these trends stem directly from non-compliance with the PCI DSS.

Most organizations will experience system attacks from a variety of sources, and some of these attacks will result in data breaches. Some breaches are due to system or technology weakness, others to internal security process failures (e.g., ignoring patches and updates). Whatever the source of the attack or the ultimate reason for compromise, we’ve found a strong correlation between non-compliance and data breaches.

The PCI DSS is specifically designed to protect merchants and organizations that deal with payment card data and associated sensitive information. Following its requirements exactly will greatly diminish the chances of a successful cyber-attack on your systems.

Our Forensic Investigators track which PCI requirements organizations are—or are not—compliant with at the time of a data breach.



Our PFIs also record whether non-compliance with these requirements directly contributed to the data breach.


You can see that non-compliance with requirements like 10 (logging), 11 (vulnerability scans), and 12 (policy/procedures documentation) frequently contributed to the data breaches themselves.

Further, if there is a successful attack, shrinking the window of compromise will go a long way to lessen the damage a data breach can cause. The longer attackers have access to your data without you knowing, the more they can take and the more profit they stand to make.

Takeaway: You can shrink the window of compromise by properly implementing security measures like PCI requirement 10, “Implement Logging and Log Management,” or PCI requirement 7, “Restrict Access.”

Download our 2017 Forensic Data Breach Trends Infographic here.

Top 10 failing self-assessment questionnaire (SAQ) sections

We scanned our merchant database in search of the top 10 areas where SecurityMetrics merchants struggle to become compliant. Starting with the least adopted requirement, these are the results:

  • Requirement 12.10.1: Create an incident response plan to be implemented in the event of system breach.
  • Requirement 12.8.5: Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.
  • Requirement 12.5.3: Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.
  • Requirement 12.1: Establish, publish, maintain, and disseminate a security policy.
  • Requirement 12.6: Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures.
  • Requirement 9.9.2.b: Verify that personnel are aware of procedures for inspecting devices and that devices are periodically inspected for evidence of tampering.
  • Requirement 9.9.2.a: Verify that documented processes include procedures for inspecting devices and frequency of inspections.
  • Requirement 12.8.4: Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.
  • Requirement 1.2.1: Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.
  • Requirement 12.4: Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.


2017 showed significant decreases in compliance levels when compared to previous years. None of the investigated breached merchants in 2017 were found to be compliant with PCI DSS. In nearly every case, the vulnerabilities that attackers leveraged to gain access to merchant systems were covered by specific sections of the PCI DSS.

Takeaway: In other words, had the organization been compliant with those sections of the PCI DSS, the breach likely would not have occurred.

Download our 2017 PANscan Results Infographic here. 

Vulnerability scan results

External vulnerability scans performed by a PCI Approved Scanning Vendor (ASV) are just one tool in validating PCI compliance. But, the results can also provide valuable insight into common weak spots you should pay special attention.

These are the top 5 areas SecurityMetrics customers failed in vulnerability scans, and one can surmise that these trends extend to businesses who are both currently and not currently working on their security:

  • TLS Version 1.0 Protocol Detection
  • SSL Medium Strength Cipher Suites Supported
  • SSL 64-bit Block Size Cipher Suites Supported (Sweet32)
  • SSL Certificate with Wrong Hostname
  • SSL Self-Signed Certificate

Takeaway: If you haven't already, make sure your cryptographic protocols are in line with the latest PCI Council guidance.

Your PCI compliance journey

When planning and designing your organization’s compliance journey, it helps to understand the bigger picture. PCI DSS requirements were not designed arbitrarily but rather, specifically, to help you avoid data breaches and mitigate their effects if they do happen.

The Security Metrics 2018 Guide to PCI DSS Compliance is a powerful tool for understanding and appreciating the connection between compliance and security.

Let us know what you think about the guide! Email us at pr@securitymetrics.com with your feedback.

Interested in a PCI Audit, HIPAA Audit, or our other security services? Contact us here.



What's Inside Our 2018 PCI Guide

The 2018 PCI Guide is here. Learn what’s in it and how it will simplify your PCI process. 

We’ve officially launched our 2018 Guide to Payment Card Industry Data Security Standard (PCI DSS) Compliance. Inside you’ll find fresh insights, tips from auditors, forensic investigation data, interactive checklists, and a new prioritized chart to guide your reading.

You can download the 2018 SecurityMetrics Guide to PCI Compliance here.

Here’s a list of 5 of the best features from our 2018 Guide to PCI DSS Compliance:

1. A prioritized approach to PCI compliance


If you’re working towards payment card industry compliance this year, you'll want to check out our newly added section that begins on page 5, titled “How to Read This Guide.” We’ve added a chart to guide you through the requirements of the PCI DSS.

The chart gives an overview of the PCI Security Standards Council’s Prioritized Approach. The PCI SSC's Prioritized Approach consists of six milestones based on high-level compliance and security goals. Our chart breaks down requirements into individual IT tasks and assigns them to their related milestone(s).

This chart is especially useful for PCI compliance officers, CISOs, IT managers—anyone whose job requires that they plan, organize, or present on internal PCI compliance efforts. The Prioritized Approach offers organizations a risk-based roadmap to address issues on a priority basis, while also supporting organizational financial and operational planning.

Depending on where you are in your compliance journey, some milestones may be more significant to you than others. Rather than reading our guide cover to cover, we recommend you use this chart to guide your PCI compliance efforts.

2. Forensic data from our 2017 investigations


We believe knowledge is power, which is why we share data from our 2017 forensic data breach investigations on pages 11-13. By learning which PCI requirements were most commonly/not commonly implemented at the time of a data breach, which non-compliant requirements directly contributed to data breaches, as well as the top SAQ failures, you can appreciate the bigger picture of what PCI compliance means for organizations.

Understanding the patterns that typically go along with data breaches empowers you to make informed decisions about allocating your PCI compliance resources.

WEBINAR: Lessons Learned from 2017 Forensics Investigations

We found that 2017 showed significant decreases in compliance levels when compared to previous years and that none of the investigated breached merchants in 2017 were found to be compliant with PCI DSS. And in nearly every case, the vulnerabilities that attackers leveraged to gain access to merchant systems would have been mitigated if the organization had been compliant with the entire PCI DSS.


3. Interactive IT Checklists 


PCI compliance comes down to the successful completion of a series of tasks. At the end of each requirement section, we include checklists as a way to help IT teams track and manage these action items.

The IT checklists have been one of the most popular and utilized features of our guides. This year, they are “interactive,” meaning you can actually check off tasks within the PDF document. You can also type directly in the assignment and completion fields.

We added the checklists specifically to give you more options to manage and document your organization’s compliance-related IT tasks. The intent is to simplify compliance for everyone: those who determine the tasks, those who assign the tasks, and those who ultimately perform the tasks. This doesn’t replace our PCI audit management tool, but should enhance the overall process of getting compliant.

Interactive IT checklists are found on the following pages: 40, 44, 48, 51, 53, 58, 60, 64, 69, 73, 81, and 86.

INFOGRAPHIC: How to Discover and Encrypt Sensitive Data


4. Tips from auditors 


Our “Tips from Auditors” sections throughout the document give context to the bigger picture of PCI compliance as well as actionable tips from our QSAs, who have years of IT security and audit experience.

We include auditor commentary and best practices for each PCI DSS requirement, as well as in other sections of the guide. If you are looking for an overview of what’s important for data security in the payment card industry, these sections would be a perfect place to start.

“Tips from an Auditor” sections can be found on the following pages: 17, 39, 43, 47, 50, 52, 56, 59, 63, 68, 72, 80, 85, and 106.



5. PCI Data Security Standard updates


Our PCI guide is written in accordance with the latest version of the PCI DSS, and outlines the supplemental guidance released by the Security Standards Council. Pages 24-30 outline and describe recent important changes and supplements to the PCI DSS, including:

PCI Data Security Standard version 3.2

New service provider requirements

Updated SSL/early TLS migration dates

February 2017 Multi-factor authentication supplement 

Multi-factor authentication in or out of the CDE (8.3)

Clarifying masking criteria (3.3)

Change management process (6.4.6)

Service provider written agreement (12.8.2)


SEE ALSO: PCI DSS 3.2 Reminder to Comply

A powerful PCI help


Whether you are brand new to PCI compliance or are a seasoned systems administrator, you will find that the 2018 SecurityMetrics Guide to PCI DSS Compliance is a dynamic, hard-working document. We designed it to be a useful tool in the hands of anyone who wants to achieve compliance with the PCI DSS.

You can download the 2018 SecurityMetrics Guide to PCI Compliance here. 

We’d love to hear what you think—do new features like the interactive checklists or “Prioritized Approach” reading guide chart help your compliance managers and IT teams? Are there features of the guide you use more than others? Or are there things you’d like to see included in the next edition?

Email pr@securitymetrics.com with your feedback about the guide.

If you’re interested in a PCI audit or our data security services, contact us here.



 No Spreadsheets Needed: Manage HIPAA in SecurityMetrics’ Health Network Portal

Protect your network, save time on HIPAA, and maintain your reputation.

HIPAA management for large networks

Data security and HIPAA compliance are more important than ever for the healthcare sector. From large health networks to small-town medical practices, protected health information (PHI) remains a high-value target for attackers. Health organizations were hit hard in 2017—the healthcare industry experienced 23.7% of total data breaches that year. This trend of cyber-attacks and data theft in healthcare seems like it’s here to stay, but complying with HIPAA requirements will go a long way to protect your system from attackers.

Download our 2018 Guide to HIPAA Compliance. 

If you’re a HIPAA manager, IT Director, or CISO responsible for network-wide HIPAA compliance at your organization, you know that the vulnerabilities of individual members can affect your network as a whole. But, overseeing your network while managing the compliance of each member often amounts to a series of messy, tedious tasks—especially if your main tracking tools are spreadsheets and emails.

All-in-one network HIPAA management solution

We designed the SecurityMetrics Health Network Portal to be an efficient, organizational portal with tools that facilitate HIPAA management, monitoring, reporting, and tracking. No spreadsheets needed. Plus, HIPAA communications and documentation can be kept on one central platform.

Learn more about the SecurityMetrics Health Network Portal here.

Overview dashboard

The network HIPAA compliance journey begins at the overview dashboard. From this main screen, you can see compliance progress across your network, assign tasks, view scan results and risk summaries, and prepare compliance reports for C-level executives or auditors.



SEE ALSO: How Brightsquid Increased Business with HIPAA Compliance


Member Summary

Member summaryView progress based on member or location. The member summary tool shows you in real time how individuals’ compliance progress affects the network. You can see which members make the network safer and which ones increase risk. Monitor members’ HIPAA compliance by viewing each of their:

  • Breach protection checklist
  • Risk analysis
  • Risk management plan
  • Vulnerability scanning
  • Policies and procedures


SEE ALSO: HIPAA FAQs

Risk Summary

The overall security of your network is made up of many members’ tasks and efforts. Our risk summary tool calculates a risk level based on the combined data of every member in your network. This lets you see where you’re at and helps determine what your HIPAA goals might be.


SEE ALSO: Health Network Portal Data Sheet

Business associate overview

Covered entities must maintain a signed up-to-date business associate agreement (BAA) for each business associate they work with. Managing these contracts and tracking down business associates is made simple with the business associate overview tool. You can see at a glance how many business associates you work with and pinpoint which ones have yet to sign BAAs.


SEE ALSO: Business Associate Agreements 101

HIPAA tools for every stage and every day

Wherever you are in your HIPAA network compliance journey, the Health Network Portal is an everyday, easy-to-use solution that provides visibility and multi-level views for busy HIPAA managers and compliance officers.

The Health Network Portal guides network-wide compliance efforts and directs attention to potential security gaps, weak spots, and vulnerabilities, which otherwise would have been missed. It’s intended to not only for daily HIPAA management but also to provide reporting resources for meetings, audits, and documentation purposes.

Think the Health Network Portal might be a good fit for your organization? Speak to a specialist or request a quote for your network here.