Key Answers (FAQs)

Although the type of audits performed and the associated objectives may differ between internal and external audit, the process followed by both parties is very similar. Whereas the timing of an external audit of the financial statements is based upon a company’s financial year-end, a programme of internal audits is planned over a longer term dependent upon company activities (e.g. system implementations, mergers and acquisitions etc.), and a view to rotating the focus on specific information systems based upon criticality. Once the timing, scope and objectives of the audits have been planned, all audits will undergo fieldwork activities (e.g. interviews, sample testing, system interrogation etc.) to provide an assessment of the internal controls and processes in-scope. The results of the audit will then typically be documented within an audit report, with a ‘close out’ meeting held with all of the relevant stakeholders to discuss the findings and agree on the details and timing of any required remediation activities.

There are formal training courses available from SAP at their training centres (where we provide the instructors)

• Turnkey Consulting can also do “onsite” training courses organised through SAP.
• Turnkey Consulting can also arrange for more ad hoc training sessions as part of the project plan.

Please call for further information, and we would be happy to work with you to understand requirements and recommend a training path.

The advantages of upgrading are summarised below:

- Analysis authorizations are custom-tailored for authorization requests from a BW system
- More flexibility to allow for changes in the data model
- No restriction on number of authorisation relevant characteristics (previously 10 per infoProvidor)
- Direct assignments of authorizations on navigational attributes
- Enforces a more consistent authorisations design
- Significantly improved trace and error analysis tools
- Integration of hierarchy authorizations
- Direct and indirect user assignment
- New functionalities like integrated planning require analysis authorizations
- Supported!

Risk Management is an SAP application which forms part of SAP's Business Objects GRC solutions. It enables an organisation to manage their enterprise risks with greater transparency and awareness, allowing corporate performance to be optimized whilst adhering to regulatory and policy compliance requirements.

Effective risk management can help improve strategic planning and decision making within an organisation, which can create significant value for an enterprise when performed as part of a unified GRC solution.

The SAP Business Objects Risk Management application enables an organisation to develop an automated and proactive risk management practice - ensuring identification and monitoring of critical risks, analysis of risk-reward tradeoffs using both qualitative and quantitive data, and the creation of resolution strategies for those risks which maximise return on investment.

The basic answer is that it will depend on the licence structure you have with SAP

• Software is basically dependent on Revenue & structure of your individual licence agreement with SAP.
• Hardware is dependent on whether you install on your current system, or use this as a pilot development on a new Netweaver environment.
• Consulting costs are generally provided on daily rate, though this is variable depending on length of project.

Please contact your SAP Account manager to get the right SAP Sales person for your area to provide the software costs. For further information on GRC consulting costs please contact us.

CCM is a solution to continuously monitor automated controls in real time. A good example are controls based on configuration settings. Using CCM a control owner can be notified when these settings change. Controls monitored by this solution save time and money to the organisation, as they are triggered only when needed, allowing the process and control owners to focus on other tasks in the mean time.

Semi-Automated controls where for example a system generated report needs to be reviewed and signed-off, can also be monitored using CCM.

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.

To discuss this in more detail please get in touch, and we can either assist your team in preparing a Rules management plan or just provide some simple pointers.

The standard methodology is to implement Risk Analysis and Remediation (Compliance Calibrator) first, as this is the Hub system

• There are actually a number of different ways you can implement dependent on what your current environment is, and what you project deadlines are.
• In order to be confident in any implementation methodology we would advise you get some advice prior to starting.
• There are a number of inter system dependencies between GRC modules which will affect your planning.

This area is highly complex, and dependent on a huge number of variables.

What is the standard methodology might well not be the best route for your requirements or environment, so we would stress that this should be considered in detail before committing to an action plan.

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.

If you would like some customised advice on timescales you should expect, please get in touch and we can assist you in putting together a more accurate model.

