A startup security checklist: your first week, month and quarter

This checklist is for founders and engineering leads at startups where nobody’s full-time job is security. It is split into three phases, your first week, first month and first quarter, and every item has an owner and a clear “done when”. By the end you will have a baseline that blocks the most common ways small companies get breached, and most of the groundwork for SOC 2 or ISO 27001.

On this page

• Before you start: pick one owner

• First week: close the obvious doors

• First month: know what you run and who can reach it

• First quarter: make it repeatable

• Common mistakes to avoid

• How the checklist maps to SOC 2 and ISO 27001

• How NexusVoid helps

Before you start: pick one owner

Security without an owner does not happen. Pick one person, usually the CTO or a senior engineer, and give them a few hours a week. They do not do every task. They make sure every task has a name next to it, a date and proof.

• One tracker: a single spreadsheet or board with the task, owner, due date and a link to proof it is done.

• Proof, not promises: keep the screenshot, export or config that shows each item is done. Customers and auditors will ask for it.

• A weekly 15-minute check: what got done, what is blocked, what changed in the stack.

Most first-week items are settings that take minutes to an hour each. Later items take longer but mostly need doing once, then keeping up.

First week: close the obvious doors

These changes block the usual ways startups get hurt: stolen passwords, leaked keys, forgotten accounts and public storage. Do them before anything else.

Use the strongest MFA you can for admins

Any MFA is far better than none. For admins and anyone with production access, prefer phishing-resistant methods such as hardware security keys or passkeys over SMS codes, which can be phished or moved to an attacker’s phone through a SIM swap. CISA describes phishing-resistant MFA as the standard to aim for.

Rotate, do not just delete

If a scanner finds an API key in your git history, deleting the file is not enough. The key is still in the history and may already have been copied. Revoke it at the provider, issue a new one, and keep it in a secrets manager or your platform’s environment settings.

Root accounts are for emergencies

The AWS root user and the top-level admin accounts in Google Cloud or Azure should almost never be used. Give them strong MFA, store the recovery details somewhere safe, and do daily work through named accounts with narrower permissions.

First month: know what you run and who can reach it

With the doors closed, the next job is visibility. You cannot protect what you do not know you run, and an inventory is one of the first things an auditor asks for.

Laptops are production too

An engineer’s laptop often holds source code, cloud credentials and copies of customer data. Turn on full-disk encryption (FileVault on macOS, BitLocker on Windows), require a screen lock and keep the operating system updated. Beyond a handful of people, use device management or a monitoring agent so you can see the state of each machine instead of asking.

A backup you have never restored is a guess

Most teams have backups switched on. Far fewer have restored from one. Pick a date, restore your production database into a separate environment, and write down how long it took and what broke. That number is your real recovery time, and the record is evidence an auditor will accept.

Look at yourself from the outside

Attackers start with what is public: forgotten subdomains, staging servers, old marketing sites and exposed admin panels. List every domain you own, check what each one serves, and take down what nobody needs. Then fix what is left, most exposed and most important first.

First quarter: make it repeatable

The first month gets you to a decent baseline. The first quarter keeps you there as the team grows and the product changes. It is also where your security work starts to look like a program to customers.

Fix deadlines people will actually meet

Pick targets you can keep, write them down and measure against them. A common shape is days for critical issues, a few weeks for high and a quarter or so for medium. The exact numbers matter less than having them, tracking them and recording why any exception was accepted.

Policies should describe what you actually do

A handful is enough to start: information security, access control, acceptable use, incident response, vendor management and data retention. Keep each one short. A policy that describes a process you do not follow is worse than none, because an auditor will test it and a customer may rely on it.

Rehearse the incident plan once

The plan needs four things: who is in charge, how to reach them at 2am, how to decide whether customers must be told, and where notes are kept. Check what your contracts and the laws that apply to you require for notification. Then spend an hour walking through a realistic scenario, such as a leaked cloud key or a stolen laptop. The gaps appear fast.

Common mistakes to avoid

• Buying tools before naming owners: a scanner nobody reads is a cost, not a control.

• Treating a scan as a pentest: scanners find known issues; a pentest also tries to chain them and abuse business logic.

• Copying long policy templates: auditors test what the policy says, so every line you cannot follow becomes a finding.

• Skipping offboarding: accounts of people who left are an easy way in and an easy audit finding.

• Waiting for a customer to ask: when a big deal needs SOC 2, the clock is already running.

• Doing it once: a checklist finished in March and forgotten by June protects nothing and proves nothing.

How the checklist maps to SOC 2 and ISO 27001

None of this is compliance theater. It is the core of what both frameworks ask for. SOC 2 is an attestation report against the AICPA’s Trust Services Criteria, issued by an independent CPA firm, and security is the one category every report must cover. ISO 27001 is a certifiable standard for an information security management system, with reference controls listed in its Annex A. They use different words for the same ideas.

The checklist is not the whole of either framework. ISO 27001 also requires the management system itself, including a defined scope, a risk method, internal audit and management review. But it covers most of the technical work. And if you keep proof for each item from day one, much of your audit evidence already exists when you start. A SOC 2 Type 2 report covers how controls operated over an observation period, commonly three to twelve months, so the earlier evidence starts, the sooner you can be audited.

How NexusVoid helps

This checklist is the program NexusVoid runs for you. Instead of a spreadsheet that goes stale, the work runs continuously and the proof is collected as it happens. If you have no security hire, NexusVoid acts as your CISO. If you have one, it takes most of the routine off their plate.

• Argus covers the outside-in and code items: it starts from your public attack surface with no credentials or installs, works inward through code, dependencies, cloud and secrets, opens fixes as pull requests and retests when they merge.

• Aegis covers the proof: tailored policies, evidence collected from your cloud, GitHub, identity provider and devices, a risk register, vendor management, device monitoring through an agent, employee training and auditor-ready exports.

• Striker covers the pentest: vulnerability assessment for web, API, cloud and mobile, pay per scan, with a report in under 60 minutes.

Early-stage startups get all three. Growth and scale startups get Your Autonomous CISO, the full 22-module program. Either way, a person on your team approves the decisions that matter, and your auditor stays independent.

Frequently asked questions

We have five engineers. Is this overkill?

No. The first-week items are mostly settings, and they block the attacks small companies actually face: stolen passwords, leaked keys and public storage. Automated attacks do not check your headcount before trying a leaked credential. Do the first week now, then pace the month and quarter items to your sales cycle.

What should we do first if we only have one afternoon?

Enforce MFA on your identity provider, email, cloud and code host. Lock down your cloud root accounts. Remove accounts for anyone who has left. Those three changes close some of the most common ways into a young company, and each takes minutes rather than days.

Do we need a pentest if we already run a scanner?

Eventually, yes. Scanners find known vulnerabilities and misconfigurations quickly and should run continuously. A pentest adds someone trying to chain issues together and abuse your business logic, which scanners cannot judge. Enterprise customers often ask for a recent pentest report. Run scanners from the first month and a pentest within the first quarter.

When should we start SOC 2?

Start the baseline now and the audit when customers need it. A Type 2 report covers an observation period of several months, so teams that already have controls running and evidence accumulating move much faster when the request arrives. Some teams begin with a Type 1 report, which looks at control design at a single point in time.

Who should own security at a startup with no security team?

Usually the CTO or a senior engineer, with a few hours a week set aside. The owner does not do every task; they make sure every task has a name, a date and proof. As you sell to larger customers the role grows, and that is the point to consider a fractional CISO, a vCISO or an autonomous CISO.

If you want a second pair of eyes on where you stand, or you would rather have this checklist run for you, talk to a founder. Book a call at /contact.