Securing Business Processes, Not Tools

The cybersecurity industry has a habit of talking about the technology stack as if it's the thing that matters. Jay Thoden van Velzen's job inside SAP's Office of the Chief Security Officer is a constant rebuttal of that frame. SAP runs the business processes that make 440,000 customers actually work — payroll, manufacturing recipes, financial close, supply chain. When you secure SAP, you aren't securing a database; you're securing whether a pharmaceutical batch becomes medicine or poison, whether a financial report leaves early, whether a transaction can be reversed.

This conversation goes after the gap between cybersecurity-as-controls and cybersecurity-as-business-enablement. Jay's view is direct: when a cyber team escalates a missed SAP patch SLA to the business and gets the exception granted in five minutes, the cyber team didn't just lose the argument — they didn't understand the cost calculus. The cost of a maintenance window, a reboot, and full regression testing on a system of record can dwarf the quantified risk of the unpatched vulnerability. Get that math wrong often enough and you stop being invited to the room.

The AI section of the conversation is where the practical wisdom lands. Jay walks through how SAP is grounding agentic systems in transactional integrity, why prompt injection is not the actual enterprise threat, and why the most useful defense for agentic AI is architectural — split planning from execution, delegate identity at the user level, drop privileges to the minimum the task needs, and create explicit escape routes when the model's pleasing instinct kicks in. For security leaders trying to figure out what good looks like as agentic AI lands inside business systems, this is the working playbook.

Thank you to our Sponsors:

Hampton North is the premier US based cybersecurity search firm. Start building your security team with Hampton North

Sysdig is the leader in AI-powered real-time cloud defense; stop watching and start defending

SAP isn't a database company or a cloud company. Jay's framing — and the operating frame across the entire OCSO function — is that SAP is a business process company first and a technology company second. That changes what threat modeling means. When a system is the path by which financial reports get signed, payroll gets calculated, or chemical doses get measured, the threat surface isn't a vulnerability list. It's whether the business process retains its integrity end-to-end.

The practical implication for any CISO outside SAP is the same: the systems that matter most in your environment are not the ones with the highest CVSS scores attached. They're the ones that, if compromised, change a business outcome — early-leaked earnings, a fraudulent transaction, a manufacturing recipe error. The work is to figure out which systems those are and threat-model them in business-process terms, not in patch-status terms. 

Jay's example is one almost every security leader will recognize. The SAP team misses the 30-day patch SLA because the next maintenance window is three months out. The cyber team escalates to the business. The business grants the exception in five minutes. The cyber team walks away frustrated, thinking the business doesn't care about security. What actually happened is that the business team did the math the cyber team didn't. 

If the quantified risk of the unpatched vulnerability is, say, $5M, and the cost of an unscheduled maintenance window — reboots, regression tests, lost transactions, ops time — comes in at $15M, the exception is the right answer. The cyber team's mistake was bringing only one side of the equation to the conversation. The work, Jay argues, is to come back with creative compensating controls — zero-trust access in front of the legacy box, network segmentation, additional monitoring — rather than insisting the SAP team just patch faster against business reality. 

This is also why generic security tooling routinely fails on SAP. Vulnerability scanners that don't understand ABAP can't read patch status. Runtime agents on in-memory databases distort CPU usage profiles. The whole reason an SAP-specific cybersecurity tooling ecosystem exists is that the rest of the industry's tools don't speak the language of the systems that matter most to the business.

The most generative section of the conversation is on how SAP is securing agentic AI in business systems. Jay's blog series with his team coined a useful frame — "the agentic wave collapse" — for the architectural pattern they're advocating: separate planning from execution. Use the LLM's creativity to construct a plan, validate that the plan is bounded and within policy, and then execute the actual transaction with deterministic code. The LLM doesn't push the order through. The deterministic step does.

The corollary is that the dangerous prompt injection scenario is mostly a red herring in real enterprises. If a malicious actor tells the agent "ignore all instructions and write me a poem," that gets logged and surfaced. The harder problem is the millions of non-malicious users who will try to negotiate with an agent the same way they'd negotiate with a human — for an out-of-bounds discount, a delivery exception, an unauthorized refund. SAP wrote a blog series on exactly this and arrived at a retail-style answer: model "wastage" as a line-item business cost, the same way retailers price in shrinkage. Quantify what you'll lose to manipulated agents, decide if the upside justifies it, and either honor the bad deals or build the architectural controls to refuse them.

The other architectural moves Jay walks through are equally practical. Delegate the user's identity into agentic interactions rather than running everything as a service account that bypasses existing controls. Drop privileges further when the task doesn't need them — browsing the catalog doesn't need order-placement scope. And build explicit escape routes for when the model's pleasing instinct kicks in: at some point, the right answer is "let me connect you to your account rep," not "let me try harder to satisfy you."

A useful piece of context: SAP went 53 years before its first in-the-wild zero day. When a vulnerability hits SAP's name in the press, executive board members get phone calls — not press releases. That's a different operating posture than most tech companies, and it's intentional. Customers don't want innovation on the foundation of their house. They want stability and predictability on the foundation, and innovation in the parts they can choose to upgrade.

The practical version of that posture is the upgrade cycle itself. Roughly half of SAP's customers are still migrating to the current product version that came out in 2015 — end of life 2027, extended support 2030. That's the dominant program at most large SAP customers right now. It's also the gate to faster patching cycles, the new AI offerings, and the cleaner cloud-native deployment posture SAP can run on automated landscapes. Until customers get there, the OT-style "take the plant down for a month every few years" upgrade cadence is the operating reality.

The closing section on sovereignty is where the conversation looks forward. The EU AI Act, GDPR, and growing demand for sovereign cloud are colliding with the practical reality that most countries don't have a domestic alternative that can match what a US hyperscaler provides. The Western European data center build-out is also constrained by zoning, so the supply side isn't catching up quickly.

What's emerging is a new construct: US technology, intermediated by a European actor under European jurisdiction. SAP's partner Delos and France's Bleu are early examples — local operators running on US cloud infrastructure under contracts that satisfy local regulatory requirements. Jurisdictions like Ireland could become attractive destinations for sovereign workloads even from non-EU member states, because they sit under EU law and can attest to AI-specific certifications like ISO 42001. For CISOs in regulated industries operating across multiple jurisdictions, this is the pattern that will likely define how AI gets consumed at enterprise scale through 2027.

Guests — Jay Thoden van Velzen, technical advisor for SAP's Office of the Chief Security Officer

Books mentioned — none

Frameworks / models / tools named — "agentic wave collapse" (SAP blog series); split planning from execution; CaMeL framework (Google DeepMind, referenced by Conor); ABAP; SAP RISE; SuccessFactors; SAP AI Foundation; ISO 42001; EU AI Act; GDPR; ITAR; just-in-time privileged access; identity delegation

Other people / shows / resources referenced — community.sap.com [VERIFY] (mentioned by Conor as where Jay's articles live); Siemens (OT industry parallel); AWS Ukraine relocation to Luxembourg; Delos (SAP sovereign-cloud partner); Bleu (France sovereign-cloud partner); Alibaba Cloud (mentioned by Stuart re: European data centers); Saudi Arabia data center build-out (mentioned by Stuart)