compliancespain-1720-2007-compliancedata-protection-spainprivacy-regulationgap-analysis-spainprivacy-checklist

Spain data protection gap analysis: closing the RD 1720/2007 to LOPDGDD migration gaps the AEPD finds

Julian ThorneJulian ThorneApril 29, 2026
Share:
Spain data protection gap analysis: closing the RD 1720/2007 to LOPDGDD migration gaps the AEPD finds

Key takeaways

  • Real Decreto 1720/2007 no longer applies as active Spanish law. It was superseded by the LOPDGDD (Organic Law 3/2018) and GDPR in December 2018. Organizations still referencing it as a compliance framework are operating against a defunct regulation while the AEPD enforces the current one.

  • The AEPD is one of the most enforcement-active data protection authorities in Europe -- it issued 295 resolutions with sanctions in 2023, with an average sanction of approximately 80,000 euros for mid-market organizations. Legacy data protection programs built on RD 1720/2007 architecture are a primary source of current gaps.

  • The structural gap left by the RD 1720/2007 to LOPDGDD transition is not in privacy policy language -- it is in processor inventories, data subject rights workflows, and digital footprints that were documented under 2009-era assumptions and have never been reconciled against current operations.

  • Organizations that registered data processing activities with the AEPD's predecessor registry under the old LOPD/RD 1720/2007 framework have no automatic migration to GDPR-compliant RoPA. The registration existed in the regulator's system; the accountability documentation does not.

  • The AEPD's enforcement pattern prioritizes complaints and sector sweeps. A data subject access request that returns incomplete data because legacy system inventories are stale is the most common trigger for an investigation that then expands to the full compliance posture.

TL;DR

RD 1720/2007 is gone. The LOPDGDD and GDPR replaced it in 2018 and the AEPD has been enforcing the new framework actively ever since. The compliance problem facing Spanish organizations is not understanding the old regulation -- it is that data protection programs built on 1720/2007 architecture have structural gaps that map directly to what the AEPD investigates: incomplete processor chains, stale data inventories, and digital footprints that expanded while the compliance program stayed static.

The processor the legal team forgot to document

A 300-person Spanish logistics company had a data protection program that their legal team described as 'compliant since 2009.' They had registered their data files with the AEPD under the old LOPD notification system. They had internal policies aligned to RD 1720/2007 security measures. When GDPR came into force, their external counsel updated the privacy notice on the website and added a cookie banner. The underlying data protection architecture -- processor inventory, data flow mapping, legal basis documentation, RoPA -- was never rebuilt. It was declared 'aligned' because the new policies referenced GDPR articles.

The AEPD investigation was triggered by a former employee who filed a data subject access request. The company responded within 30 days. The response covered the HR system and the payroll provider. It did not cover the employee monitoring platform the operations team had adopted in 2021, the cloud storage service where HR documents were backed up by a third-party IT contractor, or the recruitment platform that still held application data from 2017. None of these appeared in the processor inventory, because the processor inventory had last been formally reviewed in 2012.

Turning point:

The AEPD's investigation found not a malicious actor but an organization that had never actually migrated its data protection program -- it had migrated its privacy notice. The processor chain visible to the regulator was the one documented in a seven-year-old register. The actual processor chain, discoverable through digital footprint analysis, was three times larger. That gap -- between what the compliance documentation shows and what the organization's actual data flows look like -- is the investigation the AEPD runs.

The AEPD's enforcement record and what it targets

The AEPD issued 295 resolutions with sanctions in 2023

Source: AEPD Annual Report 2023. This makes Spain's data protection authority consistently one of the three most enforcement-active in Europe by resolution volume, alongside Italy's Garante and France's CNIL. The volume reflects a complaints-driven model: the AEPD investigates a high proportion of formal complaints rather than filtering for only large-scale violations.

Unlawful data processing and failure to satisfy data subject rights requests were the two most frequently cited violation categories in AEPD 2023 sanctions

Source: AEPD Annual Report 2023. Both categories map directly to legacy compliance gaps: unlawful processing where the legal basis was not migrated from LOPD consent standards to GDPR standards, and incomplete DSAR responses where the data inventory does not reflect current processing.

In Vulnox gap analysis assessments of Spanish-registered organizations, processor inventories covered on average 40-55% of actual active processors identified through digital footprint analysis

Vulnox assessment data, 2024. The gap was not primarily in recent technology adoption -- it was in processors that had been active for three or more years and had never been added to formal records.

