Auditing residual PII in a delivered dataset: sampling plans and acceptance thresholds

Why redaction output still needs an independent audit

Every automated detector misses something, so the buyer has to measure the residue on the delivered data rather than trust a tool's reported accuracy. Microsoft's Presidio project states that because it relies on trained models it cannot be counted on to find all sensitive information and should be combined with other protections [5]. NIST SP 800-188 makes the same point at the method level: traditional de-identification has inherent limitations that formal privacy methods do not [1].

Published scores rarely transfer to your corpus. There is no official benchmark for general PII redaction, so teams have to build labeled samples from their own data [6], and a detector evaluated on the dataset family it was trained on will look better than it performs on support tickets, CRM notes or agent traces [7]. Tool-call arguments, JSON payloads, OCR text and email signatures are the usual blind spots; the guide to measuring what PII redaction pipelines miss covers detector choice, and this page covers the acceptance math.

Legal standards also frame the audit as risk, not perfection. HIPAA's standard is that there is "no reasonable basis to believe" the information can identify an individual [3], reached through Safe Harbor's 18 identifiers or an Expert Determination [2]. The CCPA ties "deidentified" status to the holder's reasonable measures and commitments, not to a zero-error claim [4]. The buyer guide to de-identified training data maps the wider topic; see how de-identified, anonymized and pseudonymized differ legally before you write thresholds into a contract.

Define the sampling unit and the defect before you count

The audit is only meaningful if "one sample" and "one defect" are defined in the acceptance criteria before the delivery arrives. Pick the unit the model will consume: a ticket thread, a call transcript, a document page, a trajectory step or a table row. A 40-turn support thread has far more opportunities for a leak than a single invoice line, so mixing units distorts the rate.

Define a defect at the record level: a record fails if it contains at least one real identifier that the de-identification method should have removed or replaced. Count identifier-level misses as a secondary metric, because one record with an unredacted SSN is a different event from one record with an extra city name. Exclude correctly generated surrogates, which requires the supplier to document the surrogate scheme (for example, [NAME_1] tokens or realistic fake names) so reviewers can tell a replacement from a leak.

Surrogates make this harder, not easier. Carrell and colleagues showed that manual and automated PHI removal both leave residual identifiers, and that realistic surrogates conceal the residue among plausible fakes [8]. That protects data subjects, but it also hides misses from your reviewers, so ask for a supplier-side key or a held-out mapping on the audit sample, or audit a pre-surrogate checkpoint. The trade-offs are covered in masking vs surrogate replacement.

Sample sizes for a target residual rate

The sample size comes from the residual rate you want to rule out and the confidence you need, not from the size of the delivery. For a zero-defect plan (accept only if no defect is found), n = ln(1 − confidence) / ln(1 − p), where p is the maximum tolerable record-level defect rate. For large lots the population size barely matters; for lots under a few thousand records, a hypergeometric calculation lowers n slightly.

Illustrative example: invented to show structure; it does not describe an available dataset.

A quick check is the "rule of three": if you find zero defects in n records, the one-sided 95% upper bound on the rate is roughly 3/n. When you do find defects, report an exact (Clopper-Pearson) upper bound rather than a normal-approximation interval; CLT-based intervals are too narrow on samples of a few hundred and below [9]. For example, 2 defects in 600 records gives a 95% upper bound of about 1.05%, which fails a 1% threshold even though the point estimate is 0.33%.

Allowing one defect (c = 1) costs more records but cuts the risk of rejecting a good lot over one borderline label. Stratify the draw by source system, date range and record type, then size each stratum separately if any stratum carries a different risk, such as free-text notes versus structured fields.

Tiered acceptance thresholds by identifier class

One blended threshold hides the defects that matter, so set a separate limit for each identifier class. Direct identifiers and secrets warrant a zero-defect plan at a tight rate; quasi-identifiers warrant a looser rate plus a linkage review. The table below is a starting template, not a regulatory standard.

Illustrative example: invented to show structure; it does not describe an available dataset.

