Moving to SAP GRC 2026? Know Which Data Can Be Deleted in Your Current Version

Part 2 of the SAP GRC 2026 Migration Series. Follows "Migrating from Standalone SAP GRC to an Embedded Deployment: Why Delete, Archive, Then Migrate Is the Smarter Approach".

QUICK SUMMARY

The Delete to Archive to Migrate methodology answers what to do. This article answers which tables, which programs, and which archiving objects. Before moving to SAP GRC for SAP HANA (GRC 2026), GRC data falls into three technical classes. Regenerable output such as background risk analysis spool and repository synchronization snapshots can be deleted outright. 

Data such as access requests, MSMP workflow runtime, and Emergency Access Management logs must be archived under a retention policy. Configuration and master data must be preserved intact, because the upgrade path reuses it. 

Executive Summary

Part 1 of this series established why GRC cleanup must be carried out before migration rather than after it. This article provides the execution layer. It maps each phase of the Delete to Archive to Migrate methodology to the specific SAP GRC tables, standard programs, archiving objects, and SAP Notes involved, identifies three documented traps that destroy audit evidence or silently fail to free space, and sets out a six-month sequenced runbook. It also covers the Information Lifecycle Management route for personal data, which becomes a compliance obligation rather than a housekeeping preference once GDPR or similar data protection acts applies.

• Applies to: SAP Access Control 12.0, SAP Process Control 12.0, SAP Risk Management 12.0
• Target release: SAP GRC for SAP HANA 1.0 (GRC 2026)
• Migration scenario: Upgrade and Standalone to Embedded
• Primary Topics: Data Archiving, ILM, SARA, AOBJ, Housekeeping, Retention

Who Should Read This Article:

• SAP GRC Access Control Administrators executing the SAP GRC 2026 project
• SAP Basis Administrators responsible for sizing and downtime
• Internal Audit and Compliance teams approving data reduction
• Data Protection Officers (DPO) reviewing personal data retention in SAP GRC
• SAP S/4HANA migration teams planning conversion windows

Why Data Volume Becomes a Design Decision on HANA

SAP’s decision on having all the core applications in S/4HANA Foundation and cloud adoption changed the entire economics of retained data. The new SAP GRC 2026 is also part of this portfolio and runs exclusively on SAP HANA on top of SAP S/4HANA Foundation, which means every retained data moves from comparatively cheap disk into a priced, memory-resident footprint. 

Thus, the upgrade path from SAP GRC 12.0 depends on two mandatory prerequisites: the system must run on the SAP HANA database, so any system on a non-HANA database must complete a database migration first, and the underlying NetWeaver stack must be upgraded to SAP S/4HANA Foundation, which is an enhanced NetWeaver release rather than the full S/4HANA suite. 

SAP Note 3326989 sets mainstream maintenance for SAP Access Control 12.0, SAP Process Control 12.0, and SAP Risk Management 12.0 to the end of 2027, with extended maintenance to 2030. 

Two consequences follow. A heavy GRC 12.0 database directly extends conversion downtime and inflates HANA sizing. And in the standalone-to-embedded scenario covered in Part 1, where the move is treated as a merge rather than an in-place upgrade, what gets carried forward becomes an explicit scoping decision rather than an automatic outcome.

Cleanup decisions are audit decisions.. read this twice

Cleanup decisions in a GRC system are audit decisions, because the system being reduced is itself the control evidence repository. Four questions separate a defensible reduction from an evidence-destruction incident.

• Question 1 - Is the data reproducible from a source that still exists? Background risk analysis output, repository synchronizations, and management dashboards are derived artefacts. The authoritative source is the connected back-end plus the ruleset. Derived data is a Delete candidate.
• Question 2 - Is the data itself the audit evidence? Access request approvals, Firefighter session logs, and user access review sign-offs are the evidence. No back-end reproduces the approver, the timestamp, or the business justification. This is an Archive candidate, and is never a Delete candidate.
• Question 3 - Does a statutory or contractual retention period still apply? SOX, GxP, sector regulators, and internal audit charters commonly impose seven to ten years on access approval evidence. Retention overrides technical convenience.
• Question 4 - Does the data contain personal data that has passed its purpose? Access requests carry names, employee identifiers, email addresses, and manager relationships. Retaining personal data beyond its purpose is itself a finding, and SAP addresses this through Information Lifecycle Management (ILM) rather than ad hoc table deletion.

