The Startup Security Audit Checklist

A startup security audit is not a penetration test and does not need a consultant to begin. It is a review of the twenty controls that account for almost every breach a company your size actually suffers — who can reach production, where the secrets live, what is exposed to the internet, whether the backups restore, what the pipeline is allowed to do, and whether anyone would notice an incident. Most teams can close the majority of the gaps in a week at no cost, because the failures are configuration defaults rather than missing tooling. This guide is the twenty-item checklist, the four defaults nearly every startup gets wrong, what to fix this week for free, what needs budget and roughly how much, and what your first enterprise customer will ask you to produce.

Key takeaways: Run the checklist below before you buy any security tooling — most findings at this stage are settings, not products. The four defaults that cause the most damage are over-broad admin access, a database reachable from the internet, secrets committed to git history, and backups nobody has restored. Roughly two-thirds of the list is free and fits in a week; the rest costs about ₹8,000–25,000 a month in infrastructure for an early-stage product, with a penetration test at ₹1.5–5 lakh and SOC 2 well beyond that. Your first enterprise customer will ask for documents, not opinions — write the policies while the company is small. Ranges below are INFOCRUD planning figures reviewed in September 2026.

What a security audit means at this stage

For a company with a handful of engineers and a live product, an audit is an inventory exercise. You are answering four questions in order: what do we have, who can reach it, what would an attacker get, and would we know. Everything in the checklist is one of those four questions applied to a specific surface.

What it is not is a penetration test. A pen test is valuable and you will eventually be asked for one, but paying someone ₹2 lakh to discover that your database accepts connections from anywhere and four people share an admin login is an expensive way to read a checklist. Do the checklist first; the pen test is worth far more once it is done.

The honest framing: at seed stage you are not defending against a targeted attacker. You are defending against automated scanning, a leaked credential, and a departed employee — in roughly that order of likelihood. The list below is ordered by what that reality actually rewards.

The 20-item checklist

Score each item yes or no. No partial credit — "mostly" is a no, and the items where a team hesitates are reliably the ones that matter.

Access — who can reach what

1. Phase 01Multi-factor authentication on every account that can spend money or reach production. Cloud console, source control organisation, domain registrar, payment provider, email admin. The registrar is the one teams forget, and it is the one that loses you the domain
2. Phase 02No shared logins. Named accounts for every person, always. A shared account means no audit trail and no clean way to remove one person's access
3. Phase 03The cloud root account is locked away. MFA on, no access keys attached, not used for daily work, and the recovery email is a company address that outlives any individual
4. Phase 04Least privilege is at least attempted. Separate roles for people and for machines; nobody holds full administrator access because it was faster on day one
5. Phase 05Offboarding runs the same day. A written list of every system a person can reach, and revocation within 24 hours of their last day — including the personal devices holding tokens

Secrets — where the credentials live

1. Phase 01No secrets in the repository. Scan the full history, not the current files — a key removed in a later commit is still in git and still valid until it is rotated
2. Phase 02Secrets come from a manager at runtime. AWS Secrets Manager or SSM Parameter Store, injected as environment variables at deploy, never committed and never pasted into chat
3. Phase 03Separate credentials per environment. Staging must not be able to read production data. This one item prevents a large share of real-world data exposure, because staging is always the less careful environment
4. Phase 04Anything ever exposed has been rotated, and everything else has a known rotation date. "We think it was only internal" is not a rotation policy

Network and compute — what the internet can reach

1. Phase 01The database is not publicly reachable. Private subnet, security group restricted to the application, access for humans through a bastion or session manager. A strong password is not a network control
2. Phase 02No security group allows 0.0.0.0/0 except on 443 at the load balancer. In particular, no open SSH and no open database port, including "temporarily, for debugging"
3. Phase 03Object storage is private by default. Public buckets, public snapshots, and world-readable file links are among the most commonly scanned-for mistakes on the internet
4. Phase 04Patching happens on a schedule. Use managed services where you can so somebody else patches them; where you cannot, rebuild images on a cadence rather than when something breaks

Data — what you hold and whether you could get it back

