NDA Checklist for Indian Startup Founders Before Sharing Pitch Decks, Code, Data or Customer Lists
Indian startup founders should use an NDA when they are sharing genuinely confidential material: source code, technical architecture, data-room files, customer lists, pricing, pilots, algorithms, unpublished…
Why NDAs matter before sharing startup information
Founders often share sensitive information before the company is ready for scrutiny. A pitch deck goes to a possible investor. Source code goes to a technical adviser. Customer lists go to a channel partner. Financial projections go to a lender. Product roadmap and pricing go to an enterprise prospect. The conversation feels commercial, but the legal risk is already active.
An NDA cannot guarantee that nobody will misuse information. It also cannot fix a founder’s own careless process. But it creates three important protections. First, it tells the recipient what information is confidential and the permitted purpose for using it. Second, it creates a written obligation that can support contractual and injunctive remedies. Third, it shows investors, acquirers and customers that the startup treats confidential information as a serious asset.
In India, NDAs are mainly supported by contract law, confidentiality principles and remedies such as injunctions. The Indian Contract Act, 1872 matters because an NDA is a contract. The Specific Relief Act, 1963 matters because a founder may need an injunction to prevent disclosure or misuse. The Copyright Act, 1957 matters where code, designs, documents or content are shared. The Digital Personal Data Protection Act, 2023 matters where customer, employee, user or lead data includes digital personal data.
What an NDA can and cannot do
| Issue | What an NDA can do | What it cannot safely do |
|---|---|---|
| Pitch deck | Restrict copying, forwarding and use outside evaluation. | Stop someone from independently pursuing a broad market idea already public. |
| Source code | Protect repository access, architecture, credentials, deployment notes and unreleased features. | Replace copyright assignment, employee IP clauses or contractor agreements. |
| Customer list | Restrict solicitation, disclosure and use of non-public commercial data. | Protect information already public or independently known to the recipient. |
| Personal data | Set access, security, use and deletion obligations. | Replace DPDP compliance, consent, lawful processing or data-processing terms. |
| Non-compete | Protect confidential information and business opportunities during the relationship. | Broadly stop someone from working in a lawful profession, trade or business after the relationship. |
| Remedies | Support injunction, return/deletion and damages claims. | Guarantee a court order without evidence of breach, confidentiality and harm. |
Before sharing anything: classify the information
The biggest NDA mistake is using the same agreement for every situation. A founder sharing a high-level pitch deck with a VC does not need the same document as a founder giving repository access to an outsourced engineering team. Start by classifying what is being shared and how sensitive it is.
| Information type | Examples | Control level |
|---|---|---|
| Low sensitivity | Public deck, founder profile, market summary, non-confidential demo. | Watermark, access tracking and basic confidentiality notice may be enough. |
| Commercially sensitive | Pricing, pipeline, investor data room, unit economics, customer terms. | NDA, restricted access, version control and recipient list. |
| Technical sensitive | Source code, architecture, API keys, security notes, product roadmap. | NDA, access controls, limited permissions, logs and no credential sharing. |
| Personal data | Customer records, user data, employee data, lead lists, support exports. | DPDP review, purpose limitation, security terms, deletion and breach process. |
| Strategic sensitive | M&A discussions, term sheets, large customer negotiations, litigation notes. | Strict NDA, clean team access, no onward disclosure and counsel involvement. |
This classification should happen before disclosure. Once information is sent over email, WhatsApp or a shared drive without restrictions, it becomes harder to prove the startup treated it as confidential.
Core NDA clauses Indian founders should check
1. Parties and purpose
The NDA should name the correct legal parties. If the startup is incorporated, use the company name, CIN and registered office. If the disclosure is before incorporation, founders should be clear whether they are signing personally, for a proposed company, or through an existing entity. The purpose should be narrow: evaluating investment, discussing a customer pilot, conducting technical diligence, exploring acquisition, providing advisory support or negotiating a partnership.
2. Definition of confidential information
Avoid vague wording such as “all information shared by the company” without examples. A strong definition should cover written, oral, visual, electronic and access-based information, including pitch decks, product roadmap, code, data, customer lists, pricing, financials, business plans, trade secrets, credentials, designs, models, prompts, APIs, security documentation and data-room files.
3. Permitted use
The recipient should use the information only for the stated purpose. This clause is essential. Without it, the recipient may argue that the information was shared broadly for discussion. If the purpose is investment evaluation, the recipient should not use the material to build a competing product or approach customers.
4. Need-to-know access
If the recipient is a fund, company, adviser or agency, it may need to share information internally. The NDA should allow disclosure only to representatives who need access for the purpose and are bound by confidentiality obligations. Founders should avoid unlimited onward sharing to affiliates, consultants or portfolio companies.
5. Exclusions
Every NDA should exclude information already public, already known to the recipient without confidentiality duty, independently developed without using the startup’s information, or lawfully received from another source. These exclusions are normal. Overreaching NDAs that try to label everything as confidential, including public information, become harder to enforce.
6. Term and survival
The agreement should say how long the NDA remains in force and how long confidentiality obligations survive. Highly sensitive trade secrets may need protection as long as they remain non-public. Other information may have a fixed period such as two, three or five years. The period should match the information’s commercial life.
7. Return, deletion and certification
The NDA should require the recipient to return or delete confidential information on request or when discussions end. For digital data, add deletion from shared drives, local devices, backups where reasonably possible and collaboration tools. For serious disclosures, ask for written confirmation of deletion.
8. Remedies and injunctive relief
Money may not fully repair a confidentiality breach. If source code, customer lists or acquisition discussions become public, the damage can be immediate. The NDA should preserve the startup’s right to seek injunction, specific relief, damages and other remedies available under law.
Free Weekly Newsletter
Subscribe to BSA startup funding alerts
- Every Sunday, all Indian startup funding alerts in one place
- Monthly funding report on the last day of the month
- Free, concise, founder-focused, and easy to unsubscribe
Get the complete Indian startup funding roundup in your inbox, covering deals, sectors, investor moves, and founder readiness notes from the week.
Built for founders, investors, CFOs, and advisors
No spam. Unsubscribe anytime.
Pitch decks: what to share before and after NDA
Most investors will not sign an NDA for an initial pitch. Founders should accept this reality and manage it with staged disclosure. The first deck should explain the business without revealing truly sensitive details. Keep proprietary algorithms, customer names, exact margins, code, contracts and detailed data-room material for later stages.
| Before NDA | After NDA or serious diligence |
|---|---|
| Problem, market, product overview and public traction. | Customer-wise revenue, signed contracts and detailed pipeline. |
| High-level technology explanation. | Architecture documents, security notes and technical diligence files. |
| Indicative financial snapshot. | Monthly MIS, bank statements, tax filings and unit economics detail. |
| Founder background and team summary. | Founder agreements, employment contracts and compensation data. |
| Public logos only where permission exists. | Customer contracts, renewal terms and confidential case studies. |
Watermark decks, use view-only links where practical, maintain a recipient tracker and avoid sending editable financial models to casual contacts.
Source code, product demos and technical diligence
Technical diligence creates a different risk level. A founder may need to show code quality, architecture, security practices, uptime, API documentation, AI model workflow or data pipeline design. This should not be handled with a generic one-page NDA.
Before sharing code, check whether the company actually owns it. If employees created it, employment agreements and IP clauses should be in place. If contractors, agencies or freelancers contributed, written IP assignment is critical. If founders wrote the first version before incorporation, sign founder IP assignment. Copyright ownership and confidentiality are related but different. An NDA restricts disclosure and use; it does not automatically transfer ownership of code to the company.
- Prefer screen-share review before repository access.
- Create temporary, read-only accounts where possible.
- Do not share production credentials, API keys or admin passwords.
- Use a separate diligence branch or redacted repository if needed.
- Log access and revoke it after the review window.
- Check open-source licences before claiming proprietary ownership.
- Do not upload customer data into third-party diligence tools without data review.
Customer lists, personal data and DPDP risk
Customer lists are often more sensitive than founders realise. They may contain names, emails, phone numbers, purchase history, support tickets, employee contacts, user behaviour, pricing, renewal dates and complaints. Some of this may be confidential commercial information. Some may also be digital personal data.
The Digital Personal Data Protection Act, 2023 requires organisations to think about lawful processing, purpose, notice, consent or applicable grounds, security safeguards and rights of individuals. An NDA with an investor or partner does not by itself make personal data sharing compliant. If personal data is not required, share aggregated or anonymised data instead. If personal data is required, document the purpose, access controls, retention, deletion and breach notification process.
| Data item | Safer founder approach |
|---|---|
| Customer logos | Use only where contract or customer permission allows public reference. |
| Customer names | Share under NDA only when needed; consider anonymised customer categories first. |
| Email and phone lists | Avoid unless necessary; use redacted samples or aggregated metrics. |
| Support tickets | Remove personal identifiers and sensitive business content where possible. |
| Revenue by customer | Use coded customer names in early diligence and reveal identities later. |
| Health, finance or children-related data | Use enhanced legal review before sharing. |
NDA is not the same as a non-compete
Indian founders often try to put confidentiality, non-compete, non-solicit and IP ownership into one aggressive document. This can create enforceability risk. Section 27 of the Indian Contract Act makes agreements in restraint of lawful profession, trade or business void to that extent, subject to limited exceptions. A clause that protects specific confidential information is different from a clause that broadly stops a person from working in an industry.
For founders, employees, consultants and partners, the better drafting approach is to protect legitimate business interests: confidential information, trade secrets, customer relationships, employee non-solicitation, company property, IP, data and business opportunities. Avoid broad post-termination restrictions that read like a general ban on livelihood. The more tailored the clause, the more credible it is.
Practical NDA workflow for startups
| Step | Action | Owner |
|---|---|---|
| 1 | Classify information before sharing. | Founder or function head |
| 2 | Decide whether NDA is required or staged disclosure is enough. | Founder and legal/CS team |
| 3 | Use the correct NDA version: investor, vendor, employee, consultant, customer or M&A. | Legal/CS team |
| 4 | Sign before disclosure and store the signed copy. | Operations or founder office |
| 5 | Share through controlled links, not uncontrolled forwarding. | Founder or data-room admin |
| 6 | Track recipient, date, version and access level. | Data-room admin |
| 7 | Revoke access and request deletion when the purpose ends. | Operations or IT owner |
Founder mistakes to avoid
- Sending a sensitive deck first and asking for NDA later.
- Using one generic NDA for investors, contractors, employees, acquisition discussions and customer pilots.
- Defining confidential information so broadly that it includes public information and ordinary skills.
- Forgetting exclusions for independently developed or already known information.
- Sharing source code without checking IP assignment from founders and contractors.
- Sharing customer personal data when aggregated metrics would have been enough.
- Allowing onward disclosure to affiliates, advisers or portfolio companies without limits.
- Not recording who received which version of the deck or data room.
- Using overbroad non-compete clauses instead of focused confidentiality and non-solicit protection.
- Failing to revoke access after a deal, pilot or diligence process ends.
Which NDA version should a startup use?
A startup should not use one NDA for every relationship. The risk, disclosure pattern and negotiation power are different in each situation. A contractor receiving code access needs stronger IP, security and return-of-material clauses. A potential investor may accept only a lighter confidentiality framework at the data-room stage. A strategic acquisition discussion may need a mutual NDA, clean-team restrictions and rules on employee/customer contact.
| Scenario | Better NDA approach | Extra point to check |
|---|---|---|
| Investor diligence | Short NDA or data-room confidentiality terms after serious interest. | Do not disclose customer names, code or bank statements in the first cold outreach. |
| Vendor or agency | Confidentiality plus IP assignment, data handling and security obligations. | Make sure work product belongs to the company. |
| Consultant or adviser | NDA plus conflict, non-solicit and limited use of company material. | Check whether the adviser works with competitors or portfolio companies. |
| Enterprise pilot | Mutual NDA because both sides may share confidential information. | Separate pilot data, production data and customer security obligations. |
| M&A or strategic investment | Mutual NDA with no-contact, clean-team and announcement restrictions. | Control employee, customer and supplier communication tightly. |
| Employee or founder | Confidentiality inside employment/founder agreement, not only a standalone NDA. | Add IP assignment, return of property and access removal process. |
If confidential information is leaked: response checklist
A leak should be handled quickly and calmly. The first objective is to stop further disclosure. The second is to preserve evidence. The third is to understand whether the leak also involves personal data, customer contract breach, IP infringement, employee misconduct or cyber-security incident.
- Identify exactly what was disclosed, when, by whom and to whom.
- Preserve emails, access logs, download records, messages, data-room logs and screenshots.
- Disable links, revoke repository access and rotate credentials if technical information was exposed.
- Send a written notice requiring cessation of use, deletion, return and confirmation.
- Check whether customer contracts, DPDP obligations or security incident processes are triggered.
- Assess whether an injunction, damages claim, police complaint or platform takedown is appropriate.
- Update internal access controls so the same leak cannot repeat.
Do not respond only with an angry email. If the information is valuable enough to protect, preserve the evidence in a way that can support a legal notice, injunction request or settlement discussion. A founder’s reaction in the first 24 hours often decides whether the breach can be contained.
Frequently asked questions
Sources and legal references
- Indian Contract Act, 1872 on India Code: https://www.indiacode.nic.in/handle/123456789/2187
- Digital Personal Data Protection Act, 2023, MeitY PDF: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf
- Copyright Act, 1957 on India Code: https://www.indiacode.nic.in/handle/123456789/1367
- Specific Relief Act, 1963 on India Code: https://www.indiacode.nic.in/bitstream/123456789/1583/7/A1963-47.pdf
- Trade Marks Act, 1999 on India Code: https://www.indiacode.nic.in/handle/123456789/1991
Founder takeaway
A good NDA is not a fear document. It is a boundary document. It lets founders explore investment, partnerships, pilots and diligence without casually giving away the company’s most valuable information. Use it with staged disclosure, access control and clean records, and it becomes part of a serious startup governance system.
Need expert support?
BSA supports founders across India with ROC, FEMA, due diligence, fundraising readiness, and company secretarial execution.
