SI-18(5): Notice of Correction or Deletion

SI-18(5) sits in the NIST SP 800-53 Rev. 5 “System and Information Integrity” family, but it is operationally a privacy notice control: if you correct or delete someone’s PII, you must tell the right internal parties and the individual. This control is easy to “say yes to” and still fail in an assessment because teams often implement the correction/deletion work while leaving notifications informal, manual, or inconsistent across systems and third parties.

As a CCO, compliance officer, or GRC lead, your goal is to make SI-18(5) predictable under pressure: requests arrive via multiple channels, records live in multiple systems, and changes may be executed by IT ops, application owners, HR, or a third party. The fastest path to defensibility is to (1) define the recipients and the trigger, (2) standardize the notification content and delivery methods, and (3) retain artifacts that show end-to-end completion.

This page gives requirement-level implementation guidance you can hand to control owners, privacy operations, and engineering without turning it into a theory exercise, while staying aligned to NIST SP 800-53 Rev. 5. ¹

Regulatory text

Excerpt (SI-18(5)): “Notify {{ insert: param, si-18.05_odp }} and individuals that the personally identifiable information has been corrected or deleted.” ²

Operator interpretation of the excerpt

You must do two notifications after the PII change is actually executed:

1. Notify a defined set of recipients represented by the organization-defined parameter (“{{ insert: param, si-18.05_odp }}”). In practice, this is typically privacy operations, the system owner, a records office, a help desk function, or a case-management queue. Your job is to define it and make it consistent.
2. Notify the individual whose PII was corrected or deleted, using an approved method that is appropriate to the channel and identity assurance you have.

Assessors will look for proof that the notifications are part of the operational workflow, not a best-effort email when someone remembers.

Plain-English requirement (what SI-18(5) expects)

When your organization changes someone’s PII because it was wrong or because it should be removed, you must:

• Tell the people inside your organization who need to know (so downstream users stop relying on incorrect data and operational teams don’t “recreate” deleted data).
• Tell the person affected (so they understand what happened to their data and can respond if something is incomplete or incorrect).

This is a repeatable process requirement. One-off success does not pass a program assessment if you cannot show it works across cases and systems. ³

Who it applies to

Entity scope

• Federal information systems and organizations using NIST SP 800-53 Rev. 5 as a required or contractual baseline. ³
• Contractor systems handling federal data where 800-53 controls are flowed down via contract, ATO boundary, or program security requirements. ³

Operational scope (where this shows up)

• Privacy rights workflows (correction requests, deletion requests).
• Data quality remediation (internal discovery that PII is inaccurate).
• Incident response or breach remediation that includes PII correction or deletion.
• Record retention actions that delete PII and require notice under your internal rules or program commitments.
• Third party processing where a third party corrects/deletes PII on your behalf and you remain accountable for notification execution and evidence.

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

Step 1: Define the parameter (“si-18.05_odp”) recipients

Create a written definition of who must be notified internally. Keep it crisp and role-based. Examples:

• Privacy Office case queue
• System owner of the authoritative data store
• Data steward / data governance mailbox
• Records management (if deletion intersects retention holds)
• Security operations (only if your policy requires awareness of privacy-affecting changes)

Make this definition part of the control narrative and your operating procedure. ²

Step 2: Establish the trigger condition

Define the trigger as: “PII corrected or deleted in a system of record (or downstream replica) and the change is committed.”
Avoid triggering on intake or approval alone. If you notify before execution, you will create false positives that are hard to defend in evidence.

Step 3: Build a single workflow that binds request → change → notice

You need a case or ticket object that can store: requester identity, data elements affected, systems touched, completion timestamps, and outbound notice details. Common implementation options:

• Privacy case management system
• GRC workflow with privacy request module
• ITSM ticketing integrated with data owners
• A documented manual workflow with strict templates and logging (acceptable, but brittle)

Daydream is often a practical fit here because it can map SI-18(5) to an owner, an implementation procedure, and recurring evidence artifacts so you stop rebuilding proof every audit cycle. ²

Step 4: Standardize notice content (internal and external)

Create two templates:

A. Internal notice template (to “si-18.05_odp” recipients)
Include: case ID, systems updated, data elements changed, effective date/time, and any operational instructions (“do not reintroduce from source X,” “sync downstream cache Y”).

B. Individual notice template (to the data subject)
Include: confirmation that correction or deletion occurred, high-level description of what changed, what remains (if partial deletion), how to dispute, and a reference to the request/case ID. Avoid including sensitive data in the notice itself unless your delivery method and identity assurance support it.

Step 5: Execute notices with a controlled delivery method

Pick delivery channels you can evidence. Examples:

• Portal message with authenticated access
• Email with logging and retention controls
• Postal mail logged in the case (for higher assurance contexts)
• Secure messaging if you already run that channel for individuals

Align the method to your identity proofing and contact data quality. If you cannot reliably reach the individual, document your attempts and the fallback method in the procedure.

Step 6: Handle downstream systems and third parties explicitly

Your procedure must answer:

• If PII is corrected in the system of record, how do downstream copies get corrected?
• If PII is deleted, how do you prevent rehydration from a third party feed or an internal archive?
• If a third party holds the PII, who sends the individual notice: you, the third party, or both?

Contractually, you want the third party to: (1) confirm completion, (2) provide execution logs, and (3) support your notice obligations with timestamps and scope statements.

