Blocking data does not mean moving it into a folder called «archive». Article 32 of the LOPDGDD (Spain's Organic Law on Data Protection and Digital Rights Guarantee) requires organisations to identify and set data aside once it is due for rectification or erasure, preventing any further processing or display except to make it available to judges, courts, the Public Prosecutor's Office or the competent administrations during the periods in which liability may still be claimed. Once those periods have elapsed, the data must be destroyed.
Erasure, retention and blocking
Before designing any procedure, it helps to distinguish the four stages a piece of personal data goes through over its lifecycle:
- Active use: the data is still needed for the purpose that justified processing it.
- Erasure: ordinary processing of the data stops.
- Blocking: the data is set aside temporarily because of possible liabilities arising from its processing.
- Destruction: the data is deleted once the relevant limitation period has expired.
Not all erased data needs to stay blocked for the same length of time: the period depends on the liabilities that apply in each case.
When blocking applies
Blocking is triggered when a piece of data is rectified or erased, whether at the data subject's request or on the controller's own initiative once the purpose or retention period has ended, in line with the criteria set by the AEPD (Spanish DPA). Common scenarios include:
- a customer account being closed;
- an employment contract ending;
- an invoice or a file being corrected;
- consent being withdrawn;
- an inaccurate piece of data being replaced;
- a service coming to an end.
Before blocking anything, check whether a legal obligation requires the data to stay in active use: you don't block what must legally keep being used.
What blocking allows
While a piece of data remains blocked, it may only be processed to address possible liabilities and to make it available to the competent authorities. Using it for marketing, analytics, operations or «just in case» is off the table. Access to blocked data must always be exceptional, justified and logged.
Retention table
| Category | Active use | Basis | Blocking | Destruction |
|---|---|---|---|---|
| Contract | Contractual relationship | Contract | Liabilities | End of period |
| Invoice | Tax obligation | Law | Liabilities | End of period |
| HR | Employment relationship/law | Contract/law | Employment/tax | End of period |
| Marketing | Applicable basis | Consent/legitimate interest | Claims | End of period |
| Incident | Incident management | Obligation/legitimate interest | Liabilities | End of period |
Periods must be documented both by rule and by specific case: there is no generic table that works as a universal safeguard.
Designing the blocking mechanism
Logical status
The record moves into a blocked status: it sits outside ordinary applications and only an exceptional role can access it.
Separate repository
The data is exported, encrypted, into a restricted file with a hash, a date and metadata, and removed from the production environment.
Secure copy
If the system does not support blocking, or adapting it would require disproportionate effort, Article 32.4 allows for a secure copy to be made with evidence of authenticity, date and non-manipulation. This option must be justified.
Technical requirements
A well-designed blocking procedure requires:
- an unambiguous marker for the blocked status;
- exclusion from internal searches;
- blocked access via API and blocked exports;
- separate access permissions;
- encryption;
- access logs;
- the date and reason for blocking;
- a calculated retention period;
- automatic or controlled destruction;
- preservation of data integrity.
A technical administrator should not be able to access this data as a matter of routine.
Backups
Backups complicate both erasure and blocking. A specific policy must be in place covering:
- limited retention;
- access restricted to recovery purposes only;
- not restoring blocked data as if it were active;
- reapplying the corresponding status after any restoration;
- expiry of backup copies;
- documentation of the process.
There is no need to alter a backup copy in a way that compromises its integrity if isolation and a defined lifecycle are in place, but it must be guaranteed that the data does not return to active use.
SaaS systems
The contract with the data processor must allow:
- marking or exporting blocked data;
- restricting access;
- applying the defined periods;
- deleting data;
- managing backup copies;
- providing evidence of compliance;
- shutting off sub-processor access.
If the provider does not support blocking, an alternative or an equivalent secure procedure must be assessed.
Rectification
When a piece of data is rectified, the previous value should only be kept blocked if it is needed to address liabilities, while the new value remains active. The application must not display both values as current at the same time: traceability must show which value is correct and since when.
Data subject rights
When an erasure request is received, the procedure should follow these steps:
- verify the requester's identity;
- assess how Article 17 GDPR applies;
- identify any existing retention obligations;
- stop ordinary use of the data;
- block the data where appropriate;
- respond to the data subject;
- destroy the data once the period has ended.
The response to the data subject can explain the restriction applied without needing to disclose sensitive internal controls.
Exceptional access
Every request from an authority must be validated and logged, recording:
- the requesting party;
- their competence;
- the legal basis for the request;
- its scope;
- the data provided;
- the date;
- the person responsible who authorised access.
The entire dataset should not be unblocked if handing over part of it is enough.
Retention periods
The blocking period is tied to the limitation period for liabilities arising from the processing and the applicable obligations. When several periods apply at once, the criterion followed must be documented, and any suspension or interruption of the period is handled whenever legally required. The system must never use the label «indefinite».
Destruction
Once the blocking period expires:
- the repository is deleted;
- storage media are destroyed according to the defined cycle;
- backup copies are closed off once they expire;
- execution is logged;
- a sample is verified;
- only the non-personal evidence needed to show that destruction took place is kept.
Governance
| Role | Responsibility |
|---|---|
| Legal / DPO | Legal criteria and oversight |
| Data owner | Defining category and purpose |
| IT | Technical implementation |
| Security | Access and integrity |
| Provider | Execution per instructions |
| Management | Resources and risk management |
Testing
Before signing off on a blocking procedure, it's worth checking that:
- an ordinary user cannot access blocked data;
- internal searches do not return it;
- the API does not expose it;
- exports do not include it;
- a competent authority can access it through the intended flow;
- restoring backups preserves the blocked status;
- destruction runs correctly;
- logs remain intact.
Common mistakes
- Mistaking blocking for simple archiving.
- Continuing to use blocked data for marketing.
- Keeping broad administrative access to blocked data.
- Applying a single period across all categories.
- Not setting a destruction date.
- Letting backups reactivate blocked data.
- Contracting SaaS systems without blocking capability.
- Displaying the old value after a rectification.
- Handing over more data than necessary to an authority.
- Destroying data without leaving evidence of the process.
Checklist
- Data categories and periods defined.
- Retention basis identified.
- Blocked status implemented.
- Exclusion from use and display guaranteed.
- Exceptional access procedure in place.
- Logs and integrity verified.
- Backup policy updated.
- Providers reviewed.
- Restoration tests carried out.
- Destruction process documented.
Frequently asked questions
Is blocking the same as deleting?
No. Blocking means setting the data aside temporarily, without ordinary use, to address possible liabilities.
Can the company still consult blocked data?
Only in the scenarios and for the limited purposes set out in Article 32.
How long does blocking last?
Until the applicable limitation periods end, set according to the data category and the relevant liability.
What if the system doesn't support blocking?
A secure copy can be made under the conditions of Article 32.4, justifying the decision and guaranteeing the data's integrity.
Official sources consulted
At Summum Consultoría we can help build your organisation's retention table and design the blocking procedure together with your IT team and your providers.