1. Phase 01Encryption at rest and in transit. On by default for managed services, HTTPS everywhere with HSTS, no internal service quietly speaking plain HTTP
2. Phase 02Backups are automated, and someone has restored one. An untested backup is not a backup. Restore into a scratch environment, time it, and write down how long it took
3. Phase 03You have a data inventory. What personal data you hold, where it lives, why you have it, and how long you keep it. Also the deletion path, because a customer will eventually ask you to use it
4. Phase 04Production data is not copied into staging or onto laptops. Use generated or masked data. This is the most common way real customer records end up somewhere nobody is protecting

Pipeline and code

1. Phase 01Production deploys go through the pipeline, not a laptop. A deploy from one engineer's machine bypasses every control you built and cannot be audited afterwards. If your CI/CD setup is not yet the only path to production, that is the higher-value fix
2. Phase 02Branch protection is on and dependency alerts have an owner. No direct pushes to the main branch, review required, and automated dependency scanning whose alerts a named person triages weekly rather than a bot that everyone has muted

Monitoring and response

1. Phase 01Audit logging is on, retained, and alarms reach a human. Cloud audit trails enabled across regions and written somewhere the compromised account cannot delete them; alerts for error-rate spikes, repeated authentication failures, and an unexpected billing jump — the last being the fastest signal of crypto-mining on stolen credentials. And one page of written incident plan: who is called, who can revoke access at 2am, and what you tell customers

How to read your score. Below 12, stop feature work for a week. Between 12 and 17 is the normal position for a funded startup that has not done this before, and the remaining items are usually the expensive-to-fix ones. Above 17, your next useful spend is a penetration test, because the checklist is no longer where the risk is.

The four defaults every startup gets wrong

These four appear in nearly every infrastructure review we run, and each is a default that was reasonable on day one and never revisited.

The pattern is the same in all four: a setting chosen under delivery pressure, never re-examined, and invisible until it fails. That is exactly why this works as a checklist rather than as a project — nobody needs to be persuaded of the principle, somebody just has to look.

What you can fix this week, for free

Two-thirds of the list costs nothing but attention. This is a realistic week for one engineer alongside normal work.

Two notes on doing this well. Write down what you find, including the items you decide not to fix — the document is the beginning of the security policy your first enterprise customer will ask for, and a decision recorded with a reason is defensible in a way that an oversight is not. And run the offboarding checklist against people who have already left. That audit finds live access more often than anyone expects, and it is the single most common way a former contractor still holds a production key.

What needs budget, and roughly how much

The remaining third costs money. Most of it is small and recurring; a little of it is large and occasional.

Sequence matters more than the totals. A startup with an early-stage product typically ends up at roughly ₹8,000–25,000 a month for the infrastructure items, and everything above that line should be pulled forward by a specific customer requirement rather than pushed by a vendor. Buying scanning tools before completing the free checklist is the most common way security budget gets wasted at this stage: the tool reports what you already know and nobody has time to act on it.

What your first enterprise customer will ask for

The trigger for most startup security work is not an attack. It is a procurement team, and the thing that stalls deals is documentation rather than controls.

• A security questionnaire, commonly 80 to 200 questions in their format, not yours. Answering the first one takes a week; answering the next takes a day if you kept the answers
• SOC 2 Type II or ISO 27001, or a credible plan with a date. Many enterprise buyers will accept compensating evidence from a smaller vendor, but only if you offer it before they have to ask
• A penetration test report from the last twelve months, with the remediation status of each finding — the remediation column matters more than a clean report
• A data processing agreement, a sub-processor list, and a clear statement of where data physically lives. Indian customers will increasingly ask this under the country's data protection law; European ones will ask under GDPR
• Breach notification terms, usually a commitment to notify within 24 to 72 hours. Do not sign one you have no mechanism to honour
• Written policies — access control, offboarding, incident response, business continuity with a stated recovery time and recovery point objective. Three pages each is fine. Nothing is worse than no document

Budget three to eight weeks for a first enterprise security review, and start writing the policies before a deal is on the table. Every one of those documents describes something the checklist above already made you do; the work is transcription, and it is far cheaper when it is not blocking revenue.

