This article is the third of a series in the Microsoft Tech Community Public Sector Blog and touches on the most disputed conundrum of adopting cloud services in Microsoft 365 Government (GCC High). Should you deploy a data enclave, or go all in?

For the first article in the series, please refer to History of Microsoft Cloud Service Offerings leading to the US Sovereign Cloud for Government. For the second article, go to Understanding Compliance Between Microsoft 365 Commercial, GCC, GCC-High and DoD Offerings.

The Journey

Over the last three years since Microsoft 365 GCC High first launched, I have spoken with several hundred in the Defense Industrial Base (DIB) on the alignment of compliance requirements to select the most appropriate Microsoft cloud solution. This includes Aerospace and Defense (A&D) contractors for the US Department of Defense (DoD). The DIB is primarily made up of commercial entities providing products and services to the US armed forces. The DIB is unique in that they often operate as a commercial enterprise but are held accountable to US Defense regulations and standards, not unlike the accreditation required for a US Government entity. For example, to contract with the DoD, a DIB entity must demonstrate compliance with the Defense Federal Acquisition Regulation Supplement 252.204-7012 (DFARS), NIST 800-171, International Traffic in Arms Regulation (ITAR) and an alphabet soup of compliance standards. Selling to the DIB is also exceptional in they may truly possess commercial business units, or have mixed-use products and services that place their commercial business at odds with the Aerospace and Defense business, at least from a compliance posture.

From the first engagements with the DIB, virtually everyone begins the journey rationalizing the use of an ‘ITAR Compliant Data Enclave’. It typically mirrors what many have been doing on-premises. As the conversation has matured, and the DoD began enforcing DFARS on contracts, customers of GCC High have shift more and more users and workloads into GCC High. For those having difficult time finding the line of demarcation between the commercial and A&D business, most are now choosing to go all into GCC High. But for many, it took intense debate and decision-making to come to that conclusion. The A&D team here at Microsoft affectionately refer to this decision-making process as the 7 Stages of Grief.

The ‘ITAR Compliant Data Enclave’

What is a data enclave in this context? Some may also call it a ‘Bastion’ or a ‘Sequester’ for ITAR data. Ultimately, it’s shared storage for legal or technical documentation that may include Controlled Unclassified Information (CUI) or Covered Defense Information (CDI). It’s quick and easy to deploy, and often maps 1:1 with a data enclave that is on-premises today. It’s also considered to be much less expensive than alternative approaches that place more users and workloads into GCC High. On the outset, the IT cost of a data enclave does appear to be much less hassle and expense. After all, you can just lift-and-shift the on-premises documents to the cloud with a common set of migration tools. And you may choose to buy the minimum set of licenses to support the scenario. However, hindsight has proven the data enclave approach is not the holistic solution that is required to demonstrate compliance and has proven to be more expensive in the long run. This is evident if you take the holistic cost, and opportunity cost, accounting for the loss of business if your company fails to demonstrate compliance effectively.

Shared Data versus Personal Data

Shared Data is file storage or collaborative workspaces where multiple users may be owners, authors, contributors, readers, etc. This may include unstructured file storage on a file share, a SharePoint document library, a Microsoft Team, or a shared mailbox.

In an enterprise context, Personal Data is the collection of information where the user is the sole owner, and often maps 1:1 with a user’s enterprise account. Personal Data includes the user’s mailbox for email, their personal file storage, and their SIP account where a they instant message with others, host meetings, or have IP voice calls with their enterprise account and/or phone number. In the Microsoft 365 world, the mailbox is hosted in Exchange Online, the personal file storage is mapped to OneDrive for Business Online, and their SIP account is in Teams.

In the journey to compliance with US defense regulations, the emphasis has shifted from where the Shared Data resides, to where the Personal Data is located. Most DIB agree Shared Data that may contain CUI or CDI must be in an ITAR compliant data repository. However, historically much less emphasis has been placed on compliance with the Personal Data. Many have chosen the policy that CUI/CDI should not go into Personal Data.

The truth is, Personal Data is not immune from compliance. The most common spillage of CUI/CDI is into personal storage, especially in email. I’ve heard customers say the majority of their spill mitigation is in email. If your Personal Data solutions are not hitting the high bar for compliance, or worse, if they are hosted in a Commercial cloud, you have much more scope outside the accreditation boundary than where your Shared Data resides. After all, the industry is only in its infancy in terms of identifying and tagging (what we call ‘Labelling’) CUI and CDI. As a result, there is a high probability CUI/CDI is in places where you have policies prohibiting it.

It may not be your enterprise or users’ mistake for a spill into your Personal Data! It may be your customer, partner, vendor or supplier that is sending you the CUI/CDI.

