3. July 2026 · AI
Shift Up in Cybersecurity: Four Readings, One That Works
Executive Summary
- “Shift Up” is not a defined term: Four published sources use it for four different axes. Adopting it without qualifying which one you mean buys a vendor position rather than a strategy.
- The workable reading is process-centric: Security does not move up the org chart. It moves up from the technical artefact to the business process that creates the value.
- The reason is a shift in what needs protecting: Once AI is anchored inside business processes, the process is the attack surface. Code-centric models structurally miss it.
- The toolchain already exists: Process modelling and enterprise architecture produce the map on which security decisions become locatable at all. Applying it to security, however, is an approach, not a catalogue product.
- Risk quantification stays necessary, but downstream: It is the language for the board and the regulator, not the core of the realignment.
Strategic context
Situation: For over a decade, “shift left” was the organising principle of enterprise security: test earlier, patch earlier, integrate earlier into the development cycle. Investment in DevSecOps, SAST/DAST and security champions followed that logic.
Complication: For roughly two years, “shift up” has circulated as the successor term. Except every sender means something different by it. Risk quantification vendors mean the board, supply chain analysis vendors mean the supply chain, platform vendors mean tool consolidation. All three sell their own category as a paradigm.
Question: Which reading actually describes a change to the operating model, and which one merely describes a product?
Answer: The process-centric one. It is the only reading that answers what is being protected rather than only who decides, with what, or how early.
Why shift left reached its structural limits
The premise behind shift left was sound: identify security problems early in the development cycle, save cost, reduce exposure. That logic held as long as software was produced in controlled, sequential pipelines and security was a technical quality problem.
Matt Rose, Field CISO at ReversingLabs, states the problem precisely: pointing a security product at one thing gives you nothing but a snapshot. Software supply chains, open-source dependencies and AI-generated code create a web of risk that no linear model captures.
Then there is fragmentation. Uptycs cites Crunchbase data showing that more than 40 billion US dollars went into over 5,000 cybersecurity startups across ten years, while breaches are more common than ever. The cause is not a shortage of tools but their fragmentation: organisations drown in alerts and miss the real attacks.
None of that is contested. What follows from it is.
One term, four meanings
Research “shift up” and you find four published definitions. They do not contradict each other in tone, but they do in axis. And the axis is the entire content of the term, because “up” only means anything relative to a direction.
| Source | Axis | What “up” means |
|---|---|---|
| ReversingLabs | Scope of analysis | From the single component up to the entire software supply chain. Board, finance function and risk quantification do not appear. |
| Uptycs | Tooling landscape | Eliminating tool, team and infrastructure silos through unified telemetry and a common platform. |
| Kovrr | Organisational hierarchy | From the IT function up into the C-suite and the board, with financially quantified risk as the shared language. |
| Jon Robinson | Architectural depth | Quality assurance starts not on the timeline but at model, agent and context logic. |
| Process-centric reading | Value creation | From the technical artefact up to the business process that generates the value. |
The process-centric reading: security follows the value stream
The fifth reading does not come from the vendor market but from a security organisation that guides customers through transformations itself. Andreas Hauke, Head of the Office of the Chief Security Officer at SAP, sets it out publicly on LinkedIn as the outcome of co-engineering work with an Australian transport department.
His formulation: after years of shift left, the next task is closing the gap between security and the business and embedding security across the entire customer value journey. The belief underneath it is that every business transformation is joined by a security journey.
The second half of the argument is the decisive one. As customers move toward the autonomous enterprise and AI becomes anchored in business processes, security must evolve in the same direction and protect the processes that generate real value.
The reading is also metaphorically consistent. Shift left travels along the development cycle. Process-centric shift up runs perpendicular to it on the same technical map: from the system and code layer up to the process layer. The hierarchical reading, by contrast, changes the frame of reference entirely. Its “up” sits in the org chart and has nothing to do with the axis shift left ever operated on.
The limit belongs in the assessment too. This is the publicly stated position of a security executive, not a published framework or a product announcement. It holds as a direction of thinking, not as a procurement basis.
What this means concretely in an SAP context
For anyone accountable for complex SAP landscapes, the difference between the readings is not academic. SAP systems tie finance, HR, supply chain and production processes together so tightly that any weakness becomes systemic. Classic SAP security architecture was nonetheless organised reactively: authorisation concepts as a compliance exercise, GRC tooling as audit preparation, patch management as an operations task.
Thought through process-centrically, what changes is not the ownership but the frame of reference for every individual measure.
| Dimension | Frame of reference so far | Process-centric frame |
|---|---|---|
| Authorisation design | Role and transaction | Process step and the decision taken at it |
| Patch prioritisation | CVSS score of the system | Criticality of the processes running on that system |
| AI agents | Model and platform hardening | Which process steps the agent may trigger, and who reviews the outcome |
| Interfaces | Technical inventory list | Process dependency: which value stream breaks when the interface fails |
| Incident assessment | Systems affected | Processes interrupted and their contribution to the result |
The practical effect is clearest with agentic AI. An agent that releases production orders or reconciles payments is not a model security use case alone. The relevant question is which process steps it may alter and where a human countersigns. That question cannot be answered on a system map. It can be answered on a process map.
Four directions, one word
The toolchain: what it delivers and what it does not
The most interesting element of the process-centric reading is the claim that it needs no new tool. Anyone running business transformations already has process modelling and enterprise architecture in house. Both produce exactly the map that process-oriented security requires.
The evidence is more nuanced than the claim suggests. I checked what the vendors themselves document.
Enterprise architecture (SAP LeanIX): The technology risk and compliance module automatically clusters software versions into usable fact sheets, detects which custom applications run on which standard tech stacks, and maintains lifecycle data on support types and support policies. From that come reports on the root cause of technical debt and roadmaps for components nearing end of support. What the product page explicitly does not describe as a discrete feature: dependency mapping as a named capability, and direct connectors to security tooling. The value lies in the inventory picture and obsolescence risk, not in a finished security analysis.
Process layer (SAP Signavio): For risk and control, the vendor describes a four-step approach, namely document your processes, identify risks and bottlenecks, implement control measures, and monitor continuously, and names SOX, Basel and Dodd-Frank among the supported regulatory frameworks. The product page does not list named features for linking individual risks to individual process steps.
So the realistic formulation is this: the process model and the architecture repository are the defensible basis on which criticality can be argued at all. Without them, every prioritisation is an opinion. With them, it becomes traceable. Connecting that to security is work an organisation has to do itself, and Hauke consistently frames it as an opportunity rather than an available solution.
Risk quantification: the governance building block
None of this retires the hierarchical reading. It simply occupied the wrong position. Cyber risk quantification translates technical exposure into financial loss potential. That is the language boards, supervisory bodies and regulators demand, and it replaces the CVSS score that nobody at the board table can place.
Kovrr describes the strategy as reframing cybersecurity as a core business risk that aligns CISOs, C-suites and boards around financially quantified risk insights. As a governance instrument, that holds.
But quantification is a consequence, not a starting point. It presumes you already know which process creates which value and which event interrupts it. Attempting to put numbers on risk before understanding the processes produces figures with decimal places and no foundation. The sequence is the difference between defensible governance and a metric that falls apart at the next audit.
Strategic SWOT of the process-centric alignment
Strengths
- Prioritisation becomes arguable rather than opinion-based
- Reuses existing transformation artefacts
- Carries directly into securing agentic AI
- Speaks the language of the business, not only of IT
Weaknesses
- Presumes maintained process models, which are often missing
- No finished product bridge between process and security
- Requires security, business and architecture to work together
- No published framework so far, only a direction of thinking
Opportunities
- Transformation programmes as a natural entry point
- Agentic AI forces the process question regardless
- Process criticality as the basis for credible quantification
- Security joins the value discussion early instead of braking late
Threats
- Process models age faster than the landscape changes
- Visibility gets mistaken for control
- Terminological confusion: every vendor claims “shift up” differently
- Without governance attachment it stays a business-unit exercise
Maturity model: the process-centric transformation path
Regulatory accelerators: NIS2, DORA and disclosure duties
Regulation pushes in the same direction, though for a different reason than usually presented. NIS2 obliges organisations to integrate cybersecurity risk into corporate governance and holds management personally accountable. DORA requires operational resilience from financial services firms, third parties included. US disclosure rules require reporting of material cyber incidents.
What matters is the common feature of these regimes: they ask about impact, not about vulnerability. Materiality, operational resilience and business interruption are process concepts. An organisation that has sorted its risks only by system cannot answer any of those questions cleanly.
| Regime | Core requirement | Why this is process-oriented |
|---|---|---|
| NIS2 | Cybersecurity in corporate governance, management liability | Liability is measured by operational impact, not by vulnerability counts |
| DORA | Operational resilience including third parties | Resilience is defined as continuity of critical functions, which is processual |
| Disclosure rules | Reporting of material incidents | Materiality can only be argued through the affected value stream |
Key findings
- The term carries no meaning, only a direction. At any shift-up presentation, ask for the axis. Four published definitions point four ways, and three of them coincide with the sender’s product category.
- What needs protecting has moved. While software was only a tool, code was the object of protection. Once agents execute process steps, the process is.
- Visibility is not control. Neither an architecture repository nor a process model produces security decisions. They make them arguable. That is worth a great deal, but it is not the same thing.
- Quantification belongs at the end. Financial risk statements presuppose process knowledge. Reversed, you get numbers without foundation.
- Regulation already asks in process terms. Materiality and operational resilience are not system concepts. An organisation that inventoried only by system cannot answer.
Prioritised recommendations
| Priority | Action | Effect | Horizon |
|---|---|---|---|
| 1 Critical | Name the five most value-critical processes and map them to the systems they run on | Prioritisation becomes arguable for the first time | 0 to 3 months |
| 2 High | For every AI agent in production, record which process steps it may trigger and who countersigns | Closes the gap agentic AI is opening right now | 0 to 6 months |
| 3 High | Verify that existing process models and the architecture repository are current before security builds on them | Prevents decisions on an outdated map | 3 to 6 months |
| 4 Medium | Move patch and authorisation prioritisation from system criticality to process criticality | Resources follow value rather than score | 6 to 12 months |
| 5 Medium | Build risk quantification on top of process criticality and attach it to governance | Reporting capability toward regulators and boards | 12 to 18 months |
Implementation considerations
Process-centric alignment is not a software project, and it fails somewhere other than expected. The most common mistake is starting with a tool. A process modelling tool without maintained models is an empty shelf, and an architecture repository that does not know the latest migration state will reliably mislead security decisions.
Three preconditions have to come together. You need current models at least for the value-critical processes. You need a defensible mapping between process step and executing system, which in grown SAP landscapes full of custom code and interfaces is the actual work. And you need a shared way of working across security, the business and enterprise architecture, three areas whose priorities rarely coincide.
Frequently asked questions
What distinguishes shift up from shift left in concrete terms?
Shift left moves security checks earlier in the development cycle while staying at the level of technical artefacts. In the process-centric reading, shift up changes the layer of abstraction: the frame of reference is no longer the code artefact or the system but the business process that creates the value. The two movements do not exclude each other, they run perpendicular. The important caveat is that other senders use the same term for other axes, for example for security’s ascent into the boardroom.
Why are there four different definitions of shift up?
Because no institution ever standardised the term and because it sells well. ReversingLabs means the extension to the software supply chain, Uptycs the consolidation of the tooling landscape, Kovrr the anchoring in the boardroom through financial risk quantification, Jon Robinson the entry of quality assurance at model and agent logic. In three of those four cases the definition matches the sender’s product category exactly. For your own strategy work, the first question is therefore always which axis is meant.
What changes for securing AI agents?
The guiding question moves from model and platform security to process authorisation. An agent that releases production orders or reconciles payments is not a model problem but a process problem: which steps it may trigger, which thresholds apply, where a human countersigns, and how a wrong decision is detected and rolled back. Those questions cannot be answered on a system map. They can be answered on a process map.
Are process modelling and enterprise architecture sufficient as security tools?
No, and it should not be claimed. According to vendor documentation, the architecture repository supplies an inventory picture, lifecycle and obsolescence risk, and analyses of technical debt; dependency mapping as a named feature and direct security connectors are not described there. The process side describes an approach of documenting, identifying risks, implementing controls and monitoring, plus supported regulatory frameworks, but no named features for linking individual risks to individual process steps. Both deliver the map on which criticality becomes arguable. The security decision remains the organisation’s own work.
Does this make cyber risk quantification redundant?
On the contrary, but it sits elsewhere. Quantification is the language toward boards, supervisors and insurers, and it is practically indispensable for NIS2, DORA and disclosure duties. It does presuppose knowing which process creates which value and which event interrupts it. Quantifying before understanding the processes produces precise-looking numbers with no foundation. The right sequence is process criticality first, then valuation, then reporting line.
How does shift up differ from zero trust?
Zero trust is a technical architecture principle and defines how identities, networks and access are designed. The process-centric shift-up reading defines what that design orients itself toward, namely the value of the process concerned. The concepts are complementary: zero trust answers how access is controlled, shift up answers how critical a given access actually is. Zero trust without that prioritisation spreads effort evenly across unevenly important processes.
Conclusion
Shift left was a sensible organising principle for a world in which software was built and then used. That separation dissolves once agents make decisions in operations that people used to make.
“Shift up” is the term meant to fill that gap, but right now it is four terms in one. Three of them describe a product. The fourth describes a move of the object of protection from the technical artefact to the value-creating process, and only that move actually changes how an organisation prioritises security.
The practical consequence is unspectacular and therefore dependable: before evaluating the next platform or standing up the next risk model, name the five processes without which your business stops, and find out which systems and which agents operate inside them. Without that list, security is prioritised on instinct, no matter how many tools are deployed or at what level of the hierarchy it is discussed.
Sources: Andreas Hauke, Head of the Office of the Chief Security Officer at SAP, public LinkedIn post on the process-centric reading; ReversingLabs (Matt Rose, Field CISO); Uptycs, which credits Crunchbase for the investment figure; Kovrr (cyber risk quantification research); Jon Robinson via LinkedIn Pulse; vendor documentation for SAP LeanIX and SAP Signavio. Product statements reproduce only what the vendors themselves document. No figures were used without a source.
