<aside>
🔑 **NDAs are not to be taken lightly and have repercussions if we don't follow through. There are 2 key takeaways you should know about NDAs:
- Only a Co-Director can sign this.
- We should avoid NDAs if possible (e.g. asking for anonymous data that wouldn't require us to sign a NDA).**
</aside>
If you are going to use a NDA, please track it here in our Google Drive.
A NDA (Non-Disclosure Agreement) is a document that binds two parties (the Discloser, and the Recipient) to an agreement about some piece of Confidential Information. For our purposes, the Discloser is our nonprofit, the Recipient is us (Hack4Impact UIUC), and the Confidential Information is the sensitive data we NEED from the nonprofit for the project. Again, if we don't NEED this sensitive data for the project, let's avoid requesting the data and signing a NDA for it. The NDA requires us to keep the Confidential Information confidential. So if we sign a NDA, and accidentally leak the data somehow, we will be liable to the consequences. Basically, if it's our fault that the data got leaked, the legal consequences would be on us instead of the nonprofit. If our product for the nonprofit deals with sensitive data, robust security will probably need to be a big part of the product as well (look into professional security audits).
Attempting to avoid NDAs
If possible, we'd like to avoid having the liability that comes with NDAs. This doesn't mean to avoid the project and find a new project that doesn't require sensitive data. Think about the following:
- Is this requested data a core need for the project, or is it a "nice to have", low priority feature? If it isn't a core part of the project, consider avoiding it.
- Would they give you the format of the data, or create a small sample of fake data that wouldn't require you to sign a NDA, and wouldn't negatively impact the project? If so, have them do that instead, and provide and easy and secure way for the nonprofit to get their data onto the platform post-handoff.
- If the reason you need the actual data is input validation, this might not be a perfect solution (if there are edge cases in the real data not represented in the sample), but depending on the situation, this is probably an okay trade off to make. It may also require the project leads or members to create some fake data to test things on the platform.
- If you need data to train a model, the NDA is probably unavoidable, unless the model wouldn't rely on any of the sensitive parts of the data, or if they can convert sensitive information to non-sensitive (e.x. Date of Birth → Age).
Reading and Signing an NDA
<aside>
⚠️ This is not legal advice. If you have any experience with legal documents, feel free to correct and contribute to this section.
</aside>
A co-director must be the one to sign a NDA (only co-directors are authorized to sign things on the behalf of Hack4Impact UIUC). Track the NDA here by 1) putting a copy of the NDA in this folder (not signed by you), and 2) filling out the spreadsheet in the folder.
- Make sure you've confirmed with the team that they NEED the "Confidential Information" (see the previous section).
- Compare the NDA to existing examples in the drive.
- Make sure you know what is considered the "Confidential Information", what agreement you're being held to, and any processes you're expected to follow.
- Send a message and confirm with Nationals before you sign an NDA.
Working with Confidential Information
These are likely pretty general tips, a lot of the specifics may depend on the type of data we're receiving. Some of these may be obvious.
- Restrict access to the Confidential Information to as few people as possible. Generally this can just be the project leads. The project leads should take steps to anonymize the data before sharing it with the team.
- Avoid Google Drive. Google drive is secure, but its very easy to mess up sharing settings, etc.
- Keep track of anywhere the data is stored. If you download the data, keep track where it's been downloaded to so that you can go and delete it when necessary.