Building a Security Program from Scratch at a Seed to Series B Company

Security at a SaaS company is a sequence of investments, each one sized to match where the business actually is, and each one building on what came before. Skip a step or bolt something on late and the debt compounds: a hardcoded secret or a sloppy IAM policy from the earliest days of the company takes exponentially more effort to unwind once the infrastructure has grown around it. This piece maps what that sequence actually looks like, stage by stage, from seed through Series B.

What "good enough" security looks like at the seed stage

At seed, the company has an MVP in market, maybe a few hundred thousand in revenue, and an engineering team you could fit around one table. Every hour spent on security is an hour not spent shipping the feature that gets the next round closed. The right question to ask is "are we shipping anything critically broken," well before "are we compliant."

That's the frame: hygiene over compliance. A seed-stage company doesn't need a SOC 2 report. It needs to not leak customer data through a misconfigured S3 bucket or a debug endpoint someone forgot to remove.

A handful of things actually matter here, and they're all cheap relative to what they prevent:

• MFA enforced across every service and internal tool, no exceptions for "just the staging environment"
• Secrets management from day one; no API keys or database credentials sitting in a Git repo, because retrofitting a secrets manager into infrastructure that's already grown around hardcoded credentials is a multi-week project later instead of an afternoon now
• Dependency scanning wired into CI/CD, so a known-vulnerable library gets flagged before it merges, not after
• Least-privilege IAM, no shared logins, and an actual offboarding checklist for when someone leaves
• Logging and alerting sufficient to know something went wrong, even if the response to that alert is a human checking a dashboard manually

Just as important is what to skip. Don't buy enterprise security tooling nobody on a five-person engineering team has time to configure properly. Don't chase SOC 2 before the underlying processes are stable enough to document consistently. And don't commission a penetration test on a product whose core architecture is still changing week to week; you'd be paying to have last month's version tested.

The underlying principle here: at this stage, the process is the control. A written offboarding checklist that someone actually follows does more than an expensive access-management platform nobody configured correctly.

How the Series A sales cycle forces a security reckoning

Somewhere around Series A, once ARR starts crossing the seven-figure mark, the pipeline changes shape. Enterprise prospects start showing up, and they don't come alone. They come with security questionnaires, vendor risk assessments, and a request for compliance documentation that didn't exist six months earlier.

This is usually the first moment a founder feels security as a revenue problem rather than a technical one. A deal stalls not because the product doesn't work, but because nobody can answer a lengthy spreadsheet about data retention policies and incident response procedures.

The instinct at this point is usually wrong twice over. Founders either answer each questionnaire manually and inconsistently, which creates real liability when answers contradict each other across deals, or they buy some point solution, slap it on the sales deck, and hope the box gets checked. A vulnerability scanner rebranded as "penetration testing" satisfies neither the sharper auditors nor the more sophisticated enterprise buyers who know the difference.

The better response: treat that first enterprise security review as a diagnostic. It's telling you, for free, exactly which controls are missing. Series A is also the right moment to start the SOC 2 process, not because any law requires it, but because enterprise procurement increasingly assumes it exists, and the process of preparing for it forces the conversations that should've happened already: what data do you actually hold, who can access it, and how is it protected.

Two flavors of SOC 2 matter here. Type I is a point-in-time attestation that the controls exist, and it's often enough to unstick an early enterprise deal. Type II covers a sustained period of operation and proves the controls work consistently over time. That's the one enterprise procurement teams actually want.

Penetration testing enters the picture here too, though SOC 2 doesn't technically demand it by name. Auditors expect it anyway, and findings from a real test map cleanly onto the framework's Trust Service Criteria. At Series A, the goal is to stand up processes repeatable enough that a small engineering org can run them without a dedicated security hire.

The controls that need to be in place before a first formal penetration test

A penetration test checks whether controls hold up under attack. It doesn't check whether controls exist in the first place, and running one before the basics are in place wastes money and produces a report full of things everyone already knew were broken.

Before booking that first engagement, a handful of things need to be true:

• MFA enforced everywhere, no default credentials sitting on any system, session management actually tested
• Role-based access control implemented, with someone having thought through what privilege escalation paths look like
• No credentials in any repository, secrets rotated on a schedule, environment variables handled properly rather than passed around in Slack
• Known CVEs in dependencies patched, with an actual process for catching new ones
• Enough of an audit trail that the testing team can be distinguished from a real attacker during the engagement
• Production separated from development, with the external attack surface documented rather than guessed at

