Shadow IT is an (in)famous phenomenon in today’s business environments. Business departments source, develop and maintain systems on their own to support their processes. Although shadow IT supports critical business functions and is therefore accompanied by many risks, it still cannot be prohibited nor suppressed. Because of these risks, there is an urgent need to manage shadow IT. As COBIT 5 is a powerful framework for managing enterprise IT, it is interesting to look into the relationship of shadow IT and COBIT.
In this blog post I would like to focus on three different questions:
1. Which COBIT processes are meant for an organization affected by the existence of shadow IT?
2. Which COBIT processes are missing or lack maturity when business departments run their own IT?
3. How can someone start and run a shadow IT initiative?
The first question concerns the overall IT maturity. In COBIT 5, there are several processes that deal with the overall integrity and effectiveness of a company’s IT. Risk and compliance management and enterprise architecture are topics that require an integrated view on IT. The existence of shadow IT hinders this integrated view, so these important functions are disturbed.
In the case of risk management, for example, processes like EDM03 and APO12 ask for the definition of risk appetite and the definition of a risk-aware culture. Furthermore, all relevant risk should be reported and managed accordingly. Shadow IT by nature is not managed. In our studies, for example, we have never seen a shadow IT-related risk in any risk map, where in more than 16% of all cases, a shadow IT system was critical for processes with an accepted recovery time of less than one day (see Figure 1).
Regarding IT compliance management, we can observe a similar situation: the current European GDPR requirements can be violated by shadow IT, as it may exceed the purpose of data processing that has been agreed with a customer. Furthermore, shadow IT is often unknown, so that a company cannot report all systems with personal data. Finally, shadow systems often lack technical features, making it difficult to control data access and prove deletion of data records.
In terms of the overall enterprise architecture, shadow IT can also be a roadblock to the successful management of a company’s system and technology landscape.
Because shadow IT systems often are not known across the company, its architecture models, inventories and data definitions are incomplete, and thus processes like APO01 and APO03 may be incomplete. Also, processes like EDM04 are ignored as architecture principles may not be followed.
The second question covers the individual quality of shadow IT systems. When assessing existing shadow IT instances, it is important to understand the quality of its current management. Again, COBIT 5 offers a good starting point for this task: several processes deal with the individual IT services and can be used to assess the quality of each instance. As to be expected, business departments lack professionalism in IT management topics; therefore, they omit important processes from the BAI and DSS process areas. Mostly tasks like cost management, service planning, testing and security are not considered. For example, is DSS05.04 asking for a user identity management, which typically does not exist in shadow IT systems? You can find some project examples in Figure 2 below.
Figure 2: Missing COBIT processes
Our third question deals with the justification and the set-up of a shadow IT initiative. As explained above, shadow IT interferes with the overall quality of IT management and lacks individual quality. Both aspects justify starting a shadow IT initiative, as these quality issues impose risks to the company. Nevertheless, do MEA02 and MEA03 require assurance for internal and external compliance, which also includes searching for shadow IT? Also, in executing processes BAI10.05 and DSS04.04, an IT auditor can watch out for shadow IT.
A shadow IT initiative should aim for the identification and evaluation of all existing shadow IT instances as well as the definition of measures to mitigate existing risks. Mitigation, for example, can be achieved by transferring the responsibility for a shadow IT service to the IT department or setting up quality standards for the business department. In addition to the identification of existing shadow IT instances, such an initiative also gives insights into the deficits of a company’s current IT governance.
Shadow IT can be a critical topic. Therefore, it is recommended to watch out for some major success factors: just sending out questionnaires to collect a list of shadow IT instances is everything but promising. Identifying shadow IT by direct interviews is typically more successful but can be very time-consuming. Thus, it is recommended to undertake some pilot projects to create stories and experience within an organization. From there, business departments can identify and analyze their shadow IT in a self-assessment approach. This self-assessment should be embedded within an adaptive IT governance framework that assigns responsibilities between the business and IT department on a flexible basis. The IT audit function should take the role of facilitator and bring the topic to the table to let it be solved by business and IT. After implementation, of course, IT audit needs to assure the quality of the self-assessment approach and functioning of the adaptive IT governance.