{"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":"

\"MicrosoftShadow 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

Vision<\/h2>\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

Compliance standards<\/h2>\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

\"Compliance
Microsoft compliance standards.<\/figcaption><\/figure>\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

Engineering maturity<\/h2>\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

\"Moving
Moving through the Shadow IT journey starts with lower levels of maturity that focus on centralizing tools and platforms, moves to driving culture change, then to full automation and continuous compliance.<\/figcaption><\/figure>\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

Customized support<\/h3>\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>\n\n\n\n\n\n\n
Pattern<\/strong><\/th>\nCharacteristics<\/strong><\/th>\nApproach <\/strong><\/th>\n<\/tr>\n
Small teams with small asset footprints<\/strong><\/td>\n\n
    \n
  • Teams with a smaller asset (services and Azure subscriptions) footprint.<\/li>\n
  • These teams can be more agile in how they organize their efforts around the program.<\/li>\n<\/ul>\n<\/td>\n
\n
    \n
  • Push teams forward in their modern engineering and security journey.<\/li>\n
  • Use learnings from Pattern 1 teams to inform Patterns 2 and 3.<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
Medium to large asset footprints<\/strong><\/td>\n\n
    \n
  • Teams with a medium-to-large asset footprint.<\/li>\n
  • These teams may be able more agile in pockets but will need to look at automation and policy in some cases, and will require the organization to solve for the program collectively.<\/li>\n<\/ul>\n<\/td>\n
\n
    \n
  • Identify points of contact per organization.<\/li>\n
  • Push forward with smaller, more technical teams.<\/li>\n
  • Ensure more thorough plans and support models in place for less technical teams.<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
Large to very-large asset footprint<\/strong><\/td>\n\n
    \n
  • Teams with a large-to-very-large asset footprint.<\/li>\n
  • Given the size, complexity, and geographic dispersion of assets, these teams will require automation and much more rigorous planning to move forward.<\/li>\n<\/ul>\n<\/td>\n
\n