Imagine you have ten employees, a product customers are starting to trust, and a dozen online tools keeping the business running. Then someone leaves the company, a developer accidentally shares a key, or a potential customer asks how you protect their information. Where do you start?
Most small teams do not need a complicated answer. They need to know what they own, who can get into it, what would alert them to trouble, and how they would recover. This guide turns those questions into 24 practical checks you can actually work through.
It is a starting point, not an audit or a guarantee that every risk is covered. Use it alongside the NIST small business guide and CIS Implementation Group 1 to prioritize what matters to your company.
If you can do only three things this week
Protect your most important accounts. Turn on multi-factor authentication for email, cloud administration and code hosting.
Check access. Make sure former employees and contractors no longer have accounts they should not have.
Prove your backups work. Restore a sample file or a small piece of data instead of trusting a successful backup notification.
Know what you are protecting
Before buying another tool, get clear on the systems and information your business relies on.
Write down the cloud accounts, laptops, code repositories, customer databases and business apps your team uses. Start with a shared sheet if that is easiest.
Keep on file: A current system list with an owner for each entry.Find the customer records, payment information, credentials, code and documents that would cause real problems if exposed or deleted.
Keep on file: A short list of sensitive data, where it lives and who can access it.This does not require a full-time security hire. A founder or technical lead can own the checklist and make sure tasks do not get forgotten.
Keep on file: A named owner and a recurring check-in on the calendar.Look at hosting, support, analytics and other services that touch customer data or production systems. Know what each provider can see.
Keep on file: A vendor list with access levels and the date of the last review.Make accounts harder to break into
If an attacker gets into a key account, the rest of your security stack may not matter.
Start with cloud administrators, email, code hosting, password managers and finance tools. Prefer phishing-resistant methods such as security keys or passkeys where possible.
Keep on file: MFA enforcement settings and any remaining exceptions.Stop sharing passwords in chat or reusing them across tools. Store unique credentials in a team password manager, and assign ownership for shared accounts.
Keep on file: A password manager policy and list of managed accounts.Make offboarding a same-day task according to your risk and policy. Include contractors and temporary accounts, not just employees.
Keep on file: An offboarding record with the systems checked and removal times.A developer who once needed full access may not need it today. Review privileged accounts regularly and remove permissions that no longer serve a purpose.
Keep on file: A dated privileged-access review with actions taken.Keep laptops and code in good shape
Most growing startups have a lot happening on a small number of devices and repositories.
Enable automatic updates, disk encryption and screen locks. Use endpoint protection appropriate for your team, especially on devices with production access.
Keep on file: Device inventory and current security configuration.Require peer review before important changes go live. Limit who can merge into production branches and review repository membership.
Keep on file: Branch protection settings and example reviewed pull requests.API keys, database passwords and tokens should live in a secrets manager or other approved secure store, not in source files or chat messages.
Keep on file: A secrets-handling policy and scan results or remediated findings.Run relevant dependency, container and infrastructure scans. Prioritize exposed, exploitable and business-critical issues instead of chasing every low-priority alert.
Keep on file: A vulnerability backlog with owners, severity and closure dates.Protect your cloud and customer data
Your cloud provider protects its infrastructure, but your team still owns many of the settings inside your account.
Review identity permissions, storage-sharing settings, network rules and unused services. Fix anything open to the internet without a good reason.
Keep on file: A dated configuration review and remediation notes.Use encryption in transit and at rest for customer information, and manage access to encryption keys.
Keep on file: Applicable configuration exports or screenshots.Do not retain information forever just because storage is cheap. Create reasonable retention and deletion rules that meet contractual and legal needs.
Keep on file: A retention policy and records of completed deletions.Keep test environments, demo data and developer access from exposing live customer information unnecessarily.
Keep on file: An environment diagram and access boundaries.Know when something looks wrong
A security alert is useful only if somebody notices it and knows what to do.
Start with administrator changes, unusual sign-ins, code repository events and important cloud activity. You do not need every log from every system on day one.
Keep on file: A log-source list and retention settings.Decide who handles an alert during business hours and what happens outside them. A shared inbox with no owner is not an incident process.
Keep on file: An alert routing rule, owner list and example dispositions.Include who to contact, how to preserve evidence, when to isolate a system and who makes customer communication decisions.
Keep on file: A current incident contact sheet and response procedure.Run through a stolen administrator account or exposed API key. Ask what the team would do in the first hour, then write down the gaps.
Keep on file: A dated tabletop exercise and assigned follow-up actions.Be ready to get back to work
A backup is not a recovery plan until you can restore something from it.
Include important business files, databases and configuration. Protect backup access so one compromised account cannot erase everything.
Keep on file: Backup schedules, coverage and access settings.Pick a representative system or dataset and actually recover it. Confirm that the result is usable, not just that a job marked itself successful.
Keep on file: A restore test showing the date, result and any fixes needed.For your most important services, decide how long you can be offline and how much data loss is tolerable. Use those numbers to guide improvements.
Keep on file: Recorded recovery objectives and service priorities.New employees, vendors, features and markets change your risk. Revisit the list after major changes and at a regular interval.
Keep on file: A dated review log and updated owners.A simple first-month plan
Do not try to finish all 24 items in one afternoon. Give each task a real owner and spread the work over the first month. Some items will need ongoing attention after that.
Find what matters
List important systems, identify sensitive data, assign ownership and enforce MFA for your most powerful accounts.
Close easy gaps
Remove old access, review admin permissions, protect laptops and clean up secrets and repository settings.
Make problems visible
Review cloud exposure, configure useful logging, name an alert owner and prioritize major vulnerabilities.
Practice what happens next
Test a restore, walk through an incident scenario and set dates for recurring reviews.
Track actions, not just completed checkboxes
A percentage complete can make a dashboard look impressive. It does not tell you whether a control will work on a difficult day. Look for a practical outcome behind each configuration.
| Easy to count | What you really want to know |
|---|---|
| Employees with MFA enabled | Are important accounts protected, including administrator accounts and exceptions? |
| Vulnerabilities found | Are the riskiest findings assigned, fixed and checked again? |
| Alerts generated | Does someone review serious alerts and record what happened? |
| Backups marked successful | Can the team actually restore a service or dataset when needed? |
| Policies published | Can employees explain what to do when something goes wrong? |
A good first measure is consistency. Can you show what happened last month, who handled it and whether the issue was resolved? That is a stronger starting point than collecting screenshots you never look at again.
Where Jutsu can help
The basics above are still your team’s responsibility. A monitoring platform can make part of the ongoing work easier once your cloud, identity, code and device activity is connected.
Jutsu’s cybersecurity solution for startups supports monitoring and investigation across supported sources. It can help your team organize security alerts and maintain a record of the activity you investigate. Coverage depends on the sources you connect and the plan you use. It is not a replacement for patching, access reviews, training or recovery testing.
Preparing for a customer audit? Read Jutsu’s SOC 2 compliance checklist and its guide to SOC 2 gap analysis. Those are separate from this general startup security checklist.
Make security something your team can keep up with.
Explore Jutsu’s startup security offering and see how supported monitoring and investigation workflows can fit into your existing processes.
Common questions
Does a five-person startup really need a security checklist?
Yes. A small team may not need enterprise security software, but it still needs to protect accounts, devices, code and customer data. Start with the basics and assign clear ownership.
What should we do first if we have almost no budget?
Inventory important systems, enable MFA on critical accounts, remove unused access, patch devices, and check that backups can be restored. Those steps address common risks without buying a large tool stack.
Do we need a SOC 2 report to be secure?
No. SOC 2 is an independent attestation report for a defined system and set of controls. This general cybersecurity checklist is useful whether or not your company plans to undergo an examination.
How often should we review this checklist?
Review important access and security alerts frequently, make changes during onboarding and offboarding, and revisit the overall plan after major business or technical changes. Choose a schedule your team can maintain.
Is buying a security platform enough?
No. Tools can identify and organize security activity, but they do not replace decisions about permissions, updates, ownership, response and recovery.
Sources and helpful reading
This article is general educational guidance. Adapt the checklist to your architecture, contracts, applicable laws and actual business risks. Checking a box is not a security certification or audit result.