SAP Security Blogs

Turnkey's team of expert consultants share their wealth of knowledge and in-depth insight into SAP security and controls in a series of blog posts.

Access Control 5.3 end of life - time to upgrade, or do you just keep the lights on?

Friday, 23 October 2015

Posted by Simon Persin




Access Control 5.3 is due to exit “Mainstream Maintenance” and enter Extended Support at the end of 2015. Many organisations will find themselves in a situation of “end of life” with unsupported applications in various states. There is always the view that if it isn’t broken, don’t fix it. If you’re happy with only “keeping the lights on” without doing anything different, then there’s no immediate action.

However if you have plans to upgrade or patch your existing SAP systems, then you may encounter problems such as GRC systems no longer reporting access violations, or missing out on particular FireFighter functionality. So what should you do?

  • Examine the current SAP roadmap & upgrade plans for the GRC landscape
  • Explore the migration path
  • Decide whether it is worth upgrading
  • Look at the benefits:
  1. Enhanced Risk Analysis, User Interfaces and reporting capabilities
  2. More logging available in the FireFighter scenarios giving you much tighter controls
  3. Inherent workflow capabilities within FireFighter, smoothing the audit of emergency access
  4. A powerful and flexible workflow engine allowing more complex and realistic approval procedures for GRC master data and automated provisioning
  5. More intuitive User Interface is providing much greater personal control
  6. Improved Transport Management, enabling you to manage changes within GRC more efficiently and greater compliance than previous versions
  7. Object level security providing proper robust security and authorisations capability
  • Think about the wider picture
  • Ensure that the project is not seen as a generic upgrade
  • Keep up with technology


To find out more, read our latest article, find out how we delivered this upgrade for Rexam, or sign up for our upcoming webinar.

Make a Comment

Controls Automation - Monitoring vs. Operation and the Business Case for Automated Controls - Part 3

Thursday, 22 October 2015

Posted by Marc Jackson

Monitoring vs. Operation  

We talked briefly about the potential controls reporting challenges within a GRC application if you are using it for both control operation and monitoring purposes, so let’s take a closer look at this final element of controls automation – automated controls monitoring. I often find that the terms control operation and controls monitoring are used interchangeably and can be muddled up and confused, mainly because they tend to both be bundled under the umbrella term of automated controls. However you need to be very clear which of the two you are referring to when you embark on your controls automation initiatives as they are very different things, but understanding and appreciating the difference between them is actually quite straightforward.

Automated controls operation is operating a new control without any human intervention (e.g. implementing password parameter settings to password security), whereas automated controls monitoring is the monitoring of a control which is already operating, typically an automated control itself, to ensure it continues to operate as expected going forwards, and this is also performed without any human intervention (e.g. in your deficiency criteria you can state what the password parameter settings should be for it to operate effectively, and if it strays from those expected settings the monitoring rule would automatically detect this and enable the control to be remediated accordingly).

This type of insight into the operating effectiveness of your controls , and the real-time detective reactions to any operating effectiveness issues, means you can strengthen your internal control environment by having a much greater level of assurance and less time during the compliance year when controls are not working.

Part 3

Business Case for Controls Automation

Now that we’ve covered all of the elements of controls automation, lastly we’re going to take a quick look at the things you need to consider when trying to build a business case for controls automation. The number one priority is to be absolutely clear on what it is that you wish to automate, and avoid talking about it in broad general terms which will only serve to confuse those involved in the process. As we’ve discussed, there are a few different elements of controls automation and not all of them may be relevant for you at a particular point in time (e.g. you may not have a GRC application in place and so would initially like to focus on getting the most out of your in-built application controls before looking to extend the reach to GRC-enabled controls operation and monitoring).

Once you’ve decided on what it is you wish to include you can then evaluate the benefits and costs of each of these elements. Even though the quantitative benefits make the most powerful argument in a business case, the value of the qualitative benefits should not be ignored. These benefits can be looked at in 4 dimensions:

  • Cost Reduction – which refers to all direct and indirect cost savings (e.g. lower cost of controls through the reduction of manual controls, lower cost of control investigations through enhanced audit trails etc.)
  • Compliance – refers to reduction in compliance costs (e.g. lower audit costs, lower management testing costs, reduction in fines/penalties etc.)
  • Risk Reduction – refers to reduction in impact and/or probability of risks (e.g. revenue risk – missed revenue due to missed/under billing etc., cost risk – incurring additional costs due to errors in core processes leading to things such as duplicate payments/overpayments, reputational risk – due to errors in information exchanged with customers, business partners, public etc.)
  • Process Improvement – refers to increasing processing speed by automating manual steps and validations (e.g. reduced process cycle time, 100% data validation, enhanced decision-making etc.)

Of course there are also challenges and costs associated with controls automation initiatives and so these also need to be determined and documented in order to provide a comprehensive business case. Such costs include, but are not restricted to, hardware and software costs (although not a factor if not embarking on GRC-enabled controls), cost of implementation depending upon how much is done in-house or with the use of external consultants, training staff on how to use this new technology, as well as the ongoing management and maintenance of such systems, processes and controls.

Make a Comment