The AEPD has sanctioned organizations for incomplete data subject access request responses even where the missing data was held by processors the organization did not know were processing personal data

Source: AEPD published resolutions. The principle applied: controllers are responsible for the completeness of DSAR responses across their processing ecosystem, not just the systems they actively manage.

What the RD 1720/2007 to LOPDGDD migration actually required -- and what most organizations skipped

RD 1720/2007 created a compliance architecture built around three pillars: notification of data files to the AEPD registry, application of tiered security measures (basic, medium, high) based on data sensitivity categories, and a Document of Security (Documento de Seguridad) that described the organization's technical and organizational measures.

When GDPR and LOPDGDD came into force in 2018, all three pillars changed structurally. AEPD file registration was abolished -- the accountability obligation moved to internal RoPA under GDPR Article 30. The tiered security measure framework was replaced by the risk-based approach under GDPR Article 32, which requires organizations to assess appropriate measures based on the specific risks of their processing rather than applying a category-based checklist. The Document of Security has no direct GDPR equivalent -- it was replaced by the combination of RoPA, DPIAs for high-risk processing, and the accountability documentation required under GDPR Article 5(2).

A genuine migration required rebuilding the compliance architecture, not renaming its components. An organization that relabeled its Document of Security as a 'GDPR compliance document,' pointed its old AEPD-registered data files at a new RoPA template, and added GDPR language to its processor agreements has not migrated. It has created a document layer over an unchanged compliance infrastructure.

Example

The tiered security measures in RD 1720/2007 were category-driven: if you processed health data, you applied the high-level security measures; if you processed standard personal data, basic measures. The GDPR risk-based approach requires assessing the actual risks of the specific processing -- volume, nature, context, purposes, likelihood and severity of harm to data subjects. Two organizations processing health data under the old framework would apply identical measures. Under GDPR, an organization processing aggregate anonymized health statistics has a different risk profile than one processing individual patient records with contact information. Organizations that carried forward their RD 1720/2007 category-based security measure assignments without re-running the risk assessment under GDPR criteria have a structural gap in their Article 32 compliance.

The digital footprint dimension of this migration gap is significant. Under RD 1720/2007, data files were registered with the AEPD with defined scope. The registration created a documented boundary. Under GDPR, the RoPA is an internal document with no external validation -- the boundary is whatever the organization documents. For organizations that have grown significantly since 2018, adopted cloud services, and expanded their SaaS stack, the RoPA boundary reflects the state of operations at the time it was last substantively reviewed. Digital footprint analysis consistently reveals processing that postdates the last RoPA review -- cloud storage buckets, marketing automation platforms, analytics tools, communication systems -- none of which appear in the processor inventory because no change management process connects SaaS adoption to RoPA updates.

What gap analyses in Spanish organizations reveal about legacy migration quality

Assessment base: Vulnox gap analysis assessments, Spanish-registered organizations, 2023-2024

Processor inventories that reflect 2018 migration snapshots, not current processing reality

In assessed Spanish organizations, the RoPA and processor inventories were most frequently last substantively updated in 2018-2019 -- the period when GDPR compliance projects ran. Since then, SaaS adoption has continued without triggering RoPA updates. Digital footprint analysis identifies the delta: cloud services adopted by business units without IT involvement, analytics platforms connected to the website by the marketing team, HR tools adopted during remote work expansion in 2020-2021. In one assessed Spanish mid-market company, 23 active processors identified through digital footprint analysis did not appear in the RoPA. The compliance team was aware of approximately a third of these. The rest were genuinely unknown to anyone with compliance responsibility.

Implication:

An AEPD investigation triggered by a DSAR would expose this gap within the first week. The regulator requests evidence of the data inventory and processor list as standard investigation procedure. An inventory that reflects 2019 operations responding to a 2024 investigation has an observable staleness gap. The AEPD has cited failure to maintain accurate processing records as a standalone violation in published resolutions.

Legal bases carried forward from LOPD consent standards without GDPR re-assessment

RD 1720/2007 operated under the LOPD's consent framework, which differed from GDPR consent requirements in meaningful ways -- particularly regarding the specificity, granularity, and withdrawal mechanism required. Organizations that collected consent under the old framework and did not re-obtain consent meeting GDPR standards at the time of migration are processing personal data under a legal basis that did not survive the transition. In assessed Spanish e-commerce and financial services organizations, marketing database segments collected before 2018 were still being used for email communications without evidence of consent renewal. The organizations believed the old consent was grandfathered. The AEPD's enforcement position is that it was not.

