What is an NDA in a software project, and when do you actually need one?

It's a contract defining what confidential information is, who may see it, and for how long. You need one before sharing source code, architecture diagrams, credentials, or customer data. A one-way NDA suits a single discloser; a mutual NDA fits discovery calls where both sides expose technical detail. Get the governing law reviewed.

What should the definition of confidential information actually cover?

Marked documents are easy; the danger is unmarked disclosure. Name categories explicitly: source code, database schemas, API keys, infrastructure diagrams, pricing models, customer lists, product roadmap. Add a marking requirement plus a catch-all for verbal disclosures confirmed in writing within an agreed number of days. That confirmation window is negotiable, so fix it in the text.

How does an NDA differ from an IP assignment?

An NDA restricts use and disclosure; it does not move ownership. Code a contractor writes can remain theirs without a written assignment. Software engagements usually need both: an NDA covering the evaluation phase, and an IP assignment or work-for-hire clause inside the master services agreement. Read the two documents together before signing either.

What carve-outs from confidentiality are standard?

Information that is already public, independently developed without using the disclosure, lawfully received from a third party, or released in writing by the discloser. Compelled disclosure by a court or regulator is normally permitted with notice so the discloser can seek a protective order. Keep carve-outs narrow; broad ones quietly empty the agreement.

What term and survival period should an NDA use?

Two to five years is common for general business information, with trade secrets surviving as long as they stay secret under applicable law. Very long terms attract enforceability arguments in some jurisdictions. Match the term to how fast the information ages: a pricing model decays faster than a trained model or a core algorithm.

Can you actually enforce an NDA if a contractor leaks code?

Enforcement needs evidence: the signed NDA, a record of what was disclosed, repository history, and cloud audit logs showing who accessed it. Remedies are typically injunctive relief plus damages, and proving loss is difficult. Deterrents work better — least-privilege access, named credentials, revocation on exit. Involve a lawyer early.

Do NDAs hold up with offshore or freelance developers?

Yes, but sign with the right entity. A marketplace freelancer may sign personally while the work is subcontracted, so add flow-down clauses binding their subcontractors. Check governing law and whether a judgment is enforceable where they sit. Store the signed copy in your own document system, not only in the platform's inbox.

What operational overhead does an NDA add to a project?

Modest: one signed copy per counterparty, a register of who holds access, and a review before each new disclosure. The real cost is legal review time and the delay of waiting for signature before a technical call. Approve one template with your lawyer, then change only the exhibits and the term.

How do you verify an NDA is actually being honoured?

Intent is not auditable, access is. Reconcile commit history, cloud audit logs, and file-share permissions against the named individuals, and watch for unexpected clones, exports, or personal accounts. On exit, confirm credentials are revoked and copies deleted per the return-or-destroy clause. Document each check; that record is what makes a breach provable.

What if the vendor refuses to sign, or the NDA has expired?

Treat refusal as information. Limit disclosure instead: share architecture at a level that does not expose the core, or run a paid, staged evaluation under a confidentiality clause in the statement of work. If an NDA has expired, check its survival language before assuming anything; renew in writing before the next disclosure. Our team can help at /contact.

NDA Software Project: Agreements That Actually Hold

Non-disclosure agreements that mean something

A useful NDA on a software project does three things: it defines what counts as confidential, it binds the people who actually touch the material, and it puts a clock on the obligations. Everything else — recitals, boilerplate, the mutual-versus-one-way debate — is decoration if those three are missing.

Key Takeaways

An NDA covers information, not ideas. Anything public, or disclosed before signing, sits outside it.
The obligations have to reach the contractors, subprocessors and AI coding tools that actually handle your material.
Mutual is the sane default for a software project. One-way NDAs belong where only one side discloses.
Confidentiality and IP ownership are different clauses. An NDA does not transfer copyright in the code.
A defined term, a return-or-destroy step and a named contact turn a nice document into an enforceable one.
Repository permissions and audit logs do more day-to-day protection than the signed PDF ever will.
Have a lawyer in your own jurisdiction read it. Templates are a starting point, not a contract.

The four stages where confidentiality is won or lost on a software project: scoping, signing before disclosure, controlling access, and a clean exit.

What does an NDA actually protect on a software project?

An NDA protects confidential information — source code, schemas, architecture diagrams, pricing, customer lists, the contents of your discovery calls — by creating contractual duties on whoever receives it. It does not protect ideas, or stop a rival rebuilding something similar from public knowledge. Treat it as a duty of care over material, not a monopoly on a concept.

The exclusions are the part people skip. Most agreements carve out information that is already public, was already in the receiver's possession, is independently developed, or must be disclosed by law. That is normal. What is not normal is a broad "residuals" clause that lets the receiving company use anything its staff remember without notes. If you see residuals in a vendor's template, ask what it is doing there.

Why do NDAs fail once the project gets real?

Most NDAs fail quietly rather than dramatically. A director signs it, then the actual work is done by three contractors, a QA freelancer in another timezone and an AI coding assistant — none of whom have read it. The obligation exists on paper while the people holding your schema have never heard of it.

The document binds the company, not the individuals inside it. If the agreement does not name affiliates, employees, subcontractors and permitted tools, and require the receiving party to flow the obligations down, you have a promise from a legal entity that has already delegated the risk. On our own client engagements we name subcontractors before they touch anything, which is also a habit worth building into handing a project to a new developer mid-build.

When do you actually need one — and when is it overkill?

You need an NDA when you are about to hand over something that would hurt you if it leaked: source code, a database schema, customer data, pricing models or a genuine product idea. You do not need one for a public website rebuild, a logo refresh, or a first call where you discuss nothing sensitive. Match the instrument to the exposure.

Mapping the material you are sharing to the agreement and access control that actually covers it.

How does an NDA interact with IP assignment and copyright?

Confidentiality and ownership are separate legal mechanisms, and conflating them is the most expensive mistake we see. An NDA stops someone disclosing or using your information; it does not transfer copyright in the code they write. Without an assignment clause, the developer or agency typically owns the work they produced, even though you paid for it.

So a project needs both. The NDA governs the conversation and the material you share before and during the build. The assignment clause — usually in the master services agreement or the statement of work — moves ownership of the deliverables to you on payment. Moral rights, open-source dependencies and third-party licences each need their own line. We have watched a client discover at handover that the "their code" they assumed they owned was licensed, not assigned.

What belongs in an NDA for a software project?

A software-project NDA needs a tight definition of confidential information, the permitted purpose, who may receive it, the standard of care, a term, a return-or-destroy step and a remedies clause. Vague wording is what makes these documents hard to enforce, so be specific about categories of material rather than relying on "all information disclosed".

1. Definition of Confidential Information, with exclusions
2. Permitted purpose and no-other-use obligation
3. Recipients: employees, contractors, subprocessors, tools
4. Standard of care plus required technical controls
5. Term: fixed survival period after disclosure
6. Return or destruction, with written certification
7. IP ownership and assignment (separate clause)
8. Governing law, jurisdiction and remedies

Clause 3 and clause 7 are the ones that decide whether the agreement does anything. Everything above them is standard drafting.

How do you run the NDA process, step by step?

Run the process before the first technical conversation, not after. Sequence matters: you cannot un-disclose a schema. The steps below are the order we use on client work, and they keep the paperwork moving without turning a two-week discovery into a six-week legal negotiation.

Decide what you are protecting. Write down the specific artefacts — schema, repo, screenshots, pricing — before you talk to anyone.
Pick the shape. Mutual if both sides will share, one-way if only you will.
Sign before the walkthrough. The call where you screen-share the architecture is the disclosure event.
Name the recipients. List subcontractors and tools, and require the vendor to get your written approval before adding more.
Set the term. A fixed survival period, with a longer or indefinite one for genuine trade secrets.
Add the exit step. Return or destroy the material on request, with written confirmation.
Keep a register. Who signed, when, what you shared, and where the signed copy lives.

