PCI DSS for Wineries: Tasting Room, Wine Club and Online Store

What PCI DSS asks of a tasting room

PCI DSS is the payment card industry's security standard. It is not a state or federal law. You agree to it through your merchant agreement, and your payment processor or acquiring bank decides how you prove it.

The current version is 4.0.1. Every requirement that was "future-dated" in version 4.0 became mandatory on March 31, 2025, so anything you read that calls those items optional is out of date.

For most wineries, proof means a yearly Self-Assessment Questionnaire (SAQ) plus a signed attestation. That is real work, but it is sized for small merchants.

There are a lot of wineries doing this paperwork. Census County Business Patterns for 2023 counts about 115 winery establishments in Santa Barbara County and about 166 in San Luis Obispo County. The Santa Barbara County Vintners put the countywide total of wineries and tasting rooms at about 325 (2024, a marketing figure). Many take cards three ways: a terminal on the bar, an online store, and wine club charges on file.

One plain note before the details: Keith Systems is not a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV), and it does not sign your SAQ. This guide helps you prepare. It is not legal advice.

Which SAQ fits your winery

Your processor or acquirer tells you which SAQ applies. Ask them in writing rather than guessing. In general terms:

• SAQ A: card-not-present only, with every card entry happening on a page hosted by your payment provider, through a redirect or an embedded frame.
• SAQ A-EP: e-commerce where your own website controls or affects the payment page, for example by loading the scripts that build the card form.
• SAQ B: imprint machines or standalone dial-out terminals.
• SAQ B-IP: standalone terminals that connect to the provider over an IP network.
• SAQ C-VT: staff key card numbers into the provider's virtual terminal in a web browser, one at a time.
• SAQ C: a payment application on a system connected to the internet.
• SAQ P2PE: you use only a validated point-to-point encryption solution listed by the PCI Security Standards Council.
• SAQ D: everything else, including storing card data yourself. It is long.

Wineries often have more than one channel. Ask whether you file one SAQ covering everything or one per channel. Some SAQ types also require quarterly external scans by an ASV; your SAQ will say so.

If your answer turns out to be SAQ D, the useful first question is usually not "how do we pass?" but "how do we take card data out of our own systems?"

Keep the tasting room POS on its own network segment

A tasting room network gets crowded. On a typical Saturday it might carry:

• Card terminals and POS tablets
• The office computer that reads email and pays bills
• Guest Wi-Fi for visitors
• A music streaming box
• Cameras, door controllers, printers, thermostats and other connected devices

On a flat network, every one of those can reach every other one. A compromised smart TV or an infected laptop on guest Wi-Fi then sits next to your payment devices.

Segmentation fixes that. Payment devices go on their own segment, with firewall rules that allow only the outbound connections your provider requires and block traffic from the guest and device segments. PCI DSS treats systems that can reach card data as potentially in scope, so good segmentation can shrink what you have to assess. Your provider or SAQ may ask for evidence that the separation works, so keep a simple diagram and a dated copy of the rules.

Guest Wi-Fi deserves its own segment with internet access only and client isolation turned on. And please, keep the office Wi-Fi password off the chalkboard by the spit bucket.

Keith Systems works on the network side only, on your own network gear: segment design, firewall rule review, guest and device Wi-Fi separation and DNS filtering. It does not configure, log into or manage terminals, POS tablets or any other device, and it does not recommend brands. More detail lives in connected device network security and the network segmentation guide.

Protect the online store's payment page from scripts

The quiet threat to winery web stores is script skimming. An attacker slips JavaScript into a page, often through a plugin, a tag manager or a compromised admin login, and that script copies card numbers as customers type them. The checkout still works, so nobody notices.

PCI DSS 4.0.1 added two requirements aimed at this. Requirement 6.4.3 asks you to keep an inventory of every script on the payment page, confirm each one is authorized and protect its integrity. Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts on unauthorized changes to the payment page and its HTTP headers. In 2025 the Council changed SAQ A: those merchants now confirm, as an eligibility condition, that their site is not susceptible to script attacks that could affect the payment process.

Practical steps for a small winery:

1. Find out which checkout model you really use: redirect, embedded frame, or a form your site builds.
2. List every plugin, tag and tracking script on the store and checkout pages. Remove what nobody can explain.
3. Turn on MFA for the store admin, the website host, the domain registrar and DNS.
4. Keep admin accounts to the people who need them, and remove former staff and old agencies.
5. Ask your web developer or store provider, in writing, what protects the payment page from script tampering, and keep the answer with your SAQ.

Wine club cards on file, phone orders and paper

Wine club charges are where card data tends to leak into places it should not live.

• Store cards only in your payment provider's token vault, never in a spreadsheet, email, a CRM notes field or a binder.
• Never keep the three- or four-digit security code after authorization. PCI DSS prohibits it.
• Phone orders get keyed straight into the provider's system, not onto a sticky note first.
• Paper signup forms from events should be entered quickly and then cross-cut shredded. A provider-hosted signup page avoids the paper entirely.
• Search shared drives and inboxes for card numbers once a year. Old exports turn up.

A tasting room PCI checklist

• Written confirmation from your provider of which SAQ applies to each channel
• Card terminals and POS on their own network segment
• Guest Wi-Fi isolated, internet only
• Connected devices on their own segment, away from payments
• Firewall rules documented with a date
• MFA on store admin, web host, registrar, DNS and email
• Script inventory for checkout pages, unused plugins removed
• Card numbers stored only with the provider, never in files or email
• Security codes never retained
• Staff shown how to spot a tampered terminal and who to call
• SAQ, attestation and scan results filed where you can find them next year

Where Keith Systems fits

Jacob Keith (CISSP, CompTIA CySA+, CompTIA SecurityX) reviews the network side of your card environment: segmentation on your own gear, firewall rules, guest and device Wi-Fi separation, account and MFA settings, and an external exposure review with written authorization from the owner. You get written findings you can use when answering your SAQ.

What it is not: a QSA, an ASV, a terminal or POS service, a product reseller or a monitoring service. The fee is stated in writing after the free consult, before any work begins. See wineries and agriculture, then book a free security consult or call (805) 800-8163.