Absolutely not! The auditor/consultant does not require, nor should they ever request, full access to the production system. In fact, they only require display access in order to perform the reviews involved in an SAP audit.

Some SAP default profiles (e.g. S_A.SHOW) can provide most of the display access necessary to use the SAP transactions required to perform their work. Where required, additional display access can be supplemented to the auditor/consultant user ID. A list of required access should be provided to the client prior to the audit start date to make the auditors/consultants time on site as efficient and productive as possible. Short answer is do not grant full SAP access to the auditor.

As this is relatively new technology and a slightly different approach to responsibility for Security there is a lot of confusion over skills your core project team will need.

• Project management skills, and preferably some experience of GRC would come top of the list of key skills. Project success tends to depend as much on knowing what doesn’t need to be done as what does need to be done.
• Good understanding of general Risk management, as GRC projects are aimed at a far more integrated approach than managing SAP Security by itself.
• Reasonable understanding of SAP Security is preferable, but this really only has to be a basic understanding
• More important is a good understanding of SAP Business Processes, and in particular how they used in your environment.

If you would like more advice please get in touch and we can discuss the key skills required, and map out a training plan for your team members.

We have assisted a number of organisations putting a formal business case together to quantify the ROI from GRC investments

• Have developed accelerators to expedite this process.
• Available to assist in customising this to your environment.

Generally we have found that the best way to put the GRC business case together / or to perform a product comparison is to be onsite. The reason for this is that it is possible to get a clearer picture of overall objectives and timelines, and feed this into a concise comparison of strengths/ weaknesses of the tools for individual objectives.

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.

If you would like some customised advice on exact skill sets required through your project lifecycle, please get in touch and we can assist you in putting together a more accurate model.

Time spent reviewing the effectiveness and efficiency of systems and processes is something that, although desirable, tends to be overlooked as management are too busy performing their day-to-day activities to become involved in initiating and performing such tasks.

A review by the internal audit function (internal or outsourced) is an opportunity for management to have their systems and processes reviewed without having to commit significant amounts of time or resources, whilst still retaining the level of contribution desired. The review, as well as highlighting existing strengths, can identify potential areas of weakness or inefficiency within a system or process based upon key risks. As a result, the internal control environment can be enhanced with the final audit report outlining areas for improvement and recommended remediation activities necessary, which can form the basis of a management action plan.

The term Segregation of Duties (SoD) is a security principle which aims to prevent fraud and errors by disseminating the tasks and associated privileges for a specific business process among multiple users. This ensures a user does not have control over an end-to-end process without any additional user intervention.

In SAP it is possible to achieve segregation of duties by controlling and monitoring access rights of users, to ensure a single user cannot execute two or more conflicting transactions. To do this, firstly a set of rules will need to be created to identify those incompatible functions which pose a risk and need to be reviewed (e.g. Post Journal Entries AND Maintain GL Master Data). Secondly, the corresponding access in SAP needs to be mapped to the individual functions so that those users with access to incompatible functions (known as ‘SoD conflicts’) can be identified and remediated as required.

Please find a full list of the different types of controls available in SAP in our full response. Click here to view it.

The 3 main types of review (SAP Basis, SAP Business Process & SAP SoD Review) can be performed entirely using audit tools and techniques existing within the SAP system itself. The type of tools available includes:

• System transactions – for example, transaction ‘SUIM’ allows the reviewer to search for users with access to sensitive system access. In addition, transaction SE16N (display only) allows the reviewer to view SAP tables to identify information such as authorisation groups in use, table protection levels assigned etc
• SAP logs – these allow a reviewer to search for sensitive actions performed in the system (e.g. last logon date for privileged system-delivered user IDs, date production client was last opened for change etc)
• SAP reports – these allow a reviewer to examine security configuration settings (e.g. report RSPARAM can be used to examine password parameter settings)

