How to stop storing credit cards in spreadsheets
(and what PCI actually says)

CARD VAULT GUIDES · UPDATED JULY 2026 · 9 MIN READ

Somewhere in almost every small business there is a file, a folder, or a drawer that would make a payments assessor go quiet. This guide is about that file: why it exists, what the card networks' rules actually say about it, what "we're careful with it" misses, and the workflow that finally replaces it.

Three ways card numbers end up where they shouldn't

Nobody decides to build an insecure card database. It accumulates, one reasonable moment at a time, in three familiar forms:

The spreadsheet. A client asks you to keep their card for next time. You have Excel open anyway. Two years later the file has forty rows, a column helpfully labeled CVV, three copies on the shared drive, and a name like client-cards-2026-FINAL(3).xlsx. Everyone in the office knows about it. Nobody talks about it.

The PDF form that comes back by email. This one feels official, which is what makes it dangerous. You send a fillable "credit card authorization form." The customer types in their full card number, expiry, and security code, saves it, and emails it back. That number now lives in their sent folder, your inbox, your mail server, every backup of your mail server, and the attachment preview on your phone — forever, unless someone deletes all of it, which nobody ever does.

Paper. The booking sheet with a card number in the margin. The notepad by the phone. The binder of authorization forms in an unlocked drawer. Paper feels safer because it can't be hacked — but it can't be audited, access-controlled, or reliably destroyed either, and PCI applies to it just the same.

What the rules actually say

First, the thing most owners are never told directly: PCI DSS is not a law — it's a contract. When you signed your merchant agreement to accept cards, you agreed to comply with the Payment Card Industry Data Security Standard for any cardholder data you store, process, or transmit. There is no small-business exemption; size only changes how you validate, not whether the rules apply. Separately — and this part is law in most places — privacy legislation imposes breach-notification duties if the numbers ever leak.

Four requirements from PCI DSS v4.0.1 decide the fate of the spreadsheet, the PDF, and the drawer:

You may never store the security code. Full stop. Requirement 3.3.1 forbids retaining sensitive authentication data — the CVV/CVC, magnetic stripe data, or PIN — after authorization, in any form, encrypted or not. A CVV column in a spreadsheet is not a finding to remediate at your next review; it's a standing violation. And here is the part that surprises people: you don't need the CVV for card-on-file billing. A properly stored credential is charged without it.

A stored card number must be unreadable — and a workbook password doesn't count. Requirement 3.5.1 says the primary account number must be rendered unreadable anywhere it is stored, via strong cryptography with managed keys, truncation, hashing, or tokenization. Excel's password protection is not strong cryptography with key management; it's a speed bump, and it protects exactly one copy of a file that exists in five places.

Card numbers must not travel by email. Requirement 4.2.2 prohibits sending PANs over end-user messaging — email, SMS, chat — unless the number itself is rendered unreadable with strong cryptography. A customer typing their card into a PDF and pressing send fails this the moment it leaves their outbox. The form's official appearance changes nothing.

Whatever touches card data is "in scope" — and scope is the real cost. Every system that stores, processes, or transmits cardholder data falls inside your PCI assessment boundary. Keep cards in a spreadsheet and your file server, backups, and every PC that opens the file are in scope. Accept them by email and your entire mail system joins. That is how a small business ends up facing SAQ D — the long-form self-assessment with 250+ requirements — to justify a workflow it never consciously chose.

Why "we're careful with it" doesn't survive contact

Every owner of the file believes theirs is the careful one. The problem is that none of the failure modes involve carelessness:

Files multiply. The spreadsheet was emailed to the bookkeeper once, so it's in two mailboxes. It's in last year's backup. It's on the old office manager's laptop, and she left in March. You cannot delete what you cannot find, and you cannot find every copy.

One phished mailbox is a breach of everyone. A single successful phishing email against any account that can reach the file leaks every client's card at once — along with your legal duty to tell each of them what happened. The blast radius of a spreadsheet is always one hundred percent.

There is no audit trail. Who opened the file last month? Who copied a number out of it? A spreadsheet cannot answer, which means after an incident, the honest answer to "what was accessed?" is everything, possibly, by anyone.

Trust is the actual asset at stake. Your clients handed over their cards because they trust you — the firm, the clinic, the property manager. Explaining a card breach is painful for any business; for one whose relationship is built on discretion and stewardship, it is the kind of conversation businesses don't recover from.

What the fix actually looks like

The category answer is vaulting and tokenization: card numbers are captured directly into a purpose-built, PCI-assessed vault — never touching your systems — and you keep only a token, a reference that can charge that card but is worthless to a thief. Your PCI scope shrinks to almost nothing, because you no longer store, process, or transmit card data; the vault does. Honestly, you have three ways to get there:

Your payment processor's vault. Most processors offer card-on-file storage, and it genuinely solves the storage problem. The trade-off is lock-in: the stored cards belong to that processor's platform, and if you ever switch — for rates, for service, for an acquisition — you leave your card file behind and start re-collecting from scratch.

An independent vault. A vault that isn't owned by your processor holds the credential once and charges it through whichever payment gateway you use today — or switch to tomorrow. This is what Card Vault is, so weigh that disclosure accordingly; the portability argument is why independent vaults exist.

Building your own. Storing encrypted cards yourself is technically permitted — and it commits you to full SAQ D compliance, key management, quarterly scans, and everything else, forever. For a small business this is the expensive way to keep the problem.

The workflow that replaces the spreadsheet, the PDF, and the drawer

Whatever vault you choose, the day-to-day pattern that replaces "email us the form" looks like this:

1. Request. Instead of sending a PDF, you send a secure link by email or SMS. Your customer opens a page hosted by the vault — not your website, not a form that comes back to your inbox.

2. Vault. They enter the card themselves. It goes straight into the vault, encrypted. What comes back to you is a token and the last four digits — enough to recognize the card, useless to steal.

3. Authorize. Where you bill on file, the customer's agreement to your terms is captured alongside the card and stored with it — no binder of paper forms to dig through.

4. Charge. When it's time — the invoice, the retainer, the monthly run — your team charges the token from a virtual terminal or your billing system charges it by API. Nobody reads a number to anyone, ever.

Migrating the existing file follows the same motion: send every client a card-request link, and as each token comes back, delete that row. When the last row is re-vaulted, securely delete the file — and the copies in sent mail and backups, as best you can find them. From that day forward there is nothing new to leak.

Frequently asked questions