Skip to Content

I noticed a comment on a recent blog post suggesting that the difference between security and controls is only a choice of semantics, which is to say that they are for all practical purposes the same.  Perhaps I badly misunderstood the writer’s intent, because I must respectfully disagree with that view. Such a simplistic generalization is how the security group can end up getting blamed by the business for their failure to build adequate controls into their processes and system configuration.  While security is an important control, it is just one tool in the controls arsenal. In the SAP landscape security and controls are not synonymous, and business people who expect security to be “the” control may be in for a rude awakening.

SAP offers a number of configurable controls that are completely separate from security. Such transaction controls include:

  • Number ranges
  • Automatic postings
  • Data entry validation
  • Default values
  • Controls on accounting periods
  • Recurring entries

to name just a few.

  In addition, a good controls environment offers both preventive and detective controls, including monitoring, reconciliations, exception reporting, and approvals.

Segregation of duties is one of the most well known controls that is accomplished through security role design and careful role assignment; the segregation can occur at the transaction level or at the enabling authorization level. For example, sensitive FI doc types are frequently restricted to the users who need to carry out specific functions such as accounts receivable. Sometimes combinations of controls are the most effective; for example, ideally printers used for check printing are secured both physically and by restrictions on printer authorizations. However, achieving ideal segregation of duties is not always possible in small businesses or satellite locations. This is where multiple controls on processes can bring extra control assurance.

Security and other controls can be seen as the bad guys, stopping people from getting the work done, or seen as your partner in keeping the business compliant to the applicable regulations and protected from fraud. A good security design goes hand in hand to complement other controls, and together they can form a strong controls environment. Just don’t expect security design to go it alone.

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Vijay Vijayasankar
    Good point – it would be a mistake to treat security as the sole controls mechanism.

    However, security is still the last line of defense – and hence is probably the highest ranking control mechanism. Security can make an honest attempt to stop the bad guys when all else fails – but other controls have big limitations if security is not working well. So in that way – I can see why people use these 2 terms as synonyms.

    In an ideal world – all the controls complement each other. In real life – people just pick on the security team 🙂

    (0) 
    1. Gretchen Lindquist Post author
      Vijay,

      I agree that security is the last line of defense, but as a practical matter, it cannot be expected to do it all. If money were no object, the security team could be staffed with an army of skilled security resources so that each and every user could have his/her own security role built out to personal requirements. With over 50,000 users in my organization’s core system, such an idea is laughable to me even without the staffing limitations of today’s tight economy. It must be understood that nearly all users are, then, going to have more access than they really need, and other controls must complement the security design.

      Thanks for sharing your thoughts!

      Gretchen

      (0) 
  2. Gregory Misiorek
    Gretchen,

    i’m guilty as charged.

    we control to be secure and secure to be in control, but my comment was not intended to put blame on Security and Authorization team, especially when it’s coming from the accounting FI/CO team, but many FI users are simply frustrated by not being able to execute a transaction when at the same time seeing a gaping hole when authorized to edit a financial record outside the standard and normal process. you wouldn’t hear them complain if they had SAP_ALL assigned, though, which is not realistic. i can certainly appreciate the need for the strict controls, i mean, security.

    my point was more to show competing standards in IT security (controls?), financial reporting, and project management, where distinctions are often elusive to the end user who is simply trying to accomplish their business transaction process efficiently and effectively, without questioning composite roles and authorization objects or whether they follow the PMI or PRINCE method. programmers, i mean developers, don’t even have time to appreciate the nuances because their main objective is for the code to compile and execute…hmm, what else one could write about the politics of ERP implementation project?

    (0) 
    1. Gretchen Lindquist Post author
      Greg,

      I can certainly appreciate the frustration of those FI end users you cited; security inconsistencies are often frustrating to security professionals as well. Sometimes the root cause is the unintended authorization creep when users are assigned multiple roles and the overlapping authorizations increase access in unintended ways; other times the cause could be as simple as inadequate security testing when the new transaction/ program was added to the end user roles. Developers sometimes think that unit testing the transaction in the development system with their own quite broad access is all that is needed.

      We have found a benefit in requiring the developer and the business analyst to work together on a custom tcode questionnaire that is then submitted to our SAP Controls group for their approval. This helps all parties involved keep the security and control standards in mind during the development process. We also have a standard testing worksheet to document testing of all role modifications, which includes confirmation of negative testing and appropriate authority checks for organization values. Any exceptions must be noted and approved. There needs to be a clear communication that all projects are expected to adhere to the control standards, or confusion and frustration can result. We used to see projects that budgeted nothing for security build and test, but eventually that becomes less of an issue once a few high profile projects go over budget.

      If the organization is already doing these things and is still having confusion and inconsistency in security, perhaps some additional communication about security and controls expectations is needed. Not knowing all the factors, these are just a few ideas.

      I appreciate your frank comments. If you are going to be in Phoenix next week, please feel free to stop by one of my Expert Networking sessions in the Community Clubhoues and we can continue the discussion.

      Gretchen

      (0) 
    2. Kenneth Moore
      I disagree with the programmer comment, I mean software engineer, that their main objective is for the code to compile.  A good programmer definitely takes into account security/controls if it is needed in his area of expertise.

      I see both points.  User’s could care less, they just want it to work.  But when something goes wrong, it is not always security to blame.

      (0) 

Leave a Reply