This allows access to the table but prevents access to other tables within the authorization group. Prior to the authorization object S_TABU_NAM, one of the methods to reduce risk was to create a parameter transaction and skip the initial screen. Providing a user access to table maintenance transactions and access to the table through authorization object S_TABU_DIS creates excessive risk to potentially sensitive data. When functional requirements direct a security architect to provide SE16/17, SM30/SM31 or other direct table access (SM34) to the authorization group &NC&, what is the risk? In most ECC environments you will find more than 10,000 tables assigned to the authorization group &NC&. Even SAP leaves many tables in the authorization group &NC& as they may have never been designed for direct table maintenance in a production environment. However, many application developers never define an authorization group for the table and accept the default value &NC& (Not Classified authorization group). Whether the table was delivered by SAP or created custom, the authorization group has been the classic method of controlling access to tables in SAP.
Many of these companies also convert transportable tables into tables that are directly maintained in production. In each of these companies requirements have dictated that additional custom tables are required to extend SAP functionality for reports or custom processes. For over 15 years I have worked for multiple companies that run their business on SAP software.