SAP data archiving is not simply a storage exercise. It changes where business records live, how users retrieve them and when they can be destroyed. A defensible programme therefore connects legal requirements, records policy, SAP lifecycle controls, security and evidence of correct operation.

Important: This article provides general information, not legal advice. Retention, privacy, tax, employment, sector and litigation duties vary by jurisdiction and organisation. Have qualified legal, privacy, tax and records-management specialists approve the rules that apply to your data.

Start with obligations, not a generic retention period

There is no universal number of years for “SAP data.” A single SAP system may hold invoices, accounting documents, employee information, customer records, production evidence and attachments, each governed by different purposes and rules. Requirements may also differ by company code, country, product, contract or active dispute.

Build a retention schedule that identifies the record category, responsible owner, legal or business basis, triggering event, minimum or maximum period, relevant jurisdiction and approved disposition. The trigger matters: a period may run from transaction completion, contract termination, asset disposal or another defined event rather than the day data was created.

Do not translate a statute directly into an SAP setting without review. Counsel and records specialists should interpret the obligation; process owners should identify the relevant business records; SAP specialists should then map those records to archiving and ILM objects, residence rules, dependencies and storage.

Balance retention with privacy and minimisation

Keeping information indefinitely can create risk as well as cost. For organisations subject to the EU General Data Protection Regulation, Article 5 establishes principles including purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, while Article 5(2) makes the controller responsible for demonstrating compliance. Article 17 provides a right to erasure but also contains exceptions, including where processing is necessary for a legal obligation or for legal claims. The correct outcome is therefore context-dependent—not automatic deletion and not permanent retention.

An SAP archiving design should distinguish operational residence from legal retention. Moving a record out of the live database may reduce operational volume, but the archived information still exists and remains subject to applicable access, security, hold and disposition controls. Define why each category is retained, who may use it and what event makes it eligible for destruction.

Preserve records that are subject to a legal hold

Routine destruction may need to stop when litigation, an investigation or another preservation duty applies. The scope and trigger must be determined by the organisation’s legal team. Operationally, the process should identify affected information, apply the hold, prevent conflicting destruction, record approvals and release the hold only through an authorised workflow.

SAP documents legal holds as part of ILM Retention Management. In the documented model, held data is protected from destruction even after its retention period has expired. SAP also advises checking audit-area assignments, rule evaluation and existing legal holds for each ILM object. That capability still requires governance: named case owners, reliable scope criteria, monitoring and evidence that holds reached all relevant data and connected documents.

Maintain authenticity, integrity and business context

A retained file has limited value if reviewers cannot understand or trust it. Preserve enough context to interpret the record: key master data, organisational structures, currencies, units, status meanings, document relationships, attachments and relevant configuration snapshots. Custom tables and fields require explicit mapping; they should not be assumed to be covered by a standard archiving object.

Controls should support traceability from the source to the archive and, where applicable, to reports supplied for an audit or inquiry. Useful evidence can include source counts and totals, archive-session logs, exception reports, checksums, transfer records, configuration approvals and user-acceptance results. Reconciliation should be designed around meaningful business objects and balances, not only file counts.

As one jurisdiction-specific example, the US Internal Revenue Service states that a business recordkeeping system should clearly show income and expenses and that records must be kept as long as needed to substantiate tax-return items. Its guidance for machine-sensible records also addresses audit trails, documentation, integrity and accessibility. These US sources are not a global retention schedule; they illustrate why tax and audit requirements must be mapped to the organisation’s actual records and locations.

Protect archived data throughout its lifecycle

Archived does not mean offline, anonymous or automatically secure. Apply controls proportionate to sensitivity and risk across ingestion, storage, retrieval, export, backup and destruction. A practical control set normally considers:

  • role-based access and segregation of duties for administrators, report users and disposition approvers;
  • strong authentication and periodic access review;
  • encryption in transit and at rest, with governed key management;
  • tamper-evident logging of searches, views, exports, policy changes, holds and destruction;
  • backup, recovery and integrity testing matched to the required availability;
  • controlled exports, including handling of personal or confidential information; and
  • secure, verifiable destruction across primary storage, replicas and backups under an approved policy.

For personal data within its scope, GDPR Article 32 requires controllers and processors to consider appropriate technical and organisational measures based on risk, including measures related to confidentiality, integrity, availability, resilience and testing. The ArchiveHub security overview explains related platform controls, but no product alone makes an organisation compliant.

Design retrieval before removing the source system

Retention without usable retrieval may fail the business purpose. Define who must answer tax, audit, customer, employee and operational questions; what evidence they need; how quickly it must be produced; and which relationships and attachments must remain navigable. Test representative scenarios with business owners before decommissioning or removing legacy access.

Access should remain constrained to the approved purpose. A broad reporting role created for convenience may expose more historical information than a user needs. Conversely, an archive that only specialists can query may create delays and reliance on the retired application. The target design should balance usability, least privilege and evidentiary quality.

Operate retention and destruction as controlled processes

SAP ILM can evaluate time-based policies, account for legal holds and support destruction when the applicable period has expired. Configuration is only one part of the control environment. Assign accountable policy owners, require approval for rule changes, test policy outcomes, monitor exceptions and retain evidence of each authorised destruction run.

Revalidate the schedule when laws, business activities, corporate structures or systems change. Also plan for technology obsolescence: retained records must remain readable and interpretable for the required period. Migration to new storage or reporting technology should preserve integrity, metadata, permissions and audit history.

A practical governance checklist

  1. Inventory: classify SAP data, documents, custom content, interfaces and jurisdictions.
  2. Approve: obtain documented legal, privacy, tax, records and business decisions.
  3. Map: connect record categories and triggers to SAP objects, repositories and reports.
  4. Control: design access, security, holds, audit evidence and separation of duties.
  5. Validate: reconcile migrated information and test real retrieval scenarios.
  6. Dispose: destroy only after eligibility, hold checks and approval are confirmed.
  7. Review: reassess rules, access and recoverability on a defined cycle.

Use the SAP data archiving guide for the wider lifecycle, the application retirement overview when planning shutdown, and the ArchiveHub assessment to structure discovery and requirements.

Official and authoritative references