Unbeknownst to many companies, serious compliance issues lurk in the cloud. Shiva Aminian, an international trade lawyer who focuses on U.S. export controls, discusses below the regulatory challenges facing cloud users. Her remarks have been edited for length and style.
MCC: Most companies are aware of the security and privacy implications of cloud computing. They may not, however, be aware of the export control implications of cloud computing. Please give us an overview of those implications.
Aminian: Before discussing the export control implications of the cloud, we need to level set on two basic concepts: (1) how do export control rules regulate data; and (2) when it comes to data, what constitutes an export?
U.S. export control laws do not just regulate the movement of hardware. Rather, these broad regulations also extend U.S. jurisdiction to certain “technology” or “technical data.” The types of controls that extend to data depend on its export control jurisdiction and classification (J/C). Export control jurisdiction means: Is the data subject to U.S. International Traffic in Arms Regulations (ITAR) or U.S. Export Administration Regulations (EAR)? In terms of ITAR, classification means: What U.S. Munitions List (USML) category applies? In terms of EAR, classification means: What Export Control Classification Number (ECCN) applies?
EAR defines “export” as an actual shipment or transmission of items out of the U.S., or release of technology or software to a non-U.S. national in the U.S. The definition of “export” under ITAR is analogous.
Now that we have covered the basics, let’s consider how these concepts play out in the cloud computing space. First, companies that are using the cloud must establish whether the information that they are uploading to the cloud falls within the scope of technology or technical data that is subject to U.S. export control regulations. Assuming the information is subject to export controls, companies must then determine the J/C of the data.
This threshold question presents significant challenges, because many companies use IT systems that are not yet set up to record J/C information. How does this look in practical terms? A company has data residing on its internal IT system, and is considering uploading the data in the cloud. Most often, companies do not know the J/C that applies to each piece of information residing on that IT system. Moreover, applying the definitions in the regulations to come up with the correct J/C for data is not an easy task – and it is fraught with “gray zone” areas.
Let’s assume that a company has passed the first hurdle and knows the J/C of the data it is seeking to upload to the cloud. The company must now understand where that data is going. In other words, is it exporting the data, and if so, where and to whom? Depending on the J/C of the data and the country of export, an export license may be required.
The current definition of export was not written during a time when cloud computing was in the playing field, and, therefore, the direct application of the term “export” in this space creates significant challenges.
Once data is uploaded in the cloud, it can be located on different servers that are, in turn, located in different countries. Uploading data to a server outside the U.S. is considered an export and could require an authorization, depending on the J/C of the data and the location of the server. This presents significant challenges because, with the cloud, the user doesn’t necessarily know where the data will be located, and the server locations could also change.
Another challenge is the location of the users accessing the information on the cloud. Consider the following example. Technology that is subject to U.S. export control regulations is uploaded in the cloud. In this example, the cloud provider has ensured that all servers are located in the U.S., and so on its face, an export is not occurring because the data is not leaving the U.S. If a user in China accesses the data on the cloud, however, an export has just occurred, even though the data and servers are all located in the U.S. Depending on the J/C of the data and the location of the user (in this example, China), an export control license may be required.
Finally, the nationality of the cloud administrators also presents risks – particularly if the data at issue is subject to ITAR. Under ITAR, the mere ability of non-U.S. persons, whether in the U.S. or abroad, to “access” ITAR-controlled data presumes an export. Therefore, when analyzing export control implications, users and cloud providers must consider whether an export will occur as a result of non-U.S. administrator access.
MCC: The U.S. export control laws apply to technology, which the Export Administration Regulations define as “specific information necessary for the development, production or use of a product.” Yet those definitions differ among export control agencies and are subject to interpretation. Can you help sort that out for our readers?
Aminian: ITAR defines unclassified technical data to include information that is required for the design, development, production, manufacture, assembly, operation, repair, testing, maintenance or modification of defense articles. This includes information in the form of blueprints, drawings, photographs, plans, instructions or documentation. ITAR does not yet provide a definition of “required,” although a proposed rule issued in June 2015 seeks to provide a definition for the term.
In order to fall within the scope of the USML, the data must satisfy two conditions: (1) it must meet the definition of “technical data,” meaning it must be “required” for the design, development, etc. of defense articles; and (2) it must be directly related to those defense articles. For example, the design drawing of a military UAV engine (a defense article), would fall within the scope of ITAR-controlled technical data because it is “required” for the design of that defense article, and it is specific to that defense article. On the flip side, an engine maintenance manual that is generic – meaning it is used for maintenance of multiple engine models, both civil and military – may be “required” for the maintenance of that military UAV, but is not “directly related” to the defense article because it is used across many different models and is not specific to the military item.
The EAR definition of technology is more precise, because the government has already defined threshold terms such as “required.” Pursuant to EAR, technology is defined as: “[S]pecific information necessary for the ‘development,’ ‘production,’ or ‘use’ of a product.”
The notes to the definition of technology provide that “controlled” technology is defined in the General Technology Note of EAR and in the Commerce Control List (CCL). This means that technical information that is necessary for the development, production or use of an ECCN-listed commodity or software is only controlled under the corresponding technology ECCN if it meets the requirements of the General Technology Note.
Under the General Technology Note in EAR, technology that is “required” for the “development, production, or use of items on the CCL is controlled according to the provisions in each category.”
EAR defines “required” as “only that portion of technology or software which is peculiarly responsible for achieving or exceeding the controlled performance levels, characteristics or functions.”
An Advisory Opinion (AO) published by the U.S. Commerce Department’s Bureau of Industry and Security (BIS) on March 25, 2014, further clarified that the “required” limitation in the General Technology Note applies to all technology ECCNs, not just the ECCNs that use the term.
This means that, in order to fall within the scope of technology that is captured by an ECCN, the information must: (1) meet the definition of technology – meaning that it must be necessary for the development, production or use of an ECCN-listed item; and (2) meet the requirements of the General Technology Note – meaning that the necessary information must be required for achieving or exceeding the controlled performance levels, characteristics or functions of the ECCN-listed item. Represented visually, technology controlled under a specific ECCN is only the technology residing in the smallest circle (see the diagram on the following page).
As you can see from the diagram, there is still a lot of subjectivity involved in applying the “required” for threshold. What data is “necessary” versus “required”? What if data is “helpful” in the design or maintenance? Where does it fall in the diagram? To complicate matters, many ECCNs do not list out specific controlled parameters – which makes the task of identifying the “required” for element even more subjective.
While the definitions of ITAR and EAR differ, the U.S. State Department and the Commerce Department issued a proposed rule in June 2015 that seeks to harmonize the definitions. The proposed rules also try to provide more clarity on how to apply the “required” for threshold, but the proposal has been received with some criticism from the industry.
MCC: In June, the Department of Commerce’s Bureau of Industry and Security, and the State Department’s Directorate of Defense Trade Controls published proposed rules designed to harmonize Export Administration Regulations and International Traffic in Arms Regulations. Tells us about that effort and the status of efforts such as these by the government to bring some clarity to this area.
Aminian: The proposed rule takes some important steps toward recognizing the current landscape that the cloud computing community is facing, and it modifies certain historic definitions to address some of the concerns that industry has raised.
The current definition of “export” is the actual shipment or transmission of items out of the U.S. This means that the transmission of technology subject to EAR to a non-U.S. server is an export. The proposed rule includes an important carve-out from this definition. Specifically, it establishes a specific carve-out from the definition of “export” for the transfer of technology and software that is encrypted in a specific manner.
This means that cloud users may be able to upload encrypted technical data to the cloud and fall outside the scope of an export and the resulting licensing requirements for server locations, user locations and non-U.S. administrators. The important caveat is that the encrypted data must meet certain requirements – specifically, the technology must be encrypted “end-to-end,” which the proposed rules define as the provision of uninterrupted cryptographic protection of data between an originator and an intended recipient.
MCC: The government seems to have provided limited guidance in this area. Where has the government weighed in and added some clarity, and where are the gaps exporters should be aware of?
Aminian: Industry, and particularly cloud providers, have been pushing the government to provide more guidance in this area
BIS issued a January 2009 opinion stating that a cloud provider operating within the U.S. is generally not the exporter of controlled technical data that users place on, and retrieve from, its cloud. A January 2011 opinion explained that cloud providers do not need to obtain “deemed export” licenses for their foreign-national IT administrators who have access to cloud users’ controlled technology because the cloud provider is generally not the “exporter.” A November 2014 opinion confirms that there is no export of software when the user of cloud services does not download executable software, but merely operates the software as a service “in the cloud.” This guidance is limited, and while it provides some relief for the cloud provider, by converse, it places the export control responsibilities on the cloud users who don’t always have control or visibility into the server locations and access concerns.
The State Department’s Directorate of Defense Trade Controls (DDTC) has also issued a General Correspondence in May 2014 on the use of tokenization to secure ITAR-controlled technical data. Perspecsys touted the opinion in a press release as groundbreaking, stating that DDTC had approved the use of tokenization to process ITAR technical data in the cloud without a license, even when the tokenized technical data was transferred to servers located outside the U.S.
DDTC subsequently issued a statement, making clear that tokenization is not a sufficient step to prevent foreign access to ITAR-controlled technical data on the cloud.
MCC: There seems to be very real tension between the features and benefits of cloud computing, such as its transnational character, scalability and portability, and export control laws and regulations. In fact, when a U.S. company uploads technical information to the cloud, it very likely has no idea where that data will be stored in the cloud – which could be anywhere in the world. How can companies mitigate the risks of the murkiness of the trajectory and locations of its data, short of shunning the cloud altogether?
Aminian: Companies can mitigate risks by ensuring that they know the J/C of the data they are uploading to the cloud, and ensuring that they are only using the cloud for nontechnical information or “low-level” technology. If low-level technology is involved, companies must take steps to ensure against unauthorized exports to the handful of prohibited countries. Companies can also safeguard against risks by requiring contract provisions that limit the authorized locations for servers and nationalities of IT administrators.
Apart from that, companies should be active in the rulemaking process. The government recognizes that the current export controls definitions and structure are antiquated and it is looking to modify threshold definitions to account for the new environment – including cloud computing. Companies should carefully consider and weigh in on the proposed rules, and ensure that their concerns are addressed through the rulemaking process.
Shiva Aminian, Partner at Akin Gump Strauss Hauer & Feld LLP. saminian@akingump.com
Leave a Comment