ITAR Contractor Identity Compliance: Documentation and Verification Requirements

I spent six years as a DCSA background investigator. Before that, I worked as a compliance consultant to defense contractors navigating DISS and JPAS adjudication documentation. In that time, I reviewed hundreds of onboarding files. The ones that failed DCSA audits rarely failed because the contractor broke any rule intentionally. They failed because nobody had built identity verification recordkeeping into the standard workflow. ITAR cases are no different.

If your company is registered under 22 CFR Part 122 and employs or plans to employ foreign nationals, or simply maintains a workforce with access to ITAR-controlled technical data, you have documentation obligations that most HR systems were never designed to satisfy. Here is what DDTC and DCSA assessors actually look for, and what an audit-ready identity compliance file needs to contain.

What ITAR Registration Requires You to Document

ITAR registration under Part 122 confirms that a company is a U.S. person eligible to manufacture or export defense articles. Registration itself does not impose a specific identity verification checklist. What it does is bring your workforce under the scrutiny of 22 CFR Part 120.15 (U.S. person definition), Part 120.16 (foreign person definition), and the broader export control framework that makes unauthorized disclosure of ITAR-controlled technical data to a foreign person an unlicensed export.

That last point is where identity documentation becomes non-negotiable. Three obligations follow directly from it.

1. Nationality Determination Records

Before a person receives access to ITAR-controlled data, you need documented evidence of their citizenship and immigration status. For U.S. citizens, a government-issued identity document confirms citizenship. For lawful permanent residents and visa holders, immigration documentation establishes the status of the individual and which license exemptions, if any, apply. For dual nationals, the determination is more nuanced. But in every case, the starting point is a verified identity document tied to a specific individual.

Verified. Not collected. Not scanned into a shared drive. Verified against an authoritative source with a timestamp and a responsible party on record.

In our work supporting contractor onboarding programs, we've seen teams collect passports and driver's licenses but never confirm the documents were unaltered or cross-reference the extracted data against a DMV or SSA record. That gap surfaces immediately in an audit. DDTC assessors want to see that identity data was confirmed, not merely received.

2. Access Authorization Records

Once nationality is established, your records need to show the chain from verified identity to authorized access. Who reviewed the determination? Who approved the access level? When was that approval logged? Was the individual briefed on the specific ITAR controls applicable to their role?

Each access authorization event should be traceable to the underlying identity verification record. If an assessor asks why a given employee had access to an ITAR-controlled design drawing in March 2025, your file needs to produce the identity verification record, the nationality determination, the access approval, and the ITAR awareness acknowledgment, in sequence, without manual reconstruction.

That chain is what 22 CFR Part 122 audits test. Not the policy. The records.

3. Corrective Action and Exception Records

Situations arise where an employee's nationality or immigration status changes, or where an initial determination was incomplete. DDTC does not expect perfection. It expects a documented response: when was the issue identified, what interim access controls were applied, what corrective action was taken, and when was the file closed. Contractors that can produce that history consistently fare far better than those who can demonstrate a perfect process on paper but cannot produce a record of how they handled an exception.

Where Identity Verification Intersects with the Audit Trail

The audit trail is not a bureaucratic formality. It is the mechanism by which you demonstrate, to a federal assessor, that your identity verification records were not retroactively assembled. Fact: DCSA assessors are trained to identify reconstructed documentation. They look at file creation timestamps, version histories, and metadata. A well-organized binder assembled the week before a review does not pass as an audit trail.

An actual audit trail for identity verification purposes needs to capture, at minimum:

• The date and method of identity document collection (in-person, remote, NFC chip read, OCR extraction)
• The name and role of the individual who initiated the verification workflow
• The cross-reference result from an authoritative source (AAMVA state DMV confirmation, SSA CBSV response code)
• The liveness or biometric check result if remote collection was used
• Every subsequent access to or modification of the identity record, with timestamps and user attribution
• The adjudication decision, confidence score, and approving authority

