This document outlines the baseline cybersecurity expectations typically applied in venture-stage due diligence for Series A and Series B software companies. It reflects recent changes in the threat landscape, including stronger expectations around SaaS identity controls, browser-based phishing and session theft, AI-assisted development, agentic AI systems, prompt injection, and AI-driven software supply chain risk.
Minimum expectations have moved beyond basic MFA and cloud hygiene toward phishing-resistant identity controls, broader SaaS coverage, and stronger monitoring of developer tooling and browser-based attack paths. AI usage also now requires explicit governance because coding assistants, agent frameworks, and third-party models can introduce prompt injection, secret leakage, backdoored components, and hallucinated dependencies into production environments.
Baseline expectations:
Governance and ownership
- A named owner is accountable for security and privacy, even if the company does not yet have a full-time security leader.
- Leadership reviews material security risks periodically and can describe the company’s top risks and remediation priorities in plain language.
- Basic written policies exist for access control, acceptable use, incident response, vendor management, and AI use where applicable.
Identity and access
- MFA is enabled for all critical systems, including email, cloud consoles, code repositories, CI/CD, identity providers, and major SaaS platforms.
- Privileged access is limited to those who need it, and access is removed promptly when people change roles or leave.
- Companies should be moving toward phishing-resistant authentication for privileged users, especially passkeys or FIDO-based methods where supported.
- Browser and session-based threats are considered part of the identity program, with attention to adversary-in-the-middle phishing, stolen session tokens, malicious extensions, and consent-based attacks.
Devices and endpoints
- Company devices used for development or access to sensitive systems are managed and inventoried.
- Full-disk encryption, screen lock, automatic patching, and endpoint protection are enabled.
- Unmanaged or BYOD access to production or administrative systems should be tightly restricted or subject to compensating controls.
Cloud, infrastructure, and resilience
- Production is separated from development and testing environments.
- Internet exposure is limited to necessary services; databases and internal services are not exposed directly without strong justification.
- Secrets are stored in a proper secrets manager rather than code, documents, or chat tools.
- Backups exist for critical systems and data and restore testing has been performed within the last 12 months.
Software development and AppSec
- Code changes to important systems require human review before deployment.
- Dependency scanning, vulnerability scanning, and other basic CI/CD security checks are in place for the main codebase and deployment pipeline.
- Critical or high vulnerabilities are tracked and remediated on a defined timeline.
- Independent security testing, such as a penetration test or targeted application review, has been performed when risk and maturity justify it.
Data protection and privacy
- Sensitive data is encrypted at rest and in transit.
- The company can describe what sensitive data it stores, where it lives, and how long it is retained.
- Privacy disclosures and contractual commitments are aligned with actual practices.
- The company has a practical process for deletion, export, and other common customer or user privacy requests.
Vendor and SaaS risk
- Key vendors are inventoried, especially those handling customer data, authentication, payments, communications, analytics, or production infrastructure.
- Material vendors are reviewed using reasonable diligence such as security documentation, SOC 2 reports, or equivalent evidence.
- AI vendors, coding assistants, agent platforms, and model providers are treated as part of the vendor risk program, not as exceptions.
Detection and incident response
- Logging exists for important systems, including identity, cloud, and production environments.
- The company has a simple incident response plan covering roles, communications, containment, and escalation.
- Prior incidents, if any, have documented remediation and lessons learned.
AI-specific minimum expectations:
AI use governance
- The company can clearly describe where it uses AI in the product, in internal operations, and in software development.
- Employees are not permitted to place secrets, production credentials, regulated data, or large volumes of customer data into unapproved public AI tools.
- There is a basic policy for approved AI tools, approved data types, and prohibited use cases.
AI-assisted development and vibe coding
- All AI-generated code, configuration, infrastructure-as-code, and security-sensitive logic receive human review before deployment.
- AI-generated changes are subject to the same scanning and testing requirements as human-written code.
- The company has controls to reduce hallucinated or malicious dependencies, including version pinning, package review, and dependency scanning.
- Security-sensitive areas such as authentication, authorization, cryptography, IAM policies, and firewall rules are not accepted from AI tools without especially careful review.
AI agents and autonomous systems
- AI agents are inventoried along with the systems, data, and actions they can access.
- Agents use scoped credentials and least privilege permissions rather than broad production access.
- High-risk actions such as fund movement, IAM changes, destructive data actions, or production configuration changes require human approval before execution.
- Agent actions are logged and reviewable, and anomalous behavior can be investigated.
- Publicly exposed agent infrastructure, MCP-style servers, and agent marketplaces receive special scrutiny because recent reporting has highlighted exposed unauthenticated services and malicious skills in the ecosystem.[1]
Prompt injection and model misuse
- AI features and agents that read untrusted content, including emails, tickets, web pages, and uploaded documents, must account for prompt injection risk.
- The company uses practical mitigations such as restricted tool access, allow-listed actions, human confirmation for risky tasks, and controls on what instructions can trigger real-world actions.[8][1]
- Prompt and agent logs are handled as sensitive records when they may contain secrets, proprietary code, or customer information.[1]
Red lines:
The following issues are likely to create immediate diligence concerns:
- No MFA on email, cloud, code repositories, or production administration.
- Broad or poorly controlled production access, especially shared admin accounts.
- No tested backups for critical systems.
- Secrets stored in source code, tickets, shared documents, or AI chat histories.
- Heavy use of AI-generated code without human review or security scanning.
- AI agents with broad production or financial permissions and no approval gates.
- Customer or sensitive company data sent to AI providers without clear contractual and governance controls.
- Unvetted third-party models, plugins, skills, or packages introduced into production workflows, especially from public marketplaces or registries.
- A significant security incident with weak remediation or poor transparency.
What founders and management should prepare before diligence:
Founders and management should be ready to describe their main systems, data types, cloud footprint, access controls, backup approach, incident handling, major vendors, and current use of AI in both the product and internal workflows. They should also be prepared to explain how AI-generated code is reviewed, how agents are permissioned, and how sensitive data is kept out of unapproved AI tools.
How this is applied:
These expectations are meant to be practical for growth-stage startups rather than enterprise-perfect. We’re here to help you build a secure, scalable business. If you have questions about these expectations or want guidance on meeting them cost-effectively, please reach out to us before the formal diligence process begins.
The core question in diligence is whether the company understands its risks, has credible baseline controls in place, and is avoiding a small set of preventable failure modes that have become more important in 2025 and 2026.
Our commitment:
We will work with you to find pragmatic, founder-friendly solutions that balance security with velocity. Strong security is an enabler, not a blocker—and we’re invested in your success.
.
- Minimum Cybersecurity Expectations for Series A/B Companies - May 12, 2026
- What You Want in a Non-executive Chair - December 20, 2024
- Exit Advice from “Exits – Traps and Triumphs” CEOs - June 21, 2018
- Buying In – Cybersecurity Risk and Due Diligence - April 17, 2018
- A Panel of CEOs Speaking About Exits to CEOs and Business Owners - March 28, 2018
- What Worries CEOs When They Exit - January 1, 2018
- Cyber Security Problems in M&A – Real, Not Imagined, and Hitting Hard - July 17, 2017
- Cyber Security Summits – Great Content; Deep Learning; Excellent Connections - May 26, 2017
- The CEO at Exit: Prepare; Talk; Listen; Empathize - May 5, 2017
- Be Prepared! Because “Startups get bought, not sold” - November 20, 2016