SI-18(2): Data Tags

To meet the si-18(2): data tags requirement, you must implement machine-readable tags on PII so your systems can automatically find the right records and execute correction or deletion across the entire data life cycle (collection through disposal). Operationalize this by standardizing tag schema, propagating tags end-to-end, and proving automated workflows work in production. ¹

Key takeaways:

• Tagging must drive automation for PII correction and deletion, not just classification labels. ¹
• Scope includes all PII stores and flows, including logs, analytics, backups, and third-party integrations you control. ¹
• Auditors look for repeatable evidence: schema, coverage map, workflow runs, and exception handling tied to record IDs and timestamps. ¹

SI-18(2) is easy to misunderstand as “add a data classification label.” That is not the requirement. The control asks you to employ data tags so your organization can automate two specific privacy outcomes: correction of PII and deletion of PII, across the information life cycle in organizational systems. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SI-18(2) as an engineering-backed privacy operations control: define a standard PII tag model, require tag propagation wherever PII moves, and connect tags to automated workflows that can (a) locate the relevant records and (b) execute correction or deletion consistently. ¹

This page gives requirement-level guidance you can assign to system owners and privacy operations teams immediately: what “data tags” must look like, what systems must be in scope (including hard-to-delete areas like derived datasets and backups), what evidence to retain, and how to handle the inevitable exceptions without failing an assessment.

Regulatory text

NIST SI-18(2): Data Tags (excerpt) — “Employ data tags to automate the correction or deletion of personally identifiable information across the information life cycle within organizational systems.” ¹

Operator meaning (what you must do):

• Implement machine-readable tags associated with PII so systems can automatically determine what data is in scope for a correction or deletion request. ¹
• Ensure tagging supports actions across the life cycle, not only in the source application. Your tags (or tag-to-identity linkage) must survive common data movements: ETL/ELT pipelines, replication, exports, reporting warehouses, and archival. ¹
• Prove the tags drive automated correction or deletion in organizational systems, with defined exception handling where automation cannot safely apply. ¹

Plain-English interpretation

SI-18(2) requires you to make PII “actionable” by automation. If your privacy team receives a request to correct a person’s data or delete it, your systems should not rely on manual searching, spreadsheet tracking, or ad hoc scripts. The tags are the control mechanism that makes correction/deletion consistent, repeatable, and testable across every place PII exists under your control. ¹

A practical interpretation that holds up in audits:

1. You can identify PII records by a common tag or tag-linked identifier.
2. You can route those tagged records into automated correction/deletion workflows.
3. You can demonstrate the workflows executed across in-scope systems, including downstream stores. ¹

Who it applies to (entity and operational context)

Entity types

• Federal information systems and contractor systems handling federal data that implement NIST SP 800-53 controls. ¹

Operational contexts where SI-18(2) becomes “real”

• Systems that store PII in structured databases (CRM, case management, HRIS-like functions).
• Event and telemetry platforms where PII can appear (application logs, support transcripts).
• Analytics and ML pipelines where PII may be copied, transformed, or derived.
• Backup, archival, and disaster recovery processes that retain historical copies.
• Integrations with third parties where your system exports PII and later receives updates. ¹

Scoping rule you can enforce If a system creates, stores, processes, transmits, or derives PII that your organization controls, it must either: (a) support the tagging and automation model, or (b) have an approved exception with compensating controls and a plan to remediate. ¹

What you actually need to do (step-by-step)

1) Assign ownership and define the minimum viable tag schema

Decisions to make (document them):

• What counts as PII for your environment (use your existing privacy inventory/PIA standard).
• Tag format: embedded metadata (e.g., JSON field, column), sidecar metadata service, or both.
• Stable identity key: a durable identifier used to locate all related records for correction/deletion (for example, an internal subject ID mapped to user identifiers).
• Lifecycle fields that make automation safe: source system, record type, retention class, and permissible actions (correctable/deletable). ¹

