As the DIB works itself into a lather over CMMC flow-down requirements for “good security hygiene,” are we ignoring the elephant in the room? ITAR requirements flow-down via the DFARS, apply throughout the supply chain, and extend internationally.
To satisfy ITAR flow-down requirements for ECI controls, the DIB must know certain information about its information:
- Is it ECI?
- To which material, hardware, or software item does it relate?
- To which stage of the product lifecycle does it pertain?
When it comes to knowing its data, and burning down DIB Compliance Debt, these three data points, combined with export classification values of related materials, hardware, or software, enable automated ECI location, access, and transfer controls.
We can never remove the human element from the decision process, but leveraging information about our information enables a degree of certainty (mistake-proofing) and optimization, that we don’t get with manual processes. Stated plainly, automation delivers more efficient and effective communication and decision-making.
This is something IT professionals have known from inception. Information Technology sprang from the efforts of data scientist leveraging post-WWII communication/encryption techniques/technologies to more efficiently/effectively/securely communicate and make decisions (The Information, by James Gleick). Information automation is the reason IT exists.
Automation has lagged in the ITAR compliance space. Although ITAR ECI control requirements date back to 1998, the Consent Agreement requirements for a “comprehensive, automated export compliance system” were first expressed in 2004, and implemented from 2006-2010.
Although automated international shipping controls were maturing at the time, the 2004 requirements differed as they necessitated automation of the underlying export compliance processes (e.g. Restricted Parties Screening, Jurisdiction/Classification/Marking, Export Authorization Management), as well as peripheral transaction controls (e.g. travel management, visitor management, compliance requests, etc.).
It wasn’t until 2012 that a Consent Agreement called for a plan to automate ITAR ECI controls (capabilities to identify, control, and track ECI; see above linked article).
We find ourselves nearly a decade removed from the 2012 Consent Agreement. Significant advancements have been made in the techniques and technologies, but they have not been widely deployed within the DIB. Deployments have been myopic, focused only on the issues directly facing a company, and limited by company compliance culture.
To meet the challenges posed by ITAR and CMMC compliance, the DIB must deploy interoperable capabilities to identify, control, and track ECI. IT professionals passionate about the CMMC use case must understand and leverage the ITAR ECI use case. Trade professionals passionate about the export use case must understand and leverage the cyber compliance controls called for in CMMC.
What happens when the DIB can answer the three questions posed above in the same way? What does it mean for ECI flow-down requirements, capabilities, and interoperability? If you’d like to learn more about how you can answer the questions in a standardized, interoperable way, shoot me a private message and we’ll chat.
