Export Controls and Encryption: Hidden Compliance Risks in Software Licensing

If your software uses cryptographic tools such as encryption, you may be required to comply with U.S. export requirements.

This article covers common cryptographic functions in software, U.S. export regulations on software that uses cryptographic tools, and potential compliance risks, and includes a step-by-step guide to managing those risks.

How Software Uses Cryptographic Tools

Cryptography consists of techniques for protecting confidential data during transmission and storage. The word cryptography literally means "secret writing," as it comes from the Greek kryptos, meaning "hidden," and graphien, meaning "to write."

Common cryptographic tools in modern software include encryption, authentication, and digital signatures. Let's take a look at each of these techniques.

Encryption

Encryption uses algorithms (mathematical instructions) to protect data. Encryption scrambles the data and turns it into ciphertext so that it is unreadable by anyone who doesn't have the decryption key. Think of an encrypted message as a locked mailbox; only authorized parties who have the key can access the encrypted data inside.

Authentication

Authentication is a way to verify a user's identity by requiring the user to provide information only they should have access to, such as a password or biometric data. A popular method of authentication is using facial recognition technology to unlock a smartphone or access financial apps on your device.

Digital Signature

Unlike physical signatures, digital signatures can prove that no changes have been made to an online message or document after it is signed. Digital signatures work by generating a unique hash (a fixed string of numbers and letters from a file such as an email or document) using a hash function. The hash is then encrypted with the sender's private key. Any changes made to the document or message will change the hash.

For instance, let's say you are selling your house and need to sign a digital document from your realtor agreeing to list at a certain price. You can digitally sign the contract using your private key. Your realtor can then use a public key to verify your identity and ensure the document was signed by you.

What U.S. Export Laws Regulate Software That Uses Cryptographic Techniques?

Software distributors must comply with U.S. export control laws, specifically the Export Administration Regulations (EAR). Other regulations software distributors may be subject to include the Office of Foreign Assets Control (OFAC) Sanctions Regulations, Foreign Trade Regulations, and the International Traffic in Arms Regulations (ITAR).

The EAR is administered by the U.S. Department of Commerce, Bureau of Industry and Security (BIS), and controls any items that are exported, reexported, or transferred in-country that are not exclusively controlled by another U.S. government agency or not specifically excluded from the EAR.

In the context of software distribution, exporting, reexporting, and transferring have the following definitions:

• Exporting includes shipping or transmitting items out of the U.S. and releasing or transferring technology or source code to a foreign person in the U.S. (a "deemed export").
• Reexporting means shipping or transmitting an item from one foreign country to another foreign country or releasing or transferring technology or source code to a foreign person in a country other than the foreign country where the release or transfer occurred (a "deemed reexport").
• Transferring is changing the end user or end use of an item within the same foreign country ("in-country transfer").

The definition of exporting in Section 734.13 of the EAR includes transmitting items outside of the U.S. as well as transferring technology or source code to foreign nationals located in the U.S.

The following items that are exported, reexported, or transferred are subject to the EAR:

• All items located in the U.S., including items in U.S. Foreign Trade Zones or items passing through the U.S. when being moved from one foreign country to another
• All items that originate in the U.S., regardless of where they are located
• All foreign-made commodities (basic raw materials that can be traded for another or for money, such as corn, oil, or steel) that incorporate controlled U.S.-origin commodities
• Foreign-made commodities that are "bundled" with controlled U.S.-origin software
• Foreign-made software that is commingled with controlled U.S.-origin software
• Foreign-made software that is commingled with controlled U.S.-origin technology
• Certain foreign-produced "direct products" of technology and software
• Foreign-manufactured items that are developed or produced from U.S.-origin encryption items that are exported in accordance with License Exception ENC (an EAR provision that allows certain encryption items to be exported or reexported without a full export license)
• Certain foreign-produced products from a complete plant or a major component of a plant that is a "direct product" of technology or software

Export controls on encryption software (software that implements cryptography) are distinguished from controls on other EAR-regulated software because of its potential risk to U.S. national security, foreign policy, and law enforcement interests, and its necessity in protecting sensitive information.

Is Open Source Software Subject to U.S. Export Laws?

Open source software is software that allows users to access, modify, or distribute the source code.

Open source software, specifications, files that describe designs for hardware, and binaries that are published and made publicly available, are generally not subject to the EAR.

