Version 10.0 of SAP BusinessObjects GRC solutions offers greater functionality, but without careful planning you can face both immediate and long-term maintenance challenges post go-live. Risk analysis and remediation (RAR) is a good example. Increased automation and pressure from external audits can lure organizations into defining a constantly increasing number of key controls against which to manage. Maintaining a conflict-free environment may seem easy, but the sheer volume of controls can become tough to handle.

Another problem, far more difficult to address, is that of capability. SAP BusinessObjects GRC solutions make it relatively easy to increase the quality of both the controls and the reporting. However, it can be difficult to find staff with the skills and capability to match the technology in place, outside of the project team.

The organization risks noncompliance if controllers are unable to interpret the monitoring information they are provided. An example is the use of firefighter (emergency access management in version 10.0 of SAP BusinessObjects Access Control) whereby reviewers are required to examine audit logs post-usage. Finding staff with the requisite functional and technical expertise to conduct more than just a superficial review can prove daunting. Performing a detailed review of firefighter usage is laborious and often underestimated in terms of time, effort, and pre-existing knowledge.

Another challenge is that an organization’s environment can be perceived as less compliant after an implementation of SAP BusinessObjects GRC solutions, purely because of the greater visibility of control weaknesses that they provide. This may lead to business units refusing to accept the new functionality. However, the risks are not greater than before; rather, now everyone can see the gaps.

So what can you do to avoid falling into the trap of noncompliance post go-live? Here are 10 tips to consider.

1. When you define the controls, do not introduce high volumes of new controls at the start. Focus instead on the real business risks. An SAP system provides the ability to define access at a more granular level compared with other applications. Therefore, it is always tempting to create high volumes of controls at the same level (for example, document types). If you intend to define a greater number of risks as part of your ruleset, for example, then you should categorize them and focus only on critical and high business risks. Your auditors may encourage you to record all your risks, but if you know they are not business critical (i.e., the business will accept the risk), then you may want to avoid them initially.

2. Document the risks and controls as you implement SAP BusinessObjects GRC version 10.0. Many organizations make the mistake of not documenting key risks and controls because they know they are noncompliant. This lack of documentation negates the benefits of SAP BusinessObjects GRC solutions. With version 10.0 of SAP BusinessObjects GRC solutions you can mitigate risks by system and by rule so that you can manage the implementation of your controls over time, across the landscape, and in agreement with your auditors.

3. Consider your security access role design and build when defining controls. Will legacy design impede your ability to remain compliant? How do you plan to address this question? The solution to this issue may not become clear until you have defined your ruleset. To get a good understanding of the potential scale of the remediation effort, use real production data when conducting User Acceptance Testing. Copy user data back to the QA environment, which must be linked to version 10.0 of SAP BusinessObjects GRC solutions. Run user risk violation reports to identify the number of conflicts and then determine how best to remediate or mitigate the identified risks.

You can restrict the review to exclude support users so that this group of users can be tackled separately. This step gives the project and the business an early warning as to the level of compliance and allows the business to begin remediation ahead of time. Your rule set and list of critical permissions (authorizations that should be controlled [e.g., access to maintain client settings]) will help you to define your role design principles for future projects and ongoing role maintenance. During role design it is helpful to prototype your roles so that you can identify required authorizations and eliminate unnecessary conflicts. Having version 10.0 of SAP BusinessObjects GRC solutions linked to your development or sandbox environment allows you to run role risk violation reports to identify potential conflicts at the single and composite role level. You either remove these conflicts or work with the business to begin to establish mitigating controls. Building the rules into your design reduces the number of conflicts you need to manage over time.

4. Set expectations early that the organization may not be compliant on day 1. Failure to do this may result in business units refusing to accept the rule set because they go from “compliant” to “noncompliant” overnight. Give yourself time to become compliant. Agree on a remediation approach and window with the auditors to allow the organization to address the key risks. It may not be possible to resolve all conflicts in the time frames set out, so prioritize accordingly.

5. Consider phasing in new controls over time and at a pace that is acceptable to the business.  This may be through the use of the risk analysis tools, but you may also choose to implement a number of process controls in parallel. Base any decision to implement process controls on key risk areas, and focus those decisions on a set of related processes. It may be easier to begin with IT general controls initially as a proof of concept, or controls to support specific regulatory compliance requirements that affect your industry. Set out dates by which you expect compliance to be achieved in each area and measure progress over time. The project team can facilitate this process by working with the business to develop action plans to get to a compliant state.

6. The key to maintaining compliance long term is to ensure that compliant behaviors and capabilities are developed within the organization. You may need to develop a new function to support monitoring activities or supplement the existing function. For this to be successful, reviewers must have a good working knowledge of SAP as well as understanding controls and compliance. Version 10.0 of SAP BusinessObjects GRC solutions provides enhanced, customized reporting that simplifies analysis and reduces reliance on technical support to explain the output. Thus, responsibility for managing risk is moved back into the business.

7. Compliant behaviors are engendered through ongoing monitoring and reporting. Version 10.0 of SAP BusinessObjects GRC solutions allows more targeted real-time reporting – for example, an interactive access risk violations dashboard that highlights total violations by criticality. It offers drill-down functionality so that violations can then be viewed by functional area or at the user level (i.e., all users with an identical set of conflicts). These real-time reports are used to encourage business areas to become more self-regulating, and SAP BusinessObjects GRC solutions provide them with the tools to do so. The introduction of a single user interface makes reporting much easier. Providing dashboard access to business controllers for their specific business areas allows them to take more ownership and accountability for managing segregation of duties, including the creation and testing of mitigating controls. Increasing compliant behaviors helps reduce the number of issues over time and helps ensure that potential risks are identified early and managed out. For example, you can use business role modeling to run preventive simulations before assigning access to the role.

8. Including compliance-related metrics in performance plans increases the visibility of controls and compliance and reinforces the relative importance to the business. The availability of numerous SAP BusinessObjects GRC reports across access and process controls facilitates identification of control weaknesses and at which points control owners may be failing to address them over time. For example, the reporting makes it easy to identify risks by owner that have no mitigating controls defined over time, as well as mitigating controls that have failed testing over time. Workflows can be used to notify control owners of failed tests and to manage and escalate issue resolution.  

9. Ensure that the reports are easy to understand and provide control owners and reviewers with the skills and information they need to make informed decisions. Often reviewers are flooded with such huge volumes of data that the reports become meaningless and are therefore ignored. Version 10.0 of SAP BusinessObjects GRC solutions provides enhanced reporting that makes it easier for reviewers to understand the data presented to them and to slice and dice the information as they see fit. Workflows also ensure that reviewers receive up-to-date, relevant information specific to them, rather than an accumulation of data over time.

10. Ensure reviewers receive adequate levels of training on not only how to extract reports but also on how to analyze report content. Involve reviewers as much as possible during the project and hypercare phases. Don’t involve them only in the reporting phase; allow them to contribute to the designing and building phases, too. To monitor compliance, reviewers of any GRC-related activity need to have an understanding of the business process, SAP controls, and SAP security. For example, understanding the emergency access process if implemented is important. However, it is also necessary to understand whether transactions executed under the firefighter ID are defined as critical access in the rule set, and whether transaction usage is appropriate and aligned with the initial firefighter request. To ensure that the process is robust, the review requires expertise from multiple different areas of the organization as it is unlikely that any one person will have detailed knowledge across the board. The review may require input from the financial control team, security, Basis, and the business. The key is to have a single individual who can coordinate all this activity and a pragmatic review approach that meets the business risk profile.