Payment Card Industry Data Security Standard (PCI DSS)
Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards created to protect credit and debit card data against theft and fraud. It was developed and is managed by the PCI Security Standards Council (PCI SSC), a global forum founded by the five major card brands: American Express, Discover, JCB International, MasterCard, and Visa.
When people refer to "PCI (Payment Card Industry)" in the security context, they're generally talking about PCI DSS. PCI is the organization that creates the rules, while PCI DSS is the security standard, that is, the rules themselves.
Any organization, regardless of size, that stores, processes, or transmits cardholder data needs to be PCI DSS compliant. The objective is to create a secure environment for this data, reducing the risk of violations that can lead to financial losses and reputation damage. According to Verizon, 84% of data breach cases involved payment card data.
There's no federal law saying we need to implement PCI-DSS, it's a game rule if you want to work with card payment, and it'll be in the contract. If you work only with PIX, the rules are different.
Some PCI DSS requirements may also apply to entities with environments that don't store, process, or transmit account data - for example, entities that outsource payment operations or management of their cardholder data (CDE). The logic behind this statement is one of the most important principles of PCI DSS compliance: "You can outsource the operation, but you can't outsource the responsibility."
Let's quickly explore some scenarios about the statement above:
E-commerce with Redirect or iFrame. This is the most common case.- The virtual store doesn't process payment directly. The customer is redirected to a payment page hosted by your provider or enters data in a secure "window" controlled by the provider but appearing within your checkout page.
- If the application is hacked and the checkout page code is replaced by a fake but identical-looking one, data will be collected the same way.
Physical Point of Sale (POS) Terminals. Physical stores use "card machines" (POS terminals) that are provided and managed by an acquirer (like Rede or Getnet). Card data is encrypted in the terminal itself and sent directly to the acquirer, without passing through your store's network. These machines need to be audited.- A criminal may try to physically tamper with your card machine, installing a "skimming" device to steal card data or even replacing your terminal with a fake one.
- PCI DSS has requirements for physical access to cardholder data. A simple photo of the card or a camera can read the data. Train the employee not to be in possession of the customer's card for even a moment.
PCI DSS recognizes that the environment may not touch the data, but the payment ecosystem as a whole needs to be secure. The store, whether physical or virtual, is a customer interaction point and therefore a potential attack point that can compromise an otherwise secure payment process.
Before continuing, it's worth mentioning a scenario.
When using software in a PCI PTS certified terminal, where the SDK only initiates the transaction with the value, the payment process is completely isolated. The card machine captures and encrypts data, communicating directly with the gateway. As your software never accesses sensitive data and only receives the final status (approved/denied), your PCI DSS compliance obligation is drastically reduced, focusing on physical device security, not a complex audit.
Involved in the Process​
Summarizing the PCI ecosystem agents is the best way to understand how everything connects.
Both ROC and SAQ are documents used to attest PCI DSS compliance. The big difference between them is the depth of the audit and who performs it.
SAQ (Self-Assessment Questionnaire) is generally applied to smaller merchants. It's a checklist where the company itself responds yes and no to PCI DSS requirements attesting that it's compliant. It's the company's own attestation, based on its self-assessment.
ROC (Report on Compliance) is an extremely detailed and formal audit report. It's used for large merchants. An external and certified auditor, the QSA (Qualified Security Assessor), after a long and rigorous on-site and remote audit. Generally this auditor works for a QSA Company becoming a QSA Professional.
A QSA Professional cannot act autonomously or as a freelancer. They can only conduct an official audit and sign a ROC (Compliance Report) while employed and acting on behalf of a certified QSA Company.
For your complete audit, the QSA requires proof that only an ASV (Approved Scanning Vendor) company can provide: the approved external vulnerability scan report (requirement 11.2.2). Even if you have a great security team, ASV validation is necessary to have no bias in the process.
On the official website we can find certified QSAs and ASVs for auditing.
Delivery of SAQ or ROC is done once a year. If the company is level 2, 3, 4, SAQ is required; if it's level 1 (high transaction volume), ROC is done.
The ASV report is done quarterly, that is, 4 times a year regardless of level.
The Attestation of Compliance (AOC) is your annual security "diploma", the official document that proves you're PCI DSS compliant. It functions as the signed cover sheet of your assessment: if you did a self-assessment (SAQ), the AOC will have only your company's signature; if you passed an audit (ROC), it will also have the QSA auditor's signature. It's important to remember that the AOC is the result of your continuous work and, to be valid, it depends on evidence collected during the year, like quarterly ASV reports. In the end, this is the document you send to your acquiring bank to prove you did your security "homework".
- PCI Security Standards Council (PCI SSC) - The "Legislator"
- Who is it? A global forum created by the five major card brands (Visa, MasterCard, American Express, Discover, JCB).
- What does it do?
- Creates and maintains security standards (PCI DSS, PCI PTS, etc.).
- Certifies and trains auditors and vendors (QSAs, ASVs, PFIs).
- DOESN'T monitor or impose fines. Its function is purely normative and educational.
- Card Brands (Payment Brands) - The "Inspectors"
- Who are they? Visa, MasterCard, American Express, etc.
- What do they do?
- Require PCI DSS compliance from everyone participating in their payment system.
- Define compliance levels (Level 1, 2, 3, 4) and validation requirements for each.
- Apply penalties (fines, fee increases) to Acquiring Banks in case of non-compliance or data breach.
- Acquiring Bank (Acquirer) - The "Manager"
- Who is it? The financial institution that offers transaction capture service to the merchant (e.g., Cielo, Rede, Stone, Getnet).
- What does it do?
- Manages the payment contract with the merchant.
- Is primarily responsible for ensuring their merchants are compliant.
- Collects validation documents (SAQ, ROC, ASV reports).
- Passes card brand fines to non-compliant merchants.
- Merchant - The "Final Responsible"
- Who is it? Any company, of any size, that stores, processes, or transmits card data as part of its business.
- What does it do?
- Has the final responsibility to protect its customers' data.
- Implements the 12 requirements, which we'll see later, of PCI DSS in its environment.
- Validates its compliance annually through the method required for its level (SAQ or ROC).
- Qualified Security Assessor (QSA) - The "External Auditor"
- Who is it? A professional certified by PCI SSC to perform PCI DSS audits. Works for a QSA company.
- What does it do?
- Is hired by Level 1 merchants (high transaction volume) to perform a complete and independent audit.
- Produces the Report on Compliance (ROC), which is the official audit report.
- Approved Scanning Vendor (ASV) - The "External Security Inspector"
- Who is it? A company certified by PCI SSC to perform vulnerability scans.
- What does it do?
- Is hired by merchants to perform mandatory quarterly scans on networks exposed to the internet.
- Generates the ASV scan report that validates compliance with Requirement 11.2.2.
- PCI Forensic Investigator (PFI) - The "Crime Scene Expert"
- Who is it? A highly specialized company, certified by PCI SSC to investigate card data breaches.
- What does it do?
- Is activated AFTER a data breach occurs.
- Conducts forensic investigation to determine the cause and extent of the violation.
- The PFI report is required by card brands.
Understanding these roles is fundamental to navigating the PCI world. It shows that compliance is not just a technical task for the merchant, but a complex ecosystem based on shared responsibility.
Methodology​
Achieving PCI DSS compliance is a continuous process, not a single project. General steps include:
- Scoping: The first and most critical step is to identify all systems, networks, and processes that store, process, or transmit cardholder data. The goal is to isolate this environment (known as Cardholder Data Environment - CDE) to reduce compliance scope and cost.
- Assessment / Gap Analysis: Perform a gap analysis comparing existing security controls with the 12 PCI DSS requirements. This is generally done by completing the appropriate Self-Assessment Questionnaire (SAQ) for your business.
- Remediation: Fix all security gaps identified in the assessment step. This may involve implementing new technologies, changing processes, or updating policies.
- Reporting: After remediation, the organization must formally validate its compliance. This is done by submitting the SAQ or ROC (for Level 1) and other necessary documents, like the Attestation of Compliance (AOC), to acquirers (banks) and card brands.
- Continuous Monitoring: Compliance doesn't end with the report. It's a cycle. Organizations must continuously monitor their controls, apply patches, perform quarterly scans, and ensure security policies are followed.
To access the documents just visit the site.
The Quick Guide gives us a good summary of the standards that PCI DSS requires.
When we talk about data we have 2 types.
| Cardholder Data - CHD | Sensitive Authentication Data - SAD |
|---|---|
| Primary Account Number (PAN) | Full track data (magnetic stripe data or chip equivalent) |
| Cardholder Name | Card verification code |
| Expiration Date | PINs/PIN blocks |
| Service Code |