However, if your software is open source, or parts of it use open source code, it may be subject to export laws if any of the following apply:

• The open source software uses encryption, especially strong encryption or non-standard cryptography (cryptography that uses proprietary or unpublished cryptographic functionality)
• The open source software is specially designed for military or intelligence use
• The open source software doesn't meet the EAR's "publicly available" or "mass market" definitions
• The open source software is being exported to controlled individuals, entities, or countries or for restricted end uses

Keep in mind that items aren't automatically considered publicly available just because they incorporate publicly available open source code. In this situation, a new item with encryption functionality is created and must be evaluated as a whole under the EAR.

If your open source software uses non-standard cryptography, you will need to notify BIS and the NSA via email to inform them of the internet location of the open source code and provide a copy of the publicly available encryption source code.

If your open source software is specially designed for military or intelligence use, then it may be subject to the ITAR.

What Happens If You Violate the EAR?

Violations of the EAR can result in severe criminal and civil penalties, including substantial fines and prison time.

Section 764.3 (b) of the EAR lists the maximum criminal penalties for violating the law as fines of up to $1,000,000 and up to 20 years of imprisonment.

9 Export Compliance Risks When Distributing Encryption Software

There are several compliance risks you should be aware of when distributing encryption software:

1. Assuming your software isn't subject to the EAR. Whether your encryption software is subject to EAR depends on what kind of encryption it uses, whether it is publicly available or meets mass market criteria, and its intended destination and end use, among other factors.
2. Misclassifying your software. If you don't select the right Export Control Classification Number (ECCN), you run the risk of sending unauthorized exports.
3. Misapplying license exceptions. License Exception ENC needs to be applied correctly to avoid EAR violations.
4. Failing to get an export license when required. There are circumstances when you may need to get an export license for your encryption software, including when License Exception ENC doesn't apply to your software or if you intend to export to certain countries or end users.
5. Failing to submit required reports and notifications to BIS. Failure to comply with the EAR's reporting and recordkeeping requirements is a violation of the law.
6. Exporting software to embargoed or sanctioned countries or restricted users for restricted end uses without a license. Software exported to certain countries and end users or for certain end uses may be subject to licensing requirements or export restrictions.
7. Not including prohibited uses or disclaimers in your software license and legal agreements. Including clauses about restricted uses in your software license and legal agreements can help ensure that users are informed about the export rules governing your software.
8. Not establishing an Export Compliance Program (ECP). An ECP can help you comply with the EAR by creating a framework for organizing export-related data and decisions.
9. Not maintaining export control records. BIS requires applicable entities to maintain export control records for at least five years from a specified date.

Next, let's take a look at concrete steps you can take to address each of these risks and ensure compliance with the EAR.

How to Comply With the EAR When Distributing Encryption Software

Your specific obligations under the EAR depend on your software's classification, destination, end user, and intended end use.

While exact requirements vary based on your specific situation, following these nine steps can help ensure compliance with the EAR when distributing your encryption software.

Step 1. Determine Whether Your Software Is Subject to the EAR

If your software is not exported, reexported, or transferred, it is not subject to the EAR.

The EAR does not apply to certain foreign-made software that has less than a de minimis threshold (maximum amount allowed) of US-origin content.

There can be some confusion as to which regulations apply when it comes to software that uses military-grade encryption.

The International Traffic in Arms Regulations (ITAR) applies to encryption software used specifically for military purposes. You can find the types of software regulated by ITAR on the United States Munitions List (USML).

The EAR doesn't apply to software that is subject to the ITAR. The EAR applies to commercial and dual-use items–including encryption software that has both civilian and military applications but is not specifically designed for military use–that isn't covered by ITAR.

Categories XI(b),(d), and XIII(b) of the USML apply to software, technical data, and other items that are specially designed for military or intelligence applications.

The USML describes the types of software that falls under its jurisdiction, including:

• Military or intelligence cryptographic software that is capable of maintaining the confidentiality of information or information systems, such as software used for tracking, telemetry, and control (TT&C) encryption and decryption
• Military or intelligence cryptographic software that can generate spreading or hopping codes for spread-spectrum systems or equipment
• Military or intelligence cryptanalytic software
• Military or intelligence software that is authorized to control access to or transfer data between security domains listed on the Unified Cross Domain Management Office (UCDMO) Control List (UCL)
• Military or intelligence software
• Ancillary equipment
• Software specially designed for intelligence purposes that collect, survey, monitor, or exploit, or analyze and produce information from the electromagnetic spectrum, or is used to counteract those activities
• Technical data and defense services directly related to certain defense items, classified technical data related to items controlled in certain CCL ECCNs, and defense services that use classified technical data

