DEV Community: Beatriz Albernaz

Series A Security Checklist: What Investors Ask and How to Be Ready

Beatriz Albernaz — Mon, 15 Jun 2026 09:26:45 +0000

The core checklist investors use at Series A usually covers: a recent penetration test and remediation, how you handle customer data, access controls, incident response, and compliance posture (for example SOC 2 or ISO 27001 progress). The best time to prepare is 3 to 6 months before your raise, not during term sheet negotiations.

Most Series A founders are still caught off guard the first time they see a full security due diligence pass. This article walks through what investors ask, what the process looks like, and how to get your security posture ready before the conversation starts.

What Do Series A Investors Actually Ask About Security?
Security due diligence at Series A has become standard at most institutional funds, particularly for B2B SaaS companies handling customer data. The questions typically come in one of three forms: a written security questionnaire, a direct conversation with a technical partner or operating team, or a third-party review requested by the fund.

The most common questions founders receive:

Have you had a penetration test?
This is the single most common security question at Series A. Investors want to know whether an independent expert has assessed your product for vulnerabilities and what you did with the findings. A recent pentest report (within the last 12 months) with documented remediation is the clearest signal that you take security seriously.

How do you handle customer data?
Where is data stored, how is it encrypted in transit and at rest, who inside your company can access it, and what controls prevent unauthorized access? For companies handling sensitive data (health, financial, personal), investors will ask whether you have mapped your data flows and whether access is logged.

Do you have SOC 2, ISO 27001, or equivalent?
Not every Series A company has completed a formal compliance certification, and investors do not always require it. But they will ask where you are in the process. "We are targeting SOC 2 Type I by Q3" is a credible answer. "We have not thought about it" is not.

What happens if you get breached?
Investors want to know you have an incident response plan, even a basic one. Who gets notified, in what order, within what timeframe? Do you have cyber insurance? Have you tested your response?

Who has access to production?
How many people can directly access your production environment and customer data? Is access controlled by role, logged, and reviewed? Is multi-factor authentication enforced across your team?

What Does Security Due Diligence Actually Look Like?
The depth of security due diligence varies significantly by fund, deal size, and the nature of your product. Here is what to expect across three common scenarios:

Light-touch review (most common at Seed to Series A)
A written questionnaire of 20 to 50 questions covering data handling, access controls, vulnerability management, and compliance status. Usually completed by the founder or CTO. Takes 2 to 4 hours if your documentation is in order. This is the standard for most Series A deals.

Technical partner review
Some funds have technical partners or operating team members who will review your architecture, ask follow-up questions about specific controls, and sometimes request your most recent pentest report or security audit. Common at funds that focus on B2B, enterprise, or regulated industries.

Third-party security assessment
Less common at Series A, but increasingly used by larger funds or for companies in sensitive verticals. The fund may request a third-party penetration test or security review as a condition of closing, or require one to be completed within 90 days post-close. Being ahead of this is a significant advantage.

How to Get Your Security Ready Before the Raise
The goal is not to have a perfect security posture before your Series A. It is to demonstrate that security is a managed, intentional part of how you operate. Here is what to have in place:

Get a Penetration Test Done
A clean pentest report is the single most impactful thing you can do for Series A security readiness. It shows investors that an independent expert has reviewed your product, you know where your risks are, and you have addressed them. Aim to complete your pentest 3 to 6 months before your raise so you have time to remediate findings before the report lands in front of a due diligence team.

If critical or high vulnerabilities are found, and they usually are in a first pentest, that is not a problem, provided you can show they have been fixed. A report showing three critical findings, all remediated, is better than no report at all.

Faultline Security provides fixed-price pentests starting from €3,000, with reports delivered in under two weeks. Every engagement includes a letter of attestation, a one-page document confirming the pentest was performed, shareable with investors and customers without an NDA.

Scope your pentest: https://faultlinesec.com/scope

