PCI DSS Compliance Checklist for Utah Retailers and Restaurants

If your Utah store or restaurant takes cards, PCI DSS, the card industry's security standard, applies to you. This guide covers what the standard is, how small merchants prove compliance, and what to check on your network, point of sale (POS) system and card terminals.

What you must submit depends on the card brands and your payment processor, so confirm the details with your processor.

What PCI DSS is and who sets it

PCI DSS is the Payment Card Industry Data Security Standard: security requirements for any business that stores, processes or transmits payment card data. The PCI Security Standards Council (PCI SSC) maintains it.

The Council does not enforce it. The card brands (Visa, Mastercard, American Express, Discover and JCB) and acquirers, the banks that process your card payments, decide who must prove compliance and how. In practice, your acquirer, or the payment processor working for it, tells you what to submit and when.

The current version is PCI DSS v4.0.1, published in June 2024. It replaced v4.0, which was retired on December 31, 2024, and it added or removed no requirements. The new v4.0 requirements with a delayed start became mandatory on March 31, 2025, so they all apply now. Check pcisecuritystandards.org for updates.

Who has to comply and how you prove it

PCI SSC says PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of size or transaction volume. Whether a small merchant must submit proof of compliance is decided by the card brands.

The card brands assign merchant levels, mostly by annual transaction volume. Visa merged its Levels 3 and 4 on April 25, 2024, so Visa Level 3 now covers merchants processing up to 1 million Visa transactions a year. Mastercard still has its own Level 4, so one business can hold different levels with different brands. Your acquirer tells you your levels and what to submit for each.

PCI SSC describes the Self-Assessment Questionnaire (SAQ) as the tool eligible merchants use to report the results of a self-assessment. The SAQ comes with an Attestation of Compliance (AOC) that you sign. Your acquirer decides whether an SAQ is enough or an outside assessor's report is required.

Which SAQ applies depends on how you take payments:

SAQ A and A-EP: online or phone sales with card handling outsourced to compliant providers. A-EP covers online stores whose website can affect payment security.
SAQ B: imprint machines and standalone dial-out terminals.
SAQ B-IP: standalone PCI-approved terminals connected to the processor over the internet and to no other system.
SAQ C-VT: staff key card numbers into a validated provider's web virtual terminal.
SAQ C: an internet-connected POS isolated from all other systems, on a single-store network, storing no card data electronically.
SAQ P2PE: only terminals in a PCI-listed point-to-point encryption solution.
SAQ SPoC: a phone or tablet with a secure card reader, used through a solution that PCI SSC lists as validated (a SPoC solution). PCI SSC has announced a sunset period for the SPoC standard (May 1 to October 31, 2026) and points to a newer one, MPoC, so ask your acquirer which SAQ fits your reader.
SAQ D: any setup that no other SAQ covers. A POS that shares a network with a back-office computer or a second location is outside SAQ C.

Confirm that you meet every eligibility condition of your SAQ, and ask your processor which one they expect. Choosing a shorter SAQ than your setup allows gives a wrong answer.

The 12 PCI DSS requirements in plain words

PCI DSS groups its controls into 12 principal requirements:

Network security controls. Firewalls that decide what can reach card systems.
Secure configurations. No default passwords, no unneeded services.
Protect stored account data. Keep little, and make it unreadable.
Encrypt card data in transit. Strong cryptography across public networks.
Protect against malware. Anti-malware and phishing protection.
Secure systems and software. Patch on a schedule.
Need-to-know access. Only the access a job requires.
Identify and authenticate users. Unique log-ins, strong passwords and multi-factor authentication (MFA), a second proof of identity such as a code from a phone app.
Physical access. Control who can touch terminals and paper records.
Logging and monitoring. Record access to systems and card data, and review it.
Regular testing. Vulnerability scans, wireless checks, penetration tests where required.
Policies and programs. Written policy, training, vendor oversight, incident response plan.

PCI DSS checklist for a small store or restaurant

This checklist assumes one location that takes cards in person, with a POS, terminals, a router and a back-office computer. Requirement numbers refer to PCI DSS v4.x, and your SAQ decides which items you must document.

Know where card data goes

Scope the card data environment. The card data environment is every system, network and person that handles card data or could affect its security. Everything in it is in scope, meaning the PCI DSS requirements apply to it. List every place a card is read, keyed, stored or sent: terminals, POS, back-office computer, online checkout and each vendor involved. Draw the card data flow. Confirm scope at least every 12 months (12.5.2).
Do not store sensitive authentication data. After authorization, do not keep full magnetic stripe data, card verification codes or PINs, even encrypted (3.3.1). Check email, spreadsheets and notes from phone orders.
Use validated P2PE or tokenized terminals where possible. A PCI-listed point-to-point encryption (P2PE) solution encrypts card data inside the terminal, so your systems never see it in the clear. Tokenization swaps card numbers for tokens. Both shrink scope, and P2PE can qualify you for SAQ P2PE.

Separate and secure the network

Keep the POS apart from guest WiFi and office computers. Segmentation means separate networks with controlled traffic between them. PCI DSS does not require it, but without it the whole network is in scope. SAQ B-IP and SAQ C also depend on your terminals or POS not connecting to other systems. Use separate networks for the POS, guest WiFi and staff computers, and retest after network changes.
Set firewall rules that allow only what is needed. Put a firewall between card systems and everything else, including wireless networks (1.3.3). Allow necessary traffic and deny the rest (1.3.1, 1.3.2). Review rules every six months (1.2.7).
Remove default passwords and settings. Change or disable vendor default accounts on the POS, terminals, router, firewall and WiFi gear (2.2.2). Use 12 character passwords where supported (8.3.6) and give each person their own login (8.2.1).
Patch, and retire unsupported software. Install patches for critical vulnerabilities within one month of release (6.3.3), treat high-risk patches as a priority too, and set a risk-based timeline for all others. Review yearly whether your hardware and software still get vendor security fixes (12.3.4).

