NDA, IP Protection & Contracts in Game Art Outsourcing: What Happens If Something Leaks
-
Written byDenys Zadoienyi
-
Updated on12.08.2026
-
Time to read12 min
Most guidance on game art outsourcing contracts stops at the same three items: sign an NDA, get an IP assignment clause, require source file delivery. Those are necessary, and if you want the full mechanics of how to structure them into a procurement document, our guide to RFP and SOW practices covers that in depth. What almost no procurement checklist covers is the question that actually matters once those clauses are signed: what contractually happens if something leaks anyway.

“Editorial illustration created for visual reference purposes. It does not represent a real project, client work, or official software screenshot unless stated otherwise.”
This is a procurement guide, not legal advice. Contract law varies by jurisdiction, and the specific language that protects you depends on where your studio and your vendor are incorporated, what governing law your agreement specifies, and details a general guide can’t account for. Treat what follows as the questions to bring to your own counsel, not language to copy into a contract unreviewed.
IP Ownership and Source Files Are Two Different Questions
IP ownership and source-file delivery solve different problems, and contracts that treat them as one clause tend to leave a gap. An assignment clause determines who owns the copyright and related rights in the deliverables. A separate delivery clause determines which editable working files – layered PSDs, DCC project files, uncompressed textures, bakes – the client actually receives. A client can legally own the final work without receiving every production file; that doesn’t invalidate the assignment, but it does create practical dependency on the vendor and makes future modification harder. Both deserve their own line item in a Statement of Work, and we walk through exactly how to write that language in our RFP and SOW guide.
Two details worth getting right in the assignment clause itself. First, don’t lean on work-for-hire as a universal mechanism – in the U.S., it applies automatically only to employee work; for commissioned work from an outside studio, it’s available only for a narrow list of statutory categories and requires a signed written agreement even then. Whether a specific game-art deliverable qualifies – including as part of an audiovisual work, one of the enumerated categories – is fact-specific and depends on the exact nature of the work, not a general rule either way. An explicit assignment clause is the more reliable foundation regardless of jurisdiction, with work-for-hire language added as a complement where the governing law and work category actually support it, not relied on alone. Second, state the transfer trigger expressly – on creation, on delivery, on acceptance, or on full payment are all common structures, and which one applies changes who owns partially completed work if the engagement ends early.
It’s also worth having the contract address IP the vendor brings in rather than creates from scratch: reusable tools, licensed fonts, stock assets, plugins, and any generative-AI tools or AI-generated material used in production. Appropriate warranties, disclosures, and license records for this background material close a gap that a deliverables-only assignment clause leaves open. Our own Terms & Conditions show two sides of this in practice: proprietary tools, brushes, scripts, and pipelines developed by Nasty Rodent are explicitly excluded from IP transfer unless the project agreement says otherwise, and any use of AI-assisted tools in project production is subject to prior client approval. Both are worth checking for explicitly in any vendor’s contract, not assumed.
Confidentiality: Scope, Flow-Down, and Exclusions
A signed NDA protects less than people assume if the underlying terms are vague. What matters more than the fact of signing one is what it actually covers: a definition specific enough to reach unreleased assets, builds, documentation, and commercial plans without being an undefined “everything” that’s hard to apply consistently, and standard exclusions for information the vendor already knew, received lawfully from someone else, developed independently, or that becomes public without their fault – these exclusions are standard in professionally drafted NDAs and their absence is itself worth noticing.
Coverage of the vendor’s own team matters more than who signs the agreement. The vendor entity should remain responsible for everyone it authorizes to access the project – disclosing confidential information only on a need-to-know basis, and ensuring employees and subcontractors are bound by confidentiality obligations at least as protective as the client agreement. Our own Terms & Conditions show this in practice: access is limited to “team members including contractors and external partners engaged by the Company who have a legitimate need to know and who are bound by equivalent confidentiality obligations” – a flow-down structure rather than a requirement that every individual artist be a named party.
Portfolio use deserves explicit treatment rather than being left implied. Vendors reasonably want to show completed work – it’s how they win the next client – and a contract that’s silent on this produces disputes later, when the vendor assumes post-release display is fine and the client assumed nothing would ever be shown. The same Terms & Conditions handle this explicitly: absent a signed NDA restricting it, portfolio display of completed deliverables is reserved as a right, and any project requiring full confidentiality has to establish that in writing before the engagement starts. Whatever your vendor’s default is, get it stated in the contract rather than assumed.
NDA timing matters as much as its content – signed before any project material changes hands, not negotiated mid-engagement once the vendor already has access. We cover this sequencing in our vendor onboarding protocol. Worth adding to the same clause: what happens to materials after the engagement ends – return or destruction of confidential files, credential and repository-access revocation, and how long the confidentiality obligation survives termination. The survival period should be stated expressly and matched to the sensitivity and expected commercial life of the information – Nasty Rodent’s own Terms & Conditions use three years unless a separate NDA specifies a longer period, which is one reasonable structure among several rather than a market-wide standard.
What Happens If There’s a Leak: Liability, Indemnification, and Insurance
This is the part almost every public guide to outsourcing contracts skips, and it’s the part that determines what you can actually do if confidentiality fails despite the NDA.
Indemnification and direct-loss remedies. Indemnity clauses commonly allocate responsibility for specified third-party claims – for example, an allegation that the vendor’s work infringed someone else’s IP. Whether an indemnity also covers the client’s own direct losses from a confidentiality breach (legal costs, incident response, provable commercial harm from an early leak) depends on the governing law and the exact drafting, and vendor-drafted contracts sometimes limit indemnification to third-party claims by default. The agreement should address both explicitly: third-party indemnification, and the separate remedies available for the client’s own direct losses. Worth checking alongside this: who controls the defense of a claim, whether settlement requires the client’s consent, what counts as an excluded or consequential loss, and whether legal fees are recoverable.
Liability caps. Most vendor contracts include a liability cap tied to contract value, which is standard for ordinary production disputes – a missed milestone shouldn’t expose a mid-size studio to unlimited liability. Confidentiality, IP, and data-security claims deserve a separate conversation rather than defaulting to that same number, since potential damage from a leaked unreleased title has no fixed relationship to what you paid for a batch of assets. There’s more than one reasonable way to handle this: an uncapped carve-out, a separate higher cap, a cap expressed as a multiple of fees, or a cap tied to the vendor’s available insurance limits. Which structure fits depends on the project’s sensitivity and each side’s bargaining position – there’s no single correct answer, but a contract that applies the ordinary delivery-dispute cap to a confidentiality or IP claim without anyone having discussed it is worth raising before signing.
Insurance. A liability clause is only as good as the vendor’s ability to actually pay if it’s triggered, but which policy actually responds to a given incident varies. Technology errors-and-omissions or professional indemnity coverage, cyber liability, media liability, and crime coverage can each respond differently depending on whether the claim involves IP infringement, a confidentiality breach, unauthorized system access, or employee misconduct – general commercial liability insurance often covers none of these. Ask for evidence of coverage and have your own counsel or broker review the policy type, limits, exclusions, and whether the vendor’s contractual indemnity obligations are actually covered by the policy. A certificate of insurance confirms a policy exists on a given date; it doesn’t by itself establish that a specific loss would be covered or give the client rights under that policy – additional-insured status, where relevant, is a separate ask.
Breach notification. A contract silent on notification timing leaves you finding out about a leak the same way the public does. There’s no single market-standard window – some agreements specify a fixed period like 24 or 48 hours, others use “promptly” or “without undue delay,” and the right choice depends on the project’s sensitivity. Our own Terms & Conditions use the latter approach: an obligation to “promptly notify the other party upon becoming aware of any actual or suspected unauthorised disclosure,” with confidentiality obligations surviving three years past the engagement. Whichever form your contract uses, what matters is that a trigger and an obligation actually exist – not which specific wording carries it.
Governing law and jurisdiction. This clause rarely gets attention until it’s the only thing that matters – when a breach has already happened and you’re deciding where and how to pursue a remedy. The contract should name a specific governing law and forum rather than leaving it implied by either party’s place of incorporation. For cross-border engagements, arbitration under a recognized institution can offer a more consistent international enforcement path – arbitral awards are recognized across a wide range of countries under the New York Convention in a way foreign court judgments often aren’t – but arbitration isn’t automatically the right call for every contract; it can be slower and more expensive than litigation for a smaller-value dispute, and less suited to urgent injunctive relief. This is a comparison worth making with counsel rather than defaulting to either option.
What contract language can’t fully solve. Worth being direct about this: cross-border enforcement of confidentiality and IP claims is genuinely harder than domestic litigation, and a strong contract reduces risk without eliminating it. That’s why procurement teams pair contract terms with operational controls – limiting which team members at the vendor have access to sensitive material and using restricted or watermarked builds for early-stage sharing. The contract sets the terms of recourse; the operational controls reduce how often you need it.
What to Do Operationally If a Leak Is Suspected
The contract terms above determine your recourse. What actually happens in the first hours after a suspected leak is a separate, practical sequence worth agreeing on before you need it, not during a crisis:
- Activate incident response and preserve evidence – assign an owner and capture access logs, timestamps, and file-sharing records before anything else changes, since containment actions can themselves destroy the evidence needed later.
- Contain access proportionately – revoke, suspend, or restrict credentials and repository access where continued access creates real risk, informed by what step 1 already captured.
- Trigger the contractual notification – formally notify the vendor or client per the agreement, starting the clock on their obligations.
- Classify what happened – a portfolio posting, a misdirected file, a compromised account, and a deliberate disclosure are different problems with different contractual and practical consequences; treating all of them as the same “leak” slows the right response.
- Loop in the right parties – legal counsel, security or IT response personnel, the publisher where applicable, relevant insurers, and communications stakeholders, as the specific incident requires rather than in a fixed order – insurance policies often have their own notice deadlines, and security response sometimes needs to start before legal assessment is complete.
- Pursue available remedies – takedown requests or injunctive relief where distribution is ongoing and can still be limited, alongside whatever the contract’s indemnification and liability terms provide for.
None of this replaces legal advice in the moment – it’s the checklist for making sure you’re not improvising the sequence for the first time during an actual incident.
A Procurement Audit Checklist
Bring this into contract review before signing, not after a problem surfaces:
| Contract element | What to verify | Red flag |
| IP ownership | Explicit assignment clause naming all deliverables; work-for-hire language only where the category and jurisdiction actually support it | Clause relies on work-for-hire alone with no assignment backup |
| Source-file delivery | Named separately from the assignment – layered files, project files, textures | Clause covers “final deliverables” but doesn’t mention source files |
| Transfer trigger | Stated expressly – creation, delivery, acceptance, or payment | Left implied |
| Confidentiality scope | Specific defined categories, with standard exclusions (already known, public, independently developed, lawfully received from a third party, disclosure required by law) | Undefined blanket “everything,” no exclusions listed |
| NDA flow-down | Vendor contractually responsible for contractors/subcontractors having equivalent obligations | No flow-down language at all |
| Liability cap | Confidentiality/IP claims discussed separately from the general cap, even if the answer is a negotiated single number | No discussion of the cap’s scope ever happened |
| Insurance | Evidence of relevant coverage (tech E&O, cyber, or equivalent) reviewed for exclusions and limits | Vendor states coverage exists but won’t provide evidence |
| Breach notification | A defined trigger and obligation exist, in whatever form | No notification obligation specified at all |
| Governing law | Specific jurisdiction or arbitration body named explicitly | Left implied by incorporation location, never stated |
None of these questions should feel adversarial to raise with a vendor that has real production discipline. A studio with mature procurement experience expects them as standard due diligence, not as a sign of distrust.
About Nasty Rodent
Nasty Rodent is a game art outsourcing studio based in Tallinn, Estonia, delivering 3D characters, environments, props, concept art, and UX/UI for mid-core and AAA titles.
Nasty Rodent publicly states – on its About page and in its Terms & Conditions – that it operates under a certified information security system and maintains international liability insurance, with all team members handling client data bound by internal confidentiality agreements. Procurement teams should verify the scope and supporting documentation of any comparable claim during due diligence with any vendor, including Nasty Rodent.