Start Your SOC 2 Journey (Even if You Are Not Done)
You do not need a SOC 2 report to close a Series A, but you do need a credible answer to the question. Investors understand that early-stage companies are in process. What they are looking for is intentionality: a target date, a compliance partner engaged, and basic security controls in place that map to the SOC 2 Trust Services Criteria.

The five SOC 2 Trust Services Criteria are a useful framework even before you engage an auditor: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Run through each and document where you stand.

Document Your Security Policies
Investors will sometimes ask for evidence of security policies, not because they expect a 200-page information security manual, but because written policies signal that your team is operating to a standard, not improvising. The minimum set to have documented:

Access control policy (who can access what, how access is provisioned and revoked)
Data handling and retention policy
Incident response plan (even a one-page version)
Vulnerability management process (how you find, triage, and fix security issues)
Employee security training record These do not need to be elaborate. A shared Notion document with clear ownership and a last-reviewed date is enough for most Series A reviews.

Lock Down Access Controls
Before your raise, audit who has access to your production environment and customer data. The standard investors expect:

Multi-factor authentication enforced for all team members, especially on cloud infrastructure, code repositories, and admin tools
Principle of least privilege: people have access to what they need for their role, nothing more
Offboarding process: access is revoked promptly when someone leaves
Access logs: you can demonstrate who accessed what and when

Get Basic Cyber Insurance
Cyber liability insurance is increasingly expected at Series A, particularly for companies handling sensitive data. It is not expensive at early-stage, and it signals maturity to investors. Most policies cover breach response costs, legal liability, and notification expenses.

What Does a Strong Security Narrative Look Like in a Raise?
The founders who handle security due diligence best do not just answer questions. They get ahead of them. In your pitch or data room, a one-page security overview can pre-empt most investor questions and demonstrate that security is a first-class concern, not an afterthought.

A strong security overview covers:

When your last penetration test was conducted and by whom
Current compliance status (SOC 2 in progress, target date, etc.)
How customer data is stored, encrypted, and accessed
Who owns security within the company
Incident response capability and cyber insurance status This is especially valuable if you are selling to enterprise customers. It signals that you are ready for their security questionnaires too, which often become a blocker in enterprise sales.

Series A Security Checklist
Work through this before your raise:

Penetration Testing

Penetration test completed within the last 12 months
Critical and high findings remediated and documented
Remediated pentest report available to share under NDA
Letter of attestation in hand for sharing without NDA

Compliance

SOC 2 roadmap defined with target dates
Compliance partner or auditor engaged (or shortlisted)
Core security policies documented and dated

Access Controls

MFA enforced across all team members and critical systems
Production access limited to those who need it
Access provisioning and offboarding process documented
Access logs available and reviewed

Data Handling

Data flows mapped: where data lives, how it moves
Encryption in transit (TLS) and at rest confirmed
Data retention and deletion policy documented

Incident Response

Incident response plan written (even a one-pager)
Internal escalation path defined
Cyber insurance policy in place

Due Diligence Readiness

Security overview document prepared for data room
Pentest report available to share under NDA
CTO or technical founder briefed to handle security Q&A

✨ One Last Thing
I've sat across from founders in the middle of a raise who got blindsided by a security questionnaire they weren't expecting. It's a stressful situation that's entirely avoidable. If you're 3 to 6 months out from a Series A, the work you do now on security pays off twice: it closes faster, and it makes you a better company.

If you've been through a security due diligence process, I'd love to hear what surprised you most. And if you're preparing for one right now and have questions, drop them in the comments. Happy to answer anything specific to your situation.

Your AI agents are probably over-privileged and under-monitored

Beatriz Albernaz — Fri, 29 May 2026 10:13:25 +0000

You've got an AI agent running in production. It has an API key for your database, OAuth tokens for your cloud provider, and access to your customers' data across multiple tenants.

When did you last rotate those credentials?

If the answer is "when we set it up," you're not alone, but you've got a real exposure on your hands.

Why human IAM patterns break for AI agents