Mistakes that make security work worse than none

• Buying tools before finishing the free list. A dashboard of alerts nobody owns is a cost, not a control
• A pen test with no remediation budget. The report then becomes a written record of known, unfixed vulnerabilities — worse in due diligence than never having tested
• Security theatre in the deploy path. Controls that make shipping painful get routed around, and the workaround is always less safe than the thing it bypassed
• Policies nobody follows. An offboarding document that is not run is evidence that you knew and did not act
• One person holding all the access. The same key-person risk investors price in your engineering team is a security finding too — including the case where that person is unreachable during an incident
• Treating compliance as security. SOC 2 proves you follow your own process. It does not prove the process is good, and a compliant company with a public database is still breached

The pattern that works is unglamorous and continuous: a scheduled review rather than a project. On Offybox, access, environments and runbooks were documented as the system was built rather than reconstructed afterwards — which is why a security questionnaire there is a copying exercise rather than an investigation.

Frequently asked questions

How often should a startup run a security audit?

Run the checklist quarterly, and additionally whenever someone leaves, you add a new cloud service, or you sign a customer with security requirements. It takes an afternoon once the first pass is done. An external test belongs on a yearly cycle, and starting it before the internal list is clean wastes most of the fee.

Do we need SOC 2?

Only when a specific deal requires it. SOC 2 is a sales unlock, not a security programme — it certifies that you follow the controls you described. Expect ₹8–40 lakh in the first year across tooling, auditor and internal time, and three to nine months of elapsed effort. If a customer is asking, negotiate: many accept a completed questionnaire, a recent pen test and a dated commitment from an early-stage vendor.

What does a startup security audit cost if we hire someone?

An external infrastructure review at this scale is typically ₹40,000–1.5 lakh and takes one to two weeks, delivering a prioritised findings list rather than a scan dump. A full penetration test is ₹1.5–5 lakh depending on scope. The review is the better first purchase, because it tells you which of the twenty items are actually unclosed in your environment.

We use managed services. Are we not covered?

Partly, and the split is worth knowing precisely. The provider secures the infrastructure; you remain responsible for identity, permissions, network configuration, your data and your code. Nearly every cloud breach reported at startup scale falls on the customer side of that line — an over-permissive role, an exposed bucket, a leaked key — not on the provider's.

Our product is pre-revenue. Is this premature?

Items 1 through 9 are not. They cost nothing, take a day, and protect the two assets you already have: the code and the cloud account someone else can spend from. A compromised account running mining workloads produces a bill in the lakhs within days, and the cleanup consumes a sprint you cannot spare. Defer the paid items; do not defer access and secrets.

What do we do if we think we have been breached?

In order: rotate the credentials you suspect, revoke active sessions and keys, preserve the logs before anything rotates them out, and only then work out what happened. Do not rebuild the affected systems before capturing the evidence. Check your contracts and your jurisdiction's notification obligations on the same day, because those windows are short and they start when you discovered it, not when you finished investigating.

Who should own security in a small team?

One named engineer, with a recurring calendar slot and explicit permission to spend the time — not a committee, and not "everyone". At around fifteen to twenty engineers this becomes a part of someone's formal role. Before that, ownership means running the checklist on schedule and triaging the alerts, which is a few hours a month.

The bottom line

Security at startup scale is not a product you buy, it is a set of defaults you revisit. The twenty items above cover what actually goes wrong at this size, roughly two-thirds of them are free, and the four that cause the most damage — broad admin access, a reachable database, secrets in git, untested backups — are each an afternoon's work to close. Do that first, write down what you found and what you chose not to fix, and only then spend money, in the order the list sets out. The startups that get hurt are almost never the ones that lacked a tool. They are the ones where nobody had looked.

We are opening a limited number of free infrastructure security reviews this quarter — a working session against this checklist on your actual environment, with a prioritised findings list and costed fixes at the end. Book a review slot, or see how ongoing access, patching and monitoring are usually handled once the first pass is done under managed DevOps.