Destructive Actions

Understanding Destructive Actions

FERIN is designed for persistence and traceability. However, some situations require removing or hiding content. This guide covers how to handle these cases properly.

Types of Destructive Actions

Invalidation vs Deletion

FERIN's preferred approach is invalidation, not deletion. Invalidated items remain in the register with their history preserved.

When to Invalidate

• Item contains errors that cannot be corrected
• Item was created based on incorrect information
• Item is superseded by a new item
• Item is no longer relevant or appropriate

When Deletion May Be Required

• Legal order requires removal
• GDPR right to erasure applies
• Sensitive data exposed in content
• Copyright or licensing violation

Redaction

Redaction removes specific content while preserving the record and its identifier. Use redaction when you need to hide content without breaking references.

Redaction Process

1. Identify content requiring redaction
2. Create proposal (if governed) with justification
3. Obtain approval from appropriate authority
4. Replace content with redaction marker
5. Preserve redaction metadata
6. Update search indexes

Redaction Record

{
  "id": "urn:example:item:abc123",
  "content": {
    "name": "Example Item",
    "description": "[REDACTED - Privacy concern - 2024-03-15]",
    "status": "valid"
  },
  "redactions": [
    {
      "date": "2024-03-15",
      "field": "description",
      "reason": "Privacy concern",
      "approvedBy": "Control Body",
      "proposalId": "prop-789"
    }
  ]
}

What to Redact

• Personal identifying information (PII)
• Confidential business information
• Security-sensitive details
• Legally protected content

Tombstoning

Tombstoning replaces an item with a minimal placeholder, preserving the identifier but removing all content. This is more aggressive than redaction but less than purging.

Tombstone Record

{
  "id": "urn:example:item:abc123",
  "status": "removed",
  "tombstone": {
    "date": "2024-03-15",
    "reason": "Legal order #12345",
    "removedBy": "Register Manager",
    "approvalRef": "legal-order-12345"
  },
  "content": null,
  "versions": []
}

When to Use Tombstoning

• Court order requires removal
• Severe content violation
• Security vulnerability in content
• Complete content removal required

Tombstone vs Purge

Purging

Purging completely removes an item and its history. This is the most destructive action and should be extremely rare.

When Purging Is Necessary

• GDPR right to erasure with no exceptions
• Court order explicitly requiring destruction
• Illegal content that must be completely removed

Purging Process

1. Obtain legal/compliance approval
2. Document justification thoroughly
3. Identify all copies and backups
4. Remove from primary database
5. Remove from backups (or mark for exclusion)
6. Remove from search indexes
7. Remove from caches
8. Update any foreign key references
9. Create purge audit record (separate from register)

Purge Audit Log

Maintain a separate, immutable log of all purges:

{
  "purgeId": "purge-2024-0001",
  "date": "2024-03-15T14:30:00Z",
  "itemId": "urn:example:item:abc123",
  "reason": "GDPR right to erasure request #789",
  "approvedBy": "Data Protection Officer",
  "executedBy": "Register Manager",
  "systemsPurged": [
    "primary-database",
    "search-index",
    "cache-layer"
  ],
  "backupsAffected": [
    "daily-backup-2024-03-14",
    "weekly-backup-2024-03-10"
  ],
  "legalBasis": "GDPR Article 17"
}

GDPR Considerations

The General Data Protection Regulation (GDPR) requires specific handling of personal data, including the right to erasure.

Right to Erasure (Article 17)

Individuals have the right to request deletion of their personal data when:

• Data is no longer necessary for original purpose
• Consent is withdrawn
• Data was unlawfully processed
• Legal obligation requires erasure

Exceptions

Erasure may not be required when data is needed for:

• Freedom of expression and information
• Compliance with legal obligation
• Public health purposes
• Archiving in the public interest
• Establishment, exercise, or defense of legal claims

Register-Specific Considerations

Safeguards

Implement these safeguards for destructive actions:

Technical Safeguards

• Role-based access: Only specific roles can execute destructive actions
• Approval workflow: Require second-person approval for destructive actions
• Soft delete first: Mark for deletion, purge later after confirmation
• Audit everything: Log all destructive actions immutably
• Backup verification: Confirm backups are appropriately handled

Process Safeguards

• Legal review: Require legal/compliance sign-off for purges
• Waiting period: Implement delay between request and execution
• Notification: Notify relevant parties before destructive actions
• Documentation: Require thorough justification documentation
• Regular review: Periodically review destructive action logs

Implementation Checklist

Related Topics

• Security - Data protection and access control
• Operations - Backup and recovery procedures
• Actions - Standard register actions
• Governance - Approval workflows