Defusing NDA Roadblocks in Tech Diligence: How to Handle “We Can’t Share That Under NDA” in English

Introduction

In technology due diligence, you will often hear a firm “We can’t share that under NDA.” This phrase feels final, but it usually masks a mix of risk concerns, internal policies, and time pressure. Your goal is to diagnose what sits behind the refusal, then calmly reframe your request so the other side can say “yes” without feeling exposed. This lesson gives you a practical, step‑by‑step method to keep the conversation moving, protect the relationship, and still obtain decision‑grade information.

The flow we will follow mirrors a real diligence call: first, diagnose the refusal and intent; second, reframe with purpose, safeguards, and a minimal ask; third, offer structured access alternatives and negotiate scope–timeline trade‑offs; finally, close properly with documentation, next steps, and, if necessary, a respectful escalation path. Throughout, use precise, low‑friction English to lower temperature and reduce friction.

1) Diagnose the NDA Refusal Type and Intent

Before replying, pause and identify what kind of refusal you are hearing. The same sentence can hide very different risks, and each risk calls for a different response. Listen for the pattern, the speaker’s role, and the implicit fear.

• Pattern 1: “Policy Gate”

  • Typical signals: “Legal won’t allow this,” “Company policy prohibits sharing code,” “Our compliance team needs to approve.”
  • Underlying risk: A formal rule or past incident has created a blanket prohibition. The speaker (often an engineering lead or product manager) may not have discretion. The fear is violating an internal control, not necessarily you misusing the data.

• Pattern 2: “Crown Jewels”

  • Typical signals: “That’s our secret sauce,” “We don’t disclose algorithms,” “This is highly sensitive IP.”
  • Underlying risk: Exposure of core intellectual property that could reduce competitive advantage. The fear is leakage—even accidental—beyond the diligence team.

• Pattern 3: “Attack Surface”

  • Typical signals: “Security won’t permit access,” “We can’t share production credentials,” “That would create a vulnerability.”
  • Underlying risk: Operational security and regulatory exposure. The fear is creating a new attack vector or violating security certifications.

• Pattern 4: “Time and Scope Overload”

  • Typical signals: “We can’t do that within the timeline,” “Too much effort for diligence,” “Our team is at capacity.”
  • Underlying risk: Execution bandwidth and schedule. The fear is missing business milestones or over‑committing engineers.

To diagnose intent, consider:

• Who is speaking? An engineering lead may be risk‑aware but solution‑oriented; legal counsel signals policy constraints.
• How categorical is the language? Absolute language (“never,” “cannot”) indicates policy or IP concerns; qualified language (“not right now,” “not in this form”) indicates flexibility.
• What is the context? Early‑stage calls favor general explanations; later stages may allow deeper access with controls.

This diagnostic step keeps you from arguing about the wrong thing. Once you know the category and fear, you can calibrate your next move precisely.

2) Reframe with Purpose + Safeguard + Minimal Ask

When faced with “We can’t share that under NDA,” your next move is to reduce perceived risk while preserving your information objective. The most effective structure is: state your purpose, specify explicit safeguards, and narrow to a minimal ask. This shows intent, control, and restraint.

• Lead with Purpose

  • Be specific about what decision your team must make and why the requested information is necessary. Replace vague requests with targeted, outcome‑linked descriptions. This reassures the other side that you are not fishing and that the request has a legitimate diligence function.
  • Keep the purpose one or two sentences, tied directly to a risk area—security posture, IP ownership, scalability, regulatory fit, or financial exposure. Clarity reduces suspicion.

• Name Concrete Safeguards

  • Reference explicit controls you already observe: a signed NDA with defined use, restricted access to a small diligence team, no local downloads, short‑lived access, and logging. If relevant, mention counsel oversight or banker‑hosted data rooms.
  • Use neutral, process‑focused wording to show you will reduce the practical chance of leakage or misuse. The more tangible your safeguards sound, the more credible they feel.

• Propose a Minimal Ask

  • Reduce the scope to the smallest unit that can support a decision, such as a subset of files, a single environment, a specific report, or a limited time window. Small requests are easier to approve and set a cooperative tone.
  • Tie the ask to a clear, short timeline. Time‑bounded access feels safer and helps people secure internal approvals.

This three‑part structure lowers friction on both sides. It reframes you as a partner in risk management, not an adversary. Keep your language concrete, neutral, and brief. Your aim is to make “yes” feel reasonable and low‑risk.

3) Offer Structured Alternatives and Negotiate Trade‑offs

If the reframe still meets resistance, move to a menu of practical access alternatives. Each option addresses a different refusal pattern while preserving your ability to assess risk. Introduce options sequentially, from least intrusive to more direct, and link each option to the underlying concern.

• Redactions and Aggregation

  • For policy or IP concerns, suggest redacted documents (e.g., masking customer names, salt values, or secrets) or aggregated metrics instead of raw data. Emphasize that you are focused on patterns, not identities.
  • Benefit: Satisfies control needs while letting you evaluate substance (architecture choices, defect trends, incident frequency).