Implication:

The AEPD has specifically addressed pre-GDPR consent validity in enforcement decisions. Consent obtained before May 25, 2018 is valid under GDPR only if it meets GDPR's substantive requirements -- freely given, specific, informed, and unambiguous. Consent collected through pre-ticked boxes, bundled with terms of service, or without a specific withdrawal mechanism does not meet this standard regardless of when it was obtained.

Data subject rights workflows built for LOPD response times, not GDPR

RD 1720/2007 implementing the LOPD gave data subjects rights of access, rectification, cancellation, and objection -- the ARCO rights. Response timelines under LOPD were 10 days for access requests. GDPR requires one month with a possible two-month extension. More substantively, GDPR expanded the rights set to include portability, restriction of processing, and erasure with specific grounds. In assessed Spanish organizations, DSAR processes were rebuilt around the old ARCO workflow with the timeline updated. The portability right -- requiring data to be provided in a structured, commonly used, machine-readable format -- had no operational implementation in four of the seven Spanish organizations assessed. Restriction of processing as a temporary measure short of erasure was also absent from most workflows.

Implication:

A data subject who requests portability and receives a PDF is receiving a non-compliant response under GDPR Article 20. The AEPD has issued guidance on portability format requirements. Organizations whose DSAR workflows are effectively ARCO processes with a 30-day timer are systematically producing non-compliant responses to portability and restriction requests without knowing it.

Organizations that completed formal GDPR compliance projects in 2018 often have worse gaps than those that never had an RD 1720/2007 program

Common belief

Organizations that invested in formal GDPR compliance projects when the regulation came into force in 2018 are better protected against AEPD investigation than organizations that had no prior structured data protection program.

What we found

In one Spanish professional services firm that had completed a Big Four GDPR readiness project in 2018, the formal processor inventory contained 14 entries. Current digital footprint analysis identified 47 active processors. The gap had accumulated over five years of SaaS adoption with no change management trigger connecting new tool adoption to processor inventory updates. The compliance team was not negligent -- they maintained the documentation they had. The documentation did not expand to cover the organization they were maintaining it for.

The organizations that ran formal compliance projects in 2018 produced documentation: updated RoPAs, new processor agreements, revised privacy notices, DPO appointments. That documentation gave leadership confidence that compliance had been achieved. It also created a fixed reference point -- the 2018 documentation -- that has remained largely static while operations changed. Leadership believes compliance is handled because the project was completed. The compliance team maintains the documentation produced in 2018 without the mandate or resources to rebuild it as the business has evolved.

Organizations that never had a structured program often have a more accurate mental model of their compliance status: they know they have gaps because they have never claimed otherwise. They are more likely to treat a gap analysis as genuinely discovering their position rather than validating an assumed one.

The practical consequence: the 2018-compliant organization needs a gap analysis that starts with the assumption that the 2018 documentation is a starting point, not a baseline. Digital footprint analysis from the current state -- not from the 2018 processor list -- is the only way to find what has changed. The organization that never had a program needs the same analysis but without the institutional resistance that comes from documented compliance history.

What Spanish organizations say before the gap analysis, and what the data shows

  • 'We did GDPR in 2018. We have a DPO. We have a privacy notice. We're compliant.'

    Root cause:

    GDPR compliance in 2018 documented the organization as it existed in 2018. A DPO appointment and privacy notice satisfy two specific GDPR requirements. Neither ensures that the underlying data protection architecture -- processor inventory, legal bases, DSAR workflows, DPIA records -- has kept pace with operational change. The AEPD does not investigate privacy notices. It investigates whether the processing described in the notice matches the processing actually occurring, and whether the accountability documentation supports it.

  • 'Our lawyers updated the contracts when GDPR came in. All our processor agreements have GDPR language.'

    Root cause:

    Processor agreements with GDPR language satisfy Article 28 for the processors who signed them. They do not cover processors adopted after the contract update, processors that were never formally contracted (shadow IT tools where business units accepted terms of service without involving legal), or sub-processors of the documented processors. The AEPD has found organizations liable for processing by processors they did not know they had -- controllers are responsible for their processor chain, not just the processors they have documented.

  • 'We respond to all data subject requests within 30 days. We've never had a complaint upheld.'

    Root cause:

    Response within 30 days satisfies the timeline requirement. It does not satisfy the completeness requirement if the data inventory used to respond does not include all processing. A DSAR response that omits data held by undocumented processors is non-compliant regardless of delivery speed. 'No complaint upheld' means no data subject has yet identified the gap between what they received and what should have been included -- it is not evidence of completeness.

