A paralegal opens a new file. The client is a security contractor hurt during a convoy escort in southern Iraq in the mid-2000s. The intake sheet lists the employer as "GIS." A different file down the hall lists the employer as "Hart." Neither name matches the corporate title on the contract paperwork sitting in the folder.
This is the exact moment a Defense Base Act investigation stalls. The claimant knows where he worked and roughly when. He does not know which corporate entity signed his paycheck, and he certainly does not know which insurance carrier stood behind that entity. The names on the paper are not lying. They are just describing a company that operated under several identities across its life.
Private security firms from the Iraq and Afghanistan contracting era are among the hardest DBA employers to pin down. They formed fast, rebranded often, spun off regional entities, and sometimes folded one brand into another. Global Integrated Security, usually shortened to GIS, and the Hart security name are both examples of this pattern. They are separate companies with separate corporate histories, and nothing in the public record ties them together as one lineage. This article does not claim they are related. What they share is the underlying problem: each name has shifted enough over time that a single-name search misses most of that employer's footprint.
This article walks through why naming churn like this obscures the DBA employer for firms such as GIS and Hart. It also shows what federal records still exist under each name, and how to approach the problem without guessing at a corporate connection that is not there.
Why do private security contractors like Hart and GIS change names so often?
Private security companies born in the early Iraq and Afghanistan years grew under intense pressure. Contracts moved quickly. Client demands shifted. Reputational risk was constant. Rebranding was a normal business response, not an anomaly.
Several forces drove the churn. A firm might create a separate US-facing entity to bid on American government work while keeping an overseas parent. It might rename a division after a leadership change. It might absorb a smaller competitor and retire that competitor's brand over time. Each move left a trail of overlapping names.
GIS and Hart each reflect this environment in their own right, and each has its own separate corporate history. Both names appear in different records tied to protective and security-support work over the years. Available public records do not show GIS and Hart as connected to one another, and this article does not treat them as one lineage. Within either company's own history, any parent, subsidiary, or successor claim is something an investigation has to verify against primary records rather than assume.
This is not unique to one company. The same rebranding pattern shaped nearly every large protective-services prime. If you have traced the Aegis Defence to GardaWorld security lineage, you already know how many corporate identities a single guard force can generate over a decade.
How do name changes break a DBA carrier search?
DBA carrier identification depends on matching an employer name against records. When the employer used five names, a search on one name finds a fraction of the evidence. The other records sit in the database under labels your query never touches.
Think about what a partial match costs you. A legal decision filed under one entity name never surfaces when you search a different one. A contract award under the US-facing brand hides from a search on the overseas parent. A coverage filing under an abbreviation stays invisible to a search on the full corporate title.
Each miss removes a data point that could have named the carrier. Carrier evidence is already thin for security firms. Losing half of it to a name mismatch can be the difference between a confident answer and a guess.
This is why alias resolution comes first in any serious workflow. Before you ask who insured the employer, you have to define every name that employer ever used. Attorneys who skip this step often build a case on the one name the client happened to remember, which is rarely the name on the insurance policy. The broader problem is covered in our guide to why employer name changes make DBA claims so hard to trace.
What federal records exist under the GIS and Hart names?
The good news is that companies like these left footprints across public federal data. No single source answers everything, but together they let you rebuild each employer's own history.
Federal contract award data is the backbone. Our contract records include 43,298 prime awards and 4,315 subaward links drawn from USAspending. These show which entity held a contract, where the work happened, and which subcontractors operated underneath a prime. A security firm's various name variants often appear here in ways that reveal how those variants relate to each other within that same firm's own corporate structure.
Legal decisions add direct evidence. Our database holds 5,022 OALJ and Board decisions, each with the parties named in the caption. When a security firm litigated a DBA claim, the decision usually names both the employer entity and the carrier. That single line can resolve a carrier question that contract data only hints at.
Federal registration data closes gaps. With 865,232 SAM.gov entity records, you can confirm that a name is a real registered entity, capture its identifiers, and separate an active brand from a retired one. FOIA database results covering contractor presence in Afghanistan, more than 29,000 records, further confirm which companies actually operated in-country during a given window.
None of these sources was built to answer a DBA carrier question. That is the whole challenge. The data exists, but it is scattered across systems that do not talk to each other.
Why can't you match a private security employer to one carrier for the whole contract?
Attorneys new to DBA work often expect a single carrier per employer. Security contractors break that expectation harder than almost any other category.
Coverage shifts over time. A firm might carry one policy early in a contract and a different one after a renewal or a re-competition. The carrier that covered a 2005 injury may have nothing to do with the carrier on a 2009 claim under the same brand. This is why injury date drives the entire analysis, not the employer name alone.
The corporate structure compounds it. When a firm runs a US entity and an overseas entity, those two entities can carry separate coverage. A guard employed by one may fall under a policy that never touched the other. Resolving the employer name is step one. Resolving which specific entity employed the claimant on the injury date is step two, and it matters just as much.
Then there is the adjuster problem. The company that sends letters and cuts checks is frequently a third-party administrator, not the carrier. Reading that name as the insurer is one of the most common errors in security-firm files. We break down the distinction in our guide on how to tell a TPA apart from the actual DBA carrier.
The result is that a single security contractor can generate a spread of carrier records rather than one clean answer. Your job is not to find the carrier. It is to find the carrier for this claimant, this entity, this date.
How do you actually resolve an employer chain like GIS or Hart?
The reliable path is a disciplined sequence, and it never starts with the carrier question. It starts with identity.
First, collect every name in the file. Pull the intake sheet, the medical records, any contract fragments, and any prior correspondence. Write down each spelling and abbreviation exactly as it appears. Every variant of whichever entity is actually named in your file, whether that is GIS, Global Integrated Security, Hart, or a regional variant, goes on the list.
Second, resolve those names against alias and registration data. Confirm which names are real entities and how they relate. This step converts a pile of confusing labels into a defined set of employers to investigate. Iraq-era security primes are notorious for this, as our profile of a single Iraq security contractor with fourteen name variations makes clear.
Third, run each resolved entity against contract, legal, and coverage sources, filtered by the injury date. Look for the carrier named in legal decisions first, since that is direct evidence. Use contract and registration data to corroborate and to fill gaps.
Fourth, weigh the results by proximity to the injury date and by the strength of the source. A carrier named in a decision from the right period outranks a statistical correlation from a different year.
Doing this by hand across dozens of records for a firm with several name variants takes days. ClaimTrove runs this entire chain automatically. Enter the employer and injury date, and the engine resolves aliases and subsidiaries, searches every federal source in parallel, and ranks carriers by date and evidence strength. Run a name like GIS or Hart through ClaimTrove and let the tool surface the entity and carrier records for your specific claim window.
Security-firm risk profiles also reward context. Understanding what DBA data reveals about private security contractor injury rates helps you anticipate the injury types and litigation patterns you are likely to encounter in these files.
The DBA program is anchored in 42 U.S.C. 1651, and contractor coverage obligations flow from the FAR 52.228-3 insurance clause. Those rules created the paper trail. The names on the paper are the reason the trail is hard to follow. Start your investigation in ClaimTrove to turn a tangle of security-firm names into a defensible carrier answer.
This tool provides information from public DOL records. It is not legal advice. Always verify with primary sources.