Where Regulation Meets the System.

I. What ILM Actually Covers

Information Lifecycle Management is not a synonym for GDPR compliance. It is a broader discipline — and in practice, it typically starts somewhere else entirely: with the question of what to do with data that nobody needs operationally but everybody is afraid to delete.

Sometimes this is about individual records. More often, particularly in the context of S/4HANA migrations, it is about decommissioning entire systems. A legacy ECC instance that has been running for fifteen years, accumulated across mergers and carve-outs, does not simply get switched off. The data — structured transaction records, ArchiveLink documents, print lists, unstructured attachments — must be extracted, converted according to ILM retention rules, and transferred to a Retention Warehouse where it remains accessible for audit and reporting while the original system is retired. The alternative is maintaining hundreds of legacy systems at significant cost: industry research puts the average at nearly six percent of total IT budget spent on underutilised applications alone.

Within these datasets, personal and non-personal data are almost always mixed. A decommissioned HR system contains employee records alongside organisational master data. A retired PM system holds maintenance histories that may reference individual technicians alongside equipment records with no personal reference at all. This coexistence is what makes ILM technically demanding — and what distinguishes it from a simple archiving exercise.

II. Where the Data Gets Sensitive — and Where It Doesn't

The sensitivity of data in an ILM context depends entirely on what kind of business generated it.

In infrastructure — rail, aviation, energy — the challenge is retention, not deletion. A railway wagon may operate for forty years or more. The maintenance records from its first decade must remain retrievable when a safety incident occurs in its fourth. Aviation components carry similar obligations. Here, the regulatory conflict runs in the opposite direction from GDPR: the requirement is to keep data available far beyond typical system lifespans, in formats that remain readable across technology generations. This is a retention and accessibility problem, and it applies primarily through the SAP PM module rather than RE-FX.

Banks and insurance funds face their own regulatory layers — FINMA requirements in Switzerland, BaFin expectations in Germany, sector-specific retention obligations that operate independently of and in addition to general data protection law.

In real estate, the picture is different. Pure real estate companies — residential landlords, student housing operators, any B2C model with natural persons as tenants — carry large volumes of personal data by nature. Applicant records, credit checks, tenant correspondence, dunning histories, service charge settlements: these are the data categories where GDPR and its equivalents apply with full force. The Business Partner, the FI-CA line items, the RE-FX contract objects — nearly everything in a residential lease-out landscape touches a natural person.

Commercial real estate — shopping centres, office landlords, retail lettings — operates differently. The tenant is typically a legal entity. The financial flows, service charge settlements, and contract data relate to companies, not individuals. Personal data exposure is structurally lower.

But there are edge cases. A sole proprietor running a shop in a retail complex — say, Confiserie Brunner as an Einzelfirma — is a natural person. Her business data is personal data under both the GDPR and the Swiss DSG. The moment that same business becomes Brunner Confiserie GmbH, the data protection classification changes: the Swiss DSG, since its revision effective September 2023, protects only natural persons, no longer legal entities. The GDPR never protected legal persons in the first place. A small distinction in corporate form with significant consequences for archiving and deletion rules.

III. The Regulatory Map

The GDPR is a regulation, not a directive — directly applicable in every EU Member State without transposition. The legal baseline for personal data protection is therefore identical whether a company operates from Frankfurt, Amsterdam, or Luxembourg.

What differs is enforcement. A CNIL investigation in France follows different procedural patterns than a BfDI audit in Germany or a CNPD review in Luxembourg. The Belgian DPA, the Gegevensbeschermingsautoriteit, has developed its own reputation for active enforcement. The obligations are the same; the scrutiny is not. This determines how defensible an organisation’s data retention configuration needs to be — not in theory, but in the jurisdiction where the next audit will happen.

Opening clauses permit Member States to deviate in narrowly defined areas: employee data protection, public interest processing, sector-specific retention obligations such as GoBD in Germany or the Code de Commerce in France. For real estate ERP landscapes, these deviations rarely affect the core archiving logic — but they dictate specific retention periods and the legal basis for processing tenant data.

Switzerland stands outside the EU but not outside the conversation. The revised Federal Act on Data Protection (DSG), effective since September 2023, was a direct legislative response to the GDPR — designed to maintain the Swiss adequacy decision and ensure the uninterrupted flow of personal data between Switzerland and the EU. The DSG aligns closely with the GDPR in structure and intent, but differs in specifics: sanctions are personal rather than corporate (up to CHF 250,000 against individuals), the appointment of a data protection advisor is voluntary, and — as noted — legal persons are no longer protected. For any organisation operating across both the EU and Switzerland, both frameworks must be addressed in parallel.

IV. What This Means in SAP

Translated into an SAP real estate landscape, the regulatory picture produces concrete technical requirements.

For residential and student housing operators, the majority of data is personal data. The deletion chain begins at the Business Partner and cascades through RE-FX contract objects, FI-CA line items, service charge settlement documents, and potentially PM orders linked to rental units. The sequence matters: archiving a Business Partner who still has open items in FI-CA does not produce a compliance event — it produces a system inconsistency that surfaces during period-end closing.

What often happens: organisations take the ILM project as an occasion to clean up the system. Years of accumulated data, orphaned objects, never-executed archiving runs — the ILM project becomes a data hygiene initiative by default. The four most common mistakes in ILM projects are described in detail in our widely cited article on Digital Real Estate perspectives. For organisations whose ILM scope intersects with RE-FX contract structures, see also our ERP Real Estate expertise page.

But there is a pragmatic path. Smaller, focused projects are well suited for organisations with high volumes of personal data — at minimum, to get the bulk of deletion-relevant records through the ILM process. Organisations that have already marked data in a preliminary project phase — flagging records that should be excluded from standard ILM retention rules — have a significant head start. Consider that a free tip. There are other small technical decisions early in the project that save days of effort later. We know what they are because we have made the mistakes that taught us.