Card Audit: What It Is and How to Run One

A card audit is a structured review of every payment card record your business stores, processes, or pays out, checked against your own systems and your compliance obligations. It answers three questions: where card data lives, who can reach it, and whether each record still needs to exist. A good card audit ends with a written inventory, a list of gaps, and a dated plan for closing them.

related article

What a card audit covers

Scope is the part most teams get wrong. The audit has to follow the card number, not the department. That means covering systems that touch card data directly and the systems that only copy or forward it.

related article

• Card-on-file records: stored credentials, tokens, recurring billing profiles, and saved customer cards.
• Payment flows: point of sale, ecommerce checkout, call center entry, mobile terminals, and any manual keying.
• Payout records: card disbursements, refunds, and chargeback reversals.
• Access paths: admin accounts, support tools, exports, backups, and vendor connections.
• Retention: how long data is kept, why, and what deletes it.

Why businesses run a card audit

Payment card data is one of the few asset classes where a single misplaced file creates a reportable incident. An audit finds those files before someone else does. It also supports PCI DSS scoping, vendor due diligence, and internal control testing for finance teams. Regulated firms often need evidence of periodic review for examiners, and merchants need it to prove that stored cards match the token vault rather than a spreadsheet.

card check

How to run a card audit step by step

1. Define the boundary. List every business process that touches a card number, expiry date, or cardholder name, then map each to the systems that support it.
2. Build the inventory. Record system name, owner, data elements held, storage location, retention period, and encryption or tokenization status.
3. Test the records. Sample stored cards and confirm each one exists in the approved vault and nowhere else. Look for exports, test files, and local copies.
4. Review access. Pull account lists for each system and confirm every user still needs the role. Check shared logins, dormant accounts, and vendor access.
5. Check the paper trail. Confirm logs are enabled, retained, and reviewed, and that change history exists for the systems holding card data.
6. Report and remediate. Issue findings with owners and due dates, then re-test the fixes.

Card-on-file checklist

• Every saved card maps to a token, not a raw number.
• Expired cards are purged on a defined schedule.
• Deleted customer accounts remove linked card profiles.
• Exports of card data are blocked or require dual approval.
• Backups follow the same retention and access rules as production.
• Third parties handling cards are under contract and reviewed.

Common findings

The usual problems are mundane: a support spreadsheet with card numbers pasted in, a legacy billing table nobody owns, a test environment seeded with real records, and a shared admin login used by three people. Each one is fixable, but only if the audit names the owner and sets a date. Findings without owners return in the next review.

How often should you audit

Run a full card audit once a year and a lighter scoped review each quarter, or whenever a payment system changes. Any new processor, checkout flow, or vendor integration should trigger a targeted review before go-live. Store each cycle's inventory and report so you can show a trend, not a snapshot.