SAP Analytics Cloud (SAC) has become an important part of the modern SAP analytics landscape. For organizations moving from traditional reporting and planning environments into the cloud, SAC is increasingly becoming the place where business users consume analytics, build dashboards, perform planning and make decisions.
For SAP Security consultants, SAC is not just another SAP application that needs users and roles. Principles such as least privilege, role-based access, identity lifecycle and segregation of duties remain relevant in SAC, but the way they are applied is different.
To understand SAP SAC Security, I recommend to first understand how SAC came into existence, what it changed in the SAP analytics landscape and why its security model cannot simply be copied from an older SAP application.
How SAP Analytics Cloud Evolved
SAC is not a product that suddenly appeared in the SAP portfolio. Its evolution goes back to SAP Cloud for Planning, followed by SAP Cloud for Analytics. The product was subsequently known as SAP BusinessObjects Cloud before becoming SAP Analytics Cloud.
Enterprises migrated to SAC from very different directions. Some organizations have long-standing SAP BusinessObjects environments, and others have used SAP Lumira, SAP BW, Analysis for Office or a combination of these technologies. Many newer landscapes are being built around SAP S/4HANA, SAP Datasphere and SAC.
SAC is not a replacement to all these analytics platforms and SAP continues to support these products and provides different migration and integration paths depending on the technology and use case. Further, SAC can also work with existing SAP BusinessObjects environments, including supported live connections to BusinessObjects universes and Web Intelligence content.
The important point for a security consultant is that a migration from an older analytics platform to SAC should not be treated as a simple security-copy exercise.
What Changed for the Security Consultant?
Traditional SAP Security often revolves around a familiar model, referred to as RBAC which is roles, transaction codes, Fiori Apps, authorizations, and organizational values which determine the scope of access.
SAC still has users, roles and permissions, but the security picture extends further.
A user may have permission to open a story but should not necessarily have access to all underlying data. A user may be able to access a model but only see selected dimensions or members. A planner may need to change data for one business unit while being restricted to read-only access elsewhere. An administrator may have much broader capabilities than a business user.
SAP’s current documentation describes security across authentication, users, teams, roles, model security, Data Access Control (DAC), file permissions and auditing. This means that the consultant needs to think about effective access, not simply assigned access. Assigned access tells you what has been granted.
Effective access asks what the user can actually see and do after all relevant security controls are taken into account.
That is the mindset shift that makes SAC security easier to understand.
Start With the Business Requirement
A common mistake in any authorization project is to begin with the available roles.
SAC makes this particularly easy because the platform provides standard application roles such as Viewer, Modeler, Planner and various administrator or content-related roles.
SAP recommends using standard roles as templates for creating custom roles rather than directly assigning the standard roles as the long-term enterprise design.
For a security consultant, however, the more important principle comes before role creation. Start with what the user needs to do.
Imagine a regional finance manager who needs to use SAC for financial planning. The manager may need to view actual financial information, enter forecast data and review planning results. At the same time, the manager may need access only to one region and should not be able to administer users or change security settings.
Those are the actual security requirements. The role is simply the mechanism used to implement them.
This is why good SAC security design begins with the business process and the sensitivity of the data rather than with the role catalogue.
Users, Teams and Roles
The first layer of SAC authorization is familiar: users need identities, and those identities need permissions.
SAC supports user creation and provisioning through different mechanisms, including identity-provider scenarios and SAML-based mappings.
The next important concept is the team.
SAP specifically recommends assigning roles to users through teams rather than individually assigning roles to users for security reasons. SAP also recommends assigning custom roles rather than standard application roles.
For a small SAC tenant, direct user assignments may appear manageable. At enterprise scale, they can become difficult to govern.
Consider an organization with thousands of SAC users across finance, sales, HR and operations. If every user receives individual role assignments, the security team eventually has thousands of separate access decisions to understand.
A team-based approach can provide a stronger relationship between organizational responsibility and authorization.
For example, a company might have teams representing corporate finance, regional finance, sales planning and SAC administration.
However, teams do not automatically make an environment secure. A poorly designed team can distribute excessive access to everyone in the team.
The consultant therefore needs to ask two questions:
Why does this user belong to the team?
and
What access does membership in that team provide?
Roles Are Only One Part of SAC Security
Roles determine permissions and capabilities, but they do not necessarily determine the complete scope of business data available to a user.
SAP supports model-level security and Data Access Control (DAC). Model Data Privacy can determine whether model data is visible to users other than the owner, while DAC can restrict read and write access to individual dimension members.
Consider a global sales model containing data for India, Germany, the United States and Singapore.
A corporate finance executive may require visibility across all regions. An India finance manager may need access only to India.
A planner may need write access to selected planning data but only within their business unit.
All three users may have access to the same SAC environment, but their effective data access should be different. This is why a security consultant should separate two questions:
What can the user do?
and
What data can the user see or change?
The first is primarily an authorization question, and the second is a data-security question.
In SAC, the two need to be designed together.
Understanding Model Data Privacy and DAC
For someone new to SAC, Model Data Privacy and Data Access Control can initially appear similar. They solve different parts of the problem.
Model Data Privacy determines whether model data is visible and allows access levels such as Full Data Access, Limited Data Access and No Data Access.
Data Access Control can then be used to restrict access at the dimension-member level. This is useful when different users or teams need different portions of the same model.
For example, a company may have a single financial model containing multiple company codes. Instead of creating separate models for every business unit, the organization may use data-access restrictions to control which members each population can access. This can make the model architecture more manageable, but it also makes security analysis more important.
SAP documents that model-level permissions and user or team permissions can overlap and recommends checking for these overlaps when configuring model data access.
There is another important point for consultants: broad privileges can change the effective outcome.
SAP documents a Full Data Access role configuration that grants access to data across models regardless of how the role’s individual model access was otherwise defined.
This is why a consultant should never review DAC in isolation.
A good security review considers roles, teams, model access and DAC together.
Planning Adds Another Dimension
SAC is not limited to reporting and visualization. Planning introduces the ability for users to modify business information. That changes the security requirement considerably.
A finance executive may need to see a forecast. A regional planner may need to enter forecast values. A central planning team may need to review and approve the results.
These users should not necessarily receive the same permissions.
SAC supports security controls for planning models, including read and write access through Data Access Control and other planning controls. The consultant therefore needs to distinguish between users who consume information and users who can modify it.
This distinction becomes particularly important for financial planning, workforce planning and other processes where changes made in SAC can influence management decisions.
A security consultant should therefore ask not only:
Who can see this data?
but also:
Who can change it?
That question is easy to overlook when SAC is initially presented as an analytics platform.
SAC Security Does Not End at the SAC Tenant
This is where SAC becomes particularly relevant to experienced SAP Security professionals.
SAC often sits within a larger landscape involving SAP S/4HANA, SAP BW, SAP Datasphere and other data sources.
The security consultant therefore needs to understand the complete path between the user and the business data.
A simplified view is: User → Identity Provider → SAC → Data Platform → Business Data
The important question is: Where is the authorization decision actually being enforced?
In SAC and SAP Datasphere seamless-planning scenarios, SAP documents security responsibilities across both platforms. SAC Data Access Control remains applicable to data stored in Datasphere, while reporting on analytical models is secured through Datasphere as well as the appropriate SAC roles.
This means an SAC security review should not automatically stop at SAC. If the underlying data platform is enforcing part of the security model, the consultant needs to understand that layer as well.
This is particularly important when a project team says, “The user is already authorized in S/4HANA.”
That statement may be true, but it does not automatically answer whether the user’s access to the SAC representation of that data is appropriate. The connection architecture, data movement and authorization enforcement point all matter.
What About BusinessObjects and Lumira Security?
This is another area where consultants working on migrations need to be careful.
The security concepts used in a traditional SAP BusinessObjects environment do not map one-for-one to SAC.
BusinessObjects environments may involve platform security, folders, universes, documents and other content-level controls. SAC has its own security model involving roles, teams, models, dimensions, content and data access.
At the same time, SAC can still integrate with existing BusinessObjects environments. SAP currently documents both imported and live connection scenarios involving BusinessObjects universes and Web Intelligence content.
Therefore, a migration project can involve two security worlds for a period of time.
That creates a practical requirement for consultants: understand which system is authoritative for identity, which system controls access to the underlying data, and which platform controls access to the analytical content.
The migration should be designed around those answers rather than assuming that the old security model can simply be copied into the new platform.
Privileged Access Matters
An administrator is not simply another SAC user with a larger role.
A highly privileged user may be capable of changing users, teams, roles, content or other security-relevant configuration. SAP’s standard roles illustrate this difference: administrator roles contain substantially broader permissions than viewer-oriented roles.
For the security consultant, the important question is therefore not only:
Who has Admin?
It is:
Who can change the security boundary?
Those users deserve additional attention during design and periodic review.
The same principle applies to roles that provide broad data access. If a user can bypass or materially broaden the restrictions carefully established through model and dimension-level controls, that user belongs in the privileged-access discussion.
Technical Identities Should Not Be Forgotten
Modern SAC environments can also involve APIs and automated integrations.
SAP supports programmatic role assignment and user/team provisioning through APIs, which means not every access path is necessarily associated with a human administrator clicking through the SAC interface.
Technical identities should therefore be treated as part of the security model.
The consultant should understand their purpose, ownership, permissions, authentication method and lifecycle.
An integration that was created for a temporary project can become a permanent technical identity unless someone takes responsibility for removing or reviewing it.
This is not unique to SAC, but cloud analytics environments can make these identities easy to overlook.
Auditing Is Part of Security
A security design should also provide a way to understand what happened after access was granted. SAC provides auditing capabilities for activities and data changes as part of its broader security framework.
For a security consultant, this means asking whether the organization can identify relevant administrative actions, understand important data changes and retain sufficient evidence for its security or audit requirements.
The precise requirements will depend on the organization’s regulatory environment and internal controls, but the principle is universal:
If access matters, the organization should also consider how that access and relevant activity will be monitored.
What Should a Security Consultant Review?
A beginner does not need to memorize every SAC permission before participating in an implementation.
A structured review is more useful.
Start with identity. Understand authentication, provisioning, external users, inactive accounts and technical identities.
Then review roles and teams. Determine what users receive directly, what they inherit through teams and whether the resulting permissions match their business responsibilities. SAP recommends team-based role assignment for security reasons.
Next, understand the models. Identify which models contain sensitive information and how Model Data Privacy and model access are configured.
Then review Data Access Control. Determine whether users should see all dimension members or only a defined subset.
After that, review planning and content access, particularly where users can modify data or where stories and datasets contain confidential information.
Finally, examine privileged access, integrations, auditing and ongoing governance.
The objective is not simply to produce a list of roles. It is to determine whether the effective access makes sense.
Common Mistakes for New SAC Security Consultants
The most common mistake is treating SAC as if it were simply another S/4HANA authorization exercise. The security principles are familiar, but the objects and enforcement points are different.
Another mistake is starting with roles before understanding the data. A consultant cannot determine whether access is excessive without knowing what the model contains and who should see it.
A third mistake is treating Data Access Control as the complete security solution. DAC is powerful, but SAP’s documentation makes clear that model and role-level permissions also influence effective access.
It is also easy to overlook teams, privileged users, technical identities and content sharing.
Finally, security is sometimes treated as a go-live activity. In reality, users change jobs, teams change structure and business requirements evolve. A security model that was appropriate at implementation can become excessive later.
Conclusion
SAP Analytics Cloud represents a significant evolution in SAP’s analytics landscape. Its roots can be traced through SAP’s cloud planning and analytics offerings, while its current capabilities span analytics, planning, data access and content consumption.
For SAP Security consultants, the important lesson is that SAC should not be approached simply as another application that needs roles.
The security model is broader.
Users, teams and roles remain important, but the consultant also needs to understand model security, Data Access Control, planning access, content sharing, privileged users, technical identities, integrations and auditing.
Most importantly, the consultant needs to understand the difference between assigned access and effective access.
A role may look appropriate on paper while the user still has access to more data than intended. A carefully configured data restriction may be affected by a broader privilege. An SAC story may expose information to a wider audience than the underlying business requirement allows. And in an integrated landscape, the actual authorization decision may be taking place outside SAC.
That is why the best starting point for SAC security is not the role catalogue.
It is the business question:
What should this user be able to see and do, and where should that access be enforced?
Once that question is answered, the technology becomes much easier to understand.
For the SAP Security consultant, that is the real transition from traditional authorization administration to SAP SAC Security.
