Accepting credit or debit cards comes with security obligations under the Payment Card Industry Data Security Standard. The scope of those obligations depends on two things: transaction volume and how much of the payment environment the merchant controls. Smaller merchants with limited transaction volume and fully outsourced payment processing can complete a Self-Assessment Questionnaire. Larger merchants, or those with complex payment environments where cardholder data flows through their own systems and networks, are required to undergo a formal Report on Compliance conducted by a Qualified Security Assessor.
This series walks through all twelve PCI-DSS requirements using a single fictional business as the working example: Rosario’s Kitchen, a full-service Italian restaurant in Providence, RI. Single location, 35 employees, handheld POS terminals at the table, an online ordering system, and third-party delivery through DoorDash and Uber Eats. At roughly 400,000 transactions per year, Rosario’s is a Level 3 merchant — typical for a busy independent restaurant.
We start with the framework overview, then go deep on Requirements 1 and 2.
What PCI-DSS Is
PCI-DSS is a security standard created and maintained by the PCI Security Standards Council, a body founded by the major card brands — Visa, Mastercard, American Express, Discover, and JCB. It sets the baseline security controls any organization must have in place to handle cardholder data (CHD) — specifically the primary account number (PAN), cardholder name, expiration date, and service code.
Compliance is enforced by the card brands and acquiring banks. Non-compliance results in fines from your acquiring bank, increased transaction fees, and in a breach scenario, liability for fraud losses and potential loss of the ability to accept cards entirely.
Merchant Levels
Your compliance obligations scale with your transaction volume. The four levels apply to Visa and Mastercard merchants; American Express uses a similar but slightly different structure.
| Level | Transaction Volume (Annual) | Validation Requirements |
|---|---|---|
| Level 1 | Over 6 million | Annual on-site audit by a Qualified Security Assessor (QSA) producing a Report on Compliance (ROC). Quarterly network scans. |
| Level 2 | 1 million – 6 million | Annual Self-Assessment Questionnaire (SAQ). Quarterly network scans. |
| Level 3 | 20,000 – 1 million | Annual SAQ. Quarterly network scans. |
| Level 4 | Under 20,000 (e-commerce) or up to 1 million (other) | Annual SAQ recommended. Quarterly scans recommended. |
Rosario’s Kitchen processes approximately 400,000 transactions per year — Level 3. They are required to complete an annual SAQ and run quarterly vulnerability scans through an Approved Scanning Vendor (ASV).
The Twelve Requirements
PCI-DSS v4.0 organizes twelve requirements into six security goals. Each post in this series covers one or two requirements in depth. Here is the full map.
| Goal | Requirements | Focus |
|---|---|---|
| Build and Maintain a Secure Network and Systems | 1, 2 | Network security controls and secure configuration of all system components |
| Protect Cardholder Data | 3, 4 | Storage protection and encryption of CHD in transit |
| Maintain a Vulnerability Management Program | 5, 6 | Anti-malware and secure software development |
| Implement Strong Access Control Measures | 7, 8, 9 | Least privilege, authentication, and physical access |
| Regularly Monitor and Test Networks | 10, 11 | Logging, monitoring, and security testing |
| Maintain an Information Security Policy | 12 | Security policy and operational procedures |
Requirement 1 — Install and Maintain Network Security Controls
Requirement 1 is about controlling what can reach your cardholder data environment (CDE) — the systems and network segments where CHD is stored, processed, or transmitted. The primary tool is network segmentation, enforced through firewalls and equivalent network security controls.
The goal is to ensure that cardholder data is not reachable from the public internet or from other parts of your network that don’t need access to it. At Rosario’s, that means the POS network — the terminals, the POS server, and the payment processor connection — needs to be isolated from the guest Wi-Fi, the kitchen display systems, the office computers, and anything else on the premises.
What this looks like at Rosario’s Kitchen
Rosario’s has three network segments that need to be separated:
- POS network — handheld terminals, POS server, payment processor connection. This is the CDE. Access is restricted to devices and users that require it to process payments.
- Operations network — office computers, kitchen display systems, reservations system, back-office functions. Isolated from the POS network.
- Guest Wi-Fi — completely isolated from both other segments. A customer on guest Wi-Fi cannot reach any internal system.
The firewall sits between all three segments and between the POS network and the internet. Rules are documented, reviewed, and only allow traffic that is explicitly required. Default deny — if it’s not on the allowed list, it’s blocked.
An auditor will want to see documented firewall rules and network diagrams showing all connections to and from the CDE. They will test that the guest network cannot reach the POS network. They will look for any direct connection between the internet and the CDE without a firewall in between. They will also check that rules are reviewed at least every six months and that any rule that no longer has a business justification has been removed.
Common gap: Small businesses run everything on a flat network — POS, guest Wi-Fi, office computers all on the same segment. This fails Requirement 1 entirely. Segmentation is not optional.
Proving firewall rules are reviewed every six months
Evidence an auditor would accept:
- A dated review log or sign-off document showing who reviewed the firewall rules, when, and what the outcome was — even a simple spreadsheet works
- Ticket or change management records showing rules were evaluated on a scheduled basis
- Meeting minutes if the review was done as part of a security review meeting
- Screenshots or exports of the firewall rule set with a date stamp, paired with a sign-off from whoever is responsible
Requirement 2 — Apply Secure Configurations to All System Components
Out-of-the-box system configurations are designed for convenience. However, default usernames and passwords are published, and unnecessary services are enabled. Requirement 2 requires that every system component in your environment — routers, switches, firewalls, POS terminals, servers — is configured securely before it touches the CDE.
This means changing defaults, disabling services that aren’t needed, and documenting the configuration baseline so you know what “secure” looks like for each system type.
What this looks like at Rosario’s Kitchen
When Rosario’s installs a new handheld POS terminal, the following happens before it goes into production:
- The default admin password is changed to a unique, strong credential stored in a password manager
- Any remote access or management services not required for operation are disabled
- The terminal is registered in an inventory with its serial number, location, and assigned user
- The configuration is documented against a hardening standard — either a vendor-provided guide or a recognized benchmark like CIS
The same process applies to the router, the firewall, and the POS server. Every system component has a documented secure configuration. When a new device is added, it is configured to that standard before it joins the network.
An auditor will check that default credentials have been changed on all system components and that unnecessary services have been disabled. They will look for a system inventory — you need to know what’s in your environment before you can secure it. They will also check for a documented configuration standard and evidence that it has been applied consistently across all in-scope systems.
Common gap: Default passwords left unchanged on routers and POS terminals are one of the most common findings in small merchant assessments. Requirement 2 exists because attackers know the defaults too.
Proving secure configuration
Evidence an auditor would accept:
- System inventory showing every device in the CDE — make, model, serial number, location, and assigned user
- Documented hardening standard for each system type — a vendor-provided guide or CIS benchmark showing what the secure configuration looks like
- Evidence the standard was applied — configuration exports, screenshots, or a completed checklist for each device
- Confirmation that default credentials were changed — auditors may test this directly by attempting default logins
- List of services running on each system with justification for each enabled service — anything without a business reason should be disabled and documented as such
Next in this series: Requirements 3 and 4 — Protect Cardholder Data. What you are allowed to store, what you must never store, and how cardholder data must be protected when it moves across a network.