Therefore, external auditing tools are not essential. However, they can be extremely useful for reducing the amount of manual input required and making the review more efficient. This is most significant when analysing SoD conflicts in the system and/or reviewing assignment of sensitive access, particularly due to the fact there are normally several transactions which allow the same function to be performed in SAP and so each variable needs to be considered.

The precise resource and time commitment of an SAP audit will depend entirely on the scale of the audit proposed. As a guide each of the 3 main types of review (SAP Basis, SAP Business Process & SAP SoD Review) will take approx. 10–15 days for an auditor/consultant to perform.

Although the time commitment of resources from management will be minimal, there will be a requirement for their input in order to set up the auditor/consultant with the appropriate initial access to the system (and grant additional access where required during the audit). In addition, the auditor/consultant will need to discuss with management the procedural aspects of SAP administration (e.g. user administration, change management etc) and test the operating effectiveness of these processes which will require some evidence gathering by management.

Lastly, the findings will need to be discussed and validated before issuing a final report outlining strengths, weaknesses and recommendations. Therefore, input from client management (i.e. SAP Basis Manager, SAP Transport Manager, SAP Business Process Analyst etc) will be approx. a third of the total man days required for the audit (e.g. if the review took an auditor/consultant 15 days to complete a review then management would need to contribute approx. 5 days worth of resource time).

There are various definitions which exist describing the concept of auditing. In general though, an audit is a review for the purpose of independent verification. Exact definitions and objectives will depend upon the specific type of audit being performed (e.g. regulatory, statutory etc.), and the area of focus shifts according to the objectives of the audit meaning certain risk areas become under the spotlight. All of these factors will determine the auditor approach (i.e. what they will look for and how they will look for it).

The internal and external audit process is similar in many ways, to read the full response to the question please click here.

Although the role of an internal and external auditor will vary based on their functions, there are some key differences. Read the full response by clicking here.

An audit encompasses an independent review of a process, procedure or set of results to ensure their completeness, accuracy, integrity and security. Examples vary from the statutory audit of a company’s financial accounts to a compliance audit regarding the establishment of required health and safety procedures.

Internal audit is a function that, although operating independently from other departments and reports directly to the audit committee, resides within an organisation (i.e. they are company employees). It is responsible for performing audits (both financial and non-financial) within a wide range of areas within a business, as directed by the annual audit plan. Internal audit look at key risks facing the business and what is being done to manage those risks effectively, to help the organisation achieve its objectives. For example, they may look at risks to the company’s reputation such as the use of cheap labour in foreign countries, or strategic risks such as producing too many products in comparison to resources available etc.

External audit is an independent body which resides outside of the organisation which it is auditing. They are focused on the financial accounts or risks associated with finance and are appointed by the company shareholders. The main responsibility of external audit is to perform the annual statutory audit of the financial accounts, providing an opinion on whether they are a true and fair reflection of the company’s financial position. As part of this, external auditors often examine and evaluate internal controls put in place to manage the risks which could affect the financial accounts, to determine if they are working as intended.

SAP is a very large and complex ERP system, forming the platform for multiple inter-related business processes for those companies which utilise it. It is comprised of thousands of configurable tables making it highly flexible, and has a complex integrated security function. Therefore, SAP is a challenging environment to audit, particularly for those with minimal technical knowledge or appreciation of the business processes that operate within the system.

In order to gain maximum assurance from the system, the following 3 types of review would need to be performed (or they can be performed independently dependent upon the risks you wish to provide comfort over):

SAP Basis Review – covers access security (i.e. SAP authorisations) over sensitive system administration functions, configuration of security parameter settings and manual controls over system administration processes (e.g. user provisioning, change management etc)

SAP Business Process Review – covers both configurable (e.g. tolerance settings) and manual controls (e.g. reconciliations) within the business process under review such as revenue & receivables, procure to pay etc

SAP Segregation of Duties Review – covers both sensitive access and identification of incompatible duties within the business process under review.