In total there are 6 Objectives and 12 Requirements. Think of them as security goals and the specific actions needed to achieve them.
-
Objective: Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data. This means isolating the network containing card data from other less secure networks and from the internet.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters. It's crucial to change all default passwords and settings before putting a system into production.
-
Objective: Protect Cardholder Data
Requirement 3: Protect stored cardholder data. The main rule is: if you don't need it, don't store it. If you need to, data must be encrypted, truncated, or tokenized to make it unreadable.
Requirement 4: Encrypt transmission of cardholder data across open, public networks. Any card data sent over the internet or other open networks must use strong encryption (like TLS).
-
Objective 3: Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update antivirus software or programs. All systems in the cardholder data environment must be protected against malware.
Requirement 6: Develop and maintain secure systems and applications. This involves applying security patches quickly and following secure development practices to avoid vulnerabilities like SQL injection.
-
Objective: Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know. Access should only be granted to individuals whose roles explicitly require such access (principle of least privilege).
Requirement 8: Identify and authenticate access to system components. Each user with access to systems with card data must have a unique ID and a strong password.
Requirement 9: Restrict physical access to cardholder data. This applies to both data centers (with cameras, locks, and access control) and physical media like papers or backups.
-
Objective: Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data. Maintaining detailed logs of who accesses what and when is fundamental to detect and investigate incidents.
Requirement 11: Regularly test security systems and processes. This includes performing vulnerability scans, penetration tests (pentests), and security reviews.
-
Objective 6: Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security for all personnel and contractors. The organization must have a formal, documented, communicated, and maintained security policy.
If you think the company does all that massive onboarding full of content just to teach you, you're wrong. It's required to do this to maintain PCI DSS.
Benefits of Compliance and Consequences of Non-Compliance
Benefits:
- Greater Security: Protects your company and its customers against data breaches.
- Customer Trust: Demonstrates a commitment to security, increasing customer trust and loyalty.
- Fine Prevention: Avoids heavy financial penalties imposed by card brands in case of non-compliance and violations.
- Reputation Improvement: Protects your company's brand and reputation.
Consequences:
- Heavy Fines: Card brands can apply fines ranging from thousands to hundreds of thousands of dollars per month.
- Investigation Costs: In case of violation, the company is responsible for forensic investigation costs.
- Loss of Right to Process Cards: The most severe consequence is revocation of the ability to accept card payments.
- Reputation Damage: A data breach can destroy customer trust and irreparably harm the brand.