That distinction trips up a lot of organizations. A company can have a Technology Control Plan on file and still fail an audit because nobody can produce a visitor log, or because an engineer's access wasn't revoked after a role change. This checklist is built for defense contractors, aerospace suppliers, manufacturers, empowered officials, quality leaders, and the facility security and IT teams who share ITAR accountability.
One note before you start: ITAR requirements are fact-specific and the regulations change. Treat this as a working checklist, not legal advice — verify current requirements against DDTC, the eCFR, and qualified export counsel before making compliance decisions.
Key Takeaways
- Confirm ITAR scope, USML classifications, DDTC registration, and licenses before auditors arrive
- Test whether access, physical security, training, and supplier screening operate consistently, not just on paper
- Build evidence that shows who acted, when, under what approval, and how exceptions closed
- Flag missing or inconsistent records as readiness gaps, even if a procedure technically exists
- Rank findings by risk, assign owners and dates, and verify fixes before the audit begins
What to Review Before an ITAR Audit
Work through this as a control-by-control review. For each item, pull the owner, the objective evidence, and any open corrective action. Mark it ready, needs attention, or high-risk gap based on what you can actually demonstrate, not what the procedure says should happen.
Scope, Governance, and Accountability
Start by confirming your organization has documented how ITAR applies to its specific defense articles, services, software, and technical data. That includes USML categories and any overlap with EAR, DFARS, or CMMC obligations. Vague scope statements are one of the most common audit findings.
Then check accountability:
- Empowered official, export compliance lead, FSO, and IT/security owner are named, current, and know their escalation paths
- Management review records exist and are recent, not from two reorganizations ago
- The empowered official has genuine independence to investigate and refuse to sign — a requirement under eCFR's empowered official rule
- DDTC registration is current, renewal tracking exists, and applicable licenses, agreements, exemptions, and provisos are mapped to actual activity
Registration confirms you're in the system. It doesn't authorize a single export. Confirm the underlying license or exemption separately.
Controlled Data and Physical Security
Inventory controlled technical data and articles everywhere they live: design, engineering, manufacturing, quality, shipping, storage, collaboration tools, backups, and disposal. Classifications, markings, locations, and custodians should all be traceable to a name and a date.
From there, test the Technology Control Plan against real scenarios:
- U.S.-person and foreign-person access requests
- Need-to-know determinations and documented exceptions
- Visitor, contractor, and remote-work handling
- Data-release approvals
Pull facility records too: badge logs, visitor and escort sign-ins, controlled-area boundaries, and incident logs. If the TCP says visitors are escorted and logged, the sign-in sheet needs to actually exist.
Information Security and Access Control
Pull current user access lists for every system holding ITAR-controlled data and check role-based permissions, MFA, network segregation, encryption, and offboarding records. Then sample recent personnel changes — did access actually get revoked when someone left or changed roles?
A few things worth testing directly:
- Does permission scope match citizenship status, job need, and current employment?
- Have cloud, IT, and collaboration vendors been screened for location, access, and subcontracting risk?
- Are procurement and compliance approvals documented for each third-party provider?
Keep ITAR expectations distinct from separate cybersecurity frameworks like DFARS 252.204-7012 or CMMC. Passing one doesn't automatically satisfy the other.
People, Suppliers, and Transactions
Training records only matter if they're role-specific and recent. Check onboarding, refresher training, knowledge checks, and acknowledgments for anyone with access to controlled data.
Supplier review should go deeper than a signed contract:
- Export-control representations and flow-down clauses in subcontracts
- Restricted-party screening results, resolved and retained
- End-user information for technical-assistance activity
Finally, sample actual shipments and data releases. For each one, confirm the classification, the licensing or exemption decision, approvals, and recipient checks — and that supporting documentation is retrievable.
Records, Incidents, and Corrective Action
Records need to be complete, legible, retrievable, and protected from unauthorized edits. Retention periods aren't one-size-fits-all; confirm the applicable period against eCFR's recordkeeping rule rather than assuming a flat five years from shipment date.
Review prior findings and incidents with a skeptical eye. Were corrective actions closed with an effectiveness check, or just closed administratively?
This is where a controlled document system earns its keep. QMS Learning's Document Management System keeps one live revision visible, preserves full revision history, and links documents to the clauses and training records they support, so gaps surface before an auditor finds them.
The Manager Dashboard can pull that into an exportable evidence package. Neither replaces the underlying compliance program; they just make it easier to prove it's working.
How to Test Each Control and Interpret Results
A checklist tells you what to look at. Testing tells you whether it actually works. The method is the same across every control: define it, identify the owner, pull a sample, inspect the evidence, interview the people doing the work, and document any gap with an owner and a deadline.
Control Walkthroughs
Pick a real process and walk it start to finish: onboarding an engineer, approving a visitor, releasing technical data, shipping a controlled article, or removing access after termination. Follow it from request through approval, execution, record retention, and closeout.
Compare what's written against what actually happens:
- Interview the process owner and a frontline operator separately
- Note any differences in terminology, sequence, or approval steps
- Check whether system settings match the documented procedure
- Record every gap, even small ones
Sample across people, facilities, systems, suppliers, and transactions, weighted toward recent changes, documented exceptions, and high-sensitivity activity.
Evidence Quality Review
Not every record counts as evidence. For each one, check identity, date, approval, version, and whether it can be traced back to a specific person and decision. A screenshot with no context or a spreadsheet nobody can date isn't audit-proof, no matter how organized it looks.
Two tests worth running:
- Retrieval timing: how long does it take to pull a complete evidence package, including linked training and approval records?
- Unscripted interviews: can staff explain how to identify controlled data, follow release procedures, and name who approves an exception, without being coached first?
How to Interpret Results
Once you've tested a control, sort it into one of three buckets:
| Result | What it means | What to do |
|---|---|---|
| Ready | Documented, implemented, owned, and backed by complete evidence | Record the test performed and file the evidence reference |
| Needs attention | Control exists but execution is inconsistent or evidence is incomplete | Assign an owner, due date, and effectiveness check |
| High-risk gap | Can't demonstrate authorization, access restriction, or record integrity | Contain the activity, preserve evidence, escalate to legal/compliance |
Not every weak control is a violation, but a gap involving unauthorized access, missing licensing, or unresolved screening needs immediate escalation, not a note for next quarter. Suspected violations may trigger disclosure obligations under eCFR's voluntary disclosure rule; don't try to make that call from a checklist alone.
Building Team Capability Before the Audit
Completion records don't prove judgment. Scenario-based practice does: a foreign-person access request, an uncontrolled file share, an expired license, an unescorted visitor in a restricted area. Teams that have rehearsed these situations respond faster, and more correctly, when the real thing happens.
For teams that want structured, role-specific practice, QMS Learning's Aerospace & Defense Audit-Ready pathway bundles ITAR Compliance training with AS9100D and counterfeit-parts coursework. It's practitioner-built training, not a certification or a substitute for legal review. Think of it as reps before game day.
Common Errors in Reviewing ITAR Controls
Most pre-audit reviews don't fail from lack of effort. They fail from a handful of predictable blind spots:
- Mistaking existence for effectiveness: a registration certificate or a completed training course isn't proof a control operates consistently
- Reviewing documents in isolation: ignoring data flows, system permissions, physical access, and actual transaction records
- Using stale references: outdated USML classifications, expired licenses, or old restricted-party screening results
- Accepting weak evidence: email approvals or spreadsheets with no version, date, or identity trail
- Skipping reconciliation after change: new acquisitions, remote-work shifts, or new programs that nobody mapped against existing controls
- Closing findings without root cause: the same nonconformity resurfaces next year because the fix addressed symptoms, not causes
Recent DDTC enforcement actions against major aerospace contractors have involved exactly these patterns: data replicated onto unapproved infrastructure, foreign-person access that outpaced authorization, and classification errors that went unnoticed because nobody traced the actual data path.
Safety and Best Practices
Audit prep itself can create new exposure if it's handled carelessly. A few guardrails worth setting before the review starts:
- Never copy controlled technical data into unapproved AI tools, public file shares, personal devices, or foreign-hosted systems. Verify every tool against your organization's approved handling list first
- Apply least-privilege access, required citizenship-based controls, secure visitor handling, and approved encryption; have security and legal owners sign off on the details
- If you find a suspected control failure mid-review, preserve the evidence. Don't delete, alter, or casually forward records while the issue is being investigated
- Keep the audit workspace controlled: approved repositories, current document revisions, clear file naming, and one designated owner for auditor requests
- Schedule periodic internal reviews throughout the year instead of scrambling in the final weeks before an audit
Conclusion
A working ITAR pre-audit checklist connects every requirement to an owner, a tested control, objective evidence, and a documented response when something doesn't hold up. That's a different exercise than collecting policy documents the week before the audit.
Real readiness comes from testing actual workflows (access, data handling, facilities, suppliers, transactions, training, and incident response) and fixing what the testing reveals. Verify current requirements with DDTC, the eCFR, and qualified ITAR counsel. Then build recurring reviews, applied training, and controlled evidence management into how your team operates year-round, not just before an audit.
Frequently Asked Questions
What is an ITAR audit checklist?
An ITAR audit checklist is a structured review of scope, registration, licensing, access, physical and cybersecurity controls, training, suppliers, records, and corrective actions. It supports audit readiness but is not a certification or a legal determination.
What do auditors typically review during an ITAR audit?
Auditors typically review governance and USML determinations, DDTC registration and authorizations, Technology Control Plan implementation, personnel and facility access, training records, transactions, suppliers, cybersecurity controls, recordkeeping, and prior findings.
What evidence should a company prepare before an ITAR audit?
Gather current procedures, registrations, licenses or agreements, classification records, training logs, access reviews, visitor logs, screening results, shipment files, system logs, and records of past incidents and corrective actions.
How often should an organization perform an ITAR self-audit?
Frequency should be risk-based, not fixed on a calendar. Trigger a review after regulatory changes, new programs, personnel or system changes, incidents, supplier changes, or prior findings.
Does ITAR provide a formal certification that proves compliance?
No. There is no government-issued "ITAR Certified" credential. Registration identifies participants but grants no export rights. A compliance program, training, or third-party review does not replace ongoing responsibility.
What should we do if the checklist identifies a potential ITAR violation?
Contain the activity, preserve all related records, and escalate immediately to your designated compliance and legal personnel. Investigate scope and cause, document remediation, and determine reporting obligations with qualified counsel.