Delete: Data That Can Be Removed Outright

Background Risk Analysis Spool

Batch risk analysis results are the single largest contributor to GRC database growth in most landscapes. SAP KBA 2739079 documents the GRAC_DELETE_REPORT_SPOOL job, which addresses report spool for Access Risk Analysis, Access Request, Enterprise Role Management, and Superuser Privilege Management, covering tables GRACSODREPDATA and GRACSODREPINDEX. 

The trade-off must be communicated before execution. Where the job runs for a given application type, background risk analysis results are removed and the corresponding risk analysis reports are no longer viewable, which also affects historical dashboard content drawn from GRACSODREPDATA, GRACSODREPSTATUS, and GRACSODREPINDEX. 

The mitigation is straightforward. Run and export a full point-in-time violation report, store it as a signed artefact outside the GRC database, then clear the spool. Without that baseline, there is no way to demonstrate after go-live that the migration introduced no new risk.

Repository Synchronization Data

Synchronization data divides into two classes and deletion or archiving decisions must be made carefully. 

Replicated repository data is rebuildable. Users, roles, profiles, actions, and permission values are copies of objects that still exist in the connected back-end/plug-in systems. Tables such as GRACPERMFLDVAL, GRACACTPERMSYS, and GRACPERMFLDVALG fall under synchronization data per SAP Note 2268795 and are repopulated by the authorization sync jobs. 

NOTE: Practitioner guidance cautions that a large share of GRC reporting is built on synchronization data, so deleting it leaves those reports empty until a full resynchronization completes. 

This class is deletable, but only where the full sync chain has been timed end-to-end and proven to fit the available window. Full authorization sync on a large landscape is usually takes huge time.

Usage data is not rebuildable, and this is the exception that matters most. Action usage and role usage data is harvested rather than replicated. The sync job reads from STAD, workload statistics, and the SWNCMONI aggregates in the plug-in systems, which carry short retention capabilities - usually days for raw statistics and months for aggregates. A resync recovers only what the back-end still holds, which means deleted usage data is gone permanently and the gap is unfillable.

The operational consequence is direct. Usage-based role redesign, dormant role identification, User Access Reviews, SoD Reviews, Licence optimization, and any evidence that a role was genuinely unused before removal all depend on a continuous usage information. A cleanup job that treats usage data as ordinary sync data destroys the baseline for every one of those, and the loss is invisible until someone asks for eighteen months of history and finds four weeks.

Usage data is therefore an archiving candidate, never a deletion candidate.

Technical and BASIS Layer Residue

Application logs, spool and TemSe entries, ABAP dumps, batch job logs, IDoc history, table change logs in DBTABLOG, and orphaned workflow work items in the SWW runtime tables accumulate quietly in GRC systems and are rarely governed. Standard workflow housekeeping is available through transaction SWUF, and it should be understood that this path performs deletion rather than archiving. Source: SAP Workflow user group archive.

These belong on the Basis pre-conversion checklist rather than the GRC functional checklist, and routinely account for double-digit percentages of database size.

Archive: Data That Must Be Retained but Not Migrated

Archiving writes data to an archive file, then removes it from the database while keeping it readable. This is the correct treatment for everything with evidentiary weight, and it is the technical implementation of Step 2 in the Delete to Archive to Migrate methodology.

Access Requests and MSMP Workflow Runtime

Archiving object GRFNMSMP covers access request and workflow runtime tables including GRFNMWRTINST, GRFNMWRTINSTAPPL, GRFNMWRTMSGLG, GRFNMWRTARCHCONF, GRACREQ, GRACREQPROVLOG, GRACREQOWNER, GRACREQUSER, GRACREQPROVITEM, GRACSODREVIEW, and GRACUARBUSRLSNAP, with programs GRFNMW_ARCHIVE_WRITE, GRFNMW_ARCHIVE_DELETE, GRFNMW_ARCHIVE_RELOAD, and GRFNMW_ARCHIVE_READ. Source: Security Guide, SAP Access Control 12.0.