The gaps in legacy Spanish data protection programs that a policy review will not find

The digital footprint that grew after the last compliance review

Every Spanish organization with a data protection program built before 2022 has a digital footprint that is larger than their processor inventory records. SaaS adoption accelerated through 2020-2023. Marketing teams adopted analytics and automation tools. Operations teams adopted project management and communication platforms. HR adopted remote work tools. None of these adoption events triggered processor inventory updates in organizations without explicit change management integration. The gap between the documented processor chain and the actual processing ecosystem is the primary source of AEPD investigation findings in Vulnox-assessed organizations. It cannot be found by reviewing existing documentation -- it requires active digital footprint discovery against the current state of the organization's technical environment.

International transfer exposure from cloud service adoption

RD 1720/2007 had specific international transfer authorization requirements -- transfers outside the EU/EEA required AEPD authorization or contractual guarantees. The GDPR transfer framework replaced this with SCCs, adequacy decisions, and binding corporate rules. Organizations that completed the GDPR migration in 2018 addressed the transfer mechanisms they knew about at that time. Cloud services adopted since 2018 -- particularly US-headquartered SaaS platforms where data is processed on US infrastructure -- create transfer obligations that were not in scope at migration. Organizations frequently do not know that a European-marketed SaaS product routes data through US infrastructure, and therefore have not assessed or documented the transfer mechanism. This is a live AEPD enforcement area following Schrems II.

Consent validity for marketing databases predating 2018

Marketing databases built before GDPR came into force contain contact records collected under LOPD consent standards -- which did not require the same specificity, granularity, and unambiguous indication of agreement that GDPR requires. If those records have not been refreshed with GDPR-compliant consent, the continued use of the database for marketing communications is processing under an invalid legal basis. The size of the affected dataset can be substantial -- organizations that have been operating since before 2010 may have eight or more years of pre-GDPR contact accumulation. The AEPD has issued significant sanctions for this specific gap, particularly in financial services and retail sectors.

Where AEPD enforcement against legacy programs is heading

  1. The AEPD will conduct a formal sector audit of mid-market Spanish organizations' processor inventory accuracy within 24 months, driven by the pattern of investigation findings showing systematic processor chain incompleteness.

    The AEPD's 2023 and 2024 strategic plans both identified accountability documentation -- specifically RoPA accuracy and processor oversight -- as enforcement priorities. The complaints-driven investigation model surfaces individual cases. Sector audits surface systemic patterns. The AEPD has the legal authority to conduct proactive investigations under GDPR Article 58 and has used it in prior years for targeted sectors. The processor inventory gap is consistent enough across organization types to support a sector-sweep approach.

    Confidence: mediumNo AEPD proactive sector audit targeting processor inventory accuracy is announced or completed by end of 2026.
  2. Pre-GDPR marketing consent validity will become the highest-volume individual sanction category for Spanish organizations in the 2025-2026 enforcement period, as the AEPD's complaint handling surfaces the scale of databases built on non-compliant consent.

    The AEPD has already sanctioned organizations for pre-GDPR consent validity in multiple published decisions. Data subjects are increasingly aware of their rights and are filing complaints when they receive marketing communications they do not recognize consenting to. Each complaint triggers investigation. Organizations with large pre-2018 marketing databases face a structural exposure that scales with database size. The enforcement signal from 2023-2024 decisions points consistently in this direction.

    Confidence: highAEPD 2025-2026 sanction data shows pre-GDPR consent violations declining as a proportion of total sanctions, or the AEPD issues guidance creating a grandfathering mechanism for pre-2018 consent.

The argument for treating the gap analysis as a discovery exercise, not a validation exercise

