A discovery result is not defensible merely because a scanner found a value. A reviewer needs to know what was authorized, what logic ran, which evidence was observed, who interpreted it, and what happened next. An evidence pack makes those details reviewable without asking someone to reconstruct the scan from memory.
Market perspective
Gartner’s public abstract for Market Overview for Data Security Posture Management describes a market concerned with understanding where data is held and what it contains. Discovery, classification and cataloging cover both structured stores and unstructured material, with privacy, security and AI-related exposure as the risk context. This connects sensitive-data visibility with questions broader than the number of fields a scanner flags. The abstract is a market-level description, not a mandated evidence-pack format, legal standard or evaluation of PDI. It does not establish how a particular product records human decisions, carries out remediation or verifies the outcome of an approved action.
PDI perspective: PDI’s interpretation is that visibility should become a defensible evidence trail. Use the checklist below to connect approved scope, rules, findings, reviewer decisions, authorized actions, exceptions and verification. A discovery result alone is neither a verified remediation outcome nor proof of compliance. Product context: Kestryl · PII discovery.
These summaries use publicly available research or abstracts. Citations do not imply endorsement of PDI or its offerings.
PDI Evidence Pack: a practical 10-part checklist
PDI operating recommendation: use the following ten-part manifest to make a discovery run reviewable. This is PDI’s proposed working artifact, not a prescribed NIST checklist or a guarantee of legal compliance. Limit sensitive content to what an authorized reviewer needs; use protected references rather than copying personal values into the manifest.
External guidance: NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk. We use it only as privacy-risk, governance and outcome-verification framing. It is not law, does not mandate this pack, and does not certify Kestryl or a customer’s compliance.
| Part | Evidence to retain | Review question |
|---|---|---|
| 1. Scope | Approved sources, environments, exclusions, purpose and access constraints. | Does the approval cover exactly what was assessed? |
| 2. Ruleset/version fingerprint | Ruleset ID, version, configuration fingerprint and matching thresholds where used. | Can a reviewer identify the logic and configuration that ran? |
| 3. Scan timestamp | Run ID, start/end timestamps with timezone, source snapshot or extraction reference. | Can this observation be distinguished from an earlier or later run? |
| 4. Findings inventory | Stable finding IDs, source/object references, classifications and protected evidence pointers. | Can every reported count be reconciled to bounded findings? |
| 5. Reviewer decisions | Decision, responsible role, rationale and decision timestamp for each disposition. | Is an observation separate from its human interpretation? |
| 6. Approval record | Approver role, authorized scope, approval reference and any conditions. | Was the proposed action authorized before execution? |
| 7. Remediation action | System-of-action ticket, operator role, target and execution outcome. | What actually changed, or was explicitly left unchanged? |
| 8. Exceptions/refusals | Reason, owner, expiry/revisit condition and any applicable retention constraint. | Is unresolved or refused work visible rather than counted as complete? |
| 9. Verification result | Verification method, timestamp, observed result and remaining limitations. | Does closure rest on an observed outcome rather than a ticket status? |
| 10. Final evidence manifest | Linked artifact inventory, access controls, retention decision and checksums where supported. | Can the pack be located, reconciled and checked for subsequent changes? |
| Finding and run | Decision and approval | Action | Verification | Exception and manifest |
|---|---|---|---|---|
| SYN-F017: personal-email classification in a synthetic staging column; rules SYN-R3; run SYN-09 at 2026-11-10 09:00 UTC. | Synthetic data-owner role confirms the staging copy is unnecessary; approval SYN-A08 authorizes removal of that copy only. | Application operator records deletion of the staging copy under synthetic ticket SYN-C21; the source system is outside this action. | An authorized scoped recheck at 10:00 UTC finds the staging copy absent; no claim is made about unscanned sources. | An unassessed backup remains an explicit exception, not a pass. Manifest SYN-M09 links the run, decision, approval, action and recheck. |
Begin with the approved boundary
Record the assessment purpose, business owner, approving authority, time window, environments, and named data sources. Include the connection or source identifiers used by the run, but do not put credentials or sensitive sample values in the pack. The boundary should make both inclusion and exclusion legible: which schemas, object classes, file locations, or partitions were in scope, and which were intentionally deferred.
Preserve the approval that authorized the work and any operating constraints, such as read-only access, sampling limits, production windows, or a prohibition on scanning particular content. If access was unavailable, mark the source as not assessed rather than allowing a missing result to look like a clean result.
Minimum scope approval
Before a run, link the named owner’s approval to the source list, excluded locations, allowed sampling, permitted evidence exports, and stop conditions. An inaccessible source belongs in the coverage record, not in the count of successfully scanned systems.
Fingerprint the rules that produced the result
A pack should identify the detector or scanner build, ruleset name and version, configuration fingerprint, classification vocabulary, and relevant thresholds. A version label alone may not be enough if rules can be edited in place; retain a stable hash or export of the actual configuration that ran, subject to the organization’s security controls.
Record the scan start and end times, execution identity, source-system version where practical, and whether the scan was full, incremental, sampled, or metadata-only. These details let a future reviewer distinguish a change in data from a change in rules, configuration, or coverage.
- Scanner and connector versions, plus a stable configuration identifier.
- Classification rules, confidence thresholds, and approved custom dictionaries.
- Run mode, execution window, source identifiers, and coverage limitations.
Make findings inspectable, not just countable
For each finding, capture the source and object path, relevant field or location, proposed category, confidence or rationale, detector evidence, and the review status. Avoid copying raw personal data into a report unless there is an approved need and secure handling method. Often a masked example, a type summary, or a reference to a controlled evidence store is sufficient for review.
Separate an observed fact from an interpretation. “Pattern matched this field under rule R” is an observation; “this is customer identity data” may be a classification decision that requires a steward. The distinction prevents an automated signal from being presented as a settled business conclusion.
Preserve reviewer decisions and their reasoning
The pack should show who reviewed a finding, when the decision was made, which choice was selected, and the reason or supporting context. Useful outcomes include confirmed, reclassified, false positive, duplicate, needs investigation, and accepted pending owner validation. Keep the original machine result alongside the human decision; do not overwrite it.
Where a classification rule changes because of review, record the change separately and link it to the decision that prompted it. This creates a traceable feedback loop and makes it possible to explain why a later scan differs.
Tie approved actions to accountable owners
A finding can lead to masking, access review, retention analysis, deletion assessment, catalog tagging, or no change. Capture the action selected, its authorizing owner, ticket or change reference, target system, planned completion condition, and the evidence expected to close it. Discovery software may support workflow, but the system of action and its operators remain responsible for carrying out changes.
Do not equate a recommendation with execution. Mark an action as proposed, approved, scheduled, completed, or verified according to evidence actually available. For a high-impact change, link to the change record or validation result rather than relying on a status field alone.
Treat refusals and exceptions as first-class evidence
A scan may refuse a source, skip an object, stop at a permissions boundary, or leave an ambiguous finding unresolved. Record the reason, scope affected, risk owner, compensating control if any, approval, expiry or review date, and next step. An exception without an owner and review point easily becomes a permanent blind spot.
Keep “not scanned,” “scan failed,” “not applicable under the approved scope,” and “scanned with no finding” as distinct states. The distinction is essential when teams report coverage or respond to an audit request.
Make the pack reproducible and reviewable
A compact manifest can tie together approvals, configuration fingerprints, run logs, result exports, reviewer decisions, and linked action records. Store a checksum for exported artifacts where the evidence-handling process supports it, control access to the pack, and record subsequent amendments rather than silently replacing files.
The NIST Privacy Framework’s emphasis on identifying and governing privacy risks is a useful organizing lens, not a substitute for an organization’s own control requirements. Teams can use its inventory-and-mapping concepts to ask whether the evidence explains what data is processed, where it moves, and who is accountable. For more context on discovery practice, see PDI’s guide to enterprise PII discovery software. The practical test is straightforward: could a reviewer understand the boundary, reproduce the classification logic, challenge a decision, and verify the disposition without relying on the original analyst?