Why SAP security prep fails during organizational changes — And how to fix it

By Cyril Hauppert & Mark Stanley

“Audit risk always spikes when the organization changes—but no one has time to deal with it until it’s too late.”
— Mark Stanley, SAP Security Consultant, Pumpkin Consulting

When things change, risk spreads

Acquisitions, mergers, divestitures, carve-outs. shared service transitions, mass layoffs, restructuring… These are the key moments when access risk quietly explodes—just as internal focus shifts elsewhere. Controls weaken, exceptions expand, visibility fades.

And the audit clock doesn’t stop ticking.

We’ve worked with clients across all these scenarios. In nearly every case, the same pattern emerges: security leaders underestimate the complexity, and auditors find what they didn’t catch.

Why security breaks during change

1. Retained access is rarely cleaned up

Let’s say your company divests a business unit. You sign a Transitional Service Agreement (TSA). The divested users need SAP access for 12 months.

What happens 18 months later?
In one case we saw, 300+ users still had access—and the audit team flagged it as a high-risk finding. The client’s defense? “We didn’t realize the TSA ended.” It was a legitimate operational miss, especially after the deadline was previously extended, but the optics were terrible.

Without automated snapshots or expiry tracking, this happens more often than you’d think.

2. Dormant accounts multiply

During layoffs or reorgs, IT teams often wait for HR to confirm terminations. Or users are retained “just in case” for knowledge transfer.

That’s how you end up with:

• Inactive users with full production access
• Admin accounts linked to former employees are still active
• Contractors whose credentials were never revoked

“We’ve seen dormant users retained for well over 6 months—with privileged access. That’s a finding waiting to happen.”
— Cyril Hauppert

3. Shared services and centralization hide risk

When business units consolidate into shared service centers, access models become broader. One role replaces three. It’s efficient—but can be riskier.

Without granular rule reviews and simulations, you don’t always see:

• Who now has access to conflicting tasks across processes
• How exceptions were migrated from one org unit to another
• Which approvals are no longer valid because the structure changed

This is where GRC flags thousands of violations, and it is often hard to differentiate between potential and actual risk.

4. Role redesigns happen without risk simulation

Organizational change almost always leads to role redesign. New responsibilities. New systems. New approvals.

What doesn’t happen?
Simulating those new roles to see what they actually allow.

“We’ve seen new role designs approved, tested, and transported—only to realize after the audit that they introduced new SoD conflicts.”
— Mark Stanley

Without proper simulation, you’re just guessing. And when auditors test those roles against your SoD rule set, you’ll be exposed.

5. Documentation falls behind

Most organizations manage change through spreadsheets, emails, and shared folders. During periods of disruption, this breaks down.

Auditors ask:

• Who approved this exception?
• Why does this role exist?
• When did this access change?
• What was the business justification?

If you can’t answer quickly, they assume the worst. Even when your intent was valid.

What you can do: secure the change window

Here’s how we help teams reduce exposure during volatile periods:

Step 1: Run a Snapshot

Capture a full access state before change begins. This becomes your baseline for monitoring, rollback, and audit response.

Step 2: Review Dormant Users

Identify accounts that haven’t been used in the last 30–90 days. Flag high-risk users (e.g. debug, admin) with no recent activity.

Step 3: Validate Active Exceptions

Ensure each exception or mitigation still has a valid owner, a reasonable justification, and an expiration date assigned.

Step 4: Simulate Role Changes

Before any role redesign is transported, simulate SoD and critical access violations. Review results with business stakeholders.

Step 5: Track Delta Over Time

After the transition, generate a delta report:

• What changed since the baseline?
• What access was added or removed?
• What new risks appeared?

Auditors love this. It shows control—even when the environment is in constant evolution.

When security strengthens, not slips

Organizational change is not just a risk—it’s an opportunity.
Handled well, it’s your chance to:

• Eliminate outdated roles
• Reduce exception volume
• Streamline your compliance ruleset
• Align controls to new operating models

But that only happens if you have the visibility and speed to act before the audit team does.

Final word

“You’re not expected to catch everything during transformation. But you are expected to know what changed—and demonstrate that you are in control.”
— Cyril Hauppert

Access Informer gives you the tooling, visibility, and expert support to prepare your SAP security posture for change—with the evidence to prove it.

If your business is going through transition, let us help you secure it.