Controls Automation - A New Breed of Automated Controls - Part 2

Wednesday, 21 October 2015

Posted by Marc Jackson




Now we’ve looked at some of the more traditional forms of automated controls, let’s discuss a new breed of automated controls that should also be considered as part of a controls automation initiative. The use of GRC technologies within organisations, and the rich automated monitoring functionality they provide, has opened up further possibilities and opportunities to implement controls which are out of reach from traditional forms of controls automation. These business rule frameworks/engines provide the ability for organisations to design, build and implement their own business rules to define deficiency criteria which supports their own risk mitigation objectives. The opportunities are endless and controls may be implemented at configuration, master data or transaction-level.

Example: The identification of one-time vendor POs that exceed a specific % of regular purchase orders over a period of time is an example of controls made possible by GRC-enabled technology. These limits can be defined entirely by the customer and allow it to be tailored to their own purchasing policies to ensure adherence. Traditional controls don’t tend to exist for these types of examples, and it would be far too cumbersome to manage manually due to having to pull large volumes of data from several different sources and aggregate amounts over a period of time. But these are the opportunities that functionality within GRC-technologies can provide to organisations, some of which are starting to make use of them.

Another example would be the ability to monitor for unauthorised openings of the production system. Traditional controls allow you to lock down your production environment to enforce a ‘promote to production’ change management approach, but the production client does need to be opened from time to time for legitimate reasons. Using GRC to constantly monitor when this happens provides another layer of control, and allows you to ensure it has been opened in an authorised and controlled manner and spot potential attempts to make unauthorised changes directly in the production environment.

Another element of using GRC-enabled controls is the associated notifications and issue and remediation cycle workflows which accompany them and ensure the relevant individuals are fully integrated in the controls output and the subsequent investigation and remediation of exceptions found. However, due to the fact that some GRC technologies are built primarily for the monitoring and testing of controls, the remediation workflow is really designed to capture issues in the sense that a control is not operating effectively. So if you use the automated monitoring/business rule framework in these GRC-technologies to actually operate these new breed of automated controls, a control issue in this sense is not that the control isn’t working but rather an exception identified by the control completely in line with how the control should operate. This could have the potential to skew controls reporting in a GRC application, particularly if you are using it for both automated controls operation and automated controls monitoring – so this is something of which to be mindful.

 Marc's blog 2


Make a Comment

Controls Automation – Controls Terminology and Traditional Controls - Part 1

Friday, 2 October 2015

Posted by Marc Jackson

Increasingly the market is focused on automating controls to reduce the cost of compliance, improve the control environment, and realise efficiencies. More than ever now, organisations are completely information-driven and data has become the lifeblood of any business. In the past, organisations were able to manually verify and audit the accuracy, consistency and reliability of the information they used due to low-volumes and relatively stable mainframe-based information processing environments. However, with the advent of distributed technology, data volumes and compliance requirements have increased exponentially. As a result, the use of manual controls has become costly, obsolete and simply not sustainable.

Despite organisations becoming more and more aware of the value and benefits associated with controls automation, the current situation is not what you might expect. With the exception of a few progressive organisations, controls in most organisations are compliance-driven and often implemented following a risk event. It is not uncommon for manual controls accounting for more than 70% of key controls within an organisation, and there have been many studies and surveys which all provide similar conclusions

So why is this the case?:

  • Controls tend to be implemented as a knee-jerk reaction to problems
  • The absence of any recent and/or glaring information-error event means control automation projects take a backseat and compete among many organisational priorities
  • For some executives, especially those who are not accountants, risk and control-related terms can be confusing and misunderstood especially when the focus is on heavy theory
  • Implementing further technology to automate controls can also be a seemingly expensive proposition.

We’ll take a closer look at some further challenges faced a little bit later on, but right now let’s refresh our understanding of some of those commonly used control terminologies

Controls Terminology

As I’m sure you’re all aware, controls are typically categorised in terms of their nature and type, each of which has two buckets for classification purposes. The nature of a control is determined based on whether it is preventive or detective:

  1. Detective controls: will identify when a potentially undesirable activity has taken place, they will not stop it from happening but they will allow an organisation to respond appropriately and in a timely manner – so they’re very much reactive or “after the event” (e.g. a monthly review of payroll audit reports help identify potentially incorrect or unauthorised payments that have been made, such as duplicate payments or unusually large amounts, so they can be corrected as required).
  2. Preventive controls: on the other hand, will prevent an undesirable activity taking place, which avoids the need for potentially complex and lengthy investigations and associated corrective actions– so they’re very much proactive or “before the event” (e.g. 3-way match is a well-known configurable control ensuring quantity and price matches between PO, GR & IR according to customer-defined tolerances, otherwise the associated invoices are blocked for payment).

The control type is determined based on whether it is manual or automated. The difference between these two types of controls is relatively simple, manual controls require human intervention for them to operate whereas automated controls don’t, they are performed entirely by the system/application (e.g. you can configure an automated check on customer credit limits during order intake, if the credit limit is exceeded then the order is prevented).

