ITAR and EAR Compliance and Modern Product Development (Part II)
In Part I of this series, we outlined the difficulties you, as a high tech electronics manufacturer, can face when participating in the defense market. Your products may be subject to International Traffic in Arms Regulations (ITAR) and/or Export Administration Regulations (EAR), dictating tight control over all regulated technical data. Meeting these regulations while enabling your teams with the flexibility and transparency needed to make great products on-time is a challenge, but not impossible.
Our Part I blog explored ITAR and EAR requirements as they relate to controlled technical data access. We also reviewed the options for managing this product data as you execute product lifecycle management (PLM) activities. PLM tools and solutions range from word processing and spreadsheet applications and file servers to on-site systems and modern Cloud platforms. Regardless of your choice, as a registered manufacturer, you must have an understanding of regulatory requirements, identify responsible parties for each layer of your PLM tools, and enact appropriate controls. We concluded that a secure government-grade Cloud PLM provides a better-shared responsibility model as well as an enabling platform for doing the work of product development both now and in the future. Understanding what government-grade Cloud PLM offers will help you learn more about what you need from all your tools to meet regulations.
Regulations are requirements—treat them as such
Regulations are serious, and often we react with caution to reduce the risk of non-compliance. However, caution can also cost your business new customers, product innovations, and market advantages. A balance needs to be struck between meeting compliance and giving teams the advantages of current technologies and the best systems. How can you know when you have done this? When evaluating PLM options, remember that regulations as requirements. And to select the best solution, you must understand your requirements. Fortunately, for those of us in the business of creating products, requirements management is something we understand and apply here.
Requirements articulation should include:
- A statement of the need to be met, as specific as possible.
- Determination of an acceptable solution.
- The weighting of requirements as not all are equal in urgency and risk.
Regulations are onerous to read and often contain cross-references to other regulations and standards. And, some regulations are not, in fact, applicable for particular situations or companies. In short, due diligence is needed to move beyond assumptions and make the best decisions for your company.
De-mystifying ITAR and EAR regulations
Before going further, we need to be clear. ITAR and EAR regulations are complex. It is your responsibility to confer with your compliance officers and legal counsel to determine: if you need to register with ITAR, EAR, or both; what in your product data is under export control; and your requirements above and beyond specific regulations. Arena does not provide legal advice.
However, we can share our understanding as it relates to providing a government-grade Cloud platform—Arena PLM for AWS GovCloud—and why we believe it provides the balance between regulations and empowerment.
Here is the simplest regulatory articulation:
The regulations stipulate that any technical data under export control must not be exported outside the U.S. or accessible to any non-U.S. citizen at any point during design or production unless covered under an export license.
Jump over to our Part I blog and read more if you need a refresher.
For any solution you consider, you must determine how the requirement is being met and the responsible owner for that requirement. This is critical as solutions vary in approach and extent of meeting requirements.
Today, we will consider export controlled technical data in digital format (not the printed materials sitting on that desk, but digital bills of materials, product record metadata, and associated documentation).
One dangerous assumption made in the past is that if you store, access, and collaborate on your technical product data on-site (within your LAN/WAN/VPN), you are compliant with most ITAR and EAR regulations because everything is “local.” This is not true. Regulations require the demonstration of compliance regardless of where the solution resides.
The laundry list of security elements you must consider is lengthy. Everything from handling technical data from printed drawings sitting on an engineer’s desk, to digital files on an internal file server, to uploaded data in an on-site system or a Cloud application must be evaluated. Exporting controlled technical data can still occur while within the U.S. when the data is transmitted or shared in any form or format (including oral, written, physical observation, paper, email, phone, fax, application access, etc.) with foreign nationals.
Any compliance assumptions you make are by nature risky and almost always costly. Go back and read the above paragraphs again, please.
Primary considerations for digital technical data
Audited Policies and Procedures
o The statement of the security framework being used to secure export-controlled data (all the above in isolation, data integrity, and access controls), including network diagrams, company policies, security configurations, security responsibilities, threat analysis, incident reporting, and employee roles for each system in your environment that processes, stores, and transmits controlled unclassified information (CUI).
Technical Data Integrity
1. Data encryption.
When digital data moves, it needs to be encrypted. When it is stored digitally (is at-rest), it also should be encrypted. Your system of record (such as a PLM) should provide this encryption. If it is on the file server or the laptop, you need to provide this encryption layer with an appropriate tool.
2. Data movement to other systems/tools.
Does data move between locations or systems as a part of business processes? If so, what data and how are controls enforced?
3. Data classification of controlled data as “controlled.”
Most likely not all of your technical data is under export control. Controlled data, whether part numbers, descriptions, and BOM structures or digital product files, need to be identified in order for any user access control–enabled and authorized use of a resource while preventing unauthorized use or use in an unauthorized manner.
1. End-user access control.
Who specifically can access this data? How do you limit access to only those people and how do you know others cannot access?
2. History of end-user access, ensuring proper controls enforced.
1. Physical location.
The physical location of the hardware, be it file server, laptop, on-site PLM system, Cloud system, or external drive. For ITAR and EAR controlled data, the physical location must be the United States.
2. Logical and network isolation.
Prevention of any other uncontrolled, unaudited system, or device that might share the same network (physical or logical) from being able to communicate with the system storing controlled data.
Example: An easily understood example would be a network file server. If it stores controlled data, it cannot be accessible from other file servers (on the same network) that are open to foreign nationals or from U.S. citizens in an office outside the U.S. via the network.
For any solution you use with controlled product data, you should assess these key areas.
In the file, we list two PLM solution options (yes, one of them is Arena’s platform) in order to make this more concrete and useful. We have provided you a summary of how our solution answers these requirements areas as well as prompts to explore other options, such as on-site PLM.
You can (and should) then do this assessment exercise for every solution you are considering—or already have in place. Remember the Don’t Assume mantra. Any tool you use (including shared files on a server) with export-controlled data needs to be assessed.
In our Part III of this series, we’ll move away from regulatory intricacies and look at the business of making products for both commercial and defense, why it can be a bit tricky, and the most important things to get right for success in all your markets. Read about some of the opportunities and challenges of defense market entry.