Implementation note: If you cannot tag individual data elements everywhere, tag records and datasets with a linkage to a subject identifier that can drive deterministic search and action. The requirement is automation of correction/deletion across the life cycle; it does not mandate a specific tagging technology. ¹

2) Build a system-by-system coverage map (PII stores and flows)

Create a “PII tag coverage matrix” that lists:

• Data store/system name and owner
• PII types present
• How tags are applied (at ingestion, at creation, via batch enrichment)
• Where tags are persisted (DB field, object metadata, index, data catalog)
• Downstream consumers (warehouse, SIEM, third parties, backups)
• Supported automated actions: correction, deletion, both
• Exceptions and rationale (with ticket references) ¹

This matrix becomes your single best audit artifact because it proves you understood “across the information life cycle within organizational systems.” ¹

3) Implement tag propagation controls in data pipelines

You need a technical control that prevents tag loss during:

• ETL/ELT transformations (field renames, joins, denormalization)
• File exports and object storage writes
• Stream processing (events that contain user attributes)
• Log pipelines (structured logging fields) ¹

Practical patterns that work:

• Add a required “pii_subject_id” (or equivalent) field to events and records, with validation at pipeline ingress.
• Maintain a metadata service that maps subject IDs to record locations (indexes), so deletion can be executed even if the original tag is not embedded everywhere.
• Add automated tests in CI/CD that fail builds when PII fields are introduced without tagging rules. ¹

4) Connect tags to automated correction and deletion workflows

Your automation should include:

• Intake trigger: a privacy request, customer service correction, data quality fix, or internal discovery that PII is wrong.
• Resolver: translate an individual into the internal subject ID (or equivalent).
• Locator: query by tag/subject ID across systems in the coverage matrix.
• Executor:
  • Correction: update authoritative sources first, then propagate updates to replicas and derived datasets where applicable.
  • Deletion: delete or de-identify as required by your policy and system design.
• Verifier: post-run checks that confirm action completion (or record exceptions) ¹

Where teams get stuck: backups and immutable logs. Your workflow must still address them. Options include cryptographic erasure, logical deletion with compensating controls, or documented exception paths with restricted access and retention controls, based on your system constraints and policies. SI-18(2) is about automation; exceptions must be controlled, not informal. ¹

5) Define exception handling and human approval points

Automation cannot safely delete everything everywhere without guardrails. Document:

• When human approval is required (legal holds, fraud investigations, security incident evidence).
• When deletion becomes “tombstone + access restriction” pending retention expiry (if your policy supports it).
• How you prevent re-ingestion of deleted/corrected PII (block lists, idempotency keys). ¹

6) Operationalize: monitoring, metrics, and recurring tests

You need ongoing assurance:

• Scheduled tests of deletion and correction workflows in non-production and production-like environments.
• Alerts on pipeline tag-drop events (e.g., records missing required subject ID).
• Periodic reviews of the coverage matrix against architecture changes and new data stores. ¹

Daydream fit (where it naturally helps): Use Daydream to map SI-18(2) to a named control owner, a written implementation procedure, and a recurring evidence set so the control stays audit-ready as systems change. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design and operation:

Design evidence

• Approved SI-18(2) control statement (what tags are, where required, what automation does). ¹
• Tag schema specification (fields, allowed values, versioning, ownership).
• PII tag coverage matrix (systems, flows, actions supported).
• Data lifecycle documentation that shows where PII moves and where tags persist. ¹

Operational evidence

• Workflow run logs for correction and deletion (request ID, subject ID, systems targeted, success/failure, timestamps).
• Samples of completed requests with proof of downstream propagation (before/after records or attestations).
• Exception register: what could not be automated, why, who approved, and remediation plan.
• Change management records showing new systems/pipelines were onboarded to tagging requirements. ¹

Common exam/audit questions and hangups

Expect assessors to probe these points:

• “Show me how a deletion request propagates to your warehouse, log platform, and backups.” ¹
• “How do you know new PII fields don’t enter production without tags?”
• “Is the tag the same everywhere, or do you have a mapping service? Show the mapping controls.”
• “Demonstrate correction vs deletion. Do you treat them differently in code and approvals?”
• “What is your evidence that this is automated and repeatable, not a one-off script?” ¹

