When organisations sign a SAP® RISE contract, the shared-responsibility model is well documented — in theory. In practice, the security clauses that matter most are rarely negotiated before signature: independent penetration testing rights, SIEM log export entitlements, breach notification timelines, IRAP assessment access, and AI usage audit rights. Once the contract is signed, these become expensive to add.
We have reviewed RISE contracts across multiple Australian enterprise engagements. The same gaps appear consistently. The organisations that negotiate these clauses upfront spend less on security remediation in Year 1 — and have significantly stronger audit and board reporting positions within 12 months of go-live. This whitepaper covers the eight clauses worth discussing before you sign.
5 min read
Mid-Deployment
Why SAP role design fails at go-live — and how to prevent it
Role design is consistently the longest-running security workstream in any S/4HANA implementation. It starts late, competes with functional build activity, and arrives at cutover under-tested and over-permissioned. The root cause is almost always the same: roles are built from scratch during the implementation rather than from a validated, SoD-free baseline — and the functional team is engaged too late to validate them against real business processes.
In a recent S/4HANA RISE greenfield implementation, we delivered 300 SAP best-practice business roles — fully SoD-free, Signavio-aligned, with Fiori Spaces, Pages and Sections pre-configured — before functional design workshops started. The business team validated and confirmed rather than built from scratch. Four months of design effort was delivered as a plug-and-play accelerator. This whitepaper covers the five decisions that determine whether role design succeeds or fails at go-live.
5 min read
Post-Go-Live
SAP RISE shared responsibility: what your audit team will ask for
Twelve months after go-live, internal audit will ask a question most SAP teams are not prepared for: who is responsible for which security controls, and where is the evidence? The RISE shared-responsibility model is well understood at a high level. At the control level — specific parameters, specific configurations, specific log sources — the picture is rarely documented in a form an auditor can work with.
The organisations best positioned for audit are those that produced a customised Roles and Responsibilities document before go-live and ran an independent cyber assessment within the first 12 months of production. They have evidence mapped to ISM, Essential Eight and NIST — not a generic vendor security statement. This whitepaper covers what audit-ready SAP RISE evidence looks like, and how to produce it without a full re-implementation of your security controls.
5 min read
AI Security
Joule is live. Your AI governance isn't. Here's what that means.
Joule and BTP-hosted AI workloads are being enabled in SAP RISE environments faster than governance frameworks are being built around them. The attack surface is new and specific: prompt injection via business process inputs, AI agent authorisation scope that exceeds the user's own access rights, audit traceability gaps where AI interactions are not logged to your SIEM, and admin policy misconfigurations that expose sensitive financial and HR data to the AI layer.
ISO 42001 — the international standard for AI management systems — was published in 2023. SAP's own AI security guidance is evolving alongside it. Most SAP customers are running Joule without a documented governance position against either standard. The risk is not theoretical — it is a current audit gap that is growing with every new AI workload enabled in the landscape. This whitepaper covers the six governance controls every SAP AI deployment needs before go-live.
5 min read
BTP
The five BTP misconfigurations we find in every engagement
BTP security incidents are not exotic. They trace back to a small, repeatable set of misconfigurations that appear in virtually every BTP environment we assess — regardless of organisation size, industry or implementation partner. The most common: overly broad Role Collection assignments at subaccount level, Cloud Connector allowlists that permit more backend systems than required, destination service configurations with stored credentials and excessive trust scope, and principal propagation gaps that allow technical user access to bypass identity controls.
The fifth — and most consequential — is key management. BTP applications handling sensitive data frequently rely on default key configurations rather than a managed Key Management Service implementation. In a breach scenario, this means encrypted data is only as secure as the default key rotation policy. All five of these issues are identifiable and remediable in a 5-day BTP security baseline assessment. This whitepaper covers each one in detail, with the specific BTP configuration setting to check and the correct target state.
5 min read
Identity
SAP IDM end of maintenance: what to do before 2027
SAP Identity Management (IDM) reaches end of mainstream maintenance in 2027. For organisations running IDM as their primary provisioning engine into SAP — and many large Australian enterprises are — this creates a mandatory architecture decision that must be made and budgeted for now, not at the end of the maintenance window. The target state for most organisations is IAS for authentication, IPS for provisioning, and IAG for access governance — connected to on-premise GRC via the IAG Bridge during a coexistence period that may last several years.
The migration is not a lift-and-shift. Provisioning logic built in IDM over years must be redesigned for IPS transformation rules. Role architecture assumptions baked into IDM workflows may not survive the move to IAG Access Request without redesign. Corporate IDAM integration — Active Directory, Entra ID, LDAP — must be re-validated against IAS federation. Organisations that start this architecture work now will have options. Those that start in 2026 will have a deadline. This whitepaper covers the migration decision framework and the five architecture choices that determine how complex your migration will be.
5 min read
Pen Testing
What SAP KBA 3080379 actually means for your pen test programme
SAP KBA 3080379 is the Knowledge Base Article that governs penetration testing in RISE and cloud ERP environments. Most organisations know it exists. Very few have read it carefully enough to understand what it actually requires: a formal Service Request raised before testing begins, SAP NDA execution, explicit tooling approval from SAP, Rules of Engagement signed by all parties, and testing conducted only against agreed scope with approved methods. Pen tests conducted without following this process put your RISE contract at risk.
The process is not onerous — but it requires someone who has done it before to manage it efficiently. The tooling approval step alone can delay a poorly-managed engagement by two to three weeks. We manage the full KBA 3080379 process on behalf of our clients — NDA, Service Request, tooling approval and Rules of Engagement — as a standard part of every SAP penetration test engagement. This whitepaper covers the full KBA 3080379 process, the common mistakes that delay approvals, and what to include in your Rules of Engagement to protect both parties.