Don’t miss our upcoming webinar “What’s New In SAP GRC 10.1.”

// // <![CDATA[
// to make fancy buttons. Uses noConflict just in case
var $jQ = jQuery.noConflict();

// Use jQuery via $j(…)



// ]]>

This solution can be leveraged to extend and add value to your SAP Access Control investment, including SAP Process Control and SAP Risk Management.

During this webcast, you will have a clear understanding of:

  • Preparing your system landscape and architecture for SAP Access Control 10.x
  • Properly configuring your SAP Access Control 10.x solution
  • Requirements and capabilities of the latest versions of SAP Process Control
  • How to exploit key capabilities of SAP Process Control 10.1 to drive a business-wide compliance and process optimization program

Register today at 

GRC webinar


Hi there world!

Today I wanted to share a few tips and trick with you for remediating your SoD Access Risks using GRC 10.x.

Ok, so you’ve finished your GRC Implementation and now you are able to easily query your SoD and Critical Risks. Frankly, you might be panicking… 100,000 conflicts?!!?!! In the words of my people “OY VEY!” Here’s a quick step-by-step for starting to tackle the impossible.

  1. Start from the bottom up with your roles. It’s impossible to remediate your users’ access without clean roles. For this reason, a task-based role design is the best approach. Roles should be free of inherent SoD conflicts, which you can query via NWBC—>Access Management—> Risk Analysis —> Role Level.
  2. Create a critical action risk for each function that make up your SoD risks. Run Role Level Risk Analysis as above, but this time for Critical Action Risks. Make sure that your roles are free from unintentional access that could have a financial business impact, this again correlates to a task-based role design.
  3. Be wary of assigning users access to roles with a lot of transactions and permissions even if they are only display only. This can cause an issue due to the “borrowed authorization concept” in SAP Security. In that many transactions check for the same authorizations and user access cannot be viewed in a silo within a single role. Transactions can borrow permissions within other roles.
  4. Time to begin remediating access at a user level! NWBC—>Access Management—> Risk Analysis —> User Level. Run User Level Risk Analysis for Critical Actions Risks created previously, first. Because the roles are now clean of inherent conflicts, unnecessary access should be able to be removed via a role removal process, rather than via role mediation.
  5. We can now run User Level Risk Analysis again at the Permission (SoD Risk) Level. It is now possible to remediate user access by removing roles to remove any avoidable SoD conflicts.
  6. Lastly is Mitigating Control assignment for any remainaing and ONLY unavoidable SoD conflicts.

Happy Monday!


Session @ GRC Conference 2015: Achieving collaborative GRC accountability: The power of successful communication between the business and IT

Who else is already excited for GRC 2015 in Las Vegas? I am already counting down the days! This year is going to be especially thrilling for me as I’ve been chosen as a speaker for one of the conference sessions. Read my abstract below and stay tuned for more information!

Achieving Collaborative GRC Accountability:

The Power of Successful Communication Between the Business and IT

This session will highlight the importance of collaboration between the business and IT within the realm of SAP Access Control, SAP Process Control, and SAP Risk Management and provide a better understanding of the communication opportunities within GRC. During this session:
• Learn what steps you can take to eliminate common fractures such as overlapping responsibilities, processes and systems, as well as gaps or other inefficiencies from your GRC processes

• Develop a deeper understanding of the key stakeholders and contributors as part of GRC, including who participates and at what stages, why they participate, and how they perform these tasks

• Walk through common instances of separation of powers within GRC and key examples of how collaboration drives checks and balances within the system

Tips and Tricks for GRC 10.1 Access Risk Analysis : Copying and Updating the GLOBAL Rule-Set

Hi all,

I know it’s been a while! I wanted to key everyone in on my first trick for your GRC Access Control 10.1 Implementation and this one is all about Access Risk Analysis.