Skip this groundwork and the pentest report comes back full of low-hanging fruit: unpatched CVEs, default passwords, missing MFA. It's expensive to run, embarrassing to hand to an auditor, and it tells you nothing about the deeper architectural risks a real test is supposed to surface. The signal that a company is actually ready: when the engineering team can describe, without the tester's help, what they think their attack surface looks like. A good pentest then tells them what they missed. That gap is where the value lives.

What a real penetration test actually involves, and why the difference from a vulnerability scan matters

A penetration test is a time-boxed, goal-driven attack carried out by a person reasoning about a specific environment, distinct from a tool scanning for known signatures and spitting out a PDF.

Real tests share a few traits. Findings are contextualized: the tester understands the application's business logic well enough to chain three or four minor issues together into an actual path to sensitive data. Every finding gets proven with a working exploit, not just assigned a theoretical severity score. The report documents the attack chain, showing how individual issues combined to reach something that matters, rather than listing vulnerabilities in isolation. And a human triages every result before it lands in the report, which is why a good pentest has close to zero false positives.

Vulnerability scanners, things like Nessus, Qualys, or an automated Burp Suite run, do something different and genuinely useful: they find known vulnerabilities in common configurations, fast and cheap. That's a valid input into a penetration test, distinct from the test itself. Scanners can't find a business logic flaw where a user can manipulate an order total by changing a hidden form field, and they can't chain a low-severity information leak into a full account takeover. Those require a person thinking like an attacker who's read the source code.

Methodology matters here too. Whitebox testing, where the tester gets full access to source code, cloud configurations, and internal documentation, produces the most complete coverage because the tester can map every attack path instead of guessing at what's reachable from outside. Greybox and blackbox testing both have legitimate uses depending on what's being simulated, but for a growth-stage SaaS company that needs both compliance evidence and genuine assurance, whitebox produces the findings that hold up best under scrutiny.

The stakes are real: web applications account for a large majority of cyber incidents and a majority of data breaches, according to industry figures. Auditors and enterprise security reviewers know this cold. A report that doesn't address application-layer risk thoroughly isn't going to hold up in either room.

How to evaluate penetration testing vendors and spot the ones selling scans in a suit

Here's the market problem: "penetration testing" and "vulnerability scanning" get sold under the exact same word, at wildly different price points and quality levels, and a proposal document alone won't tell you which one you're buying.

A few questions separate the real testers from scanner operators wearing a nicer logo:

• What percentage of this engagement is manual testing versus automated tooling? Vendors who dodge this or redirect to a tool name are usually scanner-heavy.
• Walk through the methodology: what framework guides the test, and how does it adapt to this specific environment?
• Can a sample report from a similar engagement be shared? Look for an attack chain narrative, not a bare list of CVEs with severity scores attached.
• Who specifically runs this test, and what have they actually done before?

Certifications are worth weighing, though not all of them mean the same thing. OSCP (Offensive Security Certified Professional) is a widely recognized hands-on exploitation credential, because earning it requires actually breaking into machines under time pressure. OSWE is oriented toward web application exploitation. GXPN is aimed at more advanced attack scenarios. CEH is a more broadly held certification and doesn't validate hands-on exploitation ability in the same way, so a team whose only credential is CEH deserves a follow-up question about how deep their testing actually goes.

Red flags worth walking away from: a fixed low price with fast turnaround and no scoping call at all, which is the clearest tell of an automated scan dressed up as a manual test. A flat fee quoted without any real scoping conversation, since an underscoped test misses the assets that actually matter. No retesting policy, because a vendor who doesn't care whether the findings actually got fixed doesn't have the client's outcome as the goal. No professional indemnity insurance, given that a pentest involves deliberately trying to break production systems; ask for a certificate before signing anything. And vague or missing methodology documentation generally.

On price: a serious web application engagement at a growth-stage SaaS company typically runs $10,000 to $30,000 depending on scope. That range isn't padding. A $3,000 test that a QSA rejects during audit costs far more in the end than a $15,000 engagement that passes review the first time around. The scoping conversation itself is a quality signal, too: a vendor who asks detailed questions about IP ranges, application URLs, user roles, testing windows, and excluded systems before quoting a price is doing the job right.

What SOC 2, ISO 27001, and HIPAA each actually require from penetration testing