How do you verify the agreement is being honoured?

Verification is mostly technical. Check who has repository access, review the audit log for clone and download events, confirm subcontractors were disclosed, and keep a dated record of what you shared with whom. If you cannot answer "who downloaded the schema last month", the NDA is doing less work than you think.

The five moments in a project where confidentiality obligations change character, from an unsigned first call to the return of material after exit.

What are the failure modes, and how do you debug them?

Confidentiality breaks in predictable ways: an ex-employee keeps a clone of the repo, a contractor reuses your component library on another client, a staging environment holds live data, or the NDA was signed by someone without authority to bind the company. Each has a different fix, so diagnose before you escalate to lawyers.

Someone left with the code. Check repository access and offboarding records first. Access that was never revoked is more common than theft.
The same components appeared elsewhere. Compare commit history and timestamps before alleging anything. Shared open-source dependencies explain most of it.
Data turned up in the wrong environment. That is a control failure, not a contract failure. Fix the pipeline first.
The signatory had no authority. Confirm who can bind the counterparty before the disclosure, not after.

What does an NDA cost you in operational overhead?

The real cost of an NDA is engineering time, not legal fees. Expect a review cycle per counterparty, an access-review habit, offboarding checks when a contractor leaves, and someone keeping signed copies findable. Done well it is a few hours a year. Done badly it is a document nobody can locate when it matters most.

There is also a negotiation cost. Heavy templates slow down small vendors, and small vendors are often the ones you want. A short, clear mutual NDA that both sides can sign in a day beats a twelve-page agreement that sits in legal review while your window closes. Where the risk is genuinely low, a confidentiality clause inside the statement of work is enough — see our frequently asked questions for how we handle that on smaller engagements.

Security considerations: the technical half of confidentiality

Contracts allocate blame after the fact; controls prevent the leak. Least-privilege repository access, scoped tokens, encrypted transfer, no production data in staging, and a documented offboarding checklist do the real work. Treat the agreement and the access model as one system, because a leak does not care which half failed.

In practice that means a private repository with per-person permissions rather than a shared account, time-limited credentials, and a written record of who was granted what. GitHub's own documentation on repository access is a reasonable starting point for the mechanics. If you are handing code to an external team, the access grant is the disclosure — log it the same way you log the signed agreement.

Common mistakes we see

The same handful of mistakes show up again and again on software projects, and most are cheap to avoid at the start and expensive to unpick later. None of them need a better lawyer — they need someone to actually read the clause before the first repository is shared.

Signing an NDA after the technical walkthrough, when the schema is already on screen.
Assuming confidentiality covers ownership. It does not; get an assignment clause.
Leaving "residuals" language in a vendor template unchallenged.
Never revoking access when a contractor finishes. That is a bigger exposure than most signed agreements.
Treating the paperwork as a substitute for keeping scope creep under control, which is where most trust actually breaks down.

A realistic scenario

Picture a Kathmandu business replacing an ageing internal system. They shortlist two vendors, share a database schema and a set of screenshots, and ask for a quote. One vendor signs a mutual NDA before the call. The other asks for it after seeing the data. That gap tells you more about how the project will go than either proposal does.

The first vendor also grants a single named engineer access to a private repository, with read-only permissions and a token that expires in a week. The second asks for a shared login "so the team can look". Both eventually sign something. Only one of them has a confidentiality position that survives the first month. Legal work of this kind belongs alongside the engineering — our team can help you scope and build custom software with the agreements and access model set up from day one, and you can see how that plays out on work like a legal-sector engagement.

Alternatives compared

An NDA is one instrument among several, and picking the wrong one wastes time on both sides. A mutual NDA suits early technical conversations, a one-way NDA suits a single discloser, a statement of work with confidentiality terms suits an active engagement, and an IP assignment deed is what actually moves ownership of code.