Step 7: Make it assessable (control owner + cadence)

Assign a control owner (typically privacy ops or the system privacy lead), then define how you will periodically prove the workflow operates. A common pattern: sample closed cases and confirm that execution evidence exists for both notifications.

Required evidence and artifacts to retain

Retain artifacts that prove the change and the notice:

Core artifacts (minimum set)

• Procedure / SOP for correction/deletion and notifications, including the defined “si-18.05_odp” recipients. ²
• Case records showing request intake, identity verification (if applicable), approval, execution steps, completion date/time.
• System evidence of correction/deletion (before/after snapshot where appropriate, change log entry, database audit log, admin action log).
• Internal notice evidence (email header + body, ticket comment, workflow notification log) tied to the case ID.
• Individual notice evidence (copy of message, delivery log, portal notification record, mail log) tied to the case ID.
• Exception records for failed delivery attempts and alternate actions.

Nice-to-have artifacts that reduce audit friction

• Data map showing systems of record vs downstream replicas (helps prove you notified the right internal recipients).
• Third party attestations or completion reports for corrections/deletions executed outside your boundary.
• A control-to-evidence matrix (what evidence is produced per case, where it is stored, retention period).

Common exam/audit questions and hangups

Assessors tend to drill into these points:

• “Who is the organization-defined recipient set (‘si-18.05_odp’) and where is it documented?” ²
• “Show me a sample of completed cases and the actual notices sent to individuals.”
• “How do you know the correction/deletion occurred in all relevant systems, not just one application?”
• “What happens if the individual cannot be reached?”
• “How do you prevent deleted data from being repopulated from backups, exports, or third party sources?”
• “Where are logs stored and how do you ensure they are immutable enough for audit purposes?”

Hangup pattern: teams provide a policy statement but cannot produce transaction-level evidence that a notice was sent for a specific correction/deletion event.

Frequent implementation mistakes (and how to avoid them)

1. Undefined “si-18.05_odp” recipients.

   • Fix: write the roles/groups into the SOP and route notices via a named queue or distribution list. ²

2. Notifying on approval, not on completion.

   • Fix: workflow gate where “send notice” is locked until system evidence is attached.

3. No linkage between the case and the notice artifact.

   • Fix: require a case ID in subject lines, portal message metadata, or ticket references.

4. Partial deletion without explaining what remains.

   • Fix: template language for scoped deletion, and an internal checklist of systems excluded (with reason).

5. Third party execution with no proof.

   • Fix: add contract clauses for completion confirmation and audit logs; store third party confirmations in the case.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SI-18(5), so you should treat this as an assessment-readiness and trust control rather than a directly “fine-driven” requirement in this dataset. The operational risk is still real: failure to notify creates data quality failures downstream, repeat corrections, and customer/employee disputes that become audit findings and program risk in federal environments. ³

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable control)

• Name the control owner and backups.
• Define “si-18.05_odp” recipients and publish the SOP section. ²
• Create templates for internal notice and individual notice.
• Pick the system of record for case tracking (privacy case tool, ITSM, or GRC workflow).
• Run a small set of test cases end-to-end and verify you can produce evidence in one place.

Days 31–60 (integrate and reduce manual work)

• Integrate the workflow with the primary systems where PII is corrected/deleted (at least ticket references and timestamps).
• Add required fields: systems touched, data elements affected, completion proof, notice proof.
• Define exception handling for unreachable individuals and document it.
• If third parties process PII, update due diligence and contracts to require completion confirmations and logs.

Days 61–90 (make it durable for audits)

• Implement sampling and internal QA (periodic review of closed cases for complete evidence).
• Build a control-to-evidence matrix and standard audit packet.
• Train service desk, privacy ops, and system owners on the “do not close until notice evidence is attached” rule.
• If you use Daydream, map SI-18(5) to the owner, procedure, and recurring evidence artifacts so your audit packet is generated consistently across cycles. ²

Frequently Asked Questions

What counts as “notice” for SI-18(5)?

SI-18(5) requires notifying both defined internal recipients and the individual that PII was corrected or deleted. In practice, notice should be a logged, reproducible communication tied to a case ID and sent after the change is completed. ²

Who should we set as “{{ insert: param, si-18.05_odp }}”?

Make it role-based and aligned to your operating model, such as privacy operations plus the system owner or data steward for the system of record. Document the roles/groups in the procedure so it is stable even when personnel change. ²

Do we need to notify the individual if the deletion was required by retention policy?

SI-18(5) is triggered when PII is corrected or deleted; your procedure should define which deletion scenarios are in scope and how you handle conflicts (for example, legal holds). If you exclude certain scenarios, document the rationale and keep it consistent.

What if we corrected PII in one system but can’t find all downstream copies?

Treat this as a workflow failure until you can either correct the downstream copies or document compensating actions (for example, disabling the feed or flagging the record). Your internal notification should include operational instructions to prevent reintroduction.

Can a third party send the notice to the individual on our behalf?

They can, but you still need evidence that notice was sent and that it matches your requirements and templates. Put the responsibility, timing, and proof requirements into the contract and store the third party’s confirmation in your case file.

What evidence do auditors usually accept as proof of notice?

Auditors typically accept an export or screenshot from the case system showing the notice content plus delivery metadata, or retained email with headers and timestamps, as long as it is linked to the correction/deletion completion evidence. The key is traceability from case → change → notice.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5