Sequence matters. The write program produces the archive file but does not remove data, so records remain visible in tables and in the user interface until the delete program runs. 

Emergency Access Management Logs

Firefighter logs are the most audit-sensitive dataset in the system and the most frequently mishandled. EAM consolidates transaction usage from STAD into GRACACTUSAGE, change documents from CDPOS and CDHDR into GRACCHANGELOG, system logs from SM21 into GRACSYSTEMLOG, security audit log entries from SM20 into GRACAUDITLOG, and OS command activity from SM49 into GRACOSCMDLOG. Source: SAP Community, SAP GRC 10/10.1/12.0 Access Control Module related Tables.

EAM logs can be archived from SARA using the EAM archiving component or via program GRAC_EAM_ARCHIVE_WRITE, with archived content readable through the Archive File Browser using transaction AS_AFB. 

Action Usage and Role Usage History

Action usage supports usage-based role redesign and is separately archivable. SAP KBA 2023879 covers archiving of action usage data held in GRACACTUSAGE, and SAP KBA 2425648 documents error handling for the action usage archiving object. Confirm the exact object name in transaction AOBJ, since naming appears inconsistently across Security Guide revisions.

The governing constraint is that this data cannot be regenerated. Unlike every other dataset in the Delete category, action usage is harvested from back-end sources with their own short retention, so deletion is permanent and the gap cannot be backfilled. Archiving preserves it; deletion ends it.

A second consideration reinforces the same conclusion. Announced GRC 2026 capabilities include enhanced analytics and early AI-assisted features such as access review recommendations and anomaly detection. 

Preserve: Configuration That Must Not Be Touched

Configuration and master data carries forward. Removing it converts a technical migration into a reimplementation. The protected list is short and non-negotiable:

• Access ruleset: functions, risks, rulesets, and generated rules
• Mitigating controls with assignments, owners, and validity periods
• Connector and connector group configuration
• MSMP process configuration, agent rules, notification templates, BRF+ applications
• Business role definitions and role methodology
• Organisational rules and org-level derivation
• Provisioning configuration, number ranges, and workflow customizing

One utility is regularly misfiled as a housekeeping tool. SAP KBA 2268795 documents that report GRAC_DELETE_ACCESS_RULES deletes transactional data across a broad set of objects, including user and role violation tables, management summary and violation count tables, alert header and detail tables, the full set of mitigating control assignment tables, function action and permission tables, critical role and profile definitions, and system rule tables. 

That is a ruleset and mitigation reset. It has a legitimate purpose in a ruleset rebuild and no place in a pre-migration reduction plan.

Personal Data and the ILM Route

Deleting personal data properly is a compliance activity with its own toolset. SAP models this through business entities, ILM objects, residence time, and retention time.

The Access Control 12.0 Security Guide lists business entities with their ILM objects and indicates where blocking is required and archiving is available, including Access Request under GRAC_ARQ, Action Usage under GRAC_ACT, and Emergency Access Management under GRAC_EAM, alongside GRC-level destruction objects covering ad-hoc issues, surveys, automated monitoring job data, background report data, and business rules. All listed business entities require destruction after the end of the retention time. The guide further specifies that before an archiving object is used for the first time, the GRC Customizing activities under Blocking and Deletion must be completed to enable ILM capabilities, and that transaction ILM_DESTRUCTION is used to verify destruction policies. Source: Security Guide, SAP Access Control 12.0.

For organizations subject to the Data Protection Acts such as GDPR, CCPA, DPDPA etc., a migration is the natural point to establish this properly. Carrying a decade of unpurged personal data into a new platform propagates the exposure and makes the next data subject request harder to service.

Three Documented Traps

Trap 1 - Unbounded EAM cleanup: GRAC_SPM_CLEANUP has been reported to delete the entire contents of several EAM-related tables irrespective of the connector and timestamp selection criteria supplied, with a correction note required depending on release and support package level, and it removes audit-relevant information without a restore path. Source: SAP Community, Non-archiving solution for GRACAUDITLOG data cleanup. The same case documented GRACAUDITLOG approaching a billion records, which illustrates both why the temptation exists and why an unbounded deletion is unacceptable.