Instrument	What it does	When it fits
Mutual NDA	Both sides owe confidentiality duties	Discovery, evaluation, early technical calls
One-way NDA	Only the receiving side owes duties	You disclose; the other side does not
NDA plus IP assignment	Adds transfer of copyright in deliverables	Any paid build where you must own the code
SOW with confidentiality terms	Covers the whole engagement, not one conversation	Ongoing work and multi-phase projects
Data processing agreement	Governs personal data handling and breach duties	Anything touching customer records or PII

In short

An NDA is worth having, but it is the weaker half of confidentiality. Get the definition, the recipients, the term and the exit step right, pair it with a real IP assignment clause, and back the whole thing with access controls you can actually audit. A signed document plus a revoked token beats a signed document alone, every time.

People also search for

These are the questions engineers, founders and procurement teams ask most often when they are setting up confidentiality terms for a build. Each one links to a related guide we have already published, so you can go deeper on whichever part of the process you are wrestling with right now.

If you are starting a build and want the agreements, the repository permissions and the offboarding checklist designed together rather than bolted on afterwards, talk to our team. We will look at what you have, tell you what is missing, and put it in writing before anyone touches your code.

Frequently asked questions

It's a contract defining what confidential information is, who may see it, and for how long. You need one before sharing source code, architecture diagrams, credentials, or customer data. A one-way NDA suits a single discloser; a mutual NDA fits discovery calls where both sides expose technical detail. Get the governing law reviewed.
Marked documents are easy; the danger is unmarked disclosure. Name categories explicitly: source code, database schemas, API keys, infrastructure diagrams, pricing models, customer lists, product roadmap. Add a marking requirement plus a catch-all for verbal disclosures confirmed in writing within an agreed number of days. That confirmation window is negotiable, so fix it in the text.
An NDA restricts use and disclosure; it does not move ownership. Code a contractor writes can remain theirs without a written assignment. Software engagements usually need both: an NDA covering the evaluation phase, and an IP assignment or work-for-hire clause inside the master services agreement. Read the two documents together before signing either.
Information that is already public, independently developed without using the disclosure, lawfully received from a third party, or released in writing by the discloser. Compelled disclosure by a court or regulator is normally permitted with notice so the discloser can seek a protective order. Keep carve-outs narrow; broad ones quietly empty the agreement.
Two to five years is common for general business information, with trade secrets surviving as long as they stay secret under applicable law. Very long terms attract enforceability arguments in some jurisdictions. Match the term to how fast the information ages: a pricing model decays faster than a trained model or a core algorithm.
Enforcement needs evidence: the signed NDA, a record of what was disclosed, repository history, and cloud audit logs showing who accessed it. Remedies are typically injunctive relief plus damages, and proving loss is difficult. Deterrents work better — least-privilege access, named credentials, revocation on exit. Involve a lawyer early.
Yes, but sign with the right entity. A marketplace freelancer may sign personally while the work is subcontracted, so add flow-down clauses binding their subcontractors. Check governing law and whether a judgment is enforceable where they sit. Store the signed copy in your own document system, not only in the platform's inbox.
Modest: one signed copy per counterparty, a register of who holds access, and a review before each new disclosure. The real cost is legal review time and the delay of waiting for signature before a technical call. Approve one template with your lawyer, then change only the exhibits and the term.
Intent is not auditable, access is. Reconcile commit history, cloud audit logs, and file-share permissions against the named individuals, and watch for unexpected clones, exports, or personal accounts. On exit, confirm credentials are revoked and copies deleted per the return-or-destroy clause. Document each check; that record is what makes a breach provable.
Treat refusal as information. Limit disclosure instead: share architecture at a level that does not expose the core, or run a paid, staged evaluation under a confidentiality clause in the statement of work. If an NDA has expired, check its survival language before assuming anything; renew in writing before the next disclosure. Our team can help at /contact.