SI-19: De-identification

Quick-reference card

What this control requires

SI-19 requires your organization to strip specified personally identifiable information (PII) elements from datasets and regularly evaluate whether that de-identification remains effective. This control sits within the System and Information Integrity family and addresses a core privacy challenge: even after you remove obvious identifiers like names and Social Security numbers, residual data points can still be combined to re-identify individuals.

In practice, you need to inventory the PII elements present in your datasets, determine which elements must be removed or transformed, and then apply appropriate de-identification techniques. These techniques include suppression, generalization, masking, and pseudonymization, each suited to different data types and use cases. The control also requires that only trained personnel perform de-identification work, reducing the risk of incomplete or inconsistent removal that could leave individuals exposed.

Specifically, datasets often contain both direct identifiers and linked data that together create re-identification risk. Direct identifiers include names, Social Security numbers, dates of birth, and biometric data. Linked data encompasses medical, educational, financial, and employment records that may not identify someone in isolation but become identifying when combined. Your de-identification program must address both categories.

The second component of SI-19 focuses on ongoing evaluation. De-identification isn’t a one-time activity, and as datasets grow and external data sources become more accessible, the risk of re-identification increases.

Your organization must establish a defined frequency for reassessing whether previously de-identified datasets still protect individual privacy. This evaluation should account for new linking attacks, advances in data analytics, and changes to the datasets themselves. You can find additional context on how SI-19 fits within the broader NIST SP 800-53 framework and its family of controls.

Why it matters

Organizations that fail to de-identify PII face a category of risk that’s often invisible until an audit or regulatory inquiry exposes it. Unlike controls that address active threats, SI-19 targets a governance gap where datasets contain more identifying information than they should, sitting in systems where they don’t need to be, accessible to people who don’t need them.

The compliance consequences are direct. Privacy frameworks like HIPAA, CCPA, and GDPR impose specific requirements on how organizations handle identifiable data. If your de-identification practices can’t withstand scrutiny, audit findings escalate quickly from technical gaps to regulatory violations. Privacy impact assessments that fail to account for re-identification risk undermine the credibility of your entire privacy program.

Beyond compliance, this control addresses a growing operational vulnerability. As organizations collect and share more data across departments, vendors, and analytics platforms, the surface area for re-identification expands. Datasets that were considered safe five years ago may no longer meet that standard when combined with publicly available information.

The organizations that treat de-identification as a static, checked-off task are the ones most likely to discover gaps during an incident response or regulatory review. Without a defined evaluation cadence, you have no way to demonstrate that your de-identification keeps pace with changes in the data landscape. Auditors and regulators increasingly expect documented evidence that re-identification risk has been reassessed, not just that PII was removed at some point in the past.

What attackers exploit

• Linkage attacks: Combining de-identified datasets with publicly available records (voter registrations, social media profiles, commercial databases) to re-identify individuals
• Inadequate suppression of direct identifiers: Datasets that retain dates of birth, biometric markers, or geographic details specific enough to narrow identification to a single person
• Stale de-identification practices: Organizations that applied de-identification techniques years ago but never reassessed effectiveness as new external data sources emerged
• Insufficient access controls on de-identified datasets: Treating de-identified data as non-sensitive, granting broad access without monitoring who queries the data or how it’s combined with other sources
• Weak pseudonymization: Using reversible or predictable transformation methods that allow reconstruction of original identifiers with minimal effort

How to implement

Most SI-19 failures stem from treating de-identification as a one-time data cleanup rather than an ongoing governance discipline. The implementation steps below address both the technical removal of PII and the evaluation cycle that keeps your de-identification effective over time.

For your organization

Inventory PII elements in your datasets. Start by cataloging every dataset that contains PII, including direct identifiers (names, Social Security numbers, dates of birth, biometric data) and linked data (medical records, educational history, financial records, employment information). Map where these datasets reside, who has access, and how they flow between systems.

Select and document de-identification techniques. Match each PII element to an appropriate technique based on the dataset’s intended use. Suppression removes the data entirely. Generalization replaces specific values with broader categories (for example, replacing exact ages with age ranges). Masking obscures portions of the data while preserving format. Pseudonymization replaces identifiers with artificial values using a controlled mapping. Document which technique applies to each element and why.

Assign trained personnel. De-identification requires understanding of both the data and the privacy risks. Designate specific staff members who have received training on de-identification methods, re-identification risks, and your organization’s privacy policies. Avoid delegating this work to general IT staff without proper preparation.

Establish a re-identification risk assessment schedule. Define a frequency for evaluating whether your de-identified datasets remain protected. This schedule should account for changes to the datasets, new external data sources that could enable linkage attacks, and advances in analytics techniques. Document evaluation criteria and results each cycle. Many organizations align this evaluation with their broader privacy risk assessment cadence, running re-identification checks quarterly or semiannually depending on the sensitivity of the data involved.

Deploy supporting tooling. Data masking platforms, privacy-enhancing technologies, and data loss prevention tools can automate portions of the de-identification process. These tools help enforce consistency across large datasets and provide audit trails that demonstrate compliance. When evaluating tooling, prioritize solutions that support multiple de-identification techniques and generate logs showing which transformations were applied to which data elements.

Avoid common mistakes. Don’t assume that removing names and Social Security numbers is sufficient, since linked data like dates of birth, ZIP codes, and medical conditions can combine to re-identify individuals. Don’t treat de-identification as a one-time project with no follow-up evaluation. Don’t apply the same technique uniformly to all data types without assessing whether the technique matches the re-identification risk for each element. And don’t overlook datasets shared with third parties, since your de-identification obligations extend to data processed on your behalf.

For your vendors

When your vendors handle datasets containing PII on your behalf, their de-identification practices become your risk. You can’t outsource the data and then disclaim responsibility for how it’s protected. Security questionnaires and evidence requests should target specific gaps rather than relying on general assurances about data handling.

Questions to include in security questionnaires. Ask vendors to describe their de-identification procedures, including which techniques they use (suppression, generalization, masking, pseudonymization) and how they determine which technique applies to each data element. Ask how frequently they evaluate the effectiveness of their de-identification. Request details about who performs the work and what training those individuals have received.

Evidence to request. Ask for documented de-identification procedures, training records for personnel who handle PII removal, privacy impact assessments that address re-identification risk, and sample outputs showing de-identified datasets. Request evidence of periodic re-identification risk assessments, including the evaluation criteria and results.

Red flags to watch for. Be cautious if a vendor can’t articulate which de-identification techniques they use or defaults to vague descriptions like “we anonymize the data.” Lack of a defined evaluation schedule, absence of training documentation, or inability to produce sample de-identified outputs all signal weak practices. Vendors who treat protected health information (PHI) and other sensitive data categories identically without differentiating their de-identification approach also warrant closer scrutiny.

Verification approach. Review vendor-provided de-identified datasets against the original data schema to confirm that specified PII elements have been removed or transformed. Validate that the vendor’s evaluation frequency aligns with your organizational requirements. Confirm that personnel performing de-identification have documented training and that the vendor maintains records of completed evaluations.

Cross-reference vendor de-identification claims against the evidence they provide. A vendor that describes robust procedures but can’t produce sample outputs, training records, or evaluation results likely hasn’t operationalized the control. Periodic reassessment of vendor de-identification practices should be built into your vendor review cycle, not treated as a one-time onboarding check.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for this control.

Related controls

Review other controls in the System and Information Integrity family to understand how SI-19 fits within a broader privacy and data protection strategy.

• MP-06 — Media Sanitization: Addresses the secure removal of data from physical and digital media before disposal or reuse, complementing SI-19’s focus on removing PII from active datasets
• PM-22 — Personally Identifiable Information Quality Management: Ensures the accuracy and relevance of PII throughout its lifecycle, which directly affects the quality and completeness of de-identification efforts
• PM-23 — Data Governance Body: Establishes organizational oversight for data handling practices, including the policies and standards that govern when and how de-identification must be applied
• PM-24 — Data Integrity Board: Provides a review mechanism for data matching activities and associated privacy risks, supporting the evaluation of re-identification risk that SI-19 requires
• RA-02 — Security Categorization: Determines the sensitivity level of information and systems, which informs which datasets require de-identification and what level of protection is appropriate
• SI-12 — Information Management and Retention: Governs how long information is retained and when it should be disposed of, directly influencing the scope and timing of de-identification activities

Frequently asked questions

What is NIST SP 800-53 SI-19?

SI-19 is the NIST SP 800-53 control that requires organizations to remove specified PII elements from datasets and evaluate the effectiveness of that de-identification on a defined schedule. It applies to both direct identifiers like names and Social Security numbers and linked data such as medical, financial, and employment records. The control mandates that trained personnel perform de-identification and that organizations reassess re-identification risk as datasets and external data sources evolve.

What happens if SI-19 is not implemented?

Without SI-19 implementation, your organization retains identifiable information in datasets longer than necessary, creating exposure to privacy violations, regulatory penalties, and re-identification attacks. Privacy impact assessments and audit reviews will flag the absence of documented de-identification procedures as a material gap. In regulated industries, this gap can escalate from a technical finding to a compliance violation under frameworks like HIPAA, CCPA, and GDPR, particularly if a breach exposes datasets that should have been de-identified.

How do you audit SI-19?

Auditing SI-19 starts with reviewing documented de-identification procedures to confirm they specify which techniques apply to each PII element and who is authorized to perform the work. Auditors then examine datasets with PII removed to verify that direct identifiers and linked data have been appropriately suppressed or transformed. The evaluation schedule and results of re-identification risk assessments provide evidence that the organization treats de-identification as an ongoing discipline rather than a one-time task.

What is the difference between de-identification and anonymization?

De-identification removes or transforms specific PII elements from a dataset to reduce the risk of identifying individuals, but it may leave residual data that could enable re-identification through linkage attacks or advanced analytics. Anonymization goes further by irreversibly altering data so that individuals can never be re-identified, even with access to external datasets. SI-19 focuses on de-identification because true anonymization is difficult to achieve and verify across complex, interconnected datasets. The practical distinction matters for your privacy risk assessments, since de-identified data still requires ongoing evaluation and access controls that fully anonymized data would not.