CUP is a workflow engine focussed on the user access management processes. It allows you to define an approval process for different types of user changes and automate the provisioning of these changes based upon the decision of the defined approvers. The provisioning process can be automated through either direct or indirect role assignment as well as routing through a CUA system if required. You can also use CUP to remove access from users.

As well as this core functionality, CUP also supports periodic user access reviews and password self service to allow users to reset their own passwords.

$ values mean slightly different things, depending on where you encounter them.

If you are looking in a role, or at the contents of an authorisation profile, seeing a $ value would indicate that an organisation level has not been specified for that role, for example $BUKRS would show that company code org. level is not defined.

If you are seeing $BUKRS values in a GRC Access Risk Analysis, or within the rulset, this refers to an org. level field which is not specified, so the system will look for any value in that field. For example, 02 (change) access within ANY company code.

It is worth noting that GRC uses $ instead of * to indicate ALL values, when used in isolation.

The majority of checks for authorization in SAP are performed in the ABAP code with the AUTHORITY-CHECK ABAP statement.

If there is no AUTHORITY-CHECK in place for the authorization object (and subsequent logic for the response), then no check will take place.

SU24 allows us to effectively deactivate some authorization checks which have been coded, what it does not let us do is add in arbitary checks without the appropriate code.

User-Exits, BADI's, Enhancement Points are all potential ways of including additional checks and validation without modifying standard SAP code.

Analysis Authorizations are directly assigned to a userID in transaction RSECADMIN or via a PFCG role using the S_RS_AUTH object.

Use Transaction RSA1 to select the characteristics (InfoObjects) you wish to make Authorization Relevant. There is a checkbox on the Business Explorer tab that allows you to select whether or not the characteristic is authorisation relevant.

Transaction RSECADMIN is the main configuration transaction for Analysis Authorisations.

The new authorisations concept is activated in the IMG under the following menu path:

Business Intelligence>Settings for Reporting and Analysis>Analysis Authorizations: Select Concept

SAP BI7 (now BW7) introduces a new authorisation concept for reporting, Analysis Authorisations.

It is still possible to use the old authorisation concept in SAP BW7, but if you choose to do so then your authorisations will no longer be supported.

See note 1125108:
[…] Important: If you use the old 3.5 authorization concept in a BW 7.0 system, SAP does not accept any responsibility if errors occur after you make a change. Such problems are solved with the provision of the new authorization concept. […]

The standard PA authorisations P_ORGIN and P_ORGINCON do not have Personnel Subarea restrictions available unfortunately. The only standard options within these objects are Personnel Area, Employee Group and Employee Subgroup.

It would be possible to add an additional restriction using the Organisational Key field which allows you to essentially define a customised field restriction within the P_ORGIN or P_ORGINCON object. However, our advice is to try and work around the requirement as Org Key restrictions can get very complex and are difficult to maintain as a result.

The performance of SAP HR Structural Authorisations can be significantly improved by indexing the structural authorisations.

The following programs are involved in the optimisation process.

RHBAUS00 (transaction S_PH0_48000110) – Builds the structural authorisations into SAP Memory (table INDX) for users with an entry in table T77UU.

RHBAUS01 (transaction S_PH0_48000111) – Removes users with no entry in T77UU from the indexing table INDX.

RHBAUS02 (transaction S_PH0_48000112) – Add or removes users from the table T77UU.

The performance of the indexing program itself can sometimes be an issue for companies with a large organisational structure or with a lot of personnel records. Appraisal objects (BA) often tend to make up a large proportion of the structural population returned by a users' structural authorisations so it is often advisable to explore options other than using structural authorisations to return these. This can make it difficult to use P_HAP_DOC to restrict appraisals using the context sensitive option. A BADI is available as an alternative.

Tracking access to sensitive infotypes can be achieved using infotype audit logs and the infotype logging report - find out how by reading the full response here.

Most authorization object fields can be turned into Organizational Levels by using program PFCG_ORGFIELD_CREATE.

The procedure is detailed in OSS note 323817.

The key integration point between PC and AC is with the Risk Analysis and Remediation (RAR) component. Rules in PC can be configured to pull out user information from RAR. This integration is done via RFC connections.

Once the Real Time Agent (RTA) is installed in the back-end system, it communicated via RFC calls. The PC Automated control begins in the PC system calls the back-end system where appropriate records are retrieved. In some cases, subsets of records are copied back to the PC system, in other instances; summary information is written back to the PC system.

SAP GRC Process Controls is a tool designed to enable organisations have a continuous view over their key compliance activities across all business processes to ensure a high level of compliance to internal controls.

The tool serves as a central repository to the control framework. Within the PC tool it is also possible to alert control owners when controls need to be tested, store testing and sign-off evidence, create and delegate remediation plans, and keep an audit trail of changes to controls.

PC runs on the SAP Netweaver platform but interfaces with back-end SAP systems as well as other Netweaver solutions.

The UME is the User Management Engine within a Java system. In the same way as in any other Java System, the UME controls the user and their authorisations for the GRC component. You can define the roles and authorised "actions" within this application and assign these directly to users of the tool.

If integrating GRC with a Portal, you can use the same UME to operate for both application components.

The UME also acts as a data source for the GRC application components and can be used to define user master details for use when configuring the applications. An example of this is for the user's authentication for requesting access via CUP or to look up the users' email addresses. It is also used for assignments of approvers in the CUP workflow configuration.

Materials are assigned to Material Types and Material Types can be used to provide another level of restriction over and above organisational levels associated with Materials.

Authorisation Object M_MATE_MAR (Material Type) allows restriction by authorisation groups assigned to Material Types.

Transaction code OMS2 is used to assign authorisation groups to Material Types and these groups are entered into M_MATE_MAR to give the required access.

As with most of the implementations of the Authorisation Group concept, if there is no Authorisation Group, the check will not be performed for the Authorisation Object.

In the Authorizations tab of a role are the authorisation objects and their values.

These value sets form the profile authorizations which get loaded into the user buffer. To help monitor and manage the authorization objects in the roles, each authorization object set has an associated status.

• Standard: The authorization values in the role are the same as those configured in SU24 for the relevant transaction/s. When the relevant transaction/s is removed from the role menu, the corresponding authorization object/s are removed.
• Maintained: Where an object has been maintained for a transaction in SU24, but the values are not fully defined, the object appears in the role with one or more empty fields. When these fields are updated then the object status is "maintaned". As with objects in status "standard", removing the relevant transaction/s from the menu will result in the object/s being removed from the authorizations tab. Changed: When the authorization object values are changed from the proposal values configured in SU24, the object status is "changed". This removes the link between the object and the related transactions. If you remove a menu transaction the objects configured for it are in "changed" status, those objects will remain in the role. For this reason it is recommended that SU24 is configured correctly to remove the need to have authorization objects in "changed" status.
• Manually: Authorization objects can be manually added to roles to provide additional authorization over and above that configured in SU24. As with authorization objects in "changed" status, there is no link to any menu transactions. When used correctly, manually added authorization objects can be very effective in situations where updating SU24 is not desirable. If not documented or managed correctly they can also facilitate authorization creep in a build.

You can use transaction SPRO_ADMIN to create a project for a particular part of the IMG.

Using the profile generator, create a role and in the Menu tab select Utilities and Customising Auth.

Select the IMG project that has been created for a specific part of the IMG and the relevant transactions for the IMG activities un that project will be added into the role.

There are a number of reasons why you should be careful about granting of table display transactions in your production instance. Data from a single table may not show the "whole picture", or may be difficult to interpret, leading to forming inaccurate conclusions and making poor decisions.

If there is the requirement for an end user to display a single table then this can be provided in a secure manner without exposing other tables belonging to the same authorization group when accessing through SE16/SE17/SM30 etc.