Quasi-identifiers are judged in combination, not one at a time, which is why a per-record miss rate alone cannot clear them. Run the linkage and mosaic risk review on the quasi-identifier columns, and for free text consider the stronger tests in LLM-assisted re-identification. For health data, a Safe Harbor delivery should show zero misses on all 18 listed identifiers in the sample [2].

Running the human review

A residual audit is a labeling task, so treat it like one: written guidelines, trained reviewers, double annotation and adjudication. Two reviewers label each sampled record independently, a third adjudicates disagreements, and you report inter-annotator agreement alongside the defect count. Reviewers who see only redacted text will under-count misses that look like surrogates, so give them the surrogate scheme and examples of each identifier class.

Run an automated pre-pass with a different detector from the supplier's, then have humans review every record in the sample, not only flagged ones. Using the same tool family the supplier used tends to repeat its blind spots. Log each finding with the record ID, field or character offset, identifier class and reviewer decision.

Illustrative example: invented to show structure; it does not describe an available dataset.

residual_pii_audit:
  delivery_id: DEL-2026-0412
  manifest_sha256: "<from delivery manifest>"
  sampling_unit: support_thread
  population: 184000
  strata: [source_system, year, channel]
  seed: 20261009
  plans:
    direct_identifiers: { p_max: 0.001, confidence: 0.95, c: 0, n: 2995 }
    quasi_identifiers:  { p_max: 0.01,  confidence: 0.95, c: 1, n: 473 }
  review: { annotators: 2, adjudicator: 1, guideline_version: "v3" }
  findings:
    - { record_id: T-88213, field: body, offset: "1412-1428", class: account_number, decision: confirmed }
  result: { direct_defects: 1, upper_bound_95: 0.0016, verdict: reject }

Record the random seed and the manifest hash so the supplier can reproduce the exact sample; the manifest and checksum verification guide covers how to bind the audit to specific files.

Recall audits with a labeled sample

The found rate tells you how much PII is left; a recall audit tells you why, and only it predicts the next delivery. To measure recall you need the pre-redaction text for a labeled subset, which a buyer usually does not receive. Ask the supplier to label a random pre-redaction sample, run their pipeline over it and report per-class recall with exact confidence intervals [6].

A low found rate with weak recall usually means the corpus was sparse in PII, not that the pipeline is strong. Watch for recall reported on public PII benchmarks, which may overlap the detector's training data and overstate performance [7]. For datasets that can train or evaluate detectors themselves, see PII detection training and evaluation datasets and the glossary entry on PII detection.

Contract remedies when a lot fails

The remedy for a failed audit should be decided before delivery, written into the acceptance criteria, and tied to the inspection window. Typical buyer-side terms are rejection of the lot, supplier re-redaction at no charge, a re-audit under a tightened plan (larger n, same c), and a written root-cause note naming the pipeline change. Repeated failures can switch subsequent lots to tightened inspection, borrowing the switching-rule logic of attribute sampling standards.

Quarantine the lot until the verdict, with no copies in training buckets or annotation queues. If PII surfaces after acceptance, follow the response playbook for personal data found in a licensed dataset. Inspection windows and cure periods are covered in dataset acceptance testing, and non-privacy defects belong in acceptance sampling for record and label defects.

How SourceX handles personal details before delivery

SourceX removes or replaces personal details such as names, emails, phone numbers and account numbers before delivery, records the method used and checks a sample, while acknowledging that no method is perfect. Health records require HIPAA de-identification through Safe Harbor or Expert Determination. Diligence materials covering source, rights, preparation and allowed use are prepared per dataset, which gives your own audit a documented starting point. Buyers can describe what they need on the SourceX buyer page; datasets are sourced on request from US companies, and a request does not guarantee a match.

Request a de-identified dataset with a documented preparation method

SourceX sources operational datasets from US companies on request and manages the license that defines records, uses, term and delivery. Every dataset is rights-reviewed, and personal details are removed or replaced with the method recorded. Describe the data and the residual-PII criteria you plan to apply at sourcex.si/buyers.