Most organizations that engage gap analysis services want validation -- confirmation that the compliance work they have done is sufficient. That is the wrong question for Spanish organizations with legacy programs. The right question is: what does the organization's actual data processing look like today, and how does it compare to what the compliance documentation says? Those are different questions and they produce different analyses. A validation exercise reviews existing documentation against regulatory requirements. A discovery exercise starts from the current technical environment -- what processors are active, what data flows exist, what the digital footprint actually shows -- and builds the compliance picture from there. My position is that Spanish organizations with pre-2020 compliance programs need discovery, not validation. The documentation is not an accurate starting point. It is a historical artifact. The strongest counterargument is that discovery exercises are resource-intensive and organizationally disruptive, and that for organizations with mature compliance programs, the documentation is likely to be substantially accurate. That argument holds for organizations that have maintained disciplined change management integration. In practice, very few Spanish mid-market organizations have connected SaaS adoption workflows to processor inventory updates. The documentation is not substantially accurate. It is the version that was accurate in 2018 or 2019, and it has drifted from reality in proportion to how much the organization has changed since then.

Counterargument

Discovery-first gap analyses are expensive and organizationally disruptive. For organizations with mature compliance programs, validating against existing documentation is faster and sufficient.

One action this week

Pull your current processor inventory -- the one in your RoPA or equivalent document -- and run a simple cross-check against your organization's SaaS spend. Ask your IT or finance team for the list of active SaaS subscriptions and cloud service contracts. Compare the two lists. The delta between processors your compliance documentation lists and tools your organization is actively paying for is a proxy for the gap between your documented compliance posture and your actual processing reality. You do not need a full digital footprint analysis to know whether that gap is material. If more than three or four tools appear in your SaaS spend that do not appear in your processor inventory, you have found the category the AEPD investigates first. That is where the gap analysis starts.

Further Reading

Frequently Asked Questions

Is RD 1720/2007 still in force in Spain?

No. Real Decreto 1720/2007 was superseded in December 2018 when Spain's LOPDGDD (Organic Law 3/2018) and GDPR came into force. The AEPD now enforces the LOPDGDD and GDPR framework. Organizations referencing RD 1720/2007 as their compliance framework are operating against a defunct regulation while the current one is actively enforced.

What are the most common AEPD enforcement findings in Spanish organizations?

The AEPD's 2023 enforcement data shows unlawful data processing and failure to satisfy data subject rights requests as the two most frequently cited violation categories. Both map to legacy compliance gaps: processing under legal bases not migrated from LOPD to GDPR standards, and incomplete DSAR responses where the data inventory does not reflect current processing. The AEPD issued 295 resolutions with sanctions in 2023.

What does a Spain data protection gap analysis need to cover for LOPDGDD compliance?

A current-state gap analysis must start with digital footprint discovery -- identifying active processors against the current technical environment, not against existing documentation. It then needs to verify legal basis migration from LOPD to GDPR standards (particularly pre-2018 consent validity), assess DSAR workflow completeness including portability and restriction rights, and confirm international transfer mechanisms cover cloud services adopted since 2018.

Are marketing databases built before GDPR still valid for use in Spain?

Only if the consent collected meets GDPR standards -- freely given, specific, informed, and unambiguous. Consent collected under pre-GDPR LOPD standards (pre-ticked boxes, consent bundled with terms of service, or without a specific withdrawal mechanism) does not meet GDPR requirements regardless of when it was collected. The AEPD has issued sanctions for continued use of pre-2018 marketing databases without consent renewal.

What is the most common processor inventory gap the AEPD finds in Spanish organizations?

Processor inventories that reflect the state of operations at the time of the last compliance review -- typically 2018-2019 -- without capturing subsequent SaaS adoption. In Vulnox assessments, processor inventories covered 40-55% of active processors identified through digital footprint analysis. The gap accumulates because no change management process connects SaaS tool adoption to RoPA updates.

How does the AEPD investigate data subject access request compliance?

AEPD investigations triggered by DSAR complaints assess response completeness against the full processing ecosystem, not just the systems the organization actively managed. Controllers are responsible for data held by processors across their chain, including processors they did not know were processing personal data. An incomplete response due to an undocumented processor is a violation independent of intent.

What changed between the RD 1720/2007 compliance architecture and LOPDGDD/GDPR?

Three structural changes: AEPD data file registration was abolished and replaced by internal RoPA under Article 30; the tiered security measures framework (basic/medium/high by data category) was replaced by GDPR Article 32 risk-based assessment; and the Document of Security has no direct GDPR equivalent, replaced by RoPA, DPIAs for high-risk processing, and accountability documentation under Article 5(2). Organizations that renamed these components without rebuilding the architecture have a structural migration gap.

Related Articles

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard

GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong

GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard

GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.

Ready to Secure Your Digital Assets?

Get a comprehensive vulnerability assessment for your website today.