{"id":9381,"date":"2023-07-18T09:01:33","date_gmt":"2023-07-18T16:01:33","guid":{"rendered":"https:\/\/www.microsoft.com\/insidetrack\/blog\/?p=9381"},"modified":"2023-07-18T09:07:38","modified_gmt":"2023-07-18T16:07:38","slug":"shining-a-light-on-how-microsoft-manages-shadow-it","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/insidetrack\/blog\/shining-a-light-on-how-microsoft-manages-shadow-it\/","title":{"rendered":"Shining a light on how Microsoft manages Shadow IT"},"content":{"rendered":"
Shadow IT is the set of applications, services, and infrastructure that are developed and managed outside of defined company standards. These line-of-business-built solutions (aka Shadow IT) have always existed at Microsoft and are a common industry problem.<\/p>\n
Over the years, corporate function teams\u2014including business development, legal, finance, human resources, marketing and sales, support, and consulting\u2014have looked to alternative engineering solutions for many different reasons. Some examples include a lack of IT engineering capacity or prioritization of the business need, historically decentralized budgets, a lack of trust between IT and shadow teams, the need for specialized domain solutions, and the availability of modern tools that enable no-code\/low-code solutions to be stood up by citizen developers.<\/p>\n
Many of these reasons make strong business sense, if it can be done securely. However, because Shadow IT solutions are often built outside of the guardrails of the company\u2019s engineering systems, they pose a potential compliance risk to the enterprise, specifically in the areas of security, privacy, data governance, and accessibility.<\/p>\n
At Microsoft, we needed to first understand if applications built by shadow teams met our security compliance standards. In 2019, we conducted a security assessment on a small random sampling built by shadow teams that showed that all the Shadow apps failed to meet at least two out of three of the key security requirements, and one Shadow app failed all key security requirement areas. This presents a huge and unnecessary risk to the whole company.<\/p>\n
Ensuring we address our biggest security vulnerabilities has been our first priority internally at Microsoft in our Shadow IT journey, as the risk in today\u2019s environment is huge. The average data breach in the United States costs $4.2 million (2021 IBM), and cybercrime costs the world $6-7 trillion annually (2020 Annual Cybercrime Report).<\/p>\n
[Learn how you can start reducing your organization\u2019s Shadow IT risk in 3 steps.<\/a>\u00a0Learn more about Microsoft Azure Tenant Security Solutions (scanner) available on GitHub.<\/a> Learn why Microsoft is doing more with less: Optimizing shadow IT through Microsoft Azure best practices.<\/a>]<\/em><\/p>\n Rather than centralizing all applications into IT, our goal is to reduce or eliminate Microsoft risk by enabling teams to self-manage their assets and ensure that they adhere to the compliance standards set forth by Microsoft. Teams must not only get clean, but also stay clean.<\/p>\n Microsoft compliance standards are typically defined as four areas of focus, which are all supported by our set of Engineering Fundamentals:<\/p>\n <\/p>\n Security:<\/u><\/strong> To ensure that the confidentiality, integrity, and availability of the data and systems of an organization is maintained.<\/p>\n Privacy:<\/u><\/strong> To ensure control over the collection, use, and distribution of information.<\/p>\n Data Governance:<\/u><\/strong> To ensure that the organizational roles and responsibilities by which information is retrieved is captured and maintained appropriately.<\/p>\n Accessibility:<\/u><\/strong> To ensure that our products or services are usable by everyone.<\/p>\n Of note, Engineering Fundamentals is seen as an enabler to many compliance areas. Solid engineering fundamentals enables teams with the data, processes, and tools to build solutions that are compliant by design. Retrofitting compliance requirements after a solution has been designed creates additional risk and more work for Microsoft. Additionally, engineering fundamentals enable compliance scale.<\/p>\n Given the size and scope of this program, we approached the journey as if we were running a marathon, not a sprint. We kicked off this program in 2020 and have been operating on a multi-year time horizon. Our work has involved and impacted many people, processes, and technology across the enterprise.<\/p>\n Initially, it was important for us to recognize that not all teams were at the same level of maturity. As such, we use the following model to ensure a consistent set of criteria is used to measure engineering maturity, which allowed us to engage with teams at the right level and provide the resources they needed to advance.<\/p>\n <\/p>\n Over time, shadow teams matured their level of engineering fundamentals and ability to adhere to compliance requirements. Most teams started their journey with manual efforts, and have made progress over time, but to date are not fully mature yet. We\u2019re continuing to work toward scaling our efforts, especially as the work gets more complex.<\/p>\n Likewise, each division had specific needs for the amount and kind of engagement we provided them, depending on the size, scope, and nature of the team. At Microsoft, we customized the approach based on the nature of the team to successfully move the shadow teams forward in their journey.<\/p>\n <\/p>\nVision<\/h2>\n
Compliance standards<\/h2>\n
Engineering maturity<\/h2>\n
Customized support<\/h3>\n