You may have also heard controls referred to as “semi-automated” or “IT dependent”, these are controls which rely mainly on human intervention for their operation but they are also reliant on data provided by supporting technology. Therefore, these would include any controls involving the manual review of system-generated reports, so the manual review of FF logs is a good example. It’s important that an organisation’s internal control framework has the right balance of manual, automated, preventive and detective controls. Although preventive controls are stronger as they stop undesirable events taking place, detective controls are also important to pick up on anything that slips between the gaps, which may also be symptomatic of automated control failures.

Traditional Controls

When people hear the term automated controls they usually think of those configurable controls which are available within your ERP system that can be switched on and defined to suit the way an organisation’s business processes operate. These controls are commonly referred to as “Application Controls” and are embedded within an organisation’s business processes providing input, processing and output controls. For organisation’s embarking on a journey of automation it is strongly recommended that these controls are reviewed initially as they are readily available to use in your system, you don’t need to purchase additional hardware or software, only the relevant level of knowledge regarding the available configurable controls in those business processes being operated by your organisation.

These traditional automated controls are not only restricted to business process-related configurable controls, they also incorporate security-related system parameter settings which help define and automatically operate logical access and authentication controls. In addition, although perhaps not realised by everyone, restricted access controls are also another form of automated controls as taking away inappropriate access, whether it be for SOD or Critical Access risk purposes, removes that access risk from the user and will continue to do so without the need for any human intervention.

Example: A company can make use of a system configuration-based control which can prevent field changes to financial documents after posting to the General Ledger has taken place. For example, you’d want to prevent changes to vendor bank account details to reduce the risk of inappropriate payments. From a control perspective, if a document needs to be changed for valid reasons then it should be reversed and the correct document posted, providing full transparency into all transactions affecting the SAP General Ledger. Therefore, this helps to protect the accuracy & validity of financial reporting. An alternative manual control would involve extensive and time consuming reviews of GL document changes, so you can begin to see the positive impact of implementing automated controls.

Marc's blog

Make a Comment

Raising the Bar in Data protection

Thursday, 17 September 2015

Posted by Richard Hunt




In EU law there is an important distinction between a Directive and a Regulation – a Directive must be implemented by each member state, a Regulation becomes law in all member states upon implementation. As a consequence this new UK data protection legislation will become far more stringent than it has ever been.

The good news is that the new regulation will not be fully in force until 2017/18 so there is still time to prepare. One of the key changes is the concept of privacy by design. Similar to the idea of the least access principle, privacy by design requires that a company’s IT systems have been designed with data privacy compliance in mind. In practice this means that SAP customers will need to ensure their access controls support compliance with the regulation and that access to personal or sensitive data is justifiable and restricted to those who need it for legitimate purposes.

Whilst compliance with the new regulation will affect access controls in a number of SAP modules and there will be a number of industry specific risks, it will be SAP HCM and/or Success Factors customers who will certainly be affected. The initial draft of GDPR has proposed a series of mandatory icons which will need to be used to provide an overview of the status of an organisation’s compliance to the regulation. These icons provide a useful summary of the key requirements:

 Image 1

This will provide a requirement to justify the purposes for which the data is being held and processed. The requirement will have a number of implications with regards to the collection and retention of customer and supplier data and will also affect data held on employees in an HCM context.

image 2

Data retention is an area where many SAP implementations are going to need to tighten up in order to achieve GDPR compliance. For example, holding the full HCM record of an employee after he/she has left the organisation could be considered a breach given that the company will have no justifiable reason to retain details such as dependents or next of kin.


This requirement has some interesting implications for predictive analytics and other Big Data applications. Was data collected by the organisation for these purposes and can this be considered a reasonable extension of the data usage?



Whilst organisations may not intend to disseminate, sell or rent the personal data, they hold an obligation to ensure their employees do not is also implied by this requirement. Therefore, access controls and the ability to restrict data downloads will become increasingly important.


Insisting on the encryption of an entire SAP database is likely to be met with significant resistance from the BASIS team for a number of reasons, not least of which is performance. HANA databases have been built with encryption capabilities as standard but for those SAP customers without the luxury of a HANA landscape, compliance to this obligation will be a significant challenge.

Interestingly GDPR compliance will apply a test that will look familiar to those of us with an audit background:


  1. it must be designed so the controller is compliant if it is followed; and
  2. it must allow it to demonstrate such compliance to SAs and to data subjects

This is basically the test of design and operational effectiveness applied to controls during an audit. Roles and authorisations clearly play an important part in the implementation of a GDPR compliant solution but other tools will also be useful:


GRC Process Controls

Tools such as SAP GRC Process Controls will be very useful in the implementation of a GDPR compliance programme:


  • Documentation of the organisation’s GDPR compliance procedures
  • Assignment of control ownership and operation of these controls using PC workflows
  • Documenting and issuing Data Protection policies and amendments using the Policy Management component
  • Issue management and remediation
  • Demonstration of GDPR related compliance activities
  • GDPR compliance sign-off

 Read access logging

The new Read Access Logging functionality inherent in SAP Netweaver will be extremely useful in the implementation of monitoring controls. Allowing access to sensitive data to be monitored at a more detailed level will provide an alternative where an access controls solution would be too restrictive.



Make a Comment