SI-18(4): Individual Requests

SI-18(4): Individual Requests requires you to correct or delete personally identifiable information (PII) when an individual, or their authorized representative, asks you to do so. To operationalize it, stand up an intake-and-verification workflow, map PII to systems of record, execute changes within governed approvals, and retain evidence that each request was authenticated, fulfilled, or lawfully denied. ¹

Key takeaways:

• Build a request workflow that includes identity/authority verification, scope definition, and documented disposition for every request. ¹
• You need technical capability to locate, correct, and delete PII across systems, including downstream copies and third parties, or document exceptions. ¹
• Audit readiness depends on artifacts: tickets, approvals, execution logs, and closure communications tied to a defined procedure and control owner. ¹

SI-18(4): individual requests requirement sits at the intersection of privacy operations and security hygiene. It is simple to state but hard to execute consistently: individuals can request correction or deletion of their PII, and you must be able to do it on demand, without breaking records, workflows, or legal holds. ¹

For a CCO or GRC lead, the fastest path is to treat SI-18(4) as an operational control with three moving parts: (1) intake governance (who can ask, how you verify, how you track), (2) data operations (where the PII lives, how you change or delete it, how you propagate updates), and (3) evidence (how you prove to assessors that the process works repeatedly, not just once). ¹

This page gives requirement-level implementation guidance you can hand to privacy ops, IT, security, and application owners. It avoids legal overreach and stays anchored to the NIST requirement text, while still addressing the practical realities: backups, logs, system-of-record conflicts, third-party processors, and exceptions that must be documented cleanly. ¹

Regulatory text

Requirement (SI-18(4)): “Correct or delete personally identifiable information upon request by individuals or their designated representatives.” ¹

Operator interpretation: what you must do

1. Provide a channel for individuals (or authorized representatives) to submit correction or deletion requests for PII you maintain. ¹
2. Authenticate the requester and validate representative authority before acting. This is implied by “individuals or their designated representatives” because acting without verification creates integrity and privacy risk. ¹
3. Execute the requested correction or deletion in the relevant systems that hold the PII, or document a justified exception with a clear disposition. ¹
4. Retain evidence that you received, validated, processed, and closed each request under a consistent procedure that can be assessed. ¹

Primary NIST references

• NIST SP 800-53 Rev. 5 landing page ²
• Control text source ¹

Plain-English interpretation of the requirement

SI-18(4) means you need a repeatable way for people to ask you to fix inaccurate PII or delete PII you hold about them, and you need the operational muscle to carry that out across your environment. ¹

In practice, assessors look for two things:

• Can you do it? Data discovery, system-of-record logic, and change/delete mechanisms exist and are used. ¹
• Can you prove it? A request trail exists from intake to closure, with approvals and execution evidence. ¹

Who it applies to (entity and operational context)

Entities

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 controls are in scope by contract, authorization boundary, or flow-down. ²

Operational contexts where SI-18(4) becomes real

• HR and identity systems (employee, applicant PII).
• Customer portals and CRM systems (customer PII).
• Case management systems for benefits, healthcare, or public services.
• Security and IT systems that store user attributes (directories, IAM, ticketing notes).
• Third-party processors that store or replicate your PII (SaaS tools, print/mail houses, call centers).

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

1) Assign control ownership and define the procedure

• Name a control owner (often Privacy Officer or CISO delegate) and document a procedure that describes intake, verification, execution, and evidence. This aligns to the practical need to “map SI-18(4) to control owner, implementation procedure, and recurring evidence artifacts.” ¹
• Define RACI across Privacy, Legal, IAM, App Owners, and Records Management.

Decision points to write into the procedure

• What qualifies as “PII” in your environment (use your org’s definition and data inventory).
• Which systems are systems of record versus caches/analytics copies.
• When you will correct versus delete (some systems support correction without deletion, some support deletion with tombstoning).
• What exceptions exist (legal hold, security logs integrity, contractual obligations). If you allow exceptions, require documentation and approval.

2) Stand up a request intake channel with tracking

Minimum viable intake options:

• Web form (preferred), email alias, and mailing address, all feeding a single case/ticket queue.
• A standard request form that captures: identity details, request type (correct/delete), affected records, and representative details if applicable. ¹

Tracking requirements:

• Every request becomes a uniquely tracked case with timestamps, assigned owner, and closure status.
• Link the case to all related approvals and execution logs.

3) Verify identity and representative authority

You need a consistent verification step before touching PII:

• Individuals: validate identity using your established identity proofing method appropriate to your risk (for example, authenticated portal access plus additional verification for sensitive changes).
• Designated representatives: require proof of authority (signed authorization, power of attorney, or other documented designation your Legal team accepts). ¹

Operational rule: if verification fails, close the request as “unable to verify,” document what was missing, and retain evidence of the interaction.

4) Triage scope and locate the PII across systems

This step fails most often because teams cannot find all the places PII lives.

• Maintain a PII data map that ties data elements to applications, databases, file shares, and third parties.
• For each request, identify: system of record, downstream systems, reporting stores, and integration paths.
• If you cannot locate the record, document the searches performed and systems checked.

5) Execute correction or deletion with guardrails

Implement two runbooks: Correction and Deletion.

Correction runbook

• Validate what “correct” means (source document, user-provided proof, authoritative reference).
• Update system of record first.
• Propagate updates to downstream systems through integrations, scheduled jobs, or manual changes.
• Capture execution evidence (change tickets, database logs, application audit logs).

Deletion runbook

