When the SAP System Goes Live — But the Organization Doesn’t

The hidden risk between delivery, governance and accountability

By Eckhart Mehler for CISOsCISO — a perspective on cybersecurity leadership, governance and the decisions that determine whether organizations retain control.

The Day After Go-Live

The dashboard is green. The steering committee has closed the project.

The ERP system is live.

The transformation program is officially declared a success. And yet something feels wrong. Invoices are not moving. Approvals are stalling.

Employees begin solving problems through phone calls and spreadsheets rather than through the system itself.

• Nobody calls it a security incident.
• Nobody calls it a governance failure.
• At first, nobody even calls it a problem.

But something fundamental has changed. The system is operational. The organization is not.

Over the last years, I have observed this pattern repeatedly in large transformation programs. Not as an exception. As a recurring phenomenon.

And every time the investigation begins in the same place. We search for technical defects.

• Configuration errors.
• Integration problems.
• Missing interfaces.
• Performance bottlenecks.

The usual suspects. Yet surprisingly often, the technology itself is functioning exactly as designed.

Which leaves a far more uncomfortable possibility:

The system works. The organization doesn’t.

The Great Illusion of Transformation Governance

Large transformation programs create a powerful sense of control.

• Risk registers are maintained.
• Architectures are reviewed.
• Security controls are validated.
• Gate reviews are completed.
• Every stakeholder signs off.
• IT signs.
• Business signs.
• Risk signs.
• Compliance signs.
• Audit signs.

The governance machinery appears comprehensive. But governance frequently contains an unspoken assumption: That collective approval somehow creates collective ownership.

It doesn’t.

Because once the first real transactions begin flowing through production, the question changes. The challenge is no longer whether the project was delivered.

The challenge becomes whether the organization can actually operate under real-world conditions. That question is rarely tested with the same rigor.

What “Ready” Actually Means

At some point in almost every major transformation, someone asks the CISO a seemingly simple question:

“From a security perspective, are we ready?”

It sounds straightforward.

It isn’t.

Because readiness depends entirely on the definition.

• If the question is whether required controls have been implemented, the answer is usually yes.
• If the question is whether known vulnerabilities have been addressed, the answer is usually yes.
• If the question is whether the system can operate securely under expected conditions, the answer becomes more nuanced.

But there is a fourth question that is rarely asked:

Can the organization continue to function when conditions are no longer as expected?

That question often receives remarkably little attention.

Yet it is precisely where many transformation failures begin.

ERP Systems Are Not IT Systems

One of the most persistent misconceptions in large programs is the way ERP platforms are described.

We call them “systems.”

Technically that is correct.

Operationally it is misleading.

ERP platforms are not simply applications. They are organizational decision frameworks encoded into software. They determine:

• who may act,
• when action is permitted,
• how transactions move,
• how exceptions are handled,
• how accountability is recorded,
• how segregation of duties is enforced.

An ERP system effectively becomes the operating model of the organization.

Which means that implementation mistakes do not merely create technical issues.

They create organizational paralysis.

Failure Rarely Arrives Dramatically

When ERP environments fail, they rarely fail loudly.

They degrade.

• A payment cannot be released because nobody owns the required authorization.
• A workflow cannot be completed because reality differs from the designed process.
• A transaction remains unresolved because responsibility is unclear.

Initially these events appear operational. Later they become governance issues. Eventually they become security issues.

Not because attackers exploited a vulnerability. But because people begin adapting around the system.

• Manual workarounds emerge.
• Informal approvals appear.
• Controls are bypassed.
• Traceability weakens.
• Segregation of duties erodes.

Risk enters through necessity rather than negligence.

And that distinction matters.

The Accountability Vacuum

What makes these situations particularly interesting is that they frequently occur in highly mature organizations.

Organizations with:

• certified ISMS programs,
• mature governance structures,
• experienced executives,
• formal risk management processes,
• extensive oversight mechanisms.

The problem is rarely a lack of structure. The problem is accountability. Transformation governance distributes responsibility extremely well. It often distributes accountability out of existence.

• The CIO owns delivery.
• The business owns requirements.
• Project management owns coordination.
• Risk functions own oversight.
• Security owns control assurance.

Each role is clearly defined.

Yet when the organization cannot execute a critical business process after Go-Live, identifying true ownership suddenly becomes remarkably difficult.

Not on paper.

In reality.

Hypercare: The Most Misunderstood Phase of Transformation

