Should we use our own SOD rules or take the standard Rules provided by the Risk Analysis and

Remediation tool? There are good reasons to go either route, though we would generally advise on taking the standard rules as the starting point.

Dependent on what the timescales / objectives are limited or for continuous compliance. Always recommended to customise standard Ruleset to your business environment.

Does GRC AC 10.0 require it's own systems and architecture?

Yes, the GRC 10.0 release is an SAP system in it's own right. It will have it's own system ID and need to have its own space within your solution architecture. Since it is based upon ABAP with a Business Client frontend, it also needs to follow your standard architectural standards including pre-production and development systems. It will require connections into the wider solution landscape in a similar manner to Solution Manager and therefore care should be taken to ensure that it is appropriately defined in the system landscape directory.

Is there an upgrade path to GRC Access Controls 10.0

Not directly.The architecture of GRC AC 10.0 is based upon the ABAP platform and therefore it it not possible to technically upgrade from the previous versions on to version 10.0. However, SAP have provided migration tools from the 5.3 release to aid in transfering any data that you have in version 5.3. If you are on a previous version such as 5.2, then the standard migration path is to upgrade to 5.3 and then use the migration tools to transfer content into version 10.0

Does GRC AC 10.0 integrate with Process Controls and Risk Management?
Absolutely. The architectural shift back to ABAP for the Access Controls system allows the GRC products to co-exist in the same system. You can activate the Access Controls, Process Controls and Risk Management modules in the same system and share common master data elements between them to produce a much more tightly integrated solution. THe user interface is the same as well since the Netweaver Business Client (NWBC) is dynamic basd upon your authorisations. Simply adding the authorisations for the required modules from all of the systems, allows you to access both Process Controls and Access Controls from the same screens.

What is SAP BusinessObjects Risk Analysis & Remediation (RAR)?

Risk Analysis and Remediation (RAR) is the core module of SAP's BusinessObject Access Controls suite. Its primary function is to support the management of Segregation of Duties (SoD) controls and monitor Critical Transactions across an ERP system. RAR holds the rules for what is deemed to be a risk to the business. Using RAR you can produce analytical SoD reports on selected users, user groups, roles and profiles and can also produce reports on critical actions, critical permissions, critical roles and profiles. This is all based upon the rules defined within the tool. RAR is designed to allow all key stakeholders to work in a collaborative manner to achieve ongoing SoD and audit compliance. Risk analysis reports provide real-time data and Management reports retain an offline history of SoD status. RAR also has Simulation features to allow you to assess the impact of potential remediation activities on the reported conflicts prior to making the actual change.

What is SAP Business Objects Superuser Privilege Management (SPM)?

SAP SPM is the component of Access Controls which handles temporary elevated access. SPM allows you to define super users, or Firefighter accounts, and assign them to users to perform activities outside of their business as usual authorizations. Any activities performed with the Firefighter user IDs are automatically logged and can be delivered to defined controllers to review the access which has been used. This component is normally used for Emergency Access or High privilege authorizations.

Who will need to be involved in a SAP GRC project, and what time commitment will it require?
Basis & SAP Security team, Business managers, Internal/ External Audit

Basis team will need to be involved to a limited degree when the actual installations take place, though are not usually required much after this period. Business Process owners will need to devote time regularly throughout the project, attending workshops on Risks and Approval workflows for example. Internal/ External Audit should be involved at regular intervals as well, contributing advice on SOD risks and connected mitigating controls for example. Most businesses find that a small, dedicated GRC team is the best way to proceed, bringing in business owners on an ad hoc basis.

How long will my SAP GRC Project take?

Of course this will depend on a number of factors, like what modules you are implementing, what your objectives are, and the state of the security design and internal resources you have.

In general the expectation should be for 3 months plus for a complete Compliance Calibrator project. Firefighter and Role Expert projects will take at least 1 month. Access Enforcer projects are more likely to be similar in timescale to Compliance Calibrator. The implementation and configuration is not actually the most time consuming part of these project, generally it is the security remediation and mitigation phases that will consume 60% plus of resources.