• Confirm deletion is technically feasible without breaking required records.
• Delete or de-identify PII in system of record per your data handling approach.
• Address downstream copies and third parties: send deletion instructions, track confirmations, and record outcomes.
• Handle special data stores:
  • Backups: you may not be able to surgically delete from immutable backups; document your approach (for example, deletion takes effect upon restore events via rehydration filters or lifecycle policies).
  • Security/audit logs: if logs contain PII, define whether you redact, minimize, or retain under strict access controls; document the rationale and approval.

6) Communicate closure and retain artifacts

Close the loop with the requester:

• Confirm what was corrected/deleted, what systems were in scope, and any exceptions or limits. Keep the language factual.

Then retain evidence:

• Case record, verification evidence, approvals, execution proof, and closure notice. ¹

Required evidence and artifacts to retain

Maintain these artifacts in an assessor-ready package:

Artifact	What it proves	Owner
Written SI-18(4) procedure	Defined, repeatable process	GRC / Privacy
Request intake records (tickets/cases)	Requests are captured and tracked	Privacy Ops
Identity/authority verification record	Requester is validated	Privacy Ops / IAM
Data map / system inventory for PII	You can find PII across systems	Data Governance / IT
Change approvals (where required)	Controlled execution	App Owner / Change Mgmt
Execution evidence (logs, screenshots, audit trails)	Correction/deletion actually happened	IT / App Owner
Third-party notifications and confirmations	Downstream deletion/correction executed	Vendor/TPRM + Privacy
Exception disposition memos	Lawful/approved denials or limitations	Legal / Privacy

Daydream (as a workflow layer) typically helps by mapping SI-18(4) to a control owner, embedding the procedure into a task workflow, and generating recurring evidence packets from live tickets instead of last-minute screenshots. ¹

Common exam/audit questions and hangups

Expect these questions from assessors:

• “Show me three completed individual requests and the full evidence trail.” ¹
• “How do you validate a designated representative?” ¹
• “How do you ensure downstream systems and third parties receive the correction/deletion?” ¹
• “What are your documented exceptions (backups, logs, legal hold), and who approves them?”
• “How do you prevent unauthorized deletion of another person’s record?”

Hangups that slow audits:

• No data map, so you cannot demonstrate completeness.
• Requests handled in email with no structured evidence trail.
• “Deletion” means different things across systems, and nobody wrote down the org’s standard.

Frequent implementation mistakes and how to avoid them

1. Treating SI-18(4) as a policy statement only. Fix: require tickets, runbooks, and execution logs as “definition of done.” ¹
2. Skipping representative verification. Fix: make authority proof mandatory before any data change. ¹
3. Updating one system but missing downstream copies. Fix: maintain a PII data map and a propagation checklist per system-of-record.
4. Ad hoc exceptions (backups/logs) with no approvals. Fix: define exception categories and require Legal/Privacy sign-off recorded in the case.
5. No separation of duties for high-risk deletions. Fix: require a second approver for deletion requests affecting identity, access, or financial records.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

Risk implications still matter operationally:

• Unauthorized corrections or deletions can create integrity failures (wrong person’s record modified), security gaps (accounts orphaned), or compliance gaps (records retention conflicts).
• Failure to process requests consistently creates assessment findings because SI-18(4) is evidence-driven: assessors test completed cases, not intent. ¹

A practical 30/60/90-day execution plan

First 30 days (Immediate setup)

• Appoint control owner, define RACI, and publish the SI-18(4) procedure. ¹
• Implement a single intake queue (case management) with required fields.
• Define verification standards for individuals and representatives; get Legal sign-off.
• Identify top systems of record where requests will concentrate (HR, IAM, CRM) and write runbooks for those first.

Days 31–60 (Operationalize end-to-end)

• Build or refresh the PII data map for in-scope systems and key third parties.
• Configure change management hooks: approvals, peer review for deletions, and audit logging.
• Run tabletop tests using realistic scenarios: correction in system of record, deletion with downstream propagation, representative request, and “unable to verify.”
• Start producing an evidence packet from each completed request.

Days 61–90 (Harden and prepare for assessment)

• Expand coverage to secondary systems (analytics, archives, collaboration tools) and document exception handling.
• Add QA checks: periodic sampling of closed requests to confirm execution evidence is complete and downstream confirmations are attached.
• Align third-party contract clauses or DPAs to support correction/deletion requests and confirmation timelines.
• Use Daydream to keep SI-18(4) mapped to an owner and to standardize recurring artifacts, so audits pull from a consistent record set. ¹

Frequently Asked Questions

Do we have to delete PII everywhere, including backups?

SI-18(4) requires you to correct or delete PII upon request, but your implementation needs documented handling for systems where deletion is constrained, such as backups. Document your method and the approval for any limitation, and keep it tied to the request case. ¹

What counts as a “designated representative”?

The control allows requests by the individual or their designated representative, so you need a defined standard for acceptable proof of authority. Set the acceptable documents, require verification, and store the evidence with the case. ¹

Can we deny a request to delete if we need the data for operations?

SI-18(4) is written as “correct or delete” upon request, so any refusal should be treated as an exception that requires a documented rationale and an approval path. Keep the denial decision and communications as part of the evidence trail. ¹

How do we handle requests when multiple systems disagree on the “correct” value?

Establish a system-of-record rule per data element (for example, HR system for legal name, IAM directory for username) and document it in your procedure. Then correct downstream systems to match the system of record and record the propagation steps. ¹

Do third parties have to be included in the correction/deletion process?

If a third party stores or processes your PII, operationally you need a way to pass correction/deletion instructions and retain confirmation. Treat third parties as part of the data map and evidence package. ¹

What is the minimum evidence an auditor will accept?

A complete case file usually needs intake details, identity/authority verification, execution proof (change logs), and closure communication. Pair those cases with a documented procedure and named owner. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5