Many organizations treat Hypercare as a stabilization phase. A buffer between project completion and operational maturity.

But Hypercare often masks a deeper assumption.

An assumption that deserves more scrutiny than it typically receives.

The assumption is simple:

Whatever was not fully validated before production can be managed after production.

That may be operationally convenient. It is not always strategically sound.

Because Hypercare transfers uncertainty into a live environment where consequences are no longer theoretical.

At that point the organization itself becomes part of the test environment.

The Security Dimension Nobody Talks About

Traditional cybersecurity frameworks are built around confidentiality, integrity and availability.

These principles remain essential.

But transformation programs expose another dimension that receives far less attention:

Organizational agency.

• The ability of an organization to act.
• To make decisions.
• To execute obligations.
• To deliver services.
• To maintain trust.

An organization can possess excellent technical security while simultaneously losing operational agency.

And when that happens, traditional security reporting often fails to describe what is actually occurring.

• The system is available.
• The controls are functioning.
• The organization cannot act.
• That state sits in an uncomfortable space between operational failure and security failure.

Yet it represents real risk.

Where the CISO Enters the Conversation

Formally, CISOs are not accountable for ERP implementation.

Nor for business process design.

Nor for transformation delivery.

Yet many of the consequences ultimately surface within the CISO’s domain:

• Integrity of business transactions
• Traceability of actions
• Segregation of duties
• Control effectiveness
• Regulatory compliance
• Operational resilience

This creates a critical question:

At what point does a process design failure become a security issue?

Most governance models never answer this directly. Yet every major transformation eventually encounters the question. The organizations that manage it successfully usually share one characteristic: The CISO is involved before decisions are finalized.

Not afterwards.

Not as an observer.

Not merely as an advisor.

But as a participant in the conversations where trade-offs are made.

Because risk cannot be meaningfully managed once the decision has already been taken. At that stage, risk is often no longer managed.

It is merely documented.

Being Informed Is Not the Same as Being Involved

One of the most important governance distinctions I have encountered is surprisingly simple. Being informed means understanding a risk after it has been accepted.

Being involved means influencing the conditions under which that risk emerges.

The difference appears subtle.

Its impact is profound.

Many transformation failures originate not from technical mistakes but from decisions made months earlier:

• Decisions about scope.
• Decisions about timelines.
• Decisions about acceptable uncertainty.
• Decisions about what would be “good enough” to proceed.

These are delivery decisions.

But they are also risk decisions.

Whether organizations acknowledge that fact or not.

The Governance Question We Avoid

I do not believe these challenges will be solved through more controls.

Or more documentation.

Or more oversight committees.

Most mature organizations already possess those. What is frequently missing is something far simpler:

• Clear accountability for business capability continuity during transformation.
• Not system continuity.
• Business continuity.
• Who owns the ability to execute payments?
• Who owns the ability to maintain operational decision-making?
• Who owns the organization’s ability to function throughout transformation?

The answer is often assumed rather than defined.

And assumptions are poor governance mechanisms.

Cybersecurity 2030: When Assumptions Expire

If there is one lesson I continue returning to, it is this:

Highly structured organizations can still make profoundly unstructured decisions.

Not because they lack governance.

But because governance does not always capture how decisions are actually made under pressure.

When that happens, the consequences rarely appear in project documentation.

They appear in operations.

Which brings us back to the original question.

When a system goes live and the organization struggles to function, what exactly failed?

• The technology?
• The process?
• The governance model?

Or the collective assumption that someone, somewhere, had end-to-end visibility and accountability for the outcome?

As CISOs, our contribution is often not another control. It is a different kind of interruption.

Not at the end, when answers are expected.

Earlier, when questions are still uncomfortable.

Questions such as:

• Under which conditions does this process stop working in reality?
• Who owns that moment when the process no longer behaves as designed?
• What happens when the system is available but the organization cannot act?

These questions rarely accelerate a transformation.

But asked early enough, they expose assumptions.

And once assumptions become visible, accountability becomes far harder to diffuse.

That may be one of the most valuable security controls we have.

Publication Note & Disclaimer
This article was originally published on LinkedIn on June 1, 2026 and may have been edited or updated for publication on this site.

It reflects my personal professional perspective and does not represent the official policy or position of my employer. Drafting and editorial refinement may have been supported by commercially available AI-assisted tools. The analysis, conclusions and final curation are entirely my own.

For information regarding image credits, copyrights, trademarks and other intellectual property rights, please refer to the Imprint.