There is an evolving compliance verdict that Personal Data must fall within the accreditation boundary to be compliant with defense regulations. You may choose to enforce a policy that Personal Data is out of scope, but others may not come to the same conclusion. In other words, your customer may mandate you pull your Personal Data to within the accreditation boundary or they may choose not to do business with your company. This is not just the DoD but include the many DIB Prime Contractors out there that enforce compliance in a Flow-Down.

Migrating ITAR Users to GCC High

The next step in the journey is the decision to migrate users with direct data handling of CUI/CDI to within the accreditation boundary. For the DIB, this maps to migrating the ITAR users into GCC High along with their Personal Data.

The ultimate challenge with this approach is, where do you find the line of demarcation between those users that require persistent access to CUI/CDI, versus the rest of the user population? There are only a few types of customers where this decision is obvious.

A Federal entity that requires data sovereignty

A Commercial Enterprise where a significant portion of the business is A&D

An autonomous Business Unit inside a Commercial Enterprise that is exclusively A&D (e.g. the Public Sector business)

For everyone else, finding the line of demarcation has become elusive and is the conundrum for deciding who migrates to GCC High.

Naturally, as soon as any customer evaluates the non-discounted price tag for GCC High, they often shift to minimizing the number of users to reduce cost. It comes to no surprise when we get the first order from a sizable enterprise asking for the minimum number of seats in GCC High. However, most discover the minimum user count is not sustainable and will often grow sizably over time. Nowadays, I just call it the ‘Pilot’ until the customer continues to evolve their compliance posture.

Unfortunately, we’ve observed undue pain and frustration as a result of this approach. We have numerous customers that have daily or weekly migration batches moving more and more users into GCC High. It’s often the result of overlooked touchpoints with CUI/CDI such as in the legal department, accounting, etc. Or for what I affectionately call the ‘swivel seats’. The swivel seats are those users that rarely work with CUI/CDI but are borrowed into the A&D business for a specific project or short-term tenure. The swivel seats are not immune from compliance. In fact, they are quite often your largest exposure to spillage.

This pain and frustration is further exasperated if the users are located in a Commercial Cloud. You can only imagine the baggage associated with a migration from Commercial. It often includes the re-homing of device and software registrations, MDM enrollments, encryption technologies, etc.

Going All In To GCC High

Microsoft always recommends that an enterprise should deploy to a single tenant in the cloud unless it’s completely unavoidable. Defining what’s unavoidable is a good topic for another series of articles. For the DIB, the requirement for multiple tenants often maps to competing jurisdictions. For example, if you have a customer in the United Kingdom that requires data residency on UK soil, that competes directly with the jurisdiction for CUI/CDI categories that require data sovereignty in the US (e.g. ITAR). In other words, that UK data cannot by definition go into GCC High in the US Sovereign Cloud.

For the sake of simplicity for this argument, let’s assume the line of demarcation in your user population is simply between Commercial and GCC High. GCC High hits the high bar for compliance with US regulations and standards. Your company may put everyone into GCC High, including the exclusively Commercial user accounts. This may comprise user populations counting Foreign Nationals (from the US perspective) and users connecting from Outside the Continental United States (OCONUS). Microsoft nor GCC High restricts users nor connectivity. However, it’s your shared responsibility to maintain compliance. In other words, if you have CUI/CDI in your GCC High tenant, it’s up to you to lock that data down using access controls and data protection policies. Fortunately, if you do have a spill to an unauthorized user inside a GCC High tenant, it is contained within the US Sovereign Cloud to include the accreditation boundary. Spill mitigation is less complicated in GCC High than it is in a Commercial Cloud.

For this reason, more and more of the DIB are deciding to go all in. It’s much less complexity than attempting to straddle multiple tenants that are cross-sovereign cloud. It’s even potentially less IT cost at the end of the day, if you compare the cost of complexity paired with the financial cost and disruption of migrating people between the two environments. This may include the elevated cost of spill mitigation from the Commercial side environment.

By far and large, the principal motivator for going all into GCC High is the business opportunity or loss associated with compliance. Many DIB, especially the Prime Contractors, simply cannot afford to lose business. Or for those that are ahead of the curve, they have a distinct competitive advantage by demonstrating compliance aligned with Microsoft 365 Government (GCC High). After all, the DoD itself has already migrated many users, and is now committed to migrate all armed forces into the same Microsoft US Sovereign Cloud.

Closing Note

There are many valid reasons for companies to deploy a ‘cross-sovereign cloud’ or ‘multi-cloud’ solutions, to include one or more tenants in Commercial, GCC, GCC High, etc. The reasons that make a cross-sovereign cloud solution ‘unavoidable’ are good topics for another series of articles.

Defining what’s unavoidable would include large and complex organizations with a multi-national presence where geographical subsidiaries may need to demonstrate levels of compliance for that region or country. There are also mind-bending topics including export licenses to OCONUS locations/user populations, along with re-imports for export-controlled data.

Please let me know if there is interest out there, and I’ll start writing.

Appendix

Please follow me here and on LinkedIn. Here are my additional blog articles: