Security diligence fails in two common ways. The first is fear-driven: everything is framed as existential risk and the output is a generic control list that cannot be acted on in a deal model. The second is checkbox-driven: a report is treated as assurance and real gaps that block growth or create liability are missed. Practical underwriting sits between those extremes.
11.1 Security Posture Triage: “Minimum Bar” for Enterprise SaaS
In diligence, “security posture” becomes actionable when you treat it as a small set of capabilities that determine enterprise trust: governance, access control, vulnerability management, secure change, incident readiness, and evidence. The underwriting question is: can the company reliably meet buyer expectations without heroics, and can it improve fast enough to support the thesis?
Start by aligning on the segment bar. Enterprise buyers do not require perfection, but they do require consistent answers to questionnaires, credible evidence that controls operate, and basic technical hygiene. If the thesis includes enterprise expansion, “minimum bar” is underwriting-critical because it affects win rates, discounting, security-review cycle time, and renewal confidence.
Run posture triage fast and artifact-first. In the first week, you should be able to place the company into one of three categories. At bar: controls exist and operate consistently, with evidence. Near bar: core controls exist but are uneven or lightly documented; remediation is straightforward. Below bar: foundational gaps exist (identity, logging, vulnerability response, incident discipline) and will require a funded program before enterprise scaling is credible.
To keep triage practical, structure the first conversation as a walkthrough of “how you actually run security.” Ask who owns the program, what they review weekly or monthly, what tools generate findings, how findings are triaged, how fast critical issues are remediated, and how exceptions are handled. Then request evidence that matches the narrative. If a company says “we patch quickly,” ask for one recent critical patch and its timeline. If a company says “we have strong access controls,” ask to see how production access is granted and logged.
Request a minimum evidence set that reflects operations rather than policy intent: security ownership and org, a recent security questionnaire pack (or common-question answers), vulnerability management practices, incident response procedure (and any incident write-ups), logging/monitoring overview, and any audit reports with exceptions and management responses. If evidence is missing, treat it as a risk signal and bound conclusions explicitly.
Use a practical “minimum bar” checklist. Mark each item as present and operating, partially present, or absent, then translate gaps into commercial and operational consequences.
- Security ownership: a named accountable leader; clear responsibilities across engineering and IT.
- Asset awareness: a basic inventory of cloud accounts, production systems, and critical data stores.
- Access controls: MFA for privileged accounts; least privilege; controlled production access.
- Vulnerability management: routine scanning; a defined remediation cadence; rapid handling for critical issues.
- Secure SDLC: code review norms; CI checks; separation of environments; secrets hygiene.
- Logging and monitoring: centralized logs for key systems; alerts for suspicious activity and major failures.
- Incident response: a playbook, an on-call path, and evidence the team can execute under pressure.
- Data protection: encryption in transit/at rest; backups; reasonable key management practices.
- Vendor awareness: visibility into critical vendors/subprocessors and a basic risk review approach.
In triage, prioritize two classes of issues. Revenue blockers: gaps that routinely stall deals or force heavy discounting (SSO maturity, audit logs, unclear data segregation, lack of a credible SOC 2 path, weak security questionnaire response capability). Acute downside: gaps that materially increase breach likelihood or impact (weak privileged access, missing logging for admin actions, no patch process, secrets mismanagement, lack of incident readiness).
To interpret what you find, separate “missing control” from “missing evidence.” Missing controls can be dangerous, but missing evidence can be equally important in enterprise selling because buyers require proof. A company may genuinely do the right thing informally, but if it cannot produce evidence consistently, procurement friction will remain and audits will be painful. That means the remediation program is not only technical; it includes documentation and repeatable workflows.
Watch for posture failure modes that repeat across deals. Policy–reality gap: policies exist but enforcement is inconsistent. Tool–process gap: scanners exist but findings are not triaged and closed. Ownership gap: security is “everyone’s job,” which often means it is no one’s job. Questionnaire theater: sales answers are strong, but production access and logging are undisciplined behind the scenes.
When you find gaps, avoid fear language and convert them into underwriting actions. If the gap blocks the enterprise pipeline, quantify the pipeline at risk and estimate the time to close the gap. If the gap increases breach risk, define a funded program with clear deliverables and consider whether deal structure should include additional protections. Typical protection tools include stronger reps and warranties, covenants to complete specific remediation, cyber insurance review, and confirmatory diligence in a clean room when pre-close access is limited.
A useful output at the end of triage is a short “security posture narrative” that reads like underwriting, not like a security audit. It should state: Current bar position: at/near/below and why; Gating gaps: the few issues that block the thesis; Downside risks: the few issues that could create material incident exposure; and Remediation plan: sequenced initiatives with people, timing, and cost ranges. That narrative should feed the risk register and the first-year value-protection plan.
As a final step, assign every gap an owner and a verification method. Ownership prevents “everyone agrees” from becoming “no one delivers.” Verification forces specificity: a control is either operating with evidence, or it is still planned in practice.
11.2 Identity and Access: IAM Patterns, Privileged Access, Secrets
If you had to pick one domain that predicts both breach risk and enterprise sales friction, it would be identity and access. Most serious incidents involve compromised credentials, excessive permissions, or weak segregation of duties. Most enterprise buyers also evaluate trust through identity features: SSO, SCIM, role design, and audit logs. Underwriting should therefore assess IAM as both a security control system and a product capability.
Evaluate IAM in two planes. Customer-facing IAM: how customers authenticate, authorize, and govern users within the product. Internal IAM: how the company controls access to cloud infrastructure, production systems, and sensitive data. A weakness in either plane can be material, and the remediation path differs.
Customer-facing authentication: For enterprise SaaS, the minimum expectation is SSO via SAML or OIDC and strong authentication options for non-SSO users (MFA, sensible password policies). Go beyond “we support SSO” and ask: who uses it today, which IdPs are supported, and whether SSO is repeatable or bespoke. Bespoke SSO is not only an engineering cost; it extends sales cycles and turns every enterprise deployment into a mini-project.
Customer-facing authorization: Authorization is where many products become “enterprise-fragile.” Ask how roles and permissions are modeled, whether permissions are granular enough for real workflows, and whether the model supports least privilege without making the product unusable. Look for clarity: a small set of roles that map to customer personas, plus the ability to delegate and scope access. Overly coarse roles create a false choice: restrict too much and adoption stalls; grant too much and security posture degrades.
Enterprise governance also requires scale features. Ask about group-based permissions, delegated administration, and lifecycle management. If SCIM provisioning is absent and deprovisioning is manual, customers will raise audit concerns and your churn risk increases when champions change. Even if SCIM is a roadmap item, diligence should validate feasibility and timing because it often shows up as a late-stage procurement blocker.
Internal privileged access: Most buyer-facing assurances collapse if internal access is sloppy. Ask how many people have production access, how access is granted and revoked, and whether MFA and centralized identity are enforced across internal tools. A healthy posture includes: least privilege cloud roles, short-lived access where possible, periodic access reviews, and a “break-glass” emergency path with strong logging. Broad, long-lived admin access is common, risky, and usually fixable quickly with focused effort.
Also evaluate the “human path” to customer data. Who can access production data to troubleshoot? Under what approvals? Is access logged? Enterprise customers increasingly require clear answers here. If support staff can query production data freely, you have both a privacy and security exposure. The remediation may include stricter approvals, data masking, read-only support tooling, and better in-product diagnostics so support can solve issues without looking at customer content.
Secrets: Secrets management is high-signal because it is both common and consequential. Ask where secrets live, how they are rotated, and how they are used in production. Mature answers reference a secrets manager, rotation practices, and scanning to prevent leakage. Immature answers include secrets in repos, shared documents, or unmanaged environment variables without ownership. Even in mature teams, secret debt often accumulates during rapid growth; diligence should identify whether the company is paying it down or ignoring it.
Ask about key management and encryption boundaries at a practical level. Do they use a managed key service? Who can rotate keys? Is encryption consistent across storage, backups, and data exports? You are not trying to certify cryptographic correctness. You are trying to understand whether keys and secrets are governed as part of normal operations.
Use quick workflow tests to validate reality: how a new employee gains production access, how a departing employee is deprovisioned, how emergency access is executed, and how a customer admin provisions and deprovisions users. These workflows reveal whether access is governed or improvised, and they often uncover “shadow systems” where access persists outside the main identity provider.
Common IAM red flags to document explicitly:
- Shared accounts: shared admin credentials in internal tools or customer environments.
- Overbroad permissions: “everyone is admin” patterns due to weak role design.
- Weak deprovisioning: manual and inconsistent removal of employee or customer-user access.
- Secrets sprawl: credentials scattered across repos/CI/docs with little rotation discipline.
- Poor admin logging: limited audit trails for privileged actions and sensitive data access.
Translate IAM findings into levers. Customer-facing gaps are often growth blockers and belong in the value-creation backlog because they unlock enterprise adoption and reduce support load. Internal IAM gaps are risk items and belong in a first-100-day remediation plan. Both are usually well-scoped programs with clear deliverables, making them suitable for pricing and sequencing in the model.
11.3 Data Privacy: Retention, Deletion, Residency, and Customer Commitments
Privacy diligence should not begin and end with “GDPR compliant.” A practical approach treats privacy as a data lifecycle problem: what data is collected, where it flows, how it is accessed and shared, how long it is retained, how it is deleted, where it is stored geographically, and what has been promised to customers in contracts and DPAs.
It also helps to separate privacy from security. Security is about preventing unauthorized access and limiting blast radius when controls fail. Privacy is about appropriate use and handling: minimization, purpose limitation, transparency, retention, deletion, and contractual/regulatory commitments. The same technical controls support both, but the diligence questions differ.
Start with a right-sized data map. You do not need every schema. You do need clarity on: Data types: customer content, metadata, user identifiers, logs, analytics events, and any sensitive categories (health, payment). Data locations: production stores, warehouses, third-party tools, support systems, and backups. Data movement: exports, integrations, and subprocessors. Without this map, privacy promises are hard to validate and the company will struggle to answer customer and regulator questions consistently.
Retention: Ask for default retention by category (content, logs, analytics, support artifacts, backups) and whether it is configurable by customer or tier. Undefined retention increases storage cost, amplifies breach impact, and creates compliance friction. Underwrite whether defaults match buyer expectations and whether exceptions can be handled without one-off engineering. If the company sells into regulated verticals, retention often becomes part of the product: customers want explicit controls and reports, not informal statements.
Deletion: Deletion is where policies most often diverge from reality. Underwrite deletion end to end: what triggers it, which systems are affected (databases, caches, search indexes, warehouses, logs), and how completion is verified. Also ask how backup retention is handled and how customer commitments reflect that reality. The key questions are Capability: can deletion be executed within a defined window, and Proof: can the company demonstrate completion with logs, job records, or attestations?
In practical terms, many platforms delete primary records quickly but retain derived data in analytics or search systems longer. That can be acceptable if contracts and policies are aligned and if the company can explain the lifecycle clearly. It becomes a risk when customers believe “delete means delete everywhere immediately” and the company cannot meet that expectation. In that case, remediation may involve both technical work (lineage, purge jobs) and commercial work (standardizing commitments and language).
Residency: If international expansion or regulated segments matter, residency becomes a market-access requirement. Ask where data is stored today, whether regional deployment is supported, how tenants are provisioned by region, and how analytics pipelines and support access avoid cross-region leakage. Residency is rarely solved by “spin up a region.” It requires operational controls: region-specific logging, region-aware backups, and a clear approach to cross-region support access and incident response.
Customer commitments: Privacy diligence must include contract reality. Request standard DPAs and security addenda plus a sample of bespoke commitments from top customers. Then cross-check promised retention/deletion/residency terms against operational reality. Misalignment is both a trust risk and a future negotiation cost, and it should be addressed through contract standardization, operational improvements, or both.
A practical “commitment cross-check” method keeps this from becoming an endless legal exercise. Step through: what the standard DPA says, what top customers have asked to change, whether the product can meet those asks without one-offs, and how often exceptions are granted. Frequent bespoke privacy terms are a sign that the company has not productized trust for its target segment.
Use a data lifecycle checklist to keep diligence grounded and to surface where evidence exists versus where answers are aspirational:
- Collection: what data is collected and why.
- Classification: identification of sensitive data categories and required handling.
- Storage: primary stores plus downstream analytics/support systems.
- Access: who can access data, under what conditions, with what logging.
- Sharing: subprocessors/integrations and governance around them.
- Retention: defaults by category and customer configurability.
- Deletion: end-to-end deletion and verification, including downstream stores and backups.
- Residency: regional controls to meet customer requirements.
Translate privacy findings into investor actions. Procurement-facing gaps (retention clarity, deletion proof, residency) are often growth blockers and belong in the value-creation backlog. Exposure and impact amplifiers (excessive retention, weak access logging, unclear subprocessor governance) are risk items that should be priced into the first-year plan and tracked like any other remediation program.
11.4 Readiness for SOC 2 / ISO / HIPAA / PCI (as Applicable)
Compliance should be treated as market access, not a trophy. The underwriting question is: what assurances do current and target customers require, what does the company have today, and how hard will it be to obtain and maintain what is needed as the business scales?
Scope “as applicable” first. SOC 2 Type II is often the baseline for enterprise SaaS in the US; ISO 27001 is common in international procurement; HIPAA applies when the product processes protected health information and customers require BAAs; PCI applies when the company stores, processes, or transmits payment card data or materially participates in the payment flow.
SOC 2: If a report exists, read it. Verify scope (systems and environments covered), period, and trust principles. Review exceptions and management responses; recurring exceptions in access control, change management, or logging can be more concerning than having no report. Also review what the auditor describes as the “system” so you know whether important components are excluded. If the report includes carve-outs or relies heavily on third parties, confirm that subservice responsibilities and evidence are well managed.
Interpret SOC 2 through a practical lens. A clean report can reduce friction, but it does not eliminate risk. Pay attention to the control areas that correlate with incidents and breaches: privileged access, change control, vulnerability response, and logging. Also note complementary user entity controls; if customers must configure something for the controls to be effective, enterprise implementations may require more guidance and support than assumed.
If SOC 2 does not exist, assess the path. Readiness depends on whether foundational controls already operate (access control, change management, incident response, vendor management) and whether evidence can be produced consistently. Many teams can implement controls faster than they can implement evidence discipline; underwriting should reflect that reality. A credible plan usually includes: scoping systems, implementing controls, running them consistently, and then completing the evidence period required for a Type II opinion.
ISO 27001: ISO is governance-heavy. Readiness depends on whether the company can run an ISMS: risk assessments, policy ownership, internal audits, and management review. Technical controls matter, but ISO often fails due to weak process ownership and documentation discipline rather than “bad engineering.” If ISO is strategically important, confirm leadership commitment and the ability to maintain the program through product changes and growth.
HIPAA: Focus on scope clarity (where PHI flows), access control, audit logging, breach response readiness, and the ability to execute BAAs and customer-required safeguards. If healthcare expansion is part of the thesis, confirm that required auditability and access restrictions are feasible in the current architecture and that support workflows do not rely on unrestricted access to PHI.
PCI: Treat PCI as a scope-management topic. If the company touches card data, ask whether it stores card data, whether tokenization is used, and whether payments are routed through a compliant provider. Minimizing PCI scope can be a high-ROI architectural choice that reduces audit burden, lowers breach exposure, and protects margin.
Across frameworks, translate readiness into a plan: Current state: what exists today; Top blockers: the few gaps that prevent certification or customer acceptance; Timeline: realistic time to achieve, including evidence windows; Cost: people and vendor costs; Commercial implication: which segments or deals require it. This is where compliance stops being abstract and becomes an underwritable investment program.
Finally, be explicit about what diligence can and cannot conclude. P&TD is not a penetration test or a formal audit. Distinguish Evidence-backed conclusions: from walkthroughs and artifacts, and Assumptions: where access was limited. Where uncertainty is material, propose mitigations: confirmatory diligence, contractual protections, insurance review, and a funded first-100-day control uplift program. This is how security, privacy, and compliance become practical underwriting rather than fear.
