Are you ready for investor technical due diligence?

Funds' legal-tech DD confirms a clean chain of title to all IP. The three usual gaps: founders who wrote code BEFORE the company existed (pre-incorporation IP does not transfer automatically — it needs an express assignment, typically signed at incorporation or first financing, and it's the single most common finding); contractors and agencies, who in most jurisdictions retain ownership of what they write unless it is expressly assigned (a 'work-for-hire' label alone is often insufficient for software); and missing assignment clauses in employment contracts — employee-created work usually vests in the employer by default, but the explicit clause removes the argument. Un-assigned or ambiguously-assigned IP is a frequent reason for a delayed close, a price chip, or a specific-indemnity/holdback, so it's treated as a hard fail here.

Open-source licence compliance is a standard DD line: strong copyleft (GPL/AGPL) linked into a proprietary codebase can create disclosure obligations, and even permissive licences carry attribution requirements. Reviewers expect a software bill of materials / dependency inventory and evidence you track licences (e.g. via an SCA tool). AGPL in a SaaS backend is a particular flag. Unknown or unmanaged licence exposure reads as a governance gap.

DD checks that business-critical registrations and accounts (domains, DNS, the source-code org, cloud/root accounts, app-store and payment accounts, trademarks) are held by the company with administrative control that survives any individual's departure — not tied to a personal Gmail or a single founder's login. Personal ownership of critical accounts is both a key-person risk and a title issue.

Investors near-universally require founder reverse-vesting (commonly 4 years with a 1-year cliff, sometimes with acceleration terms) so departed founders don't retain a large dead-equity stake. Absent or already-fully-vested founder equity is a standard negotiation point and can be imposed as a condition of the round.

Technical DD assesses key-person / bus-factor risk: single points of failure in knowledge (one engineer who alone understands the architecture, holds the only production credentials, or maintains an undocumented critical system). Mitigations reviewers look for are documentation/runbooks, more than one person with production access and context, and cross-training. A bus factor of one on a core system is a material risk that gets priced or made a condition.

DD reviews employment/contractor agreements for confidentiality, IP-assignment and (where enforceable) restrictive covenants. Missing or informal arrangements — especially with early contributors and offshore contractors — leave trade secrets and the IP chain exposed and are commonly flagged for clean-up before close.

A technical DD reviewer will typically run (or ask for) a vulnerability scan of your public surface. Internet-facing services running software with known, exploitable CVEs undercut any claim of a mature security posture. Our in-depth scan fingerprints internet-facing services and flags known vulnerabilities, so a detected CVE is citable evidence against a 'no known vulnerabilities' claim in the data room.

Encryption-in-transit is part of the baseline a reviewer expects: TLS on every endpoint, modern protocol versions (1.2/1.3) with legacy 1.0/1.1 disabled, valid certificates and HSTS. Our passive and in-depth scans observe exactly these, so a weak or missing TLS configuration contradicts a 'we encrypt everything in transit' claim.

SPF, DKIM and an enforced DMARC policy (p=quarantine or p=reject) stop attackers forging your domain in the From address. A DMARC policy of p=none (or none at all) provides no enforcement. It's a small, high-signal hygiene item a reviewer checks in seconds; our scan reads these DNS records directly, so a missing or unenforced DMARC contradicts a 'we follow email security best practice' claim — and it's the one control here you can fix in an afternoon.

MFA on privileged accounts — cloud root/admin (AWS/GCP/Azure), the source-code org (GitHub/GitLab), CI/CD, and production access — is a minimum-bar control. Credential theft and repo compromise are common startup incidents, so its absence is a clear red flag a technical reviewer will call out and often make a condition of the round. Enforcement via SSO/conditional-access policies, with app-based or hardware factors rather than SMS, is preferred.

Internet-exposed management (RDP/3389, SSH/22) and datastores (MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch) dramatically enlarge the attack surface, and exposed unauthenticated databases are a recurring cause of startup data breaches. Our exposure and in-depth scans enumerate open ports, so a sensitive service reachable from outside contradicts a claim that production access is properly restricted.

Secrets management is a standard DD probe: credentials should be held in a secrets manager or environment configuration (not committed to the repo, including its history), scanned for with a secret-detection tool, scoped least-privilege, and rotated on offboarding or suspected exposure. Hard-coded or historically-committed secrets are a frequent, easily-evidenced finding and signal weak engineering hygiene.

For B2B startups, SOC 2 Type II or ISO 27001 is increasingly a sales prerequisite and a DD signal of security maturity. Reviewers accept an in-progress posture — a defined scope, a compliance platform in place, policies drafted, and a target audit date — as evidence of intent. A total absence with no plan, in a company selling to enterprises, is a gap that affects both the DD narrative and the revenue model.

DD confirms UK/EU GDPR fundamentals: a published privacy notice, documented lawful bases, records of processing, and Article 28 data-processing agreements with each subprocessor (cloud, email, analytics, payments, support). For companies handling special-category or large-scale data, DPIAs and international-transfer mechanisms (e.g. SCCs/UK IDTA) are also checked. Gaps here create regulatory exposure the investor would inherit.

Reviewers look for data governance: an inventory/data map of personal and customer data, its storage locations and flows, retention periods, and role-based access on a least-privilege basis. This underpins breach response, data-subject requests and customer security questionnaires. Ad-hoc, unmapped data with broad internal access is a maturity and compliance flag.

DD expects all code in version control with branch protection and peer review (not code on a single laptop), plus a defined, tested backup regime for code and production data with sensible RPO/RTO. Reviewers specifically ask whether restores have been tested — untested backups are treated as no backups. This underpins both resilience and the bus-factor mitigation.

Software-composition management — a dependency inventory (SBOM), automated vulnerability alerting (e.g. Dependabot/Renovate/SCA), and a process to triage and update vulnerable components — is a standard DD line. Outdated, known-vulnerable dependencies are among the easiest findings for a reviewer and speak to ongoing maintenance discipline, not just a point-in-time scan.

Source-code (or SaaS) escrow is a contractual continuity mechanism enterprise/regulated customers may require, releasing code or a running environment on defined trigger events (insolvency, sustained outage). DD also looks for a basic business-continuity/disaster-recovery plan: documented recovery steps, defined RTO/RPO and provider redundancy. You needn't already have escrow in place, but being able to offer it — and having a DR plan — signals operational maturity.