A custom transaction should be created which uses SM30 to access specific table or view. This transaction can be assigned to a role in the same way as any other standard or custom transaction code.

There are a number of different versions of GRC which have different hardware requirements, but -

• In all likelihood you will be able to install the software on your systems if you are on SAP 4.7 / ECC5 and above.
• It would always also be advisable to perform some hardware sizing exercise, partially to measure expected performance impact on your current systems.
• There are a range of options here, and this will depend in part on your comfort with Java systems.

There is some hardware sizing material available from SAP Marketplace (Quicksizer) which is not a bad place to start in sizing you requirements.

The best way to do this is probably to contact an experienced SAP GRC consultant, who can advise on requirements over the lifecycle of your implementation, as well as talk you through the risks / benefits of different approaches.

The basic integration will normally be through Java Connectors to all of your production environment SAP systems, but there is a lot of flexibility and a range of target systems covered:-

• Compliant User Provisioning (Access Enforcer) in particular will integrate into LDAP’s.
• GRC can also connect to other ERP systems such as Oracle / JDE etc.
• GRC Integrates / complements SAP AIS.
• GRC Uses the Netweaver platform, so integrates with User Management Engine functionality.
• There is integration with SAP’s Netweaver Identity Management solution.
• Integrates to Cisco systems.

There are a lot of potential integration points from your existing solutions into the various GRC tools, from Portals to LAN IDs.

As it is based on Netweaver there is great potential to integrate with almost any platform, though you need to manage any serious customisation like this carefully.

The P_PERNR authorisation object is delivered in SAP HR (HCM) to enable Employee Self Service. Using this object users you can configure authorisations to allow users to update their own data without giving them access to update other user's data.

The P_PERNR object defines four authorisation fields:

AUTHC - Authorisation Level
PSIGN - Interpretation of Assigned Authorisation
INFTY - Infotype
SUBTY - Subtype

To restrict a user to accessing their own data only use the PSIGN value 'I' and specify the infotypes and subtypes the user should be able access together with the access level they should be allowed.

The following example would allow a user to update his / her own (main) Bank details without being able to change the Bank details of other employees:

AUTHC = W
PSIGN = I
INFTY = 0007
SUBTY - 0

The exclude option (PSIGN = E) in the P_PERNR authorisation can also be used in a number of other scenarios to enforce segregation of duties within the HR department.

A structural authorisation is an object that defines the population that a user can access. Structural authorisations can be used to define a part of the organisational structure that a user gets access to.

Structural authorisations are configured in transaction OOSB.

In SAP 4.7 upwards structural authorisations can be combined with standard HR authorisations to create context sensitive authorisations using object P_ORGINCON.

There are three key differences between standard SAP R/3 security and security in SAP HR:

Infotypes - Master data in SAP HR is held in infotypes. Since master data is the key data element on which users need to be restricted infotype restrictions become extremely important in the context of SAP HR.

Structural Authorisations - In SAP HR the population that a user can access can be restricted using either the enterprise structure (Personnel Areas, Employee Groups, Company Codes, etc) or the organisational structure. Structural authorisations allow restrictions to be configured on the organisational structure.

Personnel Number Restrictions - In SAP HR a special authorisation object (P_PERNR) allows users to be restricted to accessing infotypes for their own data only. This facilitates functionality such as Employee Self Service (ESS.) The P_PERNR authorisation can also be used to prevent administrators from maintaining their own data whilst still allowing them access to others.

In order to perform a comprehensive review of SAP security, display access to several SAP Basis transactions is required. This level of access can be permitted by assigning the SAP standard profile "S_A.SHOW". It is a profile, not a role, and so will need to be assigned to the auditor user ID within the profile tab using transaction SU01.

Please note: this will not allow access to download reporting results into excel format. Therefore, this access (object S_GUI, value 61) will need to be granted separately to the auditor's user ID.

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 authorisations. 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 authorisations.

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.