Most teams I see apply the same identity model to AI agents that they use for human users. It doesn't hold up.

Human users log in, do a thing, log out. Sessions are bounded. Permissions map to job roles. Rotation happens on a schedule everyone tolerates.

AI agents are different in every one of those dimensions:

They run continuously, not in discrete sessions
They need permissions that change based on task context, not a static role
They generate and consume credentials programmatically, without human review
They operate across multiple customer tenants in the same workflow
A compromised agent credential doesn't just expose data, it takes actions on that data

The blast radius isn't the same. A leaked human user token is bad. A leaked agent credential that has read-write access to your entire database and can execute tool calls across your environment is worse.

What we actually find in AI red teaming engagements

40–50% of high-severity findings in our AI red teaming assessments are identity-related. These are the patterns that come up most:

Static, long-lived credentials
Agents deployed with API keys that haven't rotated since initial setup. Six months is common. The reasoning is usually "rotation would break things" which is true, and also a sign the credential management wasn't designed for automation.

Over-permissioned tool access
An agent needs to query one table. It has credentials for the entire database. This happens because scoping credentials is tedious to do properly, and "it works" is good enough at ship time.

Cross-tenant context leakage
Multi-tenant SaaS products where agent context from one customer bleeds into another customer's thread. Usually a missing tenant ID check somewhere in the tool call chain. Easy to miss in code review, easy to find in adversarial testing.

Secrets in places agents can read them
Environment variables, config files, conversation context. Agents are designed to access these things. An attacker's job is to make your agent hand them over through prompt injection or tool abuse.

What good agent identity looks like

None of this is exotic. It's standard security hygiene adapted for non-human principals.

Short-lived tokens, automated rotation

Credentials for AI agents should expire fast under an hour for anything sensitive. Rotation needs to be automated because you're not doing it manually at that frequency.

# Example: generating short-lived AWS credentials for an agent task
aws sts assume-role \
  --role-arn arn:aws:iam::123456789:role/agent-task-role \
  --role-session-name agent-session-$(date +%s) \
  --duration-seconds 3600

Least privilege, scoped per task

RBAC is too coarse for agents. You want attribute-based or policy-based access control that evaluates context at request time, not a role that's "good enough for most things the agent does."

Define what each agent needs for each task. Grant that. Nothing else.

Inventory your agents

You probably don't have a complete list of which agents are running, what credentials they use, and what they can access. Start there. You can't secure what you haven't inventoried.

A basic agent registry entry per deployment:

Agent name and version
Credentials in use (reference, not value)
Scope of access
Customer tenants it operates in
Last rotation date

Log actions, not just outputs

Your observability stack is probably capturing what the agent says. You also need to capture what it does: which tools it called, which files it read, which APIs it hit, which tenant's data it touched.

This is how you distinguish legitimate agent behavior from a compromised agent doing the same things.

Test tenant isolation explicitly

If you're multi-tenant, add automated tests that verify agents cannot access resources outside their assigned tenant scope. Run these in CI. Don't rely on code review alone, the failure modes are subtle and adversarial testing finds them reliably.

Before your next SOC 2 audit or enterprise deal

Enterprise customers are going to ask about this. Security questionnaires increasingly include questions about AI agent access controls, credential lifecycle, and tenant isolation.

The teams that are ahead of this have:

A separate budget line for agent identity security (not absorbed into AI innovation spend)
Automated credential rotation tied to their deployment pipeline
Fine-grained policies scoped per agent task, not per agent role
Audit logs capturing agent actions with full tenant context
External validation through red teaming before major audits or sales cycles

If you haven't done this work yet, the best time to start is before the questionnaire lands, not after.

We run AI red teaming engagements for B2B SaaS companies building AI-powered features: prompt injection, tool abuse, cross-tenant isolation, credential management. If you want to know what's actually exposed before an attacker does, scope an engagement.

We Built a Pentesting Company Because We Were Tired of Watching Startups Get Burned

