Key Answers

Although the type of audits performed and the associated objectives may differ between an internal and external GRC audit, the process followed by both parties is very similar.

Whereas the timing of an external GRC audit of the financial statements are 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 audits' timing, scope, and objectives have been planned, all audits will undergo fieldwork activities (e.g. interviews, sample testing, system interrogation, etc.) to assess the internal controls and processes in scope. The audit results will then typically be documented within an audit report, with a 'close out' meeting held with all relevant stakeholders to discuss the findings and agree on the details and timing of any required remediation activities.

There are formal GRC training courses available from SAP at their training centres. Turnkey Consulting provides all of the qualified instructors on these courses to guarantee high-quality course materials and training.

We can also provide training for your staff on-site, organised through SAP. If you aren't looking for complete GRC training, Turnkey Consulting can also organise ad hoc training sessions.

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

Authorization in SAP provides the fundamental security necessary for your system. Only users with assigned profiles and roles will have access to the information held within SAP.

It’s vital to continually upgrade your Analysis Authorizations to the latest version so that:

- You have the most flexibility to allow for changes in the data model.

- There is no restriction on the number of authorization relevant characteristics (previously 10 per infoProvidor).

- You can direct authorization assignments on navigational attributes.

- More consistent authorizations design is enforced.

- Trace and error analysis tools are improved.

- You have full integration of hierarchy authorizations.

- You can implement direct and indirect user assignments.

- You have access to new functionalities like integrated planning that require analysis authorizations.

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

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 trade-offs using qualitative and quantitative data and creating resolution strategies for those risks which maximise return on investment.

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

The software is dependent on the revenue & structure of your individual licence agreement with SAP. In comparison, the cost of the hardware depends on whether you install it on your current system or use this as a pilot development on a new Netweaver environment.

In addition, consulting costs are generally provided at a daily rate, though this is variable depending on the length of the 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.

Continuous Control Monitoring, or CCM, is a solution to continuously track automated controls in real-time. A good example is 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 meantime.

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

If you want advice from the best, we're it. Our in-depth understanding and wide-reaching experiences give us key insights that could benefit your processes enormously.

We can act as consultants or trainers, helping your team understand everything they need to know to make the right decisions for the company.

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

Various definitions exist describing the concept of a business audit. In general, though, it 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.). In addition, the area of focus can shift according to the objectives of the audit, meaning certain risk areas can be put under the spotlight.

An internal audit is a function that, although operating independently from other departments and reporting directly to the audit committee, resides within an organisation (i.e. they are carried out by company employees).

Internal audits 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 using cheap labour in foreign countries, or strategic risks such as producing too many products compared to resources available.

An external audit is carried out by an independent body outside the organisation being audited. They are focused on the financial accounts or risks associated with finance and are appointed by the company shareholders.

The primary responsibility of an external auditor is to perform the annual statutory audit of the financial accounts, providing an opinion on whether they are an accurate 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 that could affect the financial accounts to determine if they are working as intended.

An auditor is a person or company enlisted to review a business' position and verify the accuracy of the information and the integrity of the information being provided for audit. We've already mentioned that there are two types of auditor: internal and external.

There are three types of SAP audits required to gain maximum assurance from the system, these are:

SAP Basis Review – covers access security (i.e. SAP authorizations) 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 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 – looks at both sensitive access and identification of incompatible duties within the business process under review.

If your company has to undergo an annual statutory financial audit, the external auditors will likely review at least some elements of the SAP system 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, uncover any weaknesses, and perform subsequent remediation activities before the external audit takes place.

With that said, the timing and frequency of internal audit reviews do not have to be governed by the external audit. For example, an organisation may be highly motivated to demonstrate a strong internal control environment to their staff and shareholders and so will 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.

One of the primary mission objectives at Turnkey Consulting is to help the companies we work with act with integrity, embracing best practices to comply with GDPR and protect themselves with effective risk management.

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.

Authorization is the process a user must go through to access SAP. The level of access will be preset, and each user will have access to a limited number of objects within the system.

To source and access information on authorization, you can refer to the system documentation by:

1. Navigating to environment.
2. Then authorization.
3. Then objects.
4. Then display in role administration.
5. Expand the relevant node.
6. Select the I button.

The total number of authorization objects that can be assigned to a single role within the SAP system is 170 per profile.

Once you have created all of the roles you wish to assign to an SAP user, you should navigate through the following:

1. Tools.
2. Administration
3. Users

Then, select the user and navigate to the Roles tab, where you can specify which ones you want to assign to your chosen user.

You can use the Valid from and Valid to column if you are assigning a temporary role.

You can link an Analysis Authorization to a specific user via two avenues:

• In transaction RSECADMIN.
• Through a PFCG role using the S_RS_AUTH object.

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

If users have different access requirements, they need to have a role developed to reflect their needs. Unfortunately, the only way to restrict access to a user without changing their role within SAP is to implement temporary access, as explained in the above question.

Our in-depth understanding of SAP is so significant that we train other companies to use it for effective governance. As SAP partners, we've previously been invited to product training sessions before they were made widely available.

By choosing us, you and your team are gaining access to that knowledge.

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.

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.

Fraud management systems are programmes that process significant quantities of transactional data. This makes it easier to monitor, manage and identify any occurrences of fraud, and act quickly before excessive funds are lost.

Cyber security protects systems from being hacked by unauthorised people looking to exploit the technology, assets or network of contacts held within the system.

Cyber security achieves this by applying various processes and applications that control access to the system. It also alerts when there has been a breach so that action can be taken swiftly.

There are three main types of software attacks:

• Malware - refers to ‘malicious software’ and is code, or a file, that steals, infects and carries out any action the attacker chooses.
• Phishing - uses social engineering to appear as a trusted entity but is really stealing user data such as financial information and login information.
• Ransomware - is a type of malware that destroys systems or files by encrypting files onto the device the information is stored on.

Threats to cyber security are constantly evolving, but as it stands, some of the most significant issues being faced at the end of 2021 are:

• Cloud adoption outpacing security
• Double-extortion ransomware
• Healthcare cyberattacks
• Phishing
• Remote work exploitation
• Zero-day attacks

Although this is by no means an exhaustive list.

Simply put, 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, the Middle East, the United Kingdom and the 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.