How to read a MyVaultMate finding (and what to do with it)

A finding is MyVaultMate's way of saying "this file looks like it holds sensitive data." It is deliberately compact. Once you know what each field means, you can look at a finding and decide in under a minute whether to act on it, and how.

The fields in a finding

Each finding records the same things:

• File path. The full location on that computer, including the folder. The folder often tells you more than the file name does: a path under "Downloads" or "Desktop" usually means a file somebody saved and forgot.
• File type. Word, Excel, PDF, text, CSV, JSON, XML, HTML, or an .eml or Outlook .msg email message. Type matters for the fix. A spreadsheet export can often just be deleted, while a PDF may be a record you must keep.
• Kind of data. Social Security number or ITIN, payment card number, driver's license, passport, date of birth, medical record number, Medicare number, health insurance member ID, provider NPI, health information, email address, phone number or IP address, and, for GDPR, an IBAN, an EU or UK national ID number or special-category data.
• Severity. Findings are ranked from Critical down to Low, so the dashboard lists the most urgent first.
• Compliance frameworks. The frameworks the kind of data relates to, so you can see which obligations the file touches.
• Count of distinct values. How many different values were found (a daytime scan can stop early in a file; the overnight full count reads the rest). Ten distinct Social Security numbers in one file is a different problem from one.
• Redacted sample. At most a short snippet such as ***-**-1234, never longer than 64 characters. It is there so you can recognize what was matched, not to reproduce it.

The files and the full values never leave the computer, and MyVaultMate never saves the full values anywhere else. No field in the product holds a raw value.

What the kinds of data actually mean

Numbers such as Social Security numbers and ITINs are found by pattern. Card numbers are found by pattern plus a Luhn check, which filters out most random digit strings. Driver's license, passport and date-of-birth values are only reported when the value sits right next to its label, such as "DL no.", "passport" or "DOB". That keeps noise down, but it also means an unlabeled value will not be caught.

The health keyword signal works differently. It says the file reads like a medical record. It does not identify individual records, so that finding says "look at this file," not "this file contains these people." Medical record numbers, Medicare numbers and insurance member IDs are separate findings, one per number, each with a masked sample.

A one-minute routine for each finding

1. Is it real? Glance at the sample and the count. Detection is rule-based and occasional false alarms happen. If the sample is clearly a part number or an order ID, mark it as a false finding and move on.
2. Does it need to exist? Ask who created the file and why. Most findings turn out to be convenience copies: an exported client list, a scanned ID saved to the desktop, a spreadsheet emailed and saved from an attachment.
3. Where should it live? If the file is needed, it belongs in a location with proper access controls and encryption, chosen with your IT provider.
4. Who does the work? Moving, encrypting and deleting are done by you or your IT provider. MyVaultMate does not change files.
5. Record the decision. Findings can be worked through in the dashboard, so the next person sees what was handled.

Sorting by what to fix first

Start at the top of the ranking. Within the same severity, favor files with a high distinct-value count and files in shared or synced locations, because those are exposed to more people. A single file containing hundreds of values in a OneDrive or Google Drive folder deserves attention before a lone value in a private folder.

It also helps to switch between the by-computer and by-data-type views. If one machine carries most of the findings, a single clean-up session there may do more than working finding by finding.

What a finding is not

A finding is not proof of a breach, and a clean scan is not proof of safety. The scan reads only the paths you chose and only the file types it supports; RTF and PowerPoint files, Outlook .pst data files, and zip archives are not scanned yet. Treat findings as a prioritized to-do list that supports your own security and compliance work. For questions about what a particular finding means under a law or regulation, an attorney or advisor can give you specifics.

After you act on a batch, run another scan. The re-scan shows which findings are gone, and the dashboard's totals and risk score update to match, so you can compare them with the first report you saved. You can see how findings are laid out in a finished report at /sample.