SAP BusinessObjects Access Controls is SAP’s suite of tools for managing the users access across an ERP Solution Landscape. It contains four primary components which each tackle a different aspect of access management issues.

RAR – Risk, Analysis and Remediation focuses on Segregation of Duties and Critical Access definition;

SPM – Superuser Privilege Management tackles the use of temporary elevated access;

CUP – Compliant User Provisioning assists to automate user provisioning and de-provisioning processes; and

ERM – Enterprise Role Management allows roles to be defined using the same design standards and methodology across all relevant ERP systems.

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.

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.

SAP GRC Process Control interfaces with back-end ERP systems in order to provide Automated Control Functionality. If the customer is running only Manual Controls and/or Surveys, then there is no interface needed to a back-end system. If Automated Controls are used, SAP provides Real-Time Adapters (RTAs) that are installed into the back-end ERP systems. RTA’s are available for SAP and non-SAP systems.

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.

We launched Fraud management together with SAP in the UK.

Turnkey Consulting has been specifically invited to be amongst the first partners to be trained on SAP Fraud Management, prior to training being generally available.

In all our offices in Africa, Australia, Germany, Middle East, United Kingdom and United States we have consultants trained by SAP in the Fraud Management product.

SAP fraud management has a build-in predictive analysis tool, which automatically predicts the key association based on existing fraud cases. It can be used to uncover hidden trends and patterns in large amounts of data to detect fraud in near real time.

After understanding the product functionality the best way is to arrange for a hosted proof of concept, which means no time and effort is spent on setting up the system.

No, SAP Fraud management uses the widely used SQL language to define the scripts.

With fraud management you can create an integrated process between your Fraud Management team and the business. It has functionality to manage the investigation, retain documents and report on the performance of your fraud management team. Graphical data representations can also be used to give instant insight in performance.

The real time calibration and simulation on current and historical data allows you to minimize false positives. Fraud management uses these 'heuristic' learning capabilities to reduce false positives over time.

The speed at which SAP Fraud management works also means you reduce the time genuine transactions are put on hold.

Yes, fraud management can support real-time transaction analysis. It can also be leveraged to stop or put on hold fraudulent transactions in the transactional application before they are concluded.

GRC products help you manage known and evolving fraud risks and controls.

Fraud management complements this by:

(1) targeting unknown areas of potential fraud.

(2) stopping fraudulent transaction before they are concluded.

(3) offering the ability to analyse millions of transactions in real time by using HANA in memory database technology.

No, fraud management can be integrated with other systems.

If you run other ERP systems and do not want to invest in another system for your IT department to manage, SAP offers a hosted solution as well.

The access of a user in an ABAP system is granted through the roles and associated profiles assigned to them. A role contains a defined set of access which is the same for any user assigned to that role.

If a user has different access requirements then they need to have a role developed to reflect their needs.

Depending on the specific requirement, it may be preferable to use an alternative control such as the periodic management review of a relevant report.

If your company has to undergo an annual statutory financial audit then it is likely that at least some elements of the SAP system will be reviewed by the external auditors as part of this process. Therefore, it may be a good idea to perform an internal audit of your SAP system earlier in the year to ensure the system controls are working as expected and uncover any weaknesses, and perform subsequent remediation activities, prior to the external audit taking place.

In addition, the timing and frequency of internal audit reviews do not have to be governed by the external audit. An organisation may be highly motivated to demonstrate a strong internal control environment to their staff and shareholders and so perform smaller more frequent reviews throughout the year with each audit focusing on specific elements of the SAP system.

Alternatively, a system upgrade or significant development may be the catalyst for an ad hoc review to ensure that existing system controls have not been adversely affected, or that new controls have been implemented where required.

The short answer is that you don't.

The purpose of SAP_ALL is to give full access (with some minor exceptions as standard). Removing a transaction from SAP_ALL will not protect a function as users will still have the access to bypass the restriction which has been put in place.

Roles should be developed to grant access to the specific transaction and authorisation values required.