Which three 3 of these control processes are included in the PCI DSS standard?

Twelve PCI DSS requirements for compliance

There are 12 main requirements in six overarching goals for PCI DSS compliance. According to the PCI SSC, a vendor must complete the following tasks as part of its PCI compliance checklist:

Goal 1. Build and maintain a secure network.
1. Install and maintain a firewall configuration to protect card holder data (CHD).
2. Not use vendor-supplied defaults for system passwords and other security parameters.

Goal 2: Protect cardholder data.

3. Protect stored cardholder data.
4. Encrypt transmission of cardholder data across open, public networks.

Goal 3: Maintain a vulnerability management program.

5. Use and regularly update antivirus software.
6. Develop and maintain secure systems and applications.

Goal 4: Implement strong access control measures.

7. Restrict access to cardholder data by business need-to-know.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.

Goal 5: Regularly monitor and test networks.

10. Track and monitor all access to network resources and cardholder data.
11. Regularly test security systems and processes.

Goal 6: Maintain an information security policy.

12. Maintain a policy that addresses information security.

What is cardholder data?

Cardholder data is any personally identifiable information associated with a person who has a credit or debit card. This type of data also includes the person's primary account number (PAN), along with additional data such as their name, their card's expiration date and/or the card's service code:  a three- or four-digit number on cards that uses a magnetic stripe. The service code specifies acceptance requirements and limitations for magnetic-stripe-read transactions.

If the cardholder's name, expiration date and/or service code are stored, processed or transmitted with the PAN, they must be protected under PCI compliance regulations.

PCI DSS versions

PCI DSS 2.0 (Payment Card Industry Data Security Standard Version 2.0) is the second version of the Payment Card Industry Data Security Standard, and was released in 2011. According to the PCI SSC, version 2.0 included minor language adjustments to clarify the meaning of the 12 requirements. Version 2.0 reinforced the need for thorough scoping before an assessment and promoted more effective log management. It also broadened validation requirements for the assessment of vulnerabilities in a merchant environment.

PCI DSS v3.0 was the third major iteration of the standard, with new requirements that included methodology-based penetration testing to verify proper segmentation of the merchant cardholder data environment (CDE) from other IT infrastructure. Other new requirements included an inventory of all hardware and software components within the cardholder data environment, and documentation detailing which PCI requirements were managed by third-party vendors versus which were handled by the organization in-house. PCI DSS 3.0 also outlined new antimalware detection and remediation standards, as well as access control measures for onsite personnel and methods to protect payment data-capture technologies.

PCI DSS v3.2 was released in 2016, and like previous updates included clarifications to existing requirements, new or evolving requirements and additional guidance for vendors. The PCI DSS 3.2 updates protect against card exploits that are still causing problems, addressed new exploits and provided greater clarity for implementing and maintaining PCI DSS controls, according to the PCI SSC. These changes included new migration deadlines for the removal of Secure Sockets Layer (SSL)/early Transport Layer Security (TLS). With the release of v3.2, the PCI SSC noted that the credit card industry views PCI DSS compliance as a mature standard that does not require significant updates. As a result, the PCI SSC said the marketplace can expect incremental revisions like 3.2 in the future to address "the changing threat and payment landscape."

Merchant levels

The payment card industry uses merchant levels to determine risk and ascertain the appropriate level of security for their businesses. Merchant levels determine the amount of assessment and security validation that is required for the merchant to pass PCI DSS assessment. Merchants' PCI compliance levels are broken down into four categories, or "levels," based on the number of transactions the merchant handles annually.

For example, companies that process over 6 million Visa transactions a year are known as Level 1 merchants. Level 1 merchants must undergo a PCI assessment performed by a Qualified Security Assessor who issues a Report on Compliance (ROC) that verifies the business's PCI DSS compliance. The ROC is sent to the business's acquiring bank, which then sends it to the appropriate credit card company for verification.

PCI Mobile Payment Acceptance Security Guidelines

In 2013, PCI SSC published the "PCI Mobile Payment Acceptance Security Guidelines for Merchantsas End-Users" to educate merchants on the risks associated with card data transferred via mobile devices such as smartphones and tablets. The guidance outlined the major risks associated with mobile payment transactions, including account data entering the device, account data residing in the device and account data leaving the device.

The "Mobile Payment Acceptance Security Guidelines"also provided recommended measures for merchants to secure mobile devices used for payment acceptance, and guidelines for securing the payment acceptance solutions' hardware and software. The PCI SSC noted in the document's release that until mobile hardware and software implementations could meet the guidelines, the best options for merchants was using a PCI-validated, point-to-point encryption solution.

Security issues and breach risk

The PCI SSC was formed in 2006 after data security breaches of cardholder data put customers' information at risk, and increased credit card companies' costs. The risks to cardholder data include external hackers or cybercriminals; internal individuals acting maliciously or simply making a mistake; and intruders intending to cause damage or steal assets.

A Qualified Security Assessor (QSA) is a data security firm that has been trained and is certified by the PCI SSC to perform on-site security assessments to verify PCI DSS compliance. A PCI assessment is an audit for validating PCI DSS compliance. During the assessment, the QSA determines whether the merchant has met the PCI DSS 12 requirements, either directly or through a control that provides a level of defense that is similar to the requirement.

Vulnerability scanning is also common during a PCI DSS compliance audit. An Approved Scanning Vendor (ASV) is a service provider that is certified and authorized by the PCI SSC to scan payment card networks for compliance.

The penalties for not following the credit card data security standards are not widely publicized. According to the PCI DSS website, any PCI compliance fines and/or penalties associated with PCI DSS noncompliance are defined by each of the payment card brands. The consequences of not being PCI compliant reportedly range from $5,000 to $500,000, and are levied by banks and credit card institutions. Cardholder breaches can also result in the following penalties: $50 to $90 fine per cardholder data compromised, suspension of credit card acceptance by the merchant's credit card account provider, loss of reputation and potential civil litigation.