Before you implement ARA, it’s best to create a separate connector and connector group for each system. This will allow you to have different role owners across systems and associate risks to different systems as well. Long-term, it will make your GRC maintenance much more manageable.

After completing post-install steps and ARA configuration steps, the generic GLOBAL rule-set will automatically be associated with sap connector group R3. However, you will most likely need to do rule-set updates to massage the generic rule-set a bit and account for any custom transactions, customs critcal actions, critical permissions and critical roles and profiles.

My recommendation is to copy the GLOBAL rule-set by downloading it and re-naming it (the below link is the one I found the most useful for instructions on how to do this). When you download the GLOBAL rule-set you can also make additions and modifications that are befitting to your business. By doing this you can freely make changes while still maintaining the integrity of the SAP standard to refer back to. Multiple custom rule-sets can be created to serve various purposes. Once the rule-set name has been changed and necessary changes have been completed, you can upload the custom rule-set to your system specific connectors via the same too (again refer to the link below).

Downloading and Uploading GRC Access Control Rule-Set Valuable Link

A few additional notes on the issues I found with the SAP generic GLOBAL rule-set:

1. Many transactions do not have account types activated, so false positives can occur unless they are activated if you have your roles broken up by customer, vendor, G/L and Asset account types.

2. Some of the activity types are not set up correctly in the functions. Many activies are set as “1” for instance instead of “01”, 2 instead of “02”, etc. etc. You will get false negatives (THE WORST KIND) if you don’t fix this when uploading the custom version of your rule-set.

2 Go-Lives in 2 weeks.


Your Happy Sleep-Deprived Security & GRC Consultant

Back in Action!

Hi friends!

I know it’s been a while— Needless to say things have been a bit crazy around here.

I’m currently in the middle of a GRC Access Control 10.1 and I will have lots of tips and tricks to share in the upcoming weeks! I’m also finishing up a GRC Access Control 10.0 Remediation Project and a security role re-design.

Aside from the usual GRC and Security work, I’ve been keeping extra busy. A few us at itelligence started a #LeanIn focus group that is dedicated to attracting, recruiting, retaining, developing and promoting female talent across the organization. The group has begin discussing projects and initiatives that will aid us in achieving each of these objects, more to come on that!

In that meantime, I wanted to share a few articles regarding women at work:

On Women Asking for Raises:

SAP: Women in the Workforce:

Technology Diversity Gap:

How Male Allies Help the Gender Equality Movement

Happy Reading,


Integrate Policy Management into Your Global Compliance Portfolio

Hey all,

Discover how to use policy management with key elements of SAP Access Control to respond to risk events in your organization. Understand the ways in which policy management can be integrated into functional business processes.

Reading this article, you will learn how to:

  • Integrate points between policy management and other GRC components
  • Use Adobe Interactive Forms for policy awareness and training
  • Use policy management for work instructions, corporate policies, and regulatory policies

Here is the link to the full article!


Happy reading!


SAP 101: Adding Transactions to A Role

Hi all,

Sorry I’ve been so MIA lately… things have really been picking up over here and I haven’t had time to post.Needless to say I haven’t had a second to breathe, but I didn’t want you all to feel left out, so here’s a little post on an SAP Security Best Practice to wet your whistle on this fine Monday morning.

My colleague, Rahul Urs, posted this article a while back and I thought I would piggy back on that for a second. When  you are adding transactions to a role, ALWAYS add them via the menu path, NEVER add transactions manually via the authorization object S_TCODE.

One of my customers e-mailed me this week… “A bunch of users are able to execute a transaction that they are not authorized for. We wish to limit access to this transaction to a small number of users. Currently, the transaction is not assigned in any roles and yet many users are able to access it… HELP!” The customer had queried roles by transaction assignment in t-code SUIM, which only shows roles assigned directly via the menu path. I queried, roles by complex selection criteria in SUIM, for the transaction value in auth object S_TCODE and I came to learn that 10 of their roles had been updated manually with a * value for S_TCODE.

