Skip to Content

Access to SM30 in Production


We've been audited recently to adhere to Sarbanes-Oxly standard and one of the OAG comments is that no one should have access to SM30 in Production. We started looking into this and if we remove SM30 from the security profiles then Function staff responsible for configuration cannot perform a lot of validation reviews in SAP IMG activities via SPRO. We simply only want display access and we ensure this via S_TABU_DIS with activity type 03 only but once SM30 is remove from their profile they can no longer use SPRO to validate configuration. Does anyone else have this same dilemma?


Wayne Villon (Canadian Broadcasting Corporation)

Add a comment
10|10000 characters needed characters exceeded

Related questions

2 Answers

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Nov 22, 2005 at 03:43 AM

    Hi Wayne,

    Even in our organisation we had the same issue. But we've overcome this problem by creating a Transaction Variant for all those tables that are supposed to be maintained in PRD. These Tcodes should then be attached to the respective user ids who must have access to the table maintenance.

    The procedure is simple.

    Goto SE93 and create a Transaction variant for SM30.

    Give the table name and Update = X in the variants part and activate this.

    Having done that, you must then attach this Tcode to the corresponding profiles of the users in PFCG.

    Revert back for any further clarifications.



    Add a comment
    10|10000 characters needed characters exceeded

  • Posted on Nov 22, 2005 at 02:49 AM


    When we started our implementation 3 years back, we consciously avoided giving SM30 access to people in production. The reason why auditors are very stringent about this is that, this has no control over which table you change. So, once you have SM30 access, you can change almost any table that has table maintenance.

    How we avoided it is for all the Z tables, we created our own mini SM30, which essentially does the same thing like SM30, taking a table name and allowing the users either to update or display records. But the big difference is that we created a custom authorization object that takes a table name and an activity as its value. Thus we were able to control which user has which table access and to what action. Although our solution works equally good with standard SAP tables, we didn't take that route.

    Config/SAP standard tables are different. We took the conservative approach of transports. You do your changes in DEV, do a thorough test in QAS and then move them to PRD. No config change is allowed to be done directly in production system. Yes, display access to SPRO is given to some functional folks but if that in turn calls SM30 with a change access, then it is not allowed. We try to refresh our QAS system with production system, every now and then, so that we can diagnize most of the problems in QA system itself.

    Having said that, we left open the exit strategy, which is ok with the auditors is that, if such access is absolutely needed, the access will be given upon proper approval from the BPOs for <b>one time access</b> only. Upon reviewing/changing whatever, the access is immediately removed(actually the role will be assigned with an expiry date).

    You can even try transaction variants, wherein, you will prefill the SM30 initial screen and allow users to go directly to the table. So you need to create that many such transactions as you have the tables/views that are needed to be modified. This way you can avoid letting people access tables that they are not supposed to touch.

    Hope this helps,


    Add a comment
    10|10000 characters needed characters exceeded

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.