Skip to Content

A high amount of time during a SAP GRC project will be spent on defining processes and responsibilities. My suggestion is to think in lifecycles for getting a better understanding of the processes and who is taking over the responsibilty.

 

In this post I would like to clarify the lifecycle of Firefighter IDs. I have grouped them into four steps Create, Change, Delete and Review. Please see for each step expected Tasks and who is involved.

 

I have additionally added the RACI matrix to see who is Responsible, Accountable, Consulted and Informed for each step. Please be aware that this is very much depending on the point of view and can be different in your organization. My considerations are commonsense and pretty much of thinking in smooth processes throughout a global enterprise.

Lifecycle_Mitigating_Control.png

 

Creation of Firefighter ID

Tasks

  • Define the necessary access rights of the FFID
  • Define the responsibilities (Ownership, Controller)
  • Create Firefighter ID

 

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

RACI_FFID_Create.png

 

Changing of Firefighter ID

 

Tasks

  • Define the necessary changes in access rights
  • Define changes in resonsibilities (Ownership, Controller)
  • Define changes of Firefighter ID (e.g. validity)

 

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

RACI_FFID_Change.png

 

Deletion of Firefighter ID

 

Tasks

  • Delete the Firefighter ID
  • Document the decision of the deletion
  • Archive belonging firefighter logfiles

 

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible

RACI_FFID_Delete.png

 

Reviewing of Firefighter ID

 

Tasks

  • Review validity
  • Review firefighter ownership and controller
  • Check proper access rights

 

Involved functions

  • Firefighter owner
  • SAP authorization team
  • SAP GRC responsible
  • Business role owner

RACI_FFID_Review.png

 

If you want to have further information or contribute in this blog post do not hesitate to contact me or reply to this post directly.

To report this post you need to login first.

