5 Security Gaps We Find in Every 30-Person Startup

There's a common myth in startup culture: that security is a problem for later, when you have more users, more revenue, more to lose. The reality is that the 20–50 person stage is precisely when attackers pay attention. You're large enough to have real data, real infrastructure, and real credentials - but small enough that no one has been formally responsible for locking the doors.

We've assessed dozens of companies at this inflection point. The gaps vary in severity but rarely in pattern. These five show up almost universally.

Gap 01 - No offboarding process for SaaS credentials Risk tag: Data exfiltration, unauthorized access

When an employee leaves a 30-person startup, the focus is usually on Slack, email, and payroll. What gets missed is the sprawl of SaaS access that accumulated over their tenure - AWS IAM roles, GitHub personal access tokens, Notion workspaces, Stripe dashboard seats, third-party API keys shared over Slack.

In many organizations we review, former employees retain active access for weeks or months post-departure. In several cases, we've identified OAuth tokens and long-lived API keys that were never rotated after someone left, granting persistent read/write access to production data.

The fix requires a documented offboarding checklist tied to HR workflows, a centralized identity provider (Okta, Google Workspace, or equivalent) with SSO enforced across all critical tools, and a quarterly audit of service accounts and API keys mapped to individual owners.

Gap 02 - MFA is optional, not enforced Risk tag: Account takeover, supply chain compromise

Multi-factor authentication is not new. It is not complicated. And yet in the majority of early-stage startups we assess, MFA is enabled as an option rather than enforced as a policy. The gap is almost always cultural, not technical - a reluctance to add friction to the developer experience.

This matters because credential stuffing and phishing campaigns don't target the most technically sophisticated users. They target the path of least resistance. A single engineer with a weak or reused password and no MFA on your GitHub organization or AWS console is a complete perimeter breach waiting to happen.

Enforce MFA at the identity provider level, not the application level. If your IdP supports hardware key policies or phishing-resistant FIDO2 factors, prioritize those for admin and infrastructure roles. Authenticator apps are a meaningful improvement over nothing; hardware keys are substantially better than authenticator apps for high-privilege accounts.

Gap 03 - Overpermissioned cloud IAM - everywhere Risk tag: Full environment compromise, data loss

Cloud IAM is one of the most consequential and most neglected attack surfaces in early-stage infrastructure. The pattern is nearly universal: a handful of engineers bootstrapped the cloud environment, attached AdministratorAccess to get things working quickly, and never scoped it down.

By the time a company reaches 30 people, that permissive IAM posture has often proliferated across CI/CD service accounts, Lambda execution roles, and developer access policies. The blast radius of a compromised credential in this configuration is typically full environment access - meaning a single leaked key can result in complete infrastructure takeover, data exfiltration, or ransomware deployment.

Implement least-privilege IAM as a default. Start with an audit of all roles and policies with wildcard resource permissions. Use AWS IAM Access Analyzer, GCP's Policy Analyzer, or equivalent tooling to surface overpermissioned identities. For CI/CD pipelines, scope permissions to exactly what each pipeline step requires - nothing more.

Gap 04 - Secrets in version control - including "private" repos Risk tag: Credential exposure, lateral movement

Git history is permanent. That's its purpose. It's also why committed secrets are among the most persistent and underestimated vulnerabilities we find. Private repositories are not a security boundary - they become public through acquisition, contractor access, accidental visibility changes, or repository forks.

In most codebases we review, at least one of the following appears in commit history: a hardcoded database connection string, an internal API key, an AWS access key pair, or a service account credential. The presence of a .gitignore entry for .env files does not mean .env files were never committed.

Run a full historical secret scan using tools like truffleHog or gitleaks across all repositories, including archived ones. Rotate any identified secrets immediately - simply removing the commit from the current branch is insufficient if the repository has any remote history. Integrate pre-commit hooks and GitHub's native secret scanning to prevent future occurrences. Transition to a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for all application credentials.

Gap 05 - No security logging or alerting on critical paths Risk tag: Undetected breach, delayed incident response

The majority of startups we assess have no effective way to answer a basic question: has anything unauthorized happened in the last 30 days? CloudTrail may be enabled, but no one is reviewing it. Application logs may exist, but they're not centralized or monitored. There's no alerting on authentication anomalies, no detection for privilege escalation, no visibility into unusual data access patterns.

This matters because the average time to detect a breach in organizations without security monitoring is measured in months, not days. By the time a compromise is discovered, the attacker has typically established persistence, exfiltrated data of interest, and in some cases monetized access to third parties.

At minimum: enable AWS CloudTrail with log integrity validation, centralize logs into a SIEM or log aggregation platform (Datadog, Panther, Elastic), and configure alerts for high-signal events - root account usage, IAM policy changes, large data exports, and failed authentication spikes. Security logging is not a compliance checkbox; it's the foundational requirement for knowing your environment.

The question isn't whether a 30-person startup is a target. The question is whether the cost and friction of attacking you exceeds what an attacker expects to gain. Fixing these five gaps doesn't make you invulnerable - it makes you a significantly harder target than the next company on the list.

None of these gaps require a dedicated security team to address. They require clarity on ownership, a few deliberate technical decisions, and the willingness to treat security as an operational discipline rather than an audit event.

The companies that get this right early don't just avoid breaches - they build the organizational muscle that scales. Security posture, like technical debt, is far cheaper to establish proactively than to remediate after the fact.

Start with one gap. Fix it completely. Move to the next.