Beatriz Albernaz — Wed, 13 May 2026 13:47:03 +0000

There was a pattern we kept seeing that genuinely bothered us.

A startup would get to Series A, or land their first enterprise customer, and suddenly need a pentest report right now. They'd scramble to find a vendor, get hit with a 4-week scoping call process, a €30k quote, and a PDF that mostly described low-severity findings their scanner already caught.

They didn't need a €30k PDF. They needed someone to actually look at their auth layer, their API, their trust boundaries and tell them what was actually broken.

That frustration is what became Faultline Security.

The problem we were trying to solve

When we started talking to early-stage founders about security, the same themes kept coming up:

"We know we need a pentest but have no idea where to start"
"The quotes we got were either too expensive or too vague"
"We have a SOC 2 audit in 8 weeks — is that enough time?"
"Our enterprise prospect is asking for a pentest report and we've never done one"

None of these are hard problems, conceptually.

We get it! Security is almost always the thing that gets pushed to the next sprint, the next quarter, the next funding round. When you're a small team trying to ship and grow, it's genuinely hard to prioritize. But here's what we keep telling founders: starting early isn't harder, it's actually easier.

When your codebase is smaller, your attack surface is narrower, and your team is close to every decision, building a solid security foundation takes a fraction of the effort it will cost you later. The expensive, painful pentests we kept seeing weren't just a vendor problem, they were the result of years of deferred security work landing all at once. We wanted to help teams get ahead of that.

We wanted to build something different: fixed pricing, a scoping process that takes 24 hours not 2 weeks, and findings that are actually written for engineers who need to fix them — not auditors who need to check a box.

What building this taught us

Founders don't know what they need until you ask the right questions.

The first version of our intake process asked things like "what environments are in scope?" and got blank stares. We rewrote it to ask "what would hurt the most if a competitor got in?" That changed everything. Suddenly people could actually answer.

The report is the product.

We spent more time rethinking how findings are written than anything else. A finding that says "Cross-Site Scripting detected on /search" is useless. A finding that shows the exact payload, the session token that was exfiltrated in the proof of concept, and the two-line code fix — that is a product.

Timelines are the most anxiety-producing part of the whole process.

The question we get asked more than any other is: how long is this actually going to take? People have compliance deadlines, fundraise timelines, sales deals on the line. They need a real answer, not "it depends."

We wrote a detailed breakdown of this recently: How Long Does a Startup Pentest Take? — the short answer is 3 to 10 days of active testing plus 2 days for the report, so most teams have something in hand in under two weeks. But the full picture is more nuanced, and worth reading if you're scoping something with a hard deadline.

The parts nobody tells you about starting a security company

Building in security is weird. You're asking people to trust you with access to their most sensitive systems, before they know you well. Trust-building is the entire job before any actual testing happens.

We also learned that pricing transparency is itself a differentiator. Most pentesting firms won't put a number on their website. Scope varies, complexity varies. But the endless "contact us for pricing" dance adds friction that small teams don't have time for. Showing a real range upfront, even approximate, changes the quality of conversations you have.

And the writing matters more than we expected. Content like the timeline post above has brought in more qualified leads than any cold outreach we've done. People who are googling "how long does a pentest take" are in the buying process. Meeting them where they are with an honest, detailed answer builds more trust than any sales email.

Where we stand now

Faultline is purpose-built for SaaS companies and startups that are hitting real security milestones — first enterprise customer, SOC 2 audit, Series A. We're not trying to compete with the big firms doing 6-month red team engagements for banks. We're trying to be the best option for a 20-person company that ships fast and needs a pentest that matches their pace.

If you're building something and wondering whether you need a pentest, when to do it, or how to think about scope we're happy to talk. No sales process. Just people who care about shipping secure software.

You can also scope an engagement directly and get a fixed-price proposal within 24 hours.

What questions do you have about security at the early stage? Drop them in the comments. we read everything.

