Understanding Limited Data Rights in DFARS Contracts

Eric Marquette

Welcome back to the Procurement Federal Acquisition Supplement & Defense Federal Acquisition Supplements Clauses podcast. Today we’re diving deep into limited data rights under DFARS 252.227-7025—what they are, why they exist, and why the right marking legends are so important. If you’ve ever scratched your head reading contract language with ‘limited rights’ or ‘government purpose rights,’ don’t worry, you’re not alone.

Ruby Sturt

Yeah, and these definitions actually aren’t just made up by some wizard behind a curtain—they’re pulled straight from other DFARS clauses. Like, if you’re dealing with technical data, then ‘limited rights’ and ‘government purpose rights’ come from 252.227-7013. But if it’s computer software, you’ll be looking at ‘restricted rights’ and those are defined under 252.227-7014. Oh, and don’t even get me started on SBIR or STTR programs, they’ve got their own legends and that’s all in 252.227-7018.

Paul Netopski

That’s right, Ruby. And it’s crucial to distinguish the types of data we’re talking about. Technical data, computer software, commercial data, SBIR or STTR data—all have distinct rights and restrictions, and DFARS spells it out pretty specifically. For example, ‘restricted rights’ usually tie back to noncommercial software. ‘Limited rights’ apply to technical data other than commercial items. ‘Government purpose rights’ mean the government can use the data for governmental use, but not just open it up to the world. It all hinges on how you categorize—and importantly, mark—the data.

Eric Marquette

Exactly. The marking bit’s what tripped me up way back in my old media days—sort of a different context, but same chaos. We’d produce shoots and, I can’t even count how many times, we’d look at digital assets with no indication of who actually owned the rights. It caused all sorts of delays, legal back-and-forth... reminded me a lot of what happens in government contracts if you don’t get the data markings right. The government and contractors rely on those restrictive legends to signal what’s allowed, and what isn’t. Slap the wrong label, or leave it blank, and suddenly everyone’s confused about how they can use or share the asset.

Ruby Sturt

I think the categories themselves can be a bit confusing, right? There’s the whole technical data versus computer software, and then is it commercial or SBIR data, which comes with its own special sauce. But bottom line is, the legend—the marking—controls what you’re allowed to do and who else can see or use that info.

Paul Netopski

Absolutely. And as contractors, you’re on the hook to treat the legends as gospel, which sets the rules for use, sharing, modification, or even just showing someone else the data. If the definitions are blurry to you—go back to those referenced DFARS clauses. That’s the gold standard for what each term means and what each restriction covers.

Ruby Sturt

So, let’s get into what you can—and can’t—do with government-furnished info when you spot those restrictive legends. Like, is it as simple as “no sharing allowed” or are there more hoops?

Paul Netopski

It’s definitely more nuanced than that. For example, let’s say you receive GFI marked with a limited rights, restricted rights, or SBIR legend. You can only use, modify, or display that data in performance of the contract. Disclosing it to anyone else? That requires express written permission from whoever’s name is in the legend. And even then, you need a nondisclosure agreement signed and documented—there’s a template at DFARS 227.7103-7 for that specific purpose.

Eric Marquette

So it’s not enough to just keep the data to yourself—you’re also obliged to control access within your organization and suppliers, right?

Paul Netopski

Exactly. And that goes for government purpose rights, too. If it’s marked for government purposes, you can use it for government work—that’s it. Commercial uses? Off-limits unless you get the owner’s permission. And before sharing even for government work, like with your suppliers, you’ve got to ensure they sign that NDA first. There are also cases with specially negotiated licenses—think of those as “custom contracts”—where you have to stick to whatever that unique license spells out, and recipients still need to sign nondisclosure agreements.

Ruby Sturt

Paul, you ran into a real-world example like this didn’t you? With a defense supplier?

Paul Netopski

Absolutely. I’ll keep it anonymized, but a supplier in the DIB got technical data with a limited rights legend, and an enthusiastic engineer shared it with a subcontractor—no NDA in place. It resulted in a corrective action; not quite contractual Armageddon, but could’ve escalated. The contractor had to track down everyone who saw it, get the NDAs signed retroactively, and assure the data owner and government that controls were restored. It disrupted the work, eroded trust, and led to more scrutiny from the customer. So, in practice, always, always confirm the NDA is signed before sharing—no shortcuts.

Eric Marquette

It sounds like a lot of paperwork, but honestly, it’s less painful than an audit or a legal dust-up. And it’s all to prevent improper use or disclosure, which—if we look back at our earlier episodes about compliance and CMMC—can trigger a cascade of broader issues. Markings and process aren’t just box-ticking; they’re the first defense against data leaks.

Ruby Sturt

And it’s not just internal, right? Even if you’re a government support contractor, there are extra hoops—sometimes extra agreements, and even a forty-eight-hour heads-up or something? No, actually, it’s thirty days you’ve got to notify the data owner if you access it. The details stack up.

Ruby Sturt

This brings us to my favorite part—what happens if you mess up? Like, let’s say you’re a small business, you miss a marking, skip an NDA, or someone sees something they shouldn’t. What’s the fallout, and how do you fix it?

Paul Netopski

There are a few layers to this. First, as a contractor, you’re obligated to make sure your employees are held to use and nondisclosure standards before they get access to any GFI under this clause. That means NDAs, internal controls—whatever it takes to wall off sensitive info. If you breach these obligations, the government can hit you with criminal, civil, or administrative penalties, contract actions, potentially even damages. And here’s something a lot of businesses miss: the actual owner of the data has third-party beneficiary rights, so they can bring civil action directly if their info’s leaked or misused.

Eric Marquette

What Paul’s saying is, you’re not just answering to your government point of contact. There’s real indemnification language—meaning if you, or anyone you shared it with, misuses data, you could be paying legal fees, judgments, even court costs. And the party named in the legend isn’t just some silent partner—they can take you to court themselves if they feel their data’s at risk. The consequences can get quite real, quite quickly.

Ruby Sturt

So, it’s not just a regulatory slap on the wrist—potentially could be a lawsuit from the data owner or a full-blown contract breach with the government. Yikes. No surprise this all comes back to training people right, setting up airtight processes, and...checking those legends like your life depends on it. Not to be dramatic!

Paul Netopski

That’s actually not dramatic at all—it’s reality in federal contracting. And like we’ve touched on in previous episodes, having those compliance controls up front saves you a world of hurt down the line. Proactivity is cheaper than recovery, whether you’re a prime or a small supplier.

Eric Marquette

Brilliant, thanks both. That about does it for today. For everyone listening, this is just one clause in a sea of requirements—but as we’ve seen, understanding and managing data rights is absolutely foundational. We’ll dig even deeper in upcoming episodes. Ruby, Paul—always a pleasure. Thanks for joining.

Ruby Sturt

Cheers Eric, cheers Paul. Catch you all next time.

Paul Netopski

Thanks everyone—stay vigilant, stay compliant. See you next episode.