• Live Walkthroughs and Screen‑Sharing

  • For crown jewels and security concerns, propose a guided session where their engineer shares screen, navigates code modules, pipelines, or dashboards, and answers your targeted questions. No files leave their environment.
  • Benefit: High trust, immediate answers, minimal risk of data exfiltration.

• Sandbox or Read‑Only Environment

  • For attack surface risks, ask for a non‑production sandbox with masked data, or read‑only access with audit logs. Limit permissions, IP‑whitelist your team, and set access windows.
  • Benefit: Preserves operational security while allowing you to validate workflows, configs, or performance claims.

• Third‑Party Escrow or Independent Verification

  • For deep IP or legal policy blocks, suggest a reputable third‑party to review artifacts under stricter controls (escrow, VDR with watermarking, code‑scanning outputs). You receive a verification letter or high‑level findings instead of raw assets.
  • Benefit: Builds confidence via neutral verification, common in competitive or highly sensitive deals.

• Staged Scope with Timeline Trade‑offs

  • When bandwidth is the barrier, propose a phased plan: quick indicators now (architecture map, incident summary), then deeper verification later (select code modules, DR test evidence). Offer to narrow scope in exchange for faster delivery.
  • Benefit: Respects capacity while keeping critical path decisions on schedule.

When you present alternatives, signal flexibility without diluting your objective. Link each option to the specific risk you diagnosed. Keep the discussion solution‑oriented: you are not demanding a single method; you are offering a set of safe routes that lead to the same diligence answer. If one path is blocked, pivot to the next without friction.

For trade‑offs, be explicit about dependencies. Specify which items are required before sign‑off and which can move to confirmatory diligence. This transparency reduces defensiveness because it clarifies stakes and timing.

4) Close with Documentation, Next Steps, and Polite Escalation Path

Once you reach a workable path, close the loop professionally. Document what you agreed, define what will happen next, and outline an escalation path that protects rapport with the engineering lead.

• Confirm the Outcome in Writing

  • Summarize the decision, the format of access, the scope, the safeguards, and the timeline. Use concise bullets. Restate the purpose to show alignment.
  • Include any conditions (e.g., counsel’s approval, sanitized dataset preparation, or specific tools to be used). Clarify who is accountable for each step.

• Set Clear Next Steps

  • Lock in dates for the walkthrough, sandbox access, or third‑party review. Provide your team’s contact list and any technical details (IP ranges, accounts to whitelist, VDR folder names). Shorten cycle time by being operationally ready.

• Define a Respectful Escalation Path

  • If approvals stall, explain that you will route a narrow question to bankers or counsel for a policy interpretation, while keeping the engineering lead informed. Emphasize that you prefer to resolve items at the working level first.
  • This approach preserves relationship equity: you are not “going over” someone; you are widening the lane so they can stay focused on delivery.

• Record Management Representations and Issues

  • For anything that remains closed or partially closed, request a management representation stating what was not shared and why, and the impact on scope. Add this to an issue log with status and target resolution.
  • This creates a professional trail, reduces later disputes, and pre‑empts defensive reactions to your findings. If later you qualify a risk because access was limited, your documentation will show that you asked, proposed safeguards, and offered alternatives.

• Pre‑empt Defensive Pushback on Findings

  • When you draft your findings, link each risk statement to the evidence format you received (e.g., “verified via live walkthrough and redacted logs”). Note any limitations that increased residual risk. The tone should be factual, not accusatory.
  • By documenting process and constraints, you reduce emotional responses and keep the discussion focused on actions rather than blame.

Putting the Flow Together in Practice

This approach works because it respects both the seller’s risks and your diligence duties. The sequence is simple but powerful:

1. Diagnose the refusal pattern and intent. You are listening for the fear behind the “no.”
2. Reframe with a clear purpose, named safeguards, and the minimal ask. You are making “yes” easy.
3. Offer structured alternatives and negotiate scope–timeline trade‑offs. You are providing multiple safe routes to the same decision.
4. Close by documenting agreements, setting next steps, and defining a polite escalation path. You are preserving rapport and protecting the record.

Throughout, keep your English neutral, specific, and operational. Avoid emotional language or abstract requests. Anchor each statement in a diligence decision, a concrete safeguard, or a time‑boxed plan. This keeps the conversation professional and efficient.

Why This Works in Real Diligence Calls

• It is psychologically safe. By showing purpose and safeguards first, you reduce ambiguity, which is the main driver of “NDA fear.”
• It is operationally realistic. Alternatives like redactions, walkthroughs, and sandbox access map to how engineering teams actually work, so approvals are more likely.
• It preserves momentum. Negotiating scope–timeline trade‑offs acknowledges seller constraints while protecting your critical path to close.
• It protects relationships. Respectful escalation paths and crisp documentation show you value the sell‑side team’s time and responsibilities.

Adopting this structure will help you convert categorical refusals into controlled access, keep diligence on schedule, and maintain a constructive tone with the engineering lead. You will obtain the information you need without sounding adversarial, and you will leave a clean, professional record that supports your findings and your deal decisions.