Control access and protect terminals

Use multi-factor authentication. MFA is required for administrator access to the card data environment (8.4.1). It is also required for remote access into your network that could reach card systems (8.4.3). Since March 31, 2025, it is required for all access to the card data environment (8.4.2). That last rule does not apply to cashier log-ins on POS terminals that see only one card number at a time. Cover remote-support tools and the router or firewall admin page.
Protect terminals from tampering. Keep a list of every terminal with model and serial number, inspect them regularly for tampering or substitution, and train staff to report anything suspicious (9.5.1).

Monitor, test and document

Keep and review logs. Keep audit logs for at least 12 months, with the latest three months ready for analysis (10.5.1). Logs for card systems must be reviewed daily (10.4.1), using automated mechanisms (10.4.1.1). In practice that means a monitoring service or managed firewall that alerts someone.
Scan for vulnerabilities. Run internal scans every three months (11.3.1). Run external scans every three months through a PCI SSC Approved Scanning Vendor and fix findings until the scan passes (11.3.2).
Write a short security policy. State who is responsible for what and review it yearly (12.1.2).
Train staff. Give security awareness training at hire and at least every 12 months (12.6.3). Cover phishing, reporting tampered terminals, and never writing down or emailing card numbers.
Manage vendors and service providers. List every provider that touches card data or could affect its security (12.8.1). Keep written agreements in which they accept responsibility for that data (12.8.2), and check their PCI status yearly (12.8.4). Using a compliant provider does not make you compliant.
Have an incident response plan. Write down who does what, who to call, and how to notify your acquirer and the card brands (12.10.1). Test it at least every 12 months (12.10.2). Keep a printed copy, since your systems may be down when you need it.

Common mistakes

Assuming the POS vendor or processor handles compliance. Their compliance does not cover your network, staff or terminals.
Running guest WiFi and the POS on one network, which puts every guest device in scope.
Leaving default passwords in place, skipping patches, or leaving remote access on without multi-factor authentication. PCI SSC's merchant resources list weak or default passwords, unpatched software and insecure remote access among the leading causes of payment data breaches.
Treating it as a yearly form. Scans, patches, log review and training run all year.

What to ask your POS vendor

PCI SSC publishes a small merchant guide, Questions to Ask Your Vendors. Start with these:

Is your payment software validated by PCI SSC and listed on its website?
Are the terminals on PCI SSC's list of approved PIN transaction security (PTS) devices, and is the encryption a listed P2PE solution?
Does card data pass through or sit on my POS computer, router or back-office PC?
Which SAQ do you expect me to use, and can I have your Attestation of Compliance?
How do you access my system remotely, and is that access off until needed and protected by multi-factor authentication?
How do security patches reach me, and who installs them?

Where WITS fits

WITS supports Utah retail stores and restaurants with network design, segmentation, patching, monitoring and documentation. PCI DSS work sits within our IT compliance services and managed cybersecurity. Our engineers hold Cisco CCIE Enterprise Infrastructure and Kali Linux Professional (KLCP) certifications. These are networking and security credentials, not PCI credentials.

Using WITS does not make your business compliant, and WITS does not replace your acquirer's validation. You complete and submit your own SAQ. We design the network separation and run the patching and monitoring that several checklist items depend on, and we support your documentation.

Map and assess

An engineer maps where card data flows and reviews your terminals, POS, router, WiFi and back-office computers. The business assessment is a $200 flat fee, credited toward the project if you proceed.

Separate and harden

We build separate networks for the POS, staff and guests, set firewall rules, remove default credentials, add multi-factor authentication for remote access and set a patching schedule.

Monitor and document

On managed plans, WITS monitors and patches your systems and supports your documentation of the network. WITS Command is $85 per user per month. WITS Inner Circle is $125 per user per month and adds annual penetration testing, security awareness training, an incident response plan and quarterly compliance review, with support for PCI DSS. Both are month-to-month with a 5 user minimum.

PCI DSS questions from Utah merchants

Short answers for store and restaurant owners

Yes. Being small does not exempt you. Ask your processor for your merchant level, which SAQ to use and when to submit it.

Standalone PCI-approved terminals connected to no other system fit SAQ B-IP. Validated P2PE terminals fit SAQ P2PE. An isolated, internet-connected POS at a single location fits SAQ C. Other setups can fit SAQ SPoC, B, C-VT or A, and if none of them fits, SAQ D applies. Confirm with your processor.

Requirements that had been best practices until that date became mandatory, including multi-factor authentication for all access to the card data environment (8.4.2) and 12 character passwords where supported (8.3.6). Every assessment now includes them.

Yes, if guest WiFi runs on a separate network with no route to the POS or terminals. Without segmentation your whole network is in scope, and a firewall is required between wireless networks and your card systems.

No provider can do that for you. WITS can design the network separation and run the patching and monitoring your SAQ answers depend on, and support your documentation. You remain responsible for compliance. Call 385-242-2514 to book an on-site assessment.

Have another question? We're here to help.

About this guide

This is general information, not legal advice or a compliance assessment. You stay responsible for your own compliance and for what you submit to your processor, whether or not you use an IT provider. Requirements change, so read the current standard and confirm your level and SAQ with your acquirer.

Sources: PCI SSC document library, PCI SSC self-assessment questionnaires, PCI DSS v4.0.1 announcement, PCI SSC resources for merchants, PCI SSC SPoC standard, Visa What To Do If Compromised guide, merchant levels table, Mastercard Site Data Protection program.