Trap 2 - Archiving objects that free no space: SAP KBA 2444623 addresses GRC archiving objects for which no delete program exists, covering SPM_AU_LOG, SPM_CH_LOG, SPM_OC_LOG, SPM_SY_LOG, and AC_TR_LOG, where write programs are available but the deletion step remains incomplete against tables such as GRACACTUSAGE. 

Trap 3 - Write without delete: The archive file exists, the database is unchanged, and the project reports a completed archive. This is the most common cause of a sizing forecast missing by an order of magnitude.

Six-Month Cleanup Runbook

Technical Decision Matrix

This matrix extends the planning matrix from Part 1 to object level.

Common Mistakes

• Treating GRAC_DELETE_ACCESS_RULES as housekeeping. Rulesets, mitigations, and alert history are removed together. This is a ruleset reset, not a cleanup.
• Running archive write without delete. The archive file exists and the database is unchanged.
• Clearing report spool without extracting a baseline. The pre-migration violation position becomes unprovable.
• Deleting synchronization data without a proven resync window. Reporting stays dark until a multi-hour full sync completes.
• Cleaning production directly. Every deletion path should be rehearsed on a recent full copy first.
• Skipping Blocking and Deletion Customizing. Archiving objects then fail on first use, late in the schedule.
• Treating cleanup as a one-time project task. Organizations that clean once for a migration rebuild the same problem within three years.

References

• SAP Note 3326989. Announcement of the Upcoming Release. Maintenance timelines for SAP Access Control 12.0, Process Control 12.0, and Risk Management 12.0, and the announcement of the 2026 release.
• SAP Note 3334350. SAP assurance and compliance software for SAP S/4HANA. Technical prerequisites and product scope for the S/4HANA-based GRC suite.
• SAP KBA 2268795. GRAC_DELETE_ACCESS_RULES explained. Full list of tables affected by the rule deletion report. Essential reading before anyone runs it.
• SAP KBA 2739079. How to run the GRAC_DELETE_REPORT_SPOOL job. Deletion of background risk analysis spool data.
• SAP KBA 2444623. No delete program exists when archiving some GRC objects. Archiving objects where the write program exists but the delete step is incomplete.
• SAP KBA 1719967. How to archive in GRC Access Control. Overview of archiving requests and Emergency Access Management logs.
• SAP KBA 2023879 and 2425648. Action usage archiving. Archiving GRACACTUSAGE and handling errors in the action usage archiving object.
• Security Guide, SAP Access Control 12.0. Data protection chapter covering business entities, ILM objects, blocking and deletion, and the table scope of each archiving object.
• Upgrade Guide for SAP GRC Access Control for SAP HANA 1.0. https://help.sap.com/docs/SAP_GRC_ACCESS_CONTROL_FOR_SAP_HANA/ca62cf7279394ac3ba4a81ec2170656a/f228520a7e5f46ff908108b9097593d5.html
• SAP Product Availability Matrix. https://help.sap.com/docs/SUPPORT_CONTENT/sl/3362917381.html

Final Thoughts

Part 1 argued that cleanup belongs before migration. This article establishes what that costs in practice: a written retention policy, a rehearsed archiving run, an evidence baseline extracted and stored outside the system, and control owner approval for every irreversible action.

The instinct during a GRC migration is to carry everything forward, on the assumption that retained data is safer than deleted data. On a HANA-native platform that assumption inverts. Undifferentiated retention raises cost, extends downtime, degrades performance, and widens privacy exposure, while contributing nothing to auditability that a properly archived and readable dataset does not already provide.

The distinction that matters is not old versus new. It is derived, evidentiary, or configuration. Derived output is regenerated. Evidence is archived under a retention policy that Internal Audit has signed. Configuration is preserved because the upgrade depends on it. Organizations that write that classification down before the first deletion job runs arrive at GRC 2026 with a smaller, faster, defensible system.

The migration deadline is a forcing function for a discipline that should already exist. The archiving strategy defined for this project deserves to outlive it.