Disclaimer: This post is intended for informational purposes only and may not be considered legal advice. For legal advice that is specific to your situation or project, we recommend talking to your attorney.
Contracting with third-party vendors to support any business processes — from marketing to finance to leadership consulting — requires sharing some amount of confidential information with outsiders. The nature and quantity of that information varies depending on the vendor’s role, but it’s especially significant for companies working with custom software developers to create new systems that will help run and grow the business.
The software vendors will need access to information about business processes, the intellectual property underpinning existing systems, product roadmaps, and perhaps even customer and financial data, for starters. As this is sensitive information, it stands to reason that companies will want to find a way to protect it, ensuring the software developers (or any vendors who will need access to company “secrets”) cannot share it with any other parties without explicit permission.
For that, we recommend a nondisclosure agreement.
What Is a Nondisclosure Agreement?
A nondisclosure agreement (NDA) is a legally binding document that is executed to protect the confidentiality. When one party is asked to share confidential information with another, the sharing party can ask the recipient to sign an NDA indicating their commitment to protecting that information — and establishing consequences should the recipient breach confidentiality.
When Do I Need to Ask for an NDA?
It’s a common practice to sign NDAs in software development, as a developer needs a lot of insight into the business in order to design and execute a project. At Syberry, our clients often ask us to sign NDAs before any detailed conversations about a project take place, beyond just general ideas. And we’re happy to oblige. There’s nothing more important to us than our clients’ trust.
In return, we often ask clients to sign NDAs, themselves, so that we can share some of our own confidential information with them, including information about previous experience and similar projects (to the extent allowed by our agreements with other customers). When this is the case, we want to be sure our new clients aren’t going to distribute or use that information for any purposes unrelated to our project, just like they want to be sure we won’t distribute or use theirs inappropriately.
When both parties are requesting the other to sign an NDA, the two parties can sign a “Mutual NDA” instead — one document outlining both parties’ obligations to protect sensitive material.
Is an NDA Ever Not Necessary?
An NDA isn’t always necessary, especially when two parties are just beginning conversations and discussing a project in general terms. It’s not until you get into the weeds about the details and begin discussing scope of work or software requirements, that it’s likely sensitive information will be shared.
What Should an NDA Include?
Every NDA will look a little different depending on the nature of the parties and of the information being shared. However, there are several components that must be clearly defined:
- Confidential information: What information is being protected? Only documents? Only information shared in writing? Or information shared verbally, as well? Furthermore, what isn’t confidential? Information that is already public knowledge, for example, doesn’t need to be protected under an NDA, so it should be explicitly carved out of the agreement.
- Ownership: Who owns the information being shared? If either party’s IP is owned by multiple parties, all parties (and their business addresses) must be listed, along with the names of anyone with the authority to execute the NDA on behalf of their principals.
- Information handling: Who has the right to handle confidential information from either party? Is it only the leadership that’s eligible to access confidential material, or can other employees see it, too? For example, can the project managers and developers assigned to a client’s project have full access to the materials? This section may contain specific names or refer more generally to a group of people involved in the project.
- Duration: An NDA must outline a finite duration during which it is valid and enforceable. The industry standard is up to two years, but this term can be longer or shorter.
What Red Flags Should I Look for in an NDA?
If you’re ever in doubt about a term or clause in an NDA, we recommend reaching out to your attorney for help getting it just right. But here are a few things to keep an eye out for when reviewing an NDA someone has asked you to sign — or when writing one yourself for someone else to sign.
- Overly broad language: An NDA must be specific in identifying the protected information. If it’s too broad, that may make it difficult to enforce the contract, and it may even make it difficult for the signing party to operate their business if too many non-confidential materials fall under its umbrella. Usually, it is considered good practice to include only to the IP related to a specific project.
- Perpetual duration: While it’s ok for the NDA to survive the engagement by a period of time, if it lasts in perpetuity, it’s overreaching.
- Legal violations: An NDA may not contain terms or rules that violate existing legislation or regulations — or that would force either party to violate those rules.
A good relationship between a client and a software vendor is built on trust, and either party should be happy to acknowledge its dedication to protecting the other party’s sensitive information. An NDA is a powerful way to do just that.