Data Protection
A record can disappear from an application interface while remaining in a database replica, search index, log, export or backup. A technical deletion and retention assessment therefore follows the data lifecycle across storage classes and combines deletion testing with effective access analysis.
Short answer
The examination inventories primary stores, caches, replicas, archives, backups, logs and exports before evaluating deletion. It then determines which mechanism removes or marks records, when the effect reaches downstream copies and whether data remains recoverable or accessible through operational or administrative paths.
GDPR storage-limitation and security principles provide legal context, while NIST SP 800-53 and BSI logging guidance provide technical control references. The technical result does not decide the legally required retention period or whether a deletion obligation exists.
1. Inventory data locations and lifecycle states
Deletion scope depends on where copies exist
The examination maps primary databases, replicas, caches, search indexes, object stores, logs, analytics systems, exports and backup sets that can contain the relevant data. A field-level view may be necessary when only some attributes are replicated.
Lifecycle states such as active, archived, soft-deleted, expired and backup-only are distinguished. Application terminology can otherwise hide that a “deleted” record remains stored but excluded from ordinary queries.
The time relationship between those stores is important: asynchronous replication or delayed log rotation can create a period in which different systems show different deletion states.
2. Verify deletion mechanisms
A user-interface action is not sufficient evidence
The technical path from deletion request to database operation, queue message, scheduled cleanup or storage lifecycle rule is reconstructed. Code, queries, audit logs and controlled tests can show which mechanism is actually executed.
Soft deletion, anonymisation, key destruction and physical removal are technically different outcomes. The report uses precise language for the observed mechanism rather than treating all of them as equivalent “deletion”.
Where a deletion job runs asynchronously, the expected delay and evidence of completion are recorded. Failed jobs or downstream integration errors can leave residual copies even when the primary application reports success.
3. Examine retention, backups and restoration
A backup changes the technical meaning of residual availability
Retention settings are inspected in operational stores and backup systems. Rotation periods, immutable backup windows, archive tiers and snapshot schedules can determine how long older data remains technically recoverable.
A backup’s existence is distinguished from normal operational accessibility. Restoring data may require privileged procedures and may reintroduce records into an active system unless post-restore deletion processes exist.
Controlled restoration evidence can support whether data is recoverable from a particular backup class. The technical finding does not decide whether such retention is legally required or prohibited.
4. Determine roles and effective access
Configured roles and real access paths may differ
Users, groups, service accounts, database roles, cloud identities and emergency administrator paths are inventoried for the relevant stores. The assessment considers inherited permissions and machine-to-machine access as well as interactive users.
Effective permission is tested where safe and appropriate instead of inferred solely from policy documents. A user can lose access at the application layer while retaining database or export access through another role.
Logs can provide evidence of access events, but log completeness and retention limits should be stated. Absence of a log entry is not proof that no access occurred if the relevant source was not configured to record it.
5. Separate technical findings from legal retention or deletion duties
Technical state does not determine the legal requirement
The report can state that data remained stored, recoverable or accessible for a defined period and can identify the responsible technical mechanisms. It can also show which identities had effective access under the tested configuration.
Whether the data should have been deleted, whether a statutory or contractual retention obligation applied and whether access was legally authorised are separate legal questions.
The technical documentation is structured so that those questions can be assessed using reliable system facts without treating the technical finding as the legal conclusion itself.
6. Distinguish storage classes and residual accessibility
Residual data can have different practical accessibility
A record in an online database, an encrypted backup tape and an expired log awaiting physical overwrite are not equivalent states. The examination describes storage class, recovery path and access controls so that residual availability is not oversimplified.
Deletion verification can include targeted queries, storage lifecycle status, backup indexes and restore tests depending on scope. The level of assurance is tied to the tested layers.
The final statement therefore describes what was absent from normal operation, what remained stored or recoverable and what could not be verified within the examination boundary.
Is the technical conclusion sufficiently supported?
- Have all relevant storage classes and copies been inventoried?
- Is the actual deletion mechanism technically identified?
- Are soft deletion, anonymisation and physical removal distinguished?
- Are asynchronous cleanup and replication delays considered?
- Are backup retention and restoration paths documented?
- Are effective user, group and service-account permissions assessed?
- Are log coverage and retention limits stated when access evidence is used?
- Does the conclusion separate technical residual availability from legal retention or deletion duties?
Constructed example
A customer account is deleted through the application and disappears immediately from the primary user interface. The examination shows that the database record is soft-deleted, remains in an analytics export for seven days and is included in immutable daily backups for a defined rotation period.
The report records those storage states and the privileged roles capable of restoring the backup. It does not decide whether the seven-day export retention or backup period satisfies legal obligations.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Official primary legal source GDPR Article 5, including storage limitation and integrity and confidentiality principles. Legal interpretation remains separate from the technical examination. Open source.
- Official technical guidance NIST SP 800-53 Rev. 5, including Access Control, Identification and Authentication and other security control families relevant to effective access. Open source.
- Official technical guidance BSI IT-Grundschutz OPS.1.1.5 Protokollierung, used for technical context on collection, storage, protection and proper disposal of log data. Open source.
- Author methodology Sources and methodology of the knowledge base; primary storage, residual copies, backups and effective access are assessed as separate technical states.
Further reading
- Technical Reconstruction of Data Flows
- Technical Implementation of Data Minimisation
- Technical and Organisational Measures
- Pseudonymisation and Anonymisation
Critical review and methodological limitation
Deletion evidence must be interpreted by storage layer. A missing application record can coexist with technically recoverable backup or log copies, and those states should be described rather than compressed into a binary deleted/not-deleted result.
Access findings are similarly time-bound. Current role configuration does not prove historical access rights unless the relevant historical evidence is available.
- Lifecycle: map active, archived, soft-deleted and backup-only states.
- Access: include service accounts and privileged recovery paths, not only end-user roles.
- Legal boundary: report retention and accessibility without deciding the legally required period.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
Data Ethics & IT Compliance
Technical examination of documented data-protection, fairness, transparency and compliance-related implementation requirements.
Explore this assessment service