Direct answer

Define security scope by identifying business roles and responsibilities, the applications and activities each role needs, organizational restrictions such as company code or plant, segregation-of-duties concerns, approval and provisioning processes, emergency access, testing expectations and post-go-live ownership.

Begin with workplaces and responsibilities

A security design should answer who performs which business activities. SAP’s authorization guidance for S/4HANA Cloud recommends designing productive business roles around identified workplaces and refining access through restrictions. That means project teams should understand real responsibilities before they assemble technical permissions.

ROLE DESIGN WORKSHOPJob responsibilityRequired activitiesOrg restrictionsControl conflictsBusiness owners define legitimate access; security specialists translate it into enforceable roles and restrictions.
Role design is a business-control conversation before it becomes a technical configuration task.

Least privilege is a scope principle

Security scope is not “give everyone what they had before.” SAP describes restrictions that limit access by organizational entities such as company code, plant or sales organization, supporting least privilege. The project should therefore define not only which app or action a role needs, but where that access is valid.

Include governance, not just role build

Access request, approval, provisioning, role ownership, periodic review and emergency-access handling are part of the operating model. If these processes are excluded, the implementation may technically create roles but still leave control gaps after go-live.

SECURITY SCOPE LAYERS1. BUSINESS RESPONSIBILITY — what the person is accountable for2. BUSINESS ROLE — apps and activities required3. RESTRICTIONS — where the access applies4. CONTROLS — conflicts, approvals and review
Security scope becomes clearer when access is traced from business responsibility through role, restriction and governance.

Testing belongs in security scope

Roles should be tested against positive and negative expectations: users can perform authorized work and cannot perform prohibited work. Testing should also consider organizational restrictions, cross-role combinations and the impact of multiple role assignments. SAP warns that combined roles can broaden effective restrictions, so the project should validate real assignment combinations.

Think like a consultant

Ask the process owner to explain why a role needs an activity, where it should be allowed and which conflicting responsibility must remain separate. If access cannot be justified in business terms, it should not enter the productive design by default.

Official SAP References

SAP Help — Authorization ConceptSAP Help — Authorization Model

Connect security to the project design.

Solution BlueprintReporting Scope