I was able to fix this by manually inserting a new line item for S_TCODE and pasting the results from table AGR_TCODES for the role. I then inactivated the S_TCODE value for *, but it was quite the clean-up effort and less than ideal from a best practices standpoint.

So as a general rule of thumb: when  you are adding transactions to a role, ALWAYS add them via the menu path, NEVER add transactions manually via the authorization object S_TCODE.

Happy Monday!



This year, itelligence is hosting ASUG Ohio’s Annual Chapter Meeting at our US headquarters in Cincinnati.


I, along with two other members of the GRC practice will be speaking at the event. Here is an overview of the agenda as well as some further information on what our sessions will cover:



User Management Primer in SAP HANA and Best Practices for managing Security and Controls in SAP HANA and SAP BW on HANA. Rahul Urs, GRC Solution Architect,

Capture Learn How to Use Continuous Compliance Monitoring with GRC Process Control 10.1 Tracy Levine and Brian Merkel, SAP Application Consultants



Registration has not yet begun, but more information about the event and pending registration info. can be found here.

Happy 4th of July!



Webinar Recording Now Available: The Most Prevalent Debate Amongst SAP Professionals: SAP Consulting Vs. Industry Q&A

To listen to the webinar, click here.

SAP Controlling Community members recently gathered for a webinar on The Most Prevalent Debate Among SAP Professionals: SAP Consulting Vs. Industry Q&A. Listen and get tips to help direct you career.

In this webinar, Tanya Duncan and Tracy Levine compare and contrast SAP careers in consulting vs. industry positions.


Happy Friday!


Not at SAPPHIRE NOW + ASUG Annual Conference? Get your GRC Fix, Right Here, Right Now.

Let’s talk about risks baby, let’s talk about you and me. (SALT N’ PEPA PEOPLE, C’MON! Live a little!).

If you’re like me, lonely and depressed because you’re missing SAPPHIRE/ASUG 2014, well let’s pull ourselves up from our boot straps and start talking GRC, together (forever!). #postgradsap : Turning frowns upside down since 1989.

Today I will be discussing the steps to take to mitigate risks (both SoD risks and critical actions risks) with the help of GRC. So we’ve implemented GRC Access Control (10.0 or 10.1 respectively) and we have run batch risk analysis against all relevant systems. Now we are left with a slew of information, what to do next? Well my friends, it’s time to clean house.

Steps to Clean Up Your Segregation of Duties (SoD) Risks:

  1. Run batch risk analysis by users and roles at permission level for SoD Access Risks.
  2. Determine the roles that are assigned to users that have inherent SoD violations. Make role changes as necessary to remove one side of the conflict from roles with inherent violations (a task based approach to your role design will work best when trying to do such remediation tasks).
  3. Re-run batch risk analysis by user at permission level for SoD Access Risks.
  4. Determine roles that are assigned to users that have one side (or part) of the SoD conflict. Should these roles actually have this access and are the roles properly defined to indicate as such? Make any role changes as necessary.
  5. Determine users that have SoD violations and remove one or more roles from their user master record if the access is not required.
  6. Create and assign mitigating controls as necessary for the remaining and unavoidable SoD violations.


Steps to Clean Up Your Critical Action Risks:

  1. Validate the critical action rule-set… Ensure that risks are appropriately defined and actions/permissions correspond to the risk definition. Make changes to the rule-set as necessary.
  2. Run batch risk analysis at role level and user level for Critical Actions
  3. Determine roles that have critical actions. Should these roles actually have this access and are the roles properly defined to indicate as such? Make any role changes as necessary.
  4. Look at users who still have critical actions. Should these users have this access? Make user master record changes as necessary.
  5. Create and assign mitigating controls as necessary for remaining critical actions.


If you are at SAPPHIRE, don’t forget to stop by booth #339 and visit @itelligence_US!

Tuesday Shmoozeday,