ITAR compliance software controls who can open a controlled file. On its own it does not answer the question a review actually asks, which is who could reach that file, who did reach it, and where the file came from before it landed with you. Access control is a rule about what should happen. A record is evidence of what did happen. Every export conversation I have with a supplier eventually stops asking about the rule and starts asking for the evidence. The one that stays with me was an MRO shop, second morning of a customer’s supplier review. Pleasant meeting. The quality lead had the access matrix printed and it was accurate. Then the reviewer picked one repair drawing, revision C, and asked how it got there and who had opened it since. The matrix said fifteen people could reach the controlled folder. Nobody in the room could say which of the fifteen had. And nobody could show where revision C came from, because it had arrived as an email attachment in 2021, been saved to a network drive, been renamed by an engineer who has since retired, then been copied into the controlled folder when the shop stood up its new system. Everyone in that room had done their job. The record only started partway through the life of the file. I am not an export control lawyer and none of this is legal advice. The rule text, your empowered official, and a compliance professional govern what your organization has to do. What I can talk about is what a record has to be able to show when someone asks, because that part looks the same across every supplier and shop I talk to. What does ITAR compliance software actually do? ITAR compliance software is software that restricts, marks, screens, and logs access to controlled technical data. Most of it does four jobs. It restricts who can open a file. It marks the file so people know what they are holding. It checks the person against a list before granting access. It writes a log of what happened inside its own boundary. All four are useful. All four describe today. They answer “who can reach this today” with the configuration you set up last quarter. That is what a compliance checklist asks for, and it is worth having. The question underneath is historical. Not who can reach it, but who could reach it in March, when the drawing went out to a subcontractor. Not what the rule says, but what actually happened to the file. Software that enforces access without keeping a history of where the file came from and what happened to it leaves you with a policy and a set of claims. An audit asks for evidence instead. Why an access list is not a record An access list is a snapshot of a decision. It tells you who can reach the file right now, after every change anyone has made to it. Records are different in three ways that matter when someone is asking questions. A record is historical. It has to answer questions about a date that has already passed, using the permissions that existed then, not the ones that exist now. Most access lists overwrite themselves. The version that mattered is gone. A record is attached to the data. An ITAR audit trail that lives in a separate audit tool, in a ticketing system, and in three people’s memory is not one record. It is three fragments that a person has to reconcile under time pressure, usually the week before a review. A record covers the copies. The controlled file is rarely the only artifact. There is the extract someone pulled for a quote, the slide with the cross section in it, the screenshot in a support ticket, the CAD model a supplier derived from the drawing. The access list covers one file. The question is about every copy and derivative of it. What a good record has to show Five things, in plain terms. If you can produce all five for any given file, most reviews end quickly. Where it came from. The source, the date, the channel it arrived through, and who received it. Not the day it was copied into the current system. The actual origin. Who could reach it, then. The boundary as it stood on the date in question, not today’s list. Who did reach it. Opens, downloads, prints, shares, with names and timestamps. What came out of it. Derived files, extracts, quotes, models, anything that carries the controlled content forward. When access ended. For each person who left the project, the company, or the country of the work, the date their reach was removed and the evidence of it. Nothing there is exotic. Every one of the five is a question I have heard asked out loud, in a conference room, with a contract depending on the answer. Where records usually have gaps Not where people expect. The controlled system is normally fine. The gaps are at its edges, where data arrives and leaves. Files arrive by email and get saved somewhere before anyone classifies them. Somebody renames a file and there is no longer anything linking it back to where it came from. A contractor works on a laptop that nobody enrolled. An engineer leaves and their account is disabled in the identity system but not in the file store, which are two separate systems that get switched off on different days. Logs are deleted after ninety days because the default retention nobody chose is ninety days. A migration moves the files and leaves the history behind, which is the single most common one I see, and it is invisible until the first question about a date that predates the migration. None of that is a failure of ITAR compliance software. It is a failure of the handoffs around it, and the handoffs are where most of the work sits. Across aerospace and defence suppliers and MRO shops, the same pattern shows up. Good controls, honest people, a record that starts on the day the current system went live. How to test your ITAR record trail this week Pick one controlled file. Just one. A drawing, a spec, a process sheet, whatever a customer would plausibly ask about. Then try to reconstruct the five items above, all of them, without asking anyone to remember anything. Give yourself a specific past date, six months back, and answer with what you can show, not with what you believe. Where did this come from. Who could reach it on that date. Who did. What was derived from it. Who lost access, and when. Time it. In most shops the exercise takes an afternoon and produces a short, ugly list of the points where the record stops. That list is worth more than another policy document, because it is the same list a reviewer would produce, except you found it first and nobody is watching. Run it once a quarter on a different file and you learn something else: whether the gaps are closing or whether you are just documenting them again. The day you need the record is the day somebody else is asking for it. A prime’s supplier review. A customer audit two weeks before a renewal. An internal question that arrives with a lawyer’s name on it. A record you can assemble in an afternoon ends the conversation. A record that starts partway through the life of the file becomes a finding, and findings follow you: to the next audit, to the next customer, to the next contract you bid.