None of the three major frameworks say the words "penetration test" quite the way a security team might expect, but all three lean on it in practice.

SOC 2 doesn't explicitly mandate penetration testing. Auditors expect it anyway, because it's the most efficient way to demonstrate that controls actually function under the the Trust Service Criteria rather than just existing on paper. The appropriate testing methodology should be scoped to the systems and controls under review. Findings should map directly to the relevant Trust Service Criteria; a report that doesn't do this creates extra translation work at audit time that nobody wants to pay for twice. SOC 2 itself has shifted from a nice-to-have to a baseline expectation for technology companies selling into the enterprise, and auditors increasingly want proof controls hold up under real conditions, not a policy document sitting in a drive somewhere.

ISO 27001 doesn't mandate penetration testing by name either, but it's the recognized industry practice for satisfying Annex A Control 8.8, the "Management of Technical Vulnerabilities" requirement, and the operational obligations that come with it. Where SOC 2 frames testing as evidence of control effectiveness, ISO 27001 frames it as a risk-treatment mechanism, a distinction that matters when scoping the engagement. Worth flagging: the ISO/IEC 27001:2022 standard supersedes the earlier version, and any company pursuing certification should confirm they are working against the current standard.

HIPAA's Security Rule, under 45 CFR §§164.308 through 164.312, never uses the phrase "penetration test" either. But the required Technical Safeguard for a "technical security evaluation," alongside the addressable specification for "testing and revision procedures," are the hooks regulators lean on when they expect one.

There's an efficiency argument worth making here: one penetration test, scoped broadly enough to cover the superset of systems across all three frameworks, can generate findings mapped simultaneously to SOC 2 Trust Service Criteria, ISO 27001 Annex A controls, and HIPAA safeguards. That's a stronger case for one serious, well-scoped engagement than for three cheaper, narrower ones run separately.

There's also a forcing function independent of compliance entirely: cyber insurance carriers have tightened underwriting requirements considerably, and penetration testing has increasingly become part of what they expect to see.ge thresholds now require evidence of annual penetration testing carried out by a qualified human, not an automated scan. That requirement shows up on the renewal form whether or not a company is chasing SOC 2 or ISO 27001 at all.

What the Series B security program looks like in practice

By Series B, security stops being a handful of individual controls and becomes a program with moving parts that need to be coordinated with each other.

Penetration testing cadence steps up considerably. At minimum, that means annual testing across both infrastructure and application layers, plus additional testing after major feature releases, infrastructure migrations, the acquisition of new sensitive data types, and any M&A activity. Per the Kaseya Cybersecurity Survey Report 2024, the most common cadence among companies surveyed was actually twice a year, at 29%, followed by three to four times a year at 23% and once a year at 20%. The market has moved past treating an annual test as sufficient.

The stakes justify that cadence. IBM's Cost of a Data Breach Report put the average cost of a U.S. data breach at $10.22 million in 2025. At Series B scale, with real enterprise customers and meaningful ARR on the line, that risk calculus looks nothing like it did at seed.

Point-in-time testing stops being the whole story too. Continuous security scanning integrated directly into the CI/CD pipeline catches vulnerabilities introduced in a pull request before that code ever reaches production, which is the natural evolution beyond an annual pentest that only checks a snapshot in time.

Remediation discipline matters as much as the testing itself. A pentest report that sits in a shared drive untouched is security theater, nothing more. The value sits entirely in the fix-and-verify cycle: retesting should be written into vendor contracts from the start, not treated as an optional add-on negotiated later, and time-to-remediation by severity is worth tracking as an internal engineering metric the same way uptime or latency gets tracked.

There's a commercial dimension too. At Series B, the credibility of a company's security findings directly affects how fast enterprise deals close. A well-documented, human-reviewed penetration test with a clean letter of attestation functions as a sales asset that gets pulled into the deal room, well beyond its role as a compliance artifact sitting in a folder for auditors.

Laid end to end, the full arc looks like this: foundational hygiene at seed, repeatable processes and the start of SOC 2 at Series A, then annual or biannual penetration testing, continuous scanning, and full compliance attestations woven into the SDLC by Series B. The companies that get this right build security into how they hire, how they ship code, and how they think about risk at every stage, treating it as an ongoing discipline rather than a project with a start and end date, which is exactly why their programs hold up under both an auditor's checklist and an actual attacker's attention.