Category XIII of the USML lists the cryptographic software subject to the law, including military or intelligence software used for TT&C encryption and decryption purposes.

If your software isn't subject to ITAR, then it is likely subject to the EAR.

You may be able to export some publicly available software–such as open-source encryption code–or mass market software without a full export license, as long as the software meets certain conditions.

The BIS defines mass market software as that which is available to the public and sold to consumers or businesses. It considers factors such as price, existing sales channels, and the typical customer when determining whether software qualifies as mass market. The mass market qualification can also apply to components of mass market products, as long as they meet specific criteria.

To meet mass market criteria, your software must be of potential interest to a wide range of individuals and businesses and the price and information about the software's main functionality must be available before purchase without requiring vendor or supplier consultation.

Software must meet all of the following criteria to qualify as mass market:

• It is generally available to the public by being sold without restriction from retail stock via over-the-counter, mail order, electronic, or telephone call transactions
• The cryptographic functionality can't be easily changed by the user
• The software is designed for installation by the user without requiring substantial support from the supplier and
• Details of the software are accessible and will be provided upon request to the exporter's country's authority to determine compliance

Components of existing mass market products, including hardware components or executable software–can qualify for mass market treatment as long as they meet specific criteria.

Executable software is defined as software in executable form, from a hardware component excluded from ECCNS 5A002, 5A003 or 5A004. Executable software does not include complete binary images of the software running on an end-item.

In order to qualify for mass market treatment, all of the following must apply to hardware components or executable software:

• Information security is not the component's primary function or set of functions
• The component or executable software doesn't change or add any cryptographic functionality to the existing items
• The feature set of the component or executable software is fixed and not customized or modified based on customer requests
• Details about the component or executable software and relevant end items are accessible and will be provided to the exporter's country's authority to determine compliance

A classification request or self-classification report must be submitted to BIS for any mass market encryption commodities or software that meet the mass market eligibility requirements and use strong encryption.

Specifically, a classification or self-classification report is required when mass market encryption commodities or software:

• Employs a key length greater than 64 bits for the symmetric algorithm
• Doesn't implement symmetric algorithms and employs a key length greater than 768 bits for asymmetric algorithms or greater than 128 bits for elliptic curve algorithms

Note 3 to Category 5, Part 2 of the EAR explains the criteria encryption items must meet to qualify for mass market treatment.

After your mass market encryption software is classified by BIS or self-classified through a self-classification report and the software is made publicly available, it generally will no longer be subject to the EAR.

Publicly available encryption source code (such as open source code that is available for free online) and publicly available encryption object code with corresponding publicly available source code are generally not subject to the EAR.

You'll need to notify BIS ([email protected]) and the ENC Encryption Request Coordinator ([email protected]) if your code implements non-standard cryptography and if the cryptographic function or the internet location changes.

As you can see, you may need to classify your software and notify the BIS before releasing it. Next, let's take a look at how to classify your software under an Export Control Classification Number (ECCN).

Step 2. Classify Your Software Under an Export Control Classification Number (ECCN)

An Export Control Classification Number (ECCN) is a five-character designation that is used on the BIS Commerce Control List (CCL) to identify items for export control purposes.The ECCN is a key factor in determining whether you need to get a license to export software out of the U.S.

Items that are subject to the BIS but are not listed on the CCL are designated as EAR99 items. EAR99 items are typically low-tech or consumer products and don't usually need an export license. However, encryption software is generally controlled under an ECCN.

The main ECCNs for software that uses cryptographic tools include:

• 5D002–Software that uses encryption functions that require stricter export control
• 5D992–Mass market software and information security software that does not meet 5D002 criteria

The BIS Quick Reference Guide for Category 5, Part 2 of the EAR lists the two main ECCNs for encryption software, 5D002 and 5D992.

The example ECCN on the BIS Classify your item page shows that the first character of the ECCN is a number from zero to nine that identifies the category the item belongs to, the second character is a letter from A to E that identifies the product group, and the last three digits are specific entries from the CCL.

There are a few ways you can check to see if the software you want to export has an ECCN on the CCL, including asking the source, self-classifying, and requesting an ECCN through BIS.

Contact the source

One way to find out if your encryption software has an ECCN is to ask the manufacturer, producer, or developer of the software if they can give you the ECCN. If you're not sure who to ask, you can search the BIS Classification Information Table.

The BIS Classification Information Table is a list of companies that voluntarily provide descriptions of their products or services, their website addresses, and their export control point of contact information.

Self-Classify

If you are the producer or manufacturer of the encryption software or have a strong technical understanding of the software, you may be able to self-classify.

Reading the CCL Order of Review and How to Determine an ECCN, and using the CCL Order of Review Decision Tool can help you understand the classification process for your software.

Next, you can search the Interactive Commerce Control List and the Alphabetical Index to the Commerce Control List for any terms that describe your software.

For example, searching for the keywords "encryption software" on the BIS Interactive Commerce Control List turns up two ECCN results, 5D002 and 5D992.

Once you find the ECCN for your software, you can look up the reason for export control in the corresponding chapter of the EAR.

Request Classification From BIS

If you can't self-classify, you can request an official classification from BIS. Follow the guidelines in Section 748.3 of the EAR to submit an electronic request to identify the ECCN for your software via the Simplified Network Application Process Redesign (SNAP-R). This service is free, but it can take several weeks for BIS to respond to a classification request.

Here are the steps to submit a classification request through SNAP-R:

1. Register for an account in SNAP-R.
2. Find out whether the manufacturer or producer of the software has filed a License Exception ENC classification request. If they have, then you can export the software based on the classification and ENC authorization for the software.
3. If you are the manufacturer or producer of the software, or you can't get the manufacturer's classification information, then go to the main SNAP-R screen, click on Classification Request, and check the encryption tickbox.
4. Select License Exception ENC from the Block 9 pulldown list in the Special Purpose block.
5. Verify the information in Blocks 14 and 15 is correct.
6. Enter 5D002 or 5D992.c for software in Block 22(a).
7. Enter the product name and model number in Block 22(c).
8. Enter the manufacturer name or your company's label in Block 22(i).
9. Type a short technical description of the purpose of your software in Block 22(j).
10. Attach any required supporting documents (Supplement No. 6 to Part 742 Encryption Questionnaire and any data sheets, technical specifications, or marketing brochures for your software).
11. Submit the application. You will receive an Application Control Number beginning with the letter Z that you can use in future communications with BIS concerning your classification request.

You can start exporting software within 30 days of submitting a classification request to BIS, or immediately to countries listed in the Supplement No. 3 to Part 740 License Exception ENC Favorable Treatment Countries list.

Supplement No. 3 countries include Australia, Canada, Germany, Italy, and New Zealand, among others.

Information required by the Supplement No. 6 to Part 742 Encryption Questionnaire includes the name and description of the products and an explanation of how encryption is used in the products.

Step 3. Determine Eligibility for License Exception ENC

In many cases, companies that export, reexport, or transfer encryption software can rely on License Exception ENC instead of getting authorization from the BIS. Whether you can rely on License Exception ENC depends on the item, end user, end use, and destination of the item.

As long as a company has complied with any applicable reporting, classification, and licensing requirements, License Exception ENC enables businesses to export most encryption products to most destinations.

You can export your encryption software under License Exception ENC without fulfilling classification or reporting requirements in the following circumstances:

• The software is exported to private-sector end users located in Supplement No. 3 countries to be used internally for the development or production of new products.
• The software is exported to a Supplement No. 3 country for uses other than developing or producing new products, as long as the software is not U.S.-origin and became subject to the EAR after production, all parties involved in the transaction are subsidiaries of the same Supplement No. 3 company, the end user is private sector, and the characteristics of the software are not enhanced without authorization.
• The software is exported to U.S. subsidiaries for internal use (including to foreign national employees, individual contractors, and interns).
• Foreign-made software that was developed with or incorporates U.S.-origin encryption source code, components, or toolkits can be exported as long as the U.S.-origin encryption item has been classified or reported under License Exception ENC and its encryption functionality has not been modified.

The BIS License Exception ENC page lists the instances in which you can export encryption items under License Exception ENC without fulfilling classification or reporting requirements, including when exporting items to private-sector end users located in Supplement No. 3 countries for the development or production of new products.

Keep in mind that License Exception ENC does not apply to some items that are subject to other agencies, such as control software designed for military applications.

Step 4. Obtain an Export License

You may need to get an export license if your software:

• Doesn't qualify for a license exception
• Will be exported to a prohibited end user or for a restricted end use
• Will be exported to an embargoed or sanctioned country
• Is designed for military or government use

For example, a license is required when certain items go to the following end users:

• Network infrastructure items: "More sensitive government end users" located in countries other than Supplement No. 3 countries
• Encryption source code, customized items, quantum crypto, network penetration tools, public safety radios, and ultra-wideband and spread-spectrum items: Government end users outside of Supplement No. 3 countries
• Cryptanalytic commodities and software: Government end users
• Open Cryptographic Interface (OCI) items (including OCI technology): End uses outside of Supplement No. 3 countries
• Cryptanalytic technology: End users outside of Supplement No. 3 countries and all government end users
• Technology for non-standard cryptography: End users outside of Supplement No. 3 countries
• "Other" technology: Government end users located outside of Supplement No. 3 countries

According to BIS, a license is required for encryption software that goes to certain end users, such as encryption source code that is sent to government end users located outside of Supplement No. 3 countries.

If you do need an export license for your software, here's how to get one:

1. Register for a Company Identification Number (CIN) from BIS.
2. Review the list of available licenses.
3. Read Part 748 of the EAR for guidance on applying for a license.
4. Log in to SNAP-R.
5. Follow these instructions for applying for an export license or an Encryption Licensing Arrangement (ELA).
6. Submit your license application.

The BIS license application instructions page explains that applying for an individual license for an encryption item involves describing the purpose of the item and the type of encryption used in the item.

Step 5. Submit Required Reports and Notifications

You may need to submit the following reports and notifications to stay compliant with the EAR:

• Annual Self-Classification Report. You'll need to file an annual Self-Classification Report if you export encryption software under License Exception ENC. The Self-Classification Report is due by February 1 for items exported or reexported during the previous year. Supplement No. 8 to Part 742–Self-Classification Report for Encryption Items contains instructions for how to file this report.
• Semi-Annual Sales Report. You'll need to file a Semi-Annual Sales Report for exports going anywhere other than Canada and reexports from Canada of the items described in Section 740.17(b)(2) and Section 740.17(b)(3)(iii) of the EAR. You can find a list of exempt items and instructions for filing on the BIS Semi-Annual Sales Report page. The Semi-Annual Report is due August 1 for exports occurring from January 1 to June 30, and February 1 for exports occurring from July 1 to December 31.
• Encryption notifications for publicly available software that implements non-standard cryptography. You'll need to notify BIS and the ENC Encryption Request Coordinator via email of the internet location of the source code and send them each a copy of the publicly available encryption source code. You should notify the BIS and the ENC Encryption Request Coordinator each time the internet location or cryptographic functionality of the source code is changed. You can email the notification and copies of the source code to [email protected] and [email protected].

Supplement No. 8 to Part 742 explains what information you need to include in your Self-Classification Report, including the name of your software, the primary manufacturer, and your ECCN.

Step 6. Avoid Exporting to Restricted Countries or Users or for Restricted End Uses Without a License

You'll need to avoid exporting to restricted countries, entities, or individuals without a license. This includes allowing foreign nationals to access certain cloud or SaaS software, which can count as a "deemed export."

There are several lists you can check to determine whether an end user is restricted, including:

• Denied Persons List: This is a list of people and entities who have been denied export privileges. Export transactions with individuals and entities on this list are prohibited.
• Unverified List: This list consists of parties where BIS has been unable to confirm the end-user in previous transactions. These parties are subject to the restrictions and requirements in Section 744.15 of the EAR.
• Entity List: Anyone on this list is subject to additional licensing requirements and policies.
• Military End User (MEU) List: You may need a license to export to parties on this list.
• Specially Designated Nationals List: Individuals in the U.S. are generally prohibited from dealing with individuals, companies, and entities on this list.
• Consolidated Screening List: You can search this consolidated list to find individuals and organizations that are prohibited from receiving U.S. exports based on lists from the U.S. Departments of Commerce, State, and the Treasury. The Consolidated Screening List includes the Denied Persons List, the Unverified List, the Entity List, and the MEU List, among others.

You can look at the Commerce Country Chart to see whether you need a license based on the reason for control of an item on the CCL and the country of destination. Check Section 738.4 for instructions on how to use the CCL and the Country Chart to determine whether you need a license.

BIS also offers an Interactive Commerce Country Chart tool to quickly find out whether your intended export destinations require a license. You can find out about prohibitions on and licensing requirements for exports to Cuba, Iran, Iraq, North Korea, Russia, Syria, and "covered" regions of Ukraine in Parts 742 and 746 of the EAR.

The BIS Commerce Country Chart lists the reasons for control for each country, including anti-terrorism, crime control, and national security.

In addition to researching your intended destinations and end users, you'll also need to do due diligence in determining the end use of your software. Software used for restricted end uses–such as nuclear activities or the development or production of chemical and biological weapons–typically requires a license.

Section 744.4 of the EAR describes the restrictions on exporting items for certain chemical and biological weapons end uses.

Step 7. Include Prohibited Uses and Disclaimers in Your Software License and Legal Agreements

Including prohibited uses and disclaimers in your software license and legal agreements can help notify users about restricted uses of your software and show that you have done due diligence to inform users about export restrictions.

ST Imaging's End User License Agreement (EULA) explains that users must comply with U.S. law when exporting or reexporting its software, and cannot export or reexport the software to any U.S. embargoed countries or anyone on the Specially Designated Nationals List, Denied Persons List, or Entity List.

Step 8. Establish an Export Compliance Program (ECP)

An Export Compliance Program (ECP) enables you to analyze, organize, and build an integrated system of data and decisions to ensure compliance with the EAR and help you manage export decisions and transactions.

The key components of an ECP include:

• Ensuring senior management publicly supports compliance policies and procedures, provides compliance resources, and supports export compliance training
• Conducting regular risk assessments to identify and mitigate potential risks
• Drafting and implementing export authorization procedures for classification, jurisdiction, licensing, and screening
• Assigning staff to record-keeping roles
• Requiring mandatory training for all staff who are involved with exports
• Performing regular audits to evaluate the effectiveness of your export procedures and identify any potential issues
• Implementing a program for dealing with compliance issues, such as preventing and correcting export violations

You can check out the BIS Export Compliance Guidelines for a more detailed look at how to establish an effective ECP.

The Risk Assessment section of the Export Compliance Guidelines includes a summarization chart of common risks, risk mitigation tools, and resources for writing procedures.

Step 9. Maintain Export Control Records

The following transactions are subject to the EAR's recordkeeping requirements:

• Transactions involving certain restrictive trade practices or boycotts
• Exports of commodities, software, or technology from the U.S.
• Reexports, transfers, transshipment, or diversions of items exported from the U.S.
• Exports to Canada if an individual in a country other than Canada or the U.S. has an interest in them, or the item will be reexported, transshipped, or diverted to Canada from another foreign country
• All other transactions subject to the EAR

To comply with the EAR, you'll need to keep the records described in Section 762.2 of the EAR, including export control documents and BIS notifications for the required time period.

You'll need to retain required records for at least five years from the latest of the:

• Date of export
• Date of known reexport, transshipment, or diversion
• Date of any other termination of the transaction (whether completed or not) or
• Date a regulated person receives a boycott-related request or requirement (in transactions involving restrictive trade practices or boycotts)

Part 762.6 of the EAR explains that you must keep required records for at least five years from the latest of specified times, such as the date of export or reexport.

Summary

Cryptography is the science of protecting data so that only authorized parties can access it. Common cryptographic techniques include encryption, authentication, and digital signatures.

The primary U.S. export regulations software distributors need to be aware of are those listed in the EAR. Failure to comply with the EAR can result in harsh civil and criminal penalties.

Compliance risks when distributing encryption software include:

1. Assuming your software isn't subject to the EAR
2. Misclassifying your software
3. Misapplying license exceptions
4. Failing to get an export license when required
5. Failing to submit required reports and notifications to BIS
6. Exporting software to embargoed or sanctioned countries or restricted users or for restricted end uses without a license
7. Not including prohibited uses or disclaimers in your software license and legal agreements
8. Not establishing an ECP
9. Not maintaining export control records

Steps you can take to mitigate these risks include:

1. Determining whether your software is subject to the EAR
2. Classifying your software under an ECCN
3. Determining eligibility for License Exception ENC
4. Obtaining an export license (if required)
5. Submitting required reports and notifications to BIS
6. Avoiding exporting to restricted destinations or users or for restricted end uses without a license
7. Including prohibited use clauses in your software license and legal agreements
8. Establishing an ECP
9. Maintaining export control records