Hangup to preempt: teams often provide a data classification policy and a DLP screenshot. That rarely demonstrates automated correction/deletion across the life cycle, which is the core of SI-18(2). ¹

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SI-18(2)	How to avoid it
Tags exist only in the primary app DB	Downstream copies still contain PII without automated action	Build the coverage matrix; require tag propagation or locator indexes for every downstream store. 1
Tagging is manual (analyst labels datasets)	Manual tagging does not automate correction/deletion	Enforce tags at ingestion/creation with validation and CI/CD checks. 1
Deletion automation ignores derived datasets	PII can persist in aggregates, feature stores, exports	Define “derived PII” rules; include downstream deletions or de-identification steps. 1
No exception governance	“We can’t delete from X” becomes permanent and untracked	Maintain an exception register with approvals and compensating controls. 1
Evidence is ad hoc	You cannot prove continuous operation	Standardize recurring evidence collection; keep run logs and test records. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk as indirect: SI-18(2) reduces the likelihood and impact of privacy failures where organizations cannot reliably correct inaccurate PII or delete PII when required by policy, contract, or system-of-record rules. ¹

From an assessment perspective, the most common risk is an “implemented in pockets” control that does not cover the life cycle. Assessors frequently interpret that as a control design gap, even if your primary system supports deletion. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and design)

• Appoint a control owner (privacy engineering or security engineering) and a compliance owner (GRC).
• Publish the minimum tag schema and the required subject identity linkage.
• Build the first version of the PII tag coverage matrix for your highest-risk systems (systems of record plus the biggest downstream stores).
• Pick one correction workflow and one deletion workflow as reference implementations, and define what “done” evidence looks like (logs, verification). ¹

Days 31–60 (implement automation where it matters most)

• Implement tag enforcement at ingestion for the reference systems (validation checks).
• Connect tags/subject ID to automated correction and deletion executors for the reference systems.
• Add exception handling, approval points, and an exception register.
• Run controlled test requests end-to-end and archive the evidence package for audit. ¹

Days 61–90 (expand coverage and make it audit-repeatable)

• Expand tagging and automation coverage to remaining in-scope systems listed in the matrix.
• Add monitoring for tag loss and workflow failures; route alerts to an accountable team.
• Put a change gate in place so new systems that store PII cannot go live without tagging and workflow integration (or an approved exception).
• In Daydream, map SI-18(2) to the owner, procedure, and recurring evidence tasks so readiness persists through architecture changes. ¹

Frequently Asked Questions

Does SI-18(2) require a specific technology like a data catalog or DLP tool?

No. The requirement is outcome-based: use data tags to automate correction or deletion of PII across the lifecycle. You can meet it with embedded metadata, a metadata service, or another approach if it reliably drives automation. ¹

What counts as a “data tag” for auditors?

A tag is machine-readable metadata that your systems can query to locate and act on PII for correction or deletion. A human-applied label without automated workflows usually will not satisfy the “automate” expectation. ¹

Do we have to delete PII from backups to comply?

SI-18(2) requires automation across the information life cycle within organizational systems, so you must address backups in your lifecycle plan. If technical constraints prevent direct deletion, document an approved exception path and compensating controls tied to retention and access restrictions. ¹

How do we handle PII in logs and telemetry?

Treat logs as in-scope systems if they contain PII. Reduce PII logging, structure logs so subject identifiers can be found, and include the log platform in your coverage matrix and deletion/correction workflow strategy. ¹

Can we satisfy SI-18(2) if we only tag datasets, not individual fields?

Potentially, if the dataset tags plus a stable subject identifier still allow automated location and action on the relevant PII records across systems. Document the design and show end-to-end workflow evidence. ¹

What evidence is strongest in an assessment?

A complete coverage matrix plus workflow run logs that show automated correction/deletion executed across multiple systems, including downstream stores, with exceptions tracked and approved. That combination demonstrates both control design and operation. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON