PCI DSS for Small Businesses: Finding Stray Cardholder Data Before an Audit
July 3, 2026 · 3 min read
Most small offices that take cards believe they have handled PCI. They use a processor, the terminal works, and nobody keeps a card file. Then a customer emails a card number to settle an invoice, the front desk pastes it into a spreadsheet to run later, and the note stays in the file for years. One forgotten number can change the picture of what you store.
What PCI DSS asks of you
PCI DSS is the card-industry standard for anyone who stores, processes or transmits cardholder data. The details of your obligations depend on how you accept payments and what your processor and acquirer require, so confirm them with your processor. You can find the standard itself at https://www.pcisecuritystandards.org.
For a small office, the simplest path is also the most effective: avoid storing card numbers at all, and use a tokenizing processor so that card numbers pass through a system built to handle them. Every card number you do not keep is one you do not have to defend. Sensitive authentication data, such as the security code printed on the card, must not be kept after a payment is authorized.
How card numbers drift into ordinary files
- A customer emails a card number to place an order, and the message sits in an inbox or gets saved as an .eml file.
- A staff member types a number into a spreadsheet "just for now" while waiting for a callback.
- An invoice or order export prints a full card number into a PDF.
- A CRM or accounting export carries card details into a CSV that gets saved to a shared folder.
- A scanned authorization form is filed with a client's paperwork.
None of these were planned. That is exactly why they are not on anyone's inventory.
Finding it
A payment card number has a recognizable shape, and real ones pass the Luhn check, a simple checksum built into card numbers. MyVaultMate looks for card numbers using the pattern plus that check, which cuts down on random digit strings being flagged. Even so, expect an occasional false alarm, such as an order number that happens to pass the check, so someone should open the flagged files and confirm.
It scans Word and Excel (new and old formats), PDF, text, CSV, JSON, XML, HTML, .eml and Outlook .msg files on local drives, synced OneDrive or Google Drive folders, and external disks. It does not yet read RTF and PowerPoint files, Outlook .pst data files, or zip archives, so check those by hand or tell staff to move content out of them. Scanned authorization forms are not read; they are listed as “Not scanned” with a risk score of 70. Each finding shows the file path, severity and, at most, a short redacted sample, never the full number.
A short plan before an assessment
- Scan every computer and folder where card data might land.
- Confirm the top-ranked findings by opening each file.
- Remove or relocate. Delete card numbers you do not need, and change the habit that put them there: take payments through the processor, not by email or note. MyVaultMate moves or deletes nothing on its own; that is your job or your IT provider's.
- Re-scan to confirm the findings are gone. Comparing with the first saved report shows progress.
- Keep a dated record of what you found and did, using the PDF, CSV or XLSX export.
Make it routine
Run the scan on a schedule rather than once. A weekly or daily schedule, with incremental runs, catches a new stray number soon after it appears. Also write the rule down for staff: no card numbers in email, notes or spreadsheets, ever. A scan that finds nothing, shown together with its Not scanned list, is a reasonable thing to bring to an assessment conversation, but it supports your program and does not replace it or certify anything. For your specific obligations, ask your processor and a qualified advisor.
You can see what a report looks like at /sample, or start a 14-day trial at /trial/ (a card is required and never charged automatically: the 14 days start at your first computer, and you choose a plan when they end).