That is 6 data points per hire. Multiply by 50 to 500 new hires per year, and you are managing a documentation volume that no manual process handles reliably. We've found that contractors managing this manually average 3 to 5 documentation gaps per 100 onboarding files. Those gaps become audit findings.

How FedRAMP-Authorized Storage Changes the Compliance Picture

Here is the thing: even contractors with good recordkeeping habits frequently fail DCSA and DDTC reviews on storage grounds alone. Identity documents, biometric data, and nationality determination records contain personally identifiable information and, in some cases, controlled unclassified information. Federal agencies increasingly require that systems processing this data operate within a FedRAMP-authorized boundary.

Workday is not FedRAMP Moderate authorized for identity biometric data. Greenhouse is not authorized for that data category. Shared drives, certainly not. When Verifyfed collects and stores identity verification records, every document image, extracted data field, liveness check result, and audit log entry is written to AWS GovCloud infrastructure covered by Verifyfed's FedRAMP Moderate ATO. No identity record crosses a non-authorized boundary at any point in the lifecycle.

For ITAR contractors specifically, this matters because the records you are required to maintain are not just compliance paperwork. They are evidence. If DDTC investigates a potential unlicensed disclosure, the first document request will be your identity verification records for the individuals who had access to the controlled data. If those records live in a non-FedRAMP environment, the evidentiary chain is compromised before the investigation begins.

What DCSA Audit Packages Need to Show

From my time as a DCSA background investigator, the audit packages that resolved quickly shared a common structure. They did not require the contractor to make phone calls, search file shares, or reconstruct a timeline. They produced, within minutes, a complete record for any specific individual.

For ITAR identity compliance specifically, an audit-ready package for a given employee should include:

• Verified identity document images with extraction metadata (document number, issue date, expiry, issuing authority)
• AAMVA MVAConnect confirmation response for driver's license verification
• SSA CBSV response code for Social Security Number verification
• Liveness check result with timestamp and challenge type (confirms the document submitter was physically present)
• Face-comparison score against the identity document photo
• Full access-and-transform audit log for the record
• Chain-of-custody attestation signed by the verifying system
• Adjudication decision with approving authority and date

Verifyfed generates this package in under 60 seconds for any hire in the system. It exports as a signed PDF and a JSON manifest compatible with GRC platforms including Archer, ServiceNow GRC, and CMMC-AB assessment portals. When a DCSA adjudicator or DDTC compliance officer requests a file, the onboarding coordinator does not need to be a compliance engineer to produce it.

The Practical Reality for Mid-Size Contractors

Large defense primes have dedicated PERSEC teams, in-house DISS integration, and cleared-facility security officers whose primary job is this documentation work. Mid-size contractors with 1 to 3 HR staff managing CMMC and ITAR compliance programs simultaneously do not have that infrastructure. They have the same regulatory obligations and a fraction of the dedicated headcount.

Real talk: the documentation burden for ITAR identity compliance is not going to shrink. DDTC's enforcement posture has been consistent. What changes is whether your process makes the compliant path the default path, or whether compliance depends on individual coordinators remembering the right steps in the right order.

Contractors that onboard 50 to 500 cleared or clearance-eligible employees per year cannot afford 3 to 5 documentation gaps per 100 files. At $15,000 to $90,000 per delayed program start per affected employee, a single audit finding costs more than a year of identity verification tooling. The math is not complicated.

Getting Audit-Ready Before the Review Arrives

The contractors I have seen navigate ITAR audits most cleanly did not scramble the week before a review. They had a system that produced an audit package on demand, not a policy that described what an audit package should contain. The distinction is everything.

If your current identity verification process depends on coordinators manually routing documents to the right folders, tracking verification status in a spreadsheet, and assembling audit packages by hand when a review is announced, you have a documentation risk that exists independent of whether your workforce is in compliance. The records may be accurate. They will not be audit-ready.

Audit-ready means: any identity verification record for any employee, retrievable in under 2 minutes, with a complete chain of custody, stored in a FedRAMP-authorized environment, exportable in a format your assessor can accept. That standard is achievable. It just requires building the workflow that makes it the default, not the exception.