What pentest does your startup actually need?

Beatriz Albernaz — Thu, 30 Apr 2026 15:02:54 +0000

Most startup founders know they should get a pentest. Fewer know what kind, what scope, or what a reasonable price looks like and the industry hasn't made this easy to figure out.

Pricing is rarely published. Scope conversations happen after you've already given your email to a sales rep. And the word "pentest" gets used to describe everything from a lightweight automated scan to a two-week manual engagement by a team of three.

This guide gives you a framework to self-assess what you actually need, based on where your company is and what you're building.

The variables that actually determine what you need

There are four factors that map pretty cleanly to pentest scope and cost:

1. Company stage
Pre-seed and seed companies usually need a lighter engagement — enough to surface critical vulnerabilities and satisfy early security questionnaires, but not a full-blown compliance audit. Series A and beyond typically have more surface area, more integrations, and investors or enterprise customers who want to see a proper report.

2. What you're building
A web app with an authenticated user section is a different scope than an API serving third-party developers, which is different again from infrastructure with cloud components and CI/CD pipelines. Each surface has different attack vectors and different testing methodologies.

3. Compliance requirements
SOC 2 Type II, ISO 27001, and PCI DSS all have specific pentest requirements. If you're pursuing any of these, the pentest needs to meet certain criteria — scope, methodology, report format — that go beyond a general security assessment. This is often the trigger that moves a startup from "we should probably do this at some point" to "we need this done in the next 90 days."

4. Scope
This is the one founders underestimate most. Scope drives cost more than anything else. A focused test on your main web application is a very different engagement from one that covers the application, your API, your admin panel, your cloud configuration, and your internal tooling.

The main pentest types and when you need them

1. Web application pentest
The most common for early-stage SaaS. Tests your application from the perspective of an authenticated user, an unauthenticated attacker, and sometimes a privileged user. Covers OWASP Top 10 and beyond — auth flows, access controls, injection points, business logic flaws.
→ When you need it: You have a product with user accounts. A customer asked for a pentest report. You're starting a SOC 2 process.

2. API pentest
Similar to a web application test but focused on your API endpoints. Critical if your API is externally facing or consumed by third-party developers. Auth, rate limiting, data exposure, BOLA/IDOR vulnerabilities.
→ When you need it: Your API is your product or a significant part of it. You have developer customers. You're building in a regulated space.

3. Cloud / infrastructure pentest
Tests your cloud environment — misconfigurations, overly permissive IAM roles, exposed storage buckets, network segmentation issues. Usually AWS, GCP, or Azure.
→ When you need it: You've scaled beyond a simple Heroku deploy. You have infrastructure engineers managing cloud resources. ISO 27001 or SOC 2 is on the roadmap.

4. Combined / full-scope engagement
All of the above, sometimes with internal network or social engineering components. More common at Series B+ or when enterprise contracts require it.
→ When you need it: You're selling to enterprise. Your compliance framework requires broad scope. You've had a security incident and want comprehensive coverage.

A quick self-assessment
Answer these honestly and you'll have a good starting point:

-Stage: Are you pre-product-market-fit, or do you have paying customers and scaling infrastructure?

Surface area: What are the components you're worried about? Web app only? API too? Cloud infra?
Driver: Is this proactive, or is a customer / investor / compliance requirement pushing you to do it now?
Timeline: Do you have a deadline (audit, enterprise deal, fundraise)?
Budget range: Are you looking for something under €5k, €5–15k, or are you budgeting for a larger engagement?

The combination of these five answers will tell you whether you need a focused lightweight test, a standard web + API engagement, or a more comprehensive scope.

Skip the guesswork
We built a 5-question quiz that maps your answers to a recommended tier and a starting price.
→ Takes under a minute.

faultlinesec.com/quiz

It asks for your work email before showing the result [full transparency on that] and you'll hear from us. But the recommendation is genuine and accurate enough to use as a starting point for any vendor you end up going with, not just us.