The right to erasure is a privacy obligation that allows an individual to request deletion of personal data under defined legal conditions. In blockchain environments, it is difficult to satisfy when data has been written permanently across distributed nodes and cannot be removed cleanly.
Expanded Definition
Right to erasure is a privacy right that lets a data subject ask for deletion of personal data when legal conditions are met, but it is not an absolute deletion guarantee. In practice, the request must be assessed against lawful retention duties, litigation holds, audit requirements, and technical constraints. In blockchain and other append-only systems, the concept becomes especially difficult because a record may be replicated across nodes and embedded in an immutable ledger.
Definitions vary across vendors and legal programs on whether erasure means physical deletion, cryptographic destruction, logical suppression, or irreversible anonymisation. NHI Management Group treats the term as a governance outcome: the organisation must be able to prove that personal data is no longer available for processing, even if the underlying architecture cannot literally erase every copy. That is why privacy engineering and data architecture must be aligned with principles such as data minimisation and retention control from the NIST Cybersecurity Framework 2.0. The most common misapplication is treating “delete” as a UI action that removes one visible record, which occurs when replicated backups, event logs, and downstream processors are not included in the erasure workflow.
Examples and Use Cases
Implementing right to erasure rigorously often introduces retention and integrity tradeoffs, requiring organisations to weigh privacy compliance against evidentiary preservation, operational continuity, and technical immutability.
- A customer submits a deletion request, and the organisation must remove profile data from production systems, analytics stores, and any secondary processors while retaining only legally required records.
- A blockchain-based application stores user references on-chain, so the design uses off-chain personal data storage and on-chain pointers to reduce the amount of irretrievable personal data.
- A SaaS platform receives a lawful erasure request and must propagate deletion into backups, caches, logs, and third-party integrations, not just the primary database.
- A privacy team documents a “suppression” or “tombstoning” pattern where direct identifiers are removed and residual records are rendered unusable, while acknowledging that some systems do not support true deletion.
- An identity platform that manages service accounts and API credentials reviews whether account metadata qualifies as personal data and whether retention rules conflict with deletion obligations, informed by the Ultimate Guide to NHIs and implementation guidance discussed in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Right to erasure matters in NHI security because service accounts, API keys, telemetry, and access logs can contain personal data or link back to identifiable users, creating retention obligations that cross identity, application, and infrastructure layers. If deletion requests are not mapped to the full NHI lifecycle, organisations can retain data longer than permitted, expose unnecessary records during incidents, or fail to prove that a request was completed. This becomes especially important where secrets, tokens, and access histories are tied to human-owned workflows. NHI Management Group notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes deletion and traceability harder to enforce in practice from the Ultimate Guide to NHIs.
Privacy teams also need to account for federated systems, backups, and audit trails, because erasure requests often surface long after the original collection event. The control problem is not just “can this record be deleted,” but “can every dependent copy be found, assessed, and handled consistently?” That operational burden aligns with broader governance expectations in the NIST Cybersecurity Framework 2.0. Organisations typically encounter the compliance gap only after a deletion request, subpoena, breach review, or regulator inquiry, at which point right to erasure becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Data retention and disposal controls support erasure obligations across systems. |
| NIST AI RMF | AI governance includes data lifecycle and minimisation considerations relevant to erasure. | |
| NIST SP 800-63 | CSP | Identity proofing and account recovery practices affect deletion and account closure workflows. |
| OWASP Non-Human Identity Top 10 | NHI-07 | NHI lifecycle hygiene includes offboarding and removal of related credentials and records. |
Revoke NHI credentials, purge references, and validate that dependent systems no longer process the data.
Related resources from NHI Mgmt Group
- What should teams get right when reviewing guest-to-host memory operations?
- How should organisations operationalize GDPR access and erasure requests through identity systems?
- How should teams attribute AI usage to the right cost centre?
- How should landlords and letting agents implement digital right to rent checks securely?