11 Comments

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

  1. Colleen Hebbert

    Hi Alessandro

    Again, nice to see these blogs outside of the system

    Is it worth opening the topic up to FF usage – more in terms of choosing how many FF Ids to create and how long you assign them.

    In addition how we can go about designing support access (could be more a discussion and point of view  – for example, some organisations only allow display via named Id and all modify access is via FF). This can also include considerations to information captured in logs….. maybe it’s another topic by itself 🙂

    Regards

    Colleen

    (0) 
    1. Alessandro Banzer Post author

      Dear Colleen,

      thanks for your feedback. Much appreciated to get your feedback in this regard.

      What do you mean by FF usage? Do you want to see the utilization process of a Firefighter? From beginning (start transaction) till final workflow approval (from controller)?

      Regarding the support access: in our enterprise we have two approaches of firefighter usage. Firstly, SAP CC members are using firefighter for create/change authorization to support business. SAP CC members only have display authorization in the productive environment and they have to use FF for extensive authorization. Secondly, firefighters are also used in business to avoid segregation of duty conflicts. For such cases we have either defined a “personal firefighter” which is for one particular user, or a “process firefighter” which is for multiple users and only contains “one function” (e.g. maintaining posting periods).

      If you want to know more about our concepts to not hesitate to contact me.

      Regards,

      Alessandro

      (0) 
      1. Colleen Hebbert

        Hi Alessandro

        By usage, you pretty much answered the question. I find I get into discussions with people on how to design their support process around FF usage. For example, Basis particularly get frustrated if you ask them to use FF for regular system maintenance. Then others get into debates of what FF is meant to be for (i.e. fixate on word emergency and then argue a person’s job duties is not emergency)

        It’s always interesting trying to get the balance in the solution. I guess that mostly comes down to if it’s a risk; we need to track it; and can we justify the action to audit, etc. It’s partly why at the end of my comment to you I realised it might be a good discussion topic.

        Again, great to see these styles of writing that go beyond how to configure something in the system. I keep telling myself to write something but either I can’t think of a good topic (you’re a few steps ahead of me) or no time.

        Cheers

        Colleen

        (0) 
        1. Alessandro Banzer Post author

          Hi Colleen,

          I am constantly involved in such discussions but as this decision was taken by higher mangement I have a pretty good argument. Especially when it comes to SoD risks there isn’t much to discuss. Either they can define a compensating control which is effective for a particular risk or the assignment cannot be given. If the assignment cannot be given a possibility is to use firefighter to have the 4-eyes-principle in place.

          I fully agree that the naming “Emergency Access Management” can be understood wrongly but as EAM offers great possibilites it is definitely worth to use it.

          As I am not techy I am pretty much in such process and lifecycle discussion. Additionally I have the global responsibility of GRC and more focussed on defining processes, responsibilites, sequences, etc. in the global enterprise.

          Regards,

          Alessandro

          (0) 
  2. Madhu Babu Sai

    Hi Alessandro,

    I am following your blogs regularly these days. One good thing about your blogs is they are actually helping us to understand the process than technical aspects. That is where i want to improve my knowledge and thanks for all these blogs and keep them coming.

    From the projects i have worked for , I came across different opinions from different clients about this Emergency Access.

    1. One client was very strict that FF IDs should be used only by IT and no business user should be able to login as Firefighter.

    2. Another client wants 3 types of FF IDs.

    1. IT

    2. Business

    3. Production Support

    IT – Will have access to all basis transactions

    Business – Will have different Ids, like one for Accounts payable, one for Capital Project, One for Management Accounting, One for Invoicing ..etc

    Production Support – Will have access to all business configurations and table maintenance kind of activities to support business.

    Things which i want to understand from your expertise:

    1. How to decide on how many FF IDs required based on my authorization requirements?

    2. When i ask business in what kind of situations they need their users to login as Firefighters,most of them are clueless. They ask functional teams to identify and collect those scenarios.

    So, i just want to know your approach/understanding/suggestions on these.

    Regards,

    Madhu.

    (0) 
    1. Alessandro Banzer Post author

      Dear Madhu,

      thanks for your feedback. I try to answer your questions.

      Maybe a good start to share my idea on concepting firefighter in a business environment first.

      Personally I separate two main areas of users:

      – Technical users (like SAP CC, basis team, IT, etc.)

      – Business users (like finance, HR, sales, etc.)

      Technical users are not allowed to change anything in a productive environment without having the proper approval and each change must follow the 4-eyes-principle. This can consider SAP_ALL access (or similar) which MUST be monitored, e.g. by Firefighter, or also critical transactions to support business. For example if someone use sap edit, create or change business data (purchase orders, sales orders, invoices, GL accounts, etc. etc.) or customize anything directly in productive system.

      For business users I have actually two approaches for setting up firefighter. Mainly defined into “personal firefighters” and “functional firefighters”.

      – Personal firefighters contain authorizations which need to have a second person to verifiy and approve. Hereby I don’t differenciate if it is e.g. finance, sales, HR, etc. authorization. Personal firefighters are assigned to one user.

      – Functional firefighters are particularly defined for a specific function, for example payment proposal, maintain accounting period, change vendor, etc. Functional firefighters can be assigned to >1 users.

      Regarding your questions.

      1) Try to group functions together and then decide which approach is best. How many FFs you need is up to your considerations and your findings.

      2) Business does normally know who has to use authorization and to whom a firefighter should be given. I always consider the risk analysis for business, as if there is no risk I do not see the usage of a firefighter. From my point of view firefighter is a smooth way to remove a SOD conflict and to make sure a second person is verifying and approving a potential risk.

      Looking forward to hear from you.

      Regards,

      Alessandro

      (0) 
    2. Alessandro Banzer Post author

      What I forgot to mention: in some circumstances temporary SAP_ALL access is required in productive system (e.g. client copy) and to control this access we are using SAP Security Audit Log (transaction SM19 / SM20) for particular users (e.g. SAP* and basis administrator). This is also a very smooth way to check if proper access has been used.

      (0) 
  3. Sindhu D

    Hi Alessandro,

    Thank you very much for sharing valuable information, I need a suggestion, where i have a requirement to assign 100 firefighter IDs to more than 100 users, so to assign FF IDs to users we have to raise  a access request form for each user, which we want to avoid, as the FF ID can be used one at a time by a user so is there any alternative way for assigning FF Ids to all 100 users at the same time so each user has each FF ID assigned?

    Looking forward to hear from you.

    Thanks

    (0) 
  4. T. de Jong

    Hi Alessandro,

    Thank you for sharing this document.

    Can you add the role descriptions for each function?

    • Firefighter owner
    • SAP authorization team
    • SAP GRC responsible
    • Business role owner

    Is it correct to assume that the firefighter owner is the same person as the business role owner.

    Example: System Access for a Finance User is approved by the Finance Manager

    Assignment of Finance Role is approved by the Finance Role Owner

    Critical Access to finance data via a Firefighter ID is approved by FF_OWNER.

    Basically it is all about access to finance data which is a responsibility of the finance BPO-er. Of course he/she can delegate the responsibility, but he/she is accountable. Raci value should be A correct?

    In case in your example a firefighter owner solely refers to the GRC function, then it would make sense to add the function firefighter controller as well.

    (0) 
  5. T. de Jong

    Don’t get me wrong, I do not want to be a critic. However I would add double arrows from the Review Stage to Create, Delete, and Change. As reviewing should be part of each stage.

    See snapshot

    /wp-content/uploads/2014/04/snapshot_422702.jpg

    (0) 

Leave a Reply