EmberHound PCI Data Discovery
Find card data hiding outside your payment systems.
EmberHound scans files, documents, and images across enrolled company devices for stored payment-card data. See where it was found, understand what presents the greatest risk, and give your team a clear place to start remediation.
- Windows, macOS, and Linux
- Scans run on the endpoint
- Raw files are never uploaded
- Masked findings only
The problem
Payment data rarely stays where you expect it to.
A payment system can be designed perfectly and still not account for what happens around it. Somebody exports a reconciliation report to a spreadsheet. A support agent pastes a card number into a ticket while helping a customer. A refund form gets scanned and saved to a desktop. A developer copies production data into a test file. None of that is in the architecture diagram.
Policies describe what should happen. Scanning the devices tells you what did.
Exports and downloads
Reconciliation reports, chargeback files, and CSV downloads pulled for one task and never removed.
Records of conversations
Support notes, email attachments, and screenshots taken while sorting out a customer's problem.
Archives and test data
Old operational folders, zipped backups, and sample data copied from somewhere real.
What you get
Three things, from one scan.
Find stored account data
Identify files and locations holding likely payment-card information across enrolled endpoints, including copies no system of record knows about.
Prioritise what needs attention
Findings are deduplicated by fingerprint, scored for confidence, and ranked by risk, so the team works a credible list rather than every long number on the disk.
Keep evidence of the work
Scan history is retained and findings export to PDF or CSV, so internal review, remediation, and assessment activity all draw on the same record.
Detection
What EmberHound looks for.
Payment-card data first. The standard divides it into two classes that carry different rules, so the product reports them separately rather than lumping everything together as "card stuff".
Cardholder data
Card numbers
13 to 19 digits, validated with a Luhn checksum and weighted by nearby words like card, payment, visa, or mastercard. Words like invoice, order, and tracking count against a match.
Sensitive authentication data
Security codes
Three and four digit codes, reported only where cvv, cvc, security code, or card verification appears nearby. This is the class whose retention after authorisation the standard prohibits outright.
Cardholder data
Expiry dates
Month and year pairs, reported only alongside words like expires, valid thru, or exp. On their own they are weak evidence, so they mainly serve to corroborate a card number found nearby.
What it does not detect. There is no detector for full track or magnetic-stripe data, cardholder names, service codes, or PIN blocks. If a page anywhere says otherwise, it is out of date.
Also detected: bank and payment identifiers
These are in the same pack and will appear in your findings. They are not payment-card data and carry no PCI DSS obligation of their own, but they are usually worth knowing about wherever card data turns up.
Bank account numbers
8 to 17 digits, requires account, bank, checking, savings, or routing nearby
ABA routing numbers
nine digits, validated with an ABA checksum
UK sort codes
requires the words sort code, with a weighted score that penalises invoice and version contexts
SWIFT and BIC codes
requires swift or bic within 60 characters
US employer identification numbers
requires ein, employer identification, or tax id nearby
Payment processor tokens
Stripe-style identifiers such as ch_, cus_, pi_, and tok_
How it works
From agent install to exported evidence.
- 01
Deploy the endpoint agent
Push the agent through your existing MDM, or hand somebody an enrolment code. Scanning is local, so there are no inbound firewall changes to make.
- 02
Run a card data scan
Select the PCI policy and the locations in scope. The agent reads files on the device using the signed rule pack.
- 03
Review masked findings
Each finding names the data type, the device, the file, and where inside it the match sits - with a masked preview rather than the value itself.
- 04
Prioritise remediation
Assign an owner, set a status, and work down by risk. Findings carry an SLA due date, and the platform warns as it approaches.
- 05
Rescan and export
Scan again to see whether the exposure has actually gone, then export the findings and the history behind them.
Findings
See enough to investigate, without collecting the file.
A finding has to tell somebody where to go and what they will find when they get there. It must not become a second copy of the data you are trying to get rid of. So the preview is masked, the value is stored as a hash, and everything else is the metadata needed to act.
Findings locate the match inside the file itself: the page of a PDF, the sheet and cell of a spreadsheet, the path within a JSON document.
- Data type and its PCI class
- Masked preview, never the value itself
- Device, file path, and file type
- Where inside the file: page, sheet, row, or column
- Confidence score, and what adjusted it
- Risk level and exposure level
- How many times it has been seen, across how many scans
- First seen, last seen, and SLA due date
- Status, assigned owner, and resolution note
- Whether OCR was used to read it
Signal
Focus on credible findings, not every long number.
A sixteen-digit string is not a card number. An order reference, a serial number, and a tracking code all look the same to a regular expression. Six controls separate the two, and each finding records which of them applied to it.
Checksum validation
Card numbers are Luhn-checked and routing numbers ABA-checked before they become a finding. Each finding records whether the checksum passed.
Required context
Weak patterns are not reported alone. A three-digit security code only becomes a finding when a phrase like cvv or security code sits nearby.
Negative keywords
Invoice, order, tracking, shipment, test, and example all count against a card-number match rather than being ignored.
Confidence scoring
Every finding carries a score, the raw score before adjustment, and the list of adjustments applied - so a low-confidence result is visible as one.
Deduplication
A fingerprint groups the same value across scans and devices, so one card in fifty copies of an export reads as one thing to deal with.
Suppression rules
Dismiss a finding or exclude a path from future scans. A suppression needs a written reason of at least 10 characters, and it is audited.
None of this eliminates false positives, and no scanner honestly claims to. It moves the credible findings to the top of the list.
Find card data inside images and scanned documents.
A photographed receipt, a scanned refund form, a screenshot of a payment screen. Ordinary file search reads none of them, because there is no text in the file to read.
With the OCR add-on enabled, text is extracted from supported images and image-based documents before the same detection rules run, and each finding records whether OCR was used to read it, so you can tell OCR results apart from plain-text ones.
OCR is an add-on rather than part of a base plan. Ask us about OCR coverage.
- Applies the same rules to extracted text as to ordinary files
- Every finding records whether OCR produced it
- OCR confidence is recorded so low-confidence reads can be filtered
- Extraction happens on the device, like the rest of scanning
Security
Scan sensitive files without uploading them.
A card-data scanner that collected card data would be a poor trade. The architecture is built so that finding the data does not mean moving it.
Read the Trust Centre for the architecture and data-handling detail.
- Matching runs on the endpoint. The platform never reads your file system.
- Raw files stay on the device. Only a masked preview, a hash, and metadata leave it.
- Encrypted in transit and at rest.
- Organisation-level isolation, enforced in the database as well as the application.
- Every action is written to an audit log your team can read.
PCI DSS
Support PCI DSS work with evidence from actual scans.
The standard treats stored account data as something you are expected to know about and minimise. Requirement 3.2.1 asks that retention be limited to what you genuinely need for business, legal, or regulatory reasons. Requirement 3.3.1 goes further for sensitive authentication data - security codes, full track data, and PIN blocks must not be retained after authorisation, even encrypted. Both assume you can say where the data is.
A scan is one way to answer that from the devices themselves. Of the classes EmberHound detects, security codes are the sharpest: finding one stored after authorisation is a finding worth acting on straight away.
What the reports map to
EmberHound maps at requirement level. It does not produce sub-requirement mappings, and any page claiming otherwise is describing something the product does not do.
Requirement 3
Protect stored account data
The findings report states this mapping directly. Scan results show which devices hold account data and which do not.
Requirement 10
Log and monitor all access
Reports carry the scan history behind them, and platform actions are audited.
EmberHound supports payment-data discovery and PCI DSS assessment activity. It does not certify PCI DSS compliance or replace advice from a Qualified Security Assessor. Finding and removing data you did not need to keep can support scope-reduction work, but scope is determined by your whole cardholder data environment and the systems connected to it.
PCI DSS sources
- PCI DSS document library - PCI Security Standards Council
- FAQ: How long should cardholder data be stored? - PCI Security Standards Council
Use cases
What teams run it for.
Check employee endpoints
Look for exports, downloads, and temporary files holding card data on the laptops your team actually uses.
Investigate legacy storage
Find account data retained in old documents, archives, and operational folders long after the reason for keeping it ended.
Prepare for an assessment
Run a targeted scan, work through the findings, and keep the evidence of what you found and fixed before you sit down with a QSA.
Monitor for recurrence
Rescan enrolled endpoints and use scan history to see whether data you dealt with has reappeared.
Frequently asked questions
From our blog
PCI DSS and compliance guidance for security engineers.
Related resources
Find out where payment-card data is being stored.
Run your first scan on one device and review the findings without uploading the underlying files.
No card details required. One device, one user.