Get the print-ready PDF version with space to assign owners, track status, and share with your team. Includes a bonus section on SOC 2 fast-track timelines.
No spam. Unsubscribe anytime. We use privacy-first email.
Checklist sent — check your inbox. While you wait, run your first free scan.
Why Compliance Matters Before You Raise
Most pre-seed founders treat security as a post-Series A problem. That's a mistake — and increasingly, it's a deal-breaker. In 2024, over 60% of institutional investors at seed and Series A stages reported adding a security due diligence step to their process. The question isn't whether they'll ask. It's whether you'll be ready when they do.
There are four concrete reasons why you should build your compliance foundation before your next fundraise — not after.
Investor Due Diligence Has Changed
Technical due diligence used to mean checking your GitHub repo and asking about your stack. In 2025, it includes a security questionnaire, a review of your data handling practices, and increasingly a request for evidence of continuous monitoring. VCs who have been burned by portfolio company breaches — and there have been many — now ask pointed questions: Do you have MFA enforced? How do you manage secrets? What's your incident response plan? If you can't answer these fluently, you're signaling that you'll be a liability down the road.
The good news: it doesn't take months to get audit-ready. A focused 4–6 week sprint on the controls in this checklist will leave you with defensible answers to every question a VC is likely to ask. For a deeper dive on preparing for that conversation, see our guide on startup audit preparation.
Enterprise Customer Requirements
The moment you start selling to companies with more than 500 employees, you will receive a vendor security questionnaire — typically a 50–150 question document asking about your controls, your data handling, your incident response, and your compliance certifications. If you're not ready, that deal stalls. We've seen $200k ARR contracts sit in procurement limbo for 6 months because the startup couldn't produce a SOC 2 report or answer basic questions about encryption key management.
The controls in this checklist map directly to the most common enterprise vendor questionnaire questions. If you check all 47 boxes, you'll be able to answer the Shared Assessments SIG, the CAIQ, and most custom questionnaires without breaking a sweat.
Cyber Insurance Prerequisites
Cyber insurance has gotten significantly harder to obtain since 2022. Insurers now require evidence of specific controls — particularly MFA, endpoint detection, backup testing, and incident response planning — before they'll even quote you. Without these controls in place, you may be uninsurable or paying 3–5x higher premiums. Given that a single ransomware incident can cost a startup its entire runway, this is not a place to cut corners.
Liability Protection and Fiduciary Duty
As a founder, you have a fiduciary duty to protect your company's assets — including customer data. A breach caused by a preventable lapse (like not rotating API keys or leaving a database exposed to the public internet) can result in personal liability, regulatory fines, and customer contract penalties. Building the right controls now is cheaper than defending yourself later. If you're processing any EU citizen data, GDPR compliance starts with many of the same controls covered here.
Now, let's get into the checklist itself. We've organized it into five domains: Infrastructure Security, Access Control, Data Protection, Application Security, and Operational Security. Each item includes a brief explanation of why it matters and a priority rating: Critical means do it before you launch, Important means do it before you raise, and Nice to Have means do it before your first enterprise customer.
Infrastructure Security 12 Controls
Your infrastructure is the foundation everything else rests on. These controls reduce your attack surface, make your systems harder to compromise, and ensure you know when something goes wrong. They're also the first thing a penetration tester or security-conscious investor will check.
Disable password-based SSH login on all servers and require cryptographic keys. Password authentication is trivially brute-forced; a key pair with a strong passphrase is not. Run
PasswordAuthentication no in your sshd_config and test it from a fresh terminal before you close the existing session.Every server should have a host-based firewall configured to deny all inbound traffic by default, with explicit allow rules only for the ports your application legitimately needs. This single control closes hundreds of potential attack vectors. Use UFW, iptables, or cloud-provider security groups — but make sure the rules are codified in infrastructure-as-code, not applied manually and forgotten.
Every HTTP endpoint should redirect to HTTPS, and your TLS configuration should reject connections using TLS 1.0 or 1.1 (both deprecated and broken). Use a tool like SSL Labs or testssl.sh to verify your cipher suites. Certificate expiry monitoring is essential — an expired cert takes your service offline as surely as an outage.
Apply a CIS Benchmark hardening baseline to every server and VM. This means disabling unnecessary services, removing default accounts, setting secure kernel parameters, and restricting SUID binaries. Tools like Lynis can audit your hardening posture automatically and produce a prioritized remediation list.
Unpatched operating systems are the #1 cause of infrastructure compromises. You need a documented process for applying OS and package updates — ideally automated with unattended-upgrades (Ubuntu) or equivalent, with a manual review cycle for major version upgrades. Define your SLA: critical CVEs patched within 24 hours, high within 7 days, medium within 30 days.
If you're running Docker or Kubernetes, every image you build should be scanned for known CVEs before it's deployed. Tools like Trivy, Snyk, or Grype integrate directly into your CI pipeline and can fail builds when critical vulnerabilities are detected. This is the container security equivalent of not deploying known-vulnerable code. SOC 2 Type II auditors specifically look for this control.
API keys, database passwords, and tokens should never appear in your codebase, Dockerfile, or CI configuration. Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, SOPS+age, or equivalent) and inject secrets at runtime. Scan your git history for secrets already committed using tools like trufflehog or git-secrets — you may already have an exposure you don't know about.
Backups you've never tested aren't backups — they're hopes. Define your backup schedule (daily minimum for databases, weekly for configurations), store backups off-site or in a separate cloud account, and document a restore test that you run quarterly. Investors and enterprise customers will ask whether you've tested your recovery process, not just whether backups exist.
Cloudflare's free tier, AWS Shield Standard, or equivalent should be in front of your public endpoints. DDoS protection is not just about surviving attacks — it's about maintaining SLA commitments to enterprise customers and demonstrating operational maturity. Configure rate limiting at the CDN/WAF layer as a companion control.
Add CAA (Certification Authority Authorization) DNS records to specify which certificate authorities are allowed to issue TLS certificates for your domain — this prevents unauthorized cert issuance. DNSSEC adds cryptographic integrity to DNS responses. Both are quick wins that signal security maturity to auditors.
You cannot respond to incidents you don't know about. Set up monitoring for CPU, memory, disk, and application error rates — and configure alerts that actually page someone when thresholds are crossed. Tools like Prometheus + Grafana, Datadog, or New Relic are common choices. Define your on-call rotation and escalation path in writing, even if it's a one-person team.
When a breach or outage occurs, you need a plan that doesn't depend on one person remembering the right steps under pressure. Your IRP should cover: detection, containment, eradication, recovery, and post-incident review. It should also specify your customer notification obligations (GDPR requires 72-hour notification for personal data breaches). Even a two-page document is far better than nothing.
Access Control 8 Controls
Access control failures are behind the majority of data breaches. The principle of least privilege — giving every person and system only the access they actually need — dramatically reduces your blast radius when credentials are inevitably compromised. These controls are also the heart of SOC 2's CC6 (Logical and Physical Access Controls) criteria.
Every account with access to production infrastructure, cloud consoles, or sensitive data must have multi-factor authentication enabled and enforced — not just available. Hardware keys (YubiKey) are gold standard; TOTP authenticator apps are acceptable; SMS is better than nothing but should be avoided. Check your cloud provider's IAM policies to ensure MFA is required, not optional.
No human or service account should have more permissions than necessary for its specific function. In practice: your app's database user should have SELECT/INSERT/UPDATE on specific tables — not a root/admin credential. Your CI/CD runner should have deploy permissions — not full account admin. Audit your IAM policies and service account permissions quarterly.
Define roles (admin, developer, read-only, billing) and assign users to roles rather than granting permissions individually. This makes access management scalable and auditable. When an employee's role changes, you update their role assignment — you don't have to remember which individual permissions they had. Document your roles and their associated permissions.
Single Sign-On centralizes authentication, making it easier to enforce password policies, MFA, and especially to terminate access instantly when someone leaves. Connect your identity provider (Okta, Google Workspace, Azure AD) to your critical SaaS tools. If a tool doesn't support SSO, document that gap and consider whether it should have access to sensitive data at all. See also our Vanta alternative comparison for how to track this programmatically.
Define and enforce a minimum password complexity policy: minimum length (14+ characters), prohibition of common passwords, and a prohibition of password reuse across internal systems. Provide all employees with a password manager (1Password Teams, Bitwarden for Business) and make it company policy to use it. Weak passwords on non-SSO tools are a common initial access vector.
Define maximum lifetimes for all types of credentials: API keys (90 days maximum), service account keys (180 days), and JWT signing secrets (rotate annually or on-demand after potential exposure). Automate rotation where possible. Maintain an inventory of all credentials, their owners, and their expiry dates — this inventory itself is an auditable artifact.
Application sessions should expire after a reasonable period of inactivity (15–60 minutes for sensitive actions), use secure and HttpOnly cookie flags, and be invalidated server-side on logout — not just cleared client-side. Implement concurrent session limits where appropriate. These controls prevent session hijacking and unauthorized access from shared devices.
When an employee, contractor, or vendor relationship ends, access revocation must happen within the same business day — ideally within hours. Document your offboarding checklist: SSO account deactivation, SSH key removal, API key revocation, device wipe, and transfer of credentials the person owned. Insider threat from ex-employees with residual access is one of the most common and preventable breach vectors.
Data Protection 9 Controls
Data protection controls are the ones that matter most to your customers — and to regulators. If you process any personal data (even just email addresses), you have legal obligations under GDPR, CCPA, and potentially sector-specific regulations. These controls reduce both your regulatory exposure and your liability in the event of a breach.
Every database, S3 bucket, EBS volume, and file store containing customer data should use AES-256 encryption at rest. Most cloud providers offer this as a default option — verify it's actually enabled, not just available. Keep your encryption key management separate from your data storage; cloud KMS services make this straightforward without managing key material yourself.
TLS should be enforced not just on your public API but on all internal service-to-service communication, including database connections and message queue interactions. It's common to find internal microservices communicating over plain HTTP on a "trusted" internal network — that trust is misplaced. Mutual TLS (mTLS) for internal services is the gold standard.
Not all data is equally sensitive. Define at minimum three tiers: Public (can be freely shared), Internal (company-confidential but not regulated), and Restricted (PII, financial data, health information, passwords). Assign a classification to your data stores and apply appropriate access and handling controls based on tier. This policy is a prerequisite for many compliance frameworks and enterprise vendor questionnaires.
Define how long you retain each type of data and implement automated deletion at the end of the retention period. Retaining data longer than necessary increases your liability in a breach and may violate GDPR's storage limitation principle. Document your policy and be ready to produce it for enterprise customers who ask during vendor reviews.
Know exactly what personal data you collect, where it's stored, how it flows through your systems, and who can access it. This data map is required for GDPR compliance (Article 30 Records of Processing Activities) and is the first thing a data protection regulator asks for after a breach. It's also essential for responding to subject access requests from your users.
Encrypting data at rest in your primary database means nothing if your backups are stored unencrypted. Verify that your backup process preserves encryption, that backup files are encrypted before they leave your primary environment, and that the decryption keys are stored separately from the backup data. An unencrypted backup in a public S3 bucket is one of the most common causes of data breaches.
When you decommission a server, wipe a laptop, or delete customer data, ensure the deletion is cryptographic or physical — not just a file system delete. For cloud storage, use crypto-shredding (delete the encryption key to make data unrecoverable). For physical devices, document your hardware disposal process. This is relevant to GDPR's right to erasure and to preventing data recovery from old hardware.
If you're processing EU personal data and you share that data with third-party services (your cloud provider, email platform, analytics tool, etc.), GDPR requires a signed DPA with each of them. Most large vendors (AWS, Google, Stripe) offer standard DPAs — you just have to sign them. Maintain a list of all sub-processors and your DPA status with each. This list is required by some enterprise customers as part of vendor review.
Your privacy policy must accurately describe the data you collect, how you use it, who you share it with, how long you keep it, and how users can exercise their rights. Templated privacy policies that don't reflect your actual practices are a liability, not a protection. Have yours reviewed by a privacy attorney — it's a few hundred dollars well spent. Keep it updated when your data practices change.
Application Security 8 Controls
Application security is where most breaches actually happen — not in the infrastructure, but in the application layer. These controls don't require a security team; they require good engineering practices and the right tooling in your CI/CD pipeline. Many of them are free.
Your application is only as secure as its dependencies. Run software composition analysis (SCA) on every build using Dependabot, Snyk, or OWASP Dependency-Check. Configure automated PRs for security patches and define a policy for how quickly you'll act on critical CVEs in your dependencies. Supply chain attacks (like the Log4j incident) exploited this gap catastrophically.
Static analysis (Semgrep, CodeQL, Bandit) catches security bugs in your code before it ships. Dynamic testing (OWASP ZAP, Burp Suite automated scans) tests your running application for common web vulnerabilities. Running both as part of your CI pipeline means you catch most security bugs before they reach production — and you have documented evidence of security testing for auditors. See our guide on SOC 2 for startups for how this maps to audit evidence.
SQL injection and XSS remain in the OWASP Top 10 despite being entirely preventable. Use parameterized queries or an ORM for all database interactions — never string-concatenated SQL. Validate and sanitize all user input server-side (client-side validation is UX, not security). This single class of controls prevents the most common application-level attacks.
Cross-Site Request Forgery (CSRF) tricks authenticated users into making unintended requests to your application. Protect against it using the SameSite cookie attribute (Lax or Strict), CSRF tokens for non-GET requests, and verifying the Origin and Referer headers on state-changing endpoints. Most modern frameworks include CSRF protection — make sure it's enabled and not accidentally bypassed.
Without rate limiting, your login endpoint is vulnerable to brute-force attacks and credential stuffing. Implement rate limiting at both the application layer (per-IP and per-account limits) and the infrastructure layer (WAF/CDN rules). Add progressive delays or CAPTCHA after repeated failures. The same control protects API endpoints from abuse and keeps your costs predictable.
Error messages shown to users should never include stack traces, database schema information, file paths, or internal configuration details. These are a roadmap for attackers. Log detailed errors server-side (to your centralized logging system), but return generic, user-friendly error messages in API responses and UI. Distinguish clearly between user errors (400-range) and server errors (500-range).
HTTP security headers are free, take 30 minutes to implement, and prevent entire classes of attacks. At minimum: Content-Security-Policy (prevents XSS), X-Frame-Options or frame-ancestors (prevents clickjacking), Strict-Transport-Security (enforces HTTPS), X-Content-Type-Options: nosniff, and Referrer-Policy. Test your configuration at securityheaders.com and aim for a B+ or better.
Authenticate API requests using short-lived JWTs or OAuth tokens rather than long-lived API keys where possible. When long-lived API keys are necessary, scope them to the minimum required permissions and provide customers with easy revocation. Store API keys hashed, not in plaintext — if your database is compromised, hashed keys prevent immediate credential reuse.
Operational Security 10 Controls
Operational security is about the processes and practices that keep your security posture from degrading over time. It's the difference between a security program and a one-time security sprint. These controls take longer to implement but are what separates companies that pass SOC 2 audits from companies that nearly pass.
Document who is authorized to make changes to production systems, how changes are approved, and how they are rolled back if they cause issues. Even a simple process — PR required, one reviewer approval, deployment via CI/CD only — is dramatically better than ad-hoc SSH sessions by whoever happens to be on call. Change logs are also valuable forensic evidence in incident investigation.
Require at least one peer review for all code changes before they merge to your main branch. This catches security issues that automated tools miss and ensures no single engineer can ship arbitrary code to production unilaterally. Configure branch protection rules in GitHub or GitLab to enforce this — and protect the protection rules themselves from being bypassed.
All deployments to production should run through your CI/CD pipeline, not via direct SSH or manual commands. This ensures deployments are audited, reproducible, and that bypassing your security gates requires compromising the CI system itself. Grant your CI runner only the permissions needed for deployment and revoke direct production access from developer accounts where possible.
Ship all application logs, authentication events, and administrative actions to a centralized logging system (Loki, CloudWatch Logs, Datadog) that is separate from your production systems. Logs should be immutable — an attacker who compromises your application should not be able to erase evidence of their activity. Define log retention: 90 days minimum, 1 year for compliance-relevant events. This is SOC 2 CC7.2.
Before onboarding any vendor that will have access to sensitive data, conduct a lightweight security review: Does the vendor have SOC 2? Do they have a published security page? Do they offer a DPA? What is their breach notification policy? Document your assessments. Enterprise customers will ask whether you assess your sub-processors, and this documentation is your answer.
Define your Recovery Time Objective (RTO — how long it takes to restore service) and Recovery Point Objective (RPO — how much data you can afford to lose). Document the steps to restore your service from scratch using only your backups, your runbooks, and a fresh cloud account. Run a tabletop exercise annually. Investors increasingly ask about RTO/RPO as part of due diligence.
Phishing remains the #1 initial access vector for breaches — and your employees are the target. Run annual security awareness training covering phishing recognition, social engineering red flags, password security, and incident reporting procedures. Tools like KnowBe4, Proofpoint Security Awareness, or even a well-crafted internal training session satisfy this control. Document completion for compliance evidence.
You cannot secure assets you don't know exist. Maintain a current inventory of all servers, cloud resources, developer laptops, SaaS subscriptions, and repositories that touch production data. This inventory is the foundation of your vulnerability management program and is required by virtually every compliance framework. Infrastructure-as-code makes cloud asset inventory largely automatic — make it a habit.
Formally identify, assess, and prioritize security risks to your business annually — and document the results. A risk assessment doesn't need to be a 200-page NIST SP 800-30 exercise; a structured spreadsheet identifying your top 10 risks, their likelihood and impact, and your mitigation plan is sufficient for most frameworks. The act of documenting forces useful conversations about where you're exposed.
Collect and maintain in a single location: your security policies, risk assessment, vendor assessments, training records, incident response plan, and evidence of control operation. Store this in a git repository or a dedicated compliance tool. When an investor or enterprise customer asks for your security documentation, you want to be able to send a well-organized package within 24 hours — not spend two weeks scrambling to compile one.
How to Use This Checklist
47 controls can feel overwhelming when you're a two-person team with a product to ship. Here's how to approach it without losing momentum.
Prioritization Framework
Start with every item marked Critical. There are 16 of them. These are the controls that prevent the most common, most damaging attack scenarios — credential compromise, unpatched vulnerabilities, data exposure. Most of them can be implemented in a single engineering sprint. If a breach happened tomorrow, these are the controls that would determine whether it was catastrophic or contained.
Next, address the Important items in order of your biggest risk exposure. If you're already talking to enterprise customers, prioritize the access control and data protection sections. If you're pre-launch and focused on infrastructure stability, prioritize the operational security controls. The Nice to Have items are genuinely valuable but can be deferred until you have more capacity.
Timeline Suggestions
- Week 1–2: All Critical infrastructure and access control items. These are primarily configuration changes with high impact-to-effort ratios.
- Week 3–4: Critical application security items. Add SAST, dependency scanning, and security headers to your CI pipeline.
- Month 2: Data protection and operational security Important items. These require more process design but establish your compliance foundation.
- Month 3: Remaining Important items and first pass at Nice to Have. By this point you should be able to answer any investor due diligence questionnaire confidently.
For a detailed 90-day roadmap tailored to your specific stack and stage, see our startup audit preparation guide.
Run a free infrastructure scan and get a prioritized list of the controls you're missing — mapped to this checklist. No credit card. Results in under 5 minutes.
Start Free ScanAutomate Your Compliance Journey with Alpha Audit
Working through this checklist manually is entirely feasible — and we encourage it, because understanding why each control matters makes you a better security decision-maker. But many of these controls can be continuously monitored rather than periodically reviewed, and that's where automation makes a meaningful difference.
Alpha Audit automates evidence collection and monitoring for 30 of the 47 controls in this checklist, including:
- Continuous vulnerability scanning for OS packages, Docker images, and application dependencies (Controls 5, 6, 8)
- TLS certificate monitoring with expiry alerts and cipher suite validation (Control 3)
- SSH configuration auditing to detect password auth re-enablement (Control 1)
- Open port and firewall rule change detection (Control 2)
- Secrets scanning across your codebase and CI configuration (Control 7)
- Security header analysis on all public endpoints (Control 14 of Application Security)
- Backup verification status tracking (Control 8)
- SOC 2 control mapping with continuous evidence collection across all five Trust Service Criteria
- Monthly security posture reports suitable for sharing with investors, enterprise customers, and your cyber insurance provider
Rather than maintaining a spreadsheet and hoping manual checks catch regressions, Alpha Audit continuously monitors your environment and alerts you the moment a control falls out of compliance. It's particularly useful for the controls that are easy to set up and easy to accidentally break — like MFA enforcement, secret rotation reminders, and dependency vulnerability thresholds.
Compared to enterprise compliance platforms like Vanta or Drata (which typically cost $10,000–$20,000/year and require 50+ employees to justify), Alpha Audit is designed for the stage you're at now — see our full comparison with Vanta. And unlike point-in-time pen tests, our continuous scanning means your compliance evidence is always current, not 11 months stale.
Alpha Audit monitors 30+ of these 47 controls continuously. Connect your infrastructure in minutes and get your first security posture report before your next investor call.
Frequently Asked Questions
Do I really need all 47 controls before raising a seed round?
Not all 47 — but all 16 Critical controls, and as many Important controls as you can complete in your available time. Seed investors in 2025 vary widely in how deep they go on security due diligence; many don't ask at all. But Series A investors at institutional funds almost universally do, and the time between seed and Series A is often 12–18 months. If you build the foundation now, you won't be scrambling to remediate 30 findings in the month before your Series A closes — which happens more often than you'd think and has killed or significantly delayed deals.
How does this checklist relate to SOC 2 certification?
The 47 controls in this checklist are not a direct 1:1 mapping to SOC 2 Trust Service Criteria — SOC 2 has roughly 60–80 controls depending on which criteria you include. But there is substantial overlap, particularly in the Access Control (CC6), Operations (CC7), and Change Management (CC8) domains. If you complete this checklist, you'll have addressed the majority of SOC 2 Type I requirements and be well-positioned for a Type II audit. Our SOC 2 for startups guide has the full mapping. You can also explore how Alpha Audit compares to SOC 2 automation platforms for the remaining evidence collection steps.
How long does it actually take to complete this checklist?
For a two-engineer team starting from a typical early-stage infrastructure (cloud VMs, Docker, a few SaaS tools), the Critical items take 1–2 weeks of focused effort. The full 47 controls, with proper documentation, realistically take 6–8 weeks — call it one sprint per section. The biggest time investment is usually the process and documentation work in the Operational Security section, not the technical controls. Using an automation platform like Alpha Audit can compress the ongoing maintenance from hours per week to minutes.
What if I'm pre-product and don't have a production infrastructure yet?
Building your infrastructure with these controls from the start is dramatically easier than retrofitting them later. Focus on the access control section first — SSO, MFA, and least privilege are entirely team process questions that don't depend on having infrastructure. Then implement the application security controls as architecture decisions when you're building (parameterized queries, security headers, input validation). The infrastructure controls follow naturally once you're deploying. Starting clean means you won't have the "we have 50 hardcoded secrets in our codebase" problem that plagues retrofits.
Is this checklist specific to any cloud provider or tech stack?
The controls are intentionally platform-agnostic — they apply equally to AWS, GCP, Azure, and on-premises infrastructure. The implementation details differ (e.g., UFW vs. AWS Security Groups vs. GCP Firewall Rules for the firewall control), but the requirement is the same. Similarly, the application security controls apply regardless of whether you're using Node.js, Python, Go, or any other stack — the concepts of parameterized queries, input validation, and security headers are universal. Where specific tooling is mentioned, it's illustrative rather than prescriptive.
Get the print-ready PDF with owner assignment columns and status tracking. Share it with your co-founder, your first security hire, or your board.
No spam. Unsubscribe anytime.
Checklist on its way — check your inbox. Start your free scan while you wait.