Who Owns Your SAP BTP? A Practical Governance Framework

There is a question that tends to surface at the worst possible moment, usually in the middle of an incident call or an audit kickoff: “Who actually owns our BTP?”

It sounds simple. It almost never has a clean answer.

A few months into most SAP BTP journeys, the picture looks something like this:

• One team spun up a subaccount for a side project and forgot about it. 
• Procurement signed a second contract for a different business unit, so now there are two global accounts nobody reconciles. 
• An extension app stopped working over the weekend, and three people each assumed someone else was responsible for it. 
• Finance opened the consumption bill and asked why it doubled. 
• And the security team found a sub-account with a trust configuration that should never have shipped.

None of this happens because anyone was careless. It happens because BTP is easy to start and hard to govern. The platform is designed to let teams build, extend, and integrate quickly, and it does that job well. Speed without structure, though, is exactly how you end up unable to answer that one question.

This article is the practitioner’s version: not just why governance matters, but the concrete structures you can implement. We will cover the symptoms that signal a governance gap, the account model SAP itself recommends, the five pillars that hold a durable framework together, a RACI matrix for BTP resources, a starter set of security controls, and the anti-patterns that quietly undo good intentions.

Why Governance, and Why Early

Left alone, BTP environments grow the way a garden grows when nobody is tending it. Organically, and then all at once. Most of the trouble traces back to a handful of recurring symptoms. If you recognize more than two of these, you already have a governance gap; you just have not named it yet.

• Multiple contracts and global accounts. When different departments procure BTP independently, you end up with fragmented landscapes, duplicated services, and no single view of what the company actually owns. Each global account is the realization of a separate commercial contract with SAP, and you are billed per global account, so scattered procurement quietly inflates cost and complexity at the same time.
• Unclear ownership of accounts, apps, and service instances. When no individual or team is accountable for a resource, maintenance falls into the gap between roles. The app that “just works” has no owner until the day it stops working.
• Security exposure from unmanaged accounts. Orphaned subaccounts, leftover trust configurations, and over-privileged role collections are the kind of thing that looks harmless on a Tuesday and becomes the headline of your next penetration test.
• Blocked teams because of missing entitlements. Entitlements are your right to provision and consume a service, and quota is how much of it you can use. Get the allocation wrong and a development team sits idle, waiting on access to a service they were promised weeks ago.
• No transparency on consumption and cost. Consumption can only be monitored at the level of a subaccount, directory, or space, not per application. If everything lives in one shared sub-account, you cannot tell which project is driving the bill, which makes cost optimization more or less impossible.
• Broken apps with no clear responder. “The integration is down” is a very different sentence when there is a named owner versus when there is not. Without ownership, broken applications drift, and small outages become long ones.

And, of course, the headline question: nobody owns your BTP. When that is true, it is usually the first domino. Everything above tends to follow.

These are not hypotheticals. They are the patterns SAP customers run into repeatedly as their BTP usage scales beyond the first proof of concept. The encouraging part is that every one of them is preventable. A governance framework is simply the discipline of deciding the answers up front instead of discovering them under pressure.

The Reference Account Model

The foundation of BTP governance is the account model. Get the structure right early and most of the symptoms above never get a chance to take hold.

SAP BTP organizes resources in a hierarchy. At the top sits the global account, which represents your contract with SAP and holds your purchased entitlements and quotas. Beneath it, optional directories act like folders that group and manage sets of sub-accounts. And sub-accounts are where the real work happens: you deploy applications, consume services, and manage members, authorizations, and entitlements there. (SAP Help Portal, Account Model)

Start With Staged Development Environments

In the cloud, just as on premise, SAP recommends a staged development process so that changes are qualified before they reach production. In practice that means one global account with a separate sub-account for each stage. (SAP BTP Best Practices Guide, Setting Up Your Account Model)

Keeping these three apart is not bureaucracy for its own sake. It is what prevents a development experiment from corrupting production data or knocking a live integration offline. The separation is the safety rail.

A useful aside from the field: if you are running the Kyma runtime, you may not need three full sub-accounts. SAP notes that you can combine DEV and TEST and use namespaces inside a cluster to create separation, since each Kyma sub-account maps to one cluster. The principle holds either way; only the mechanism changes.

Then Layer in Sub-accounts for Real-World Needs

Once the dev/test/prod spine is in place, sub-accounts become your main tool for reflecting how the organization actually operates: separate by project or scenario to keep access rules clean, separate by team to make ownership obvious, vary trust configurations where different identity providers are needed, carve out high-security subaccounts for sensitive apps, and share central services such as SAP HANA Cloud, SAP Integration Suite, or SAP Build Work Zone from a dedicated subaccount rather than duplicating them. (SAP BTP Best Practices Guide, Sharing SAP BTP Services)

When the count of sub-accounts starts climbing, that is the moment to introduce directories as your primary structuring mechanism, and to manage users and entitlements for whole groups of sub-accounts at once.

Adopt a Naming Convention on Day One

This is the cheapest discipline with the highest payoff, and the one teams most often skip. A consistent naming convention turns a landscape you have to investigate into one you can read at a glance. A workable pattern:

<org>-<businessunit>-<stage>-<purpose>

Examples:
abc-fin-dev-payments
abc-fin-test-payments
abc-fin-prod-payments
abc-shared-prod-integration
abc-hr-prod-higsec-payroll

Directory grouping:
abc-fin   (contains all Finance subaccounts)
abc-hr    (contains all HR subaccounts)

Pick the segments that matter to you (stage, business unit, region, sensitivity), fix the order, and never deviate. Pair it with labels on sub-accounts and directories for flexible reporting that cuts across the hierarchy.

The Five Pillars of BTP Governance

A clean account model is the skeleton. These five pillars are the muscle that keeps it functioning as the platform scales. Each one below pairs the principle with a concrete guardrail you can implement.

1. Identity and Access Management

Governance starts with deciding who can access what, and under which conditions. Federate BTP with a trusted identity provider, typically SAP Cloud Identity Services (Identity Authentication), or your corporate IdP over SAML or OAuth, so that people authenticate with corporate credentials and MFA under a single point of control. Avoid leaving production sub-accounts trusting only the default shared SAP ID Service. Application-level technical roles are then aggregated into business-level role collections, and access is granted on least privilege. (SAP Help Portal, SAP BTP Security)

The part teams skip is the recurring review. Access granted in month one is rarely the access still needed in month twelve. Build periodic access reviews into the governance calendar so stale and over-privileged assignments get caught on a schedule rather than during an audit.

2. Entitlement Management

Entitlements define which services are available where, and quotas define how much. Both are managed at the global account level and distributed down through directories to sub-accounts, which is where they are finally consumed. When you remove a quota from a subaccount, it returns to the global account pool and can be reassigned. (SAP Help Portal, Entitlements and Quotas)

A governance process needs a clear, documented workflow for requesting, approving, and tracking entitlements, to avoid both over-allocation that inflates cost and under-allocation that blocks teams. Only global account administrators can configure entitlements for sub-accounts and managed directories, so name those administrators explicitly rather than leaving the role implied. (SAP Help Portal, Managing Entitlements and Quotas Using the Cockpit)

3. Cost Monitoring and FinOps

BTP consumption is metered, which means weak governance translates directly into spend you did not plan for. Because consumption is tracked at the sub-account, directory, and space level rather than per application, your account structure is also your cost-allocation structure. That is the strongest practical argument for giving each major project or business unit its own subaccount: usage becomes legible, and you can finally say Project A consumed sixty percent and Project B forty, instead of guessing.

Guardrails that work: align sub-accounts and directories to cost centers so chargeback is accurate, set internal credit budgets per team, configure consumption alerts before a team hits its ceiling, and run regular cost reviews. If one project consistently overruns, redistributing or buying more capacity should be a conscious decision, not a month-end surprise.

4. Security and Compliance

SAP publishes a continuously expanding set of SAP BTP Security Recommendations covering the configuration of its services. Treat that list as a baseline to measure against, not a one-time checklist. A starter set of controls that belong in nearly every governance model:

Compliance obligations such as GDPR or SOC 2 belong in the model from the start, not bolted on after the first finding. It is far cheaper to design for them than to retrofit them. (SAP Learning, Architecting Security for SAP BTP) 

5. Ownership and Accountability

This is the pillar that answers the question in the title. Every sub-account, application, and service instance should have a named owner. A RACI model removes the ambiguity that lets incidents drift, and it means that when something breaks, the responder is already known. Ownership is also the cheapest control on this list: it costs a spreadsheet and a decision, and it prevents more chaos than any tool.

A starting RACI for the most common BTP governance activities (adapt the roles to your org):

What Not to Do: Governance Anti-Patterns

The failure modes are as predictable as the symptoms. Watch for these, because each one feels reasonable in the moment and costs you later:

Bringing It Together

BTP governance is not a project you finish. It is a discipline that grows with your platform footprint. The good news, and the throughline of everything above, is that the failure modes are entirely preventable: unclear ownership, security gaps, runaway cost, and blocked teams all dissolve when the right structure and accountability exist before the sprawl does.

Invest early in a clean account hierarchy, a naming convention, named owners backed by a RACI, documented entitlement workflows, a measured security baseline, and cost visibility tied to your subaccount structure. Do that, and BTP stays what it is meant to be: a controlled, secure, and cost-efficient foundation for your SAP landscape.

So when someone on the next incident call asks who owns your BTP, the answer should be immediate, specific, and confident. Governance is what turns “nobody” into a name.

Download the BTP Governance Toolkit

Designed by SAP practitioners, this toolkit provides field-tested guidance, governance checklists, and best practices for SAP BTP programs.