insiderBOOKS Articles and Insights

blog
Performance / Forecasting and Planning

Upgrading SAP Access Control? Here’s What You Need to Know

GRC expert Gary Prewett recently answered questions from SAP customers in a live, hour-long chat on SAPinsider Online. Below is an edited selection of the Q&A, covering topics such as version considerations for existing SAP customers and what to consider with a completely fresh SAP Access Control upgrade,

 

Q: If you're considering an SAP Access Control upgrade, are there any reasons for implementing version 10.0 instead of 10.1?

Gary Prewett: Great question. I can think of some good reasons to run version 10.0 in lieu of 10.1, but not that many. The primary reason I can think of is if a customer is trying to install it on an older version of SAP NetWeaver (they could be running in a shared landscape, which is not recommended, or only have older versions of SAP NetWeaver certified to run in their production environments). Version 10.1 requires SAP NetWeaver 7.4 SP04. That said, there are a lot of bug fixes in SAP Access Control 10.1, and they’ve spent a lot of time enhancing the user interface and making functionality improvements. For these reasons, I’d strongly recommend going with version 10.1 unless there is a compelling reason not to run SAP NetWeaver 7.4.

 

Q: For an upgrade from SAP Access Control 5.3 to 10.1, what will happen to current rule sets and modifications as we add new 10.x rule set updates?

Gary Prewett: This is a common question for users considering an upgrade. You definitely have the ability to export your existing rule set from version 5.3 and import that into your SAP Access Control 10.1 development system — the migration guide documents the steps needed (Analytics > GRC > Access Control > Release 10.1). You’ll want to make sure that you do this after your 10.1 solution configuration is completed (i.e., after your BC Set activation, which configures the SAP-delivered rule set). The good news is that rule set changes since then are released as incremental changes and should not overwrite your rule set, unless you happen to have caught these fixes independently. In that case, you can always extract the incremental updates and validate against your existing rule set.

And if you’ve been applying the access risk rule update notes all along in your SAP solutions for GRC 5.3 landscape, there should be no need to make rule set changes. Check SAP Notes 1809810 and 1960531 for more on rule set updates.

 

Q: We are a green-field site and plan to implement SAP Access Control 10.1. What are some of the pitfalls and challenges?

Gary Prewett: So, great question. This depends on what's in scope for your implementation, but generally speaking your biggest challenges are more compliance-related than technical. Common technical challenges include:

1)     Spend the time to make sure your hardware is sized appropriately.

2)     I'd recommend running dedicated hardware. A lot of customers with shared GRC landscapes run into compatibility issues with support packages, notes, etc. in a shared landscape.

3)     Firefighter log sync issues: This is a common problem you need to have roles assigned to Firefighter users (or roles, in a role-based EAM scenario) with transaction codes defined in the menus. Granting a Firefighter role with S_TCODE = "*" and no menu defined will not sync Firefighter activity. You may need to spend some time redesigning scenarios.

If you are a public company, you may have noticed your external auditors questioning assumptions and findings, and this will be extended to your SAP Access Control environment. Common compliance challenges include:

1)     Business requirements. You should definitely spend some time thinking through your business requirements prior to implementing. You may not have the concept of role owners or risk owners or process owners in your organization — be sure to think through these.

2)     Change management. Any changes to your rule sets should be appropriately documented and ties to an existing control approved by the auditors, or ties to a risk assessment.

3)     Think through your technical controls as well. A lot of your GRC configuration options can adversely impact your GRC-based controls. You probably want to include these in your audit reviews.

GRC configuration settings are discussed in detail in the master guide (available via the instguides link mentioned above).

Popular Chapters

View More
  • Chapter 7: Phase Four: Transition

    In the final phase, transition, we go through what you can expect at go-live, followed by lengthy discussions regarding service level agreements, operations process training, and transition to cloud operations. We talk about intricacies of system stabilization and monitoring. Finally, we explore the options for business continuity and security

    Read More
  • Chapter 6: Phase Three: Build

    In the third phase, build, we walk through developing proofs of concept for your project. The chapter discusses how to take advantage of a provision-shared infrastructure, as well as strategies for building and testing that infrastructure. There is an examination on how to build and mitigate databases and applications, as well as planning the phase cutover. It also looks at automated provisioning and automated services.

    Read More
  • Chapter 5: Phase Two: Model

    The second phase of moving SAP to the cloud, model, contains an overview of the second half of onboarding to the cloud. It examples infrastructure requirements and design and walks the reader through the process of developing a workload analysis. The chapter discusses application and business process discovery as well as operational run books and migration strategy.

    Read More
View More