The First 10 Security Steps for a Business Under 20 People

For a team under twenty, account security and recovery discipline usually matter more than buying a large security stack.

A very small business gets the most value from reducing a few operational failure modes: one stolen admin login controlling everything, one unpatched device becoming a foothold, one former worker retaining access, or one incident leaving the team unable to restore critical data. The first security program should therefore be a short set of owned, testable controls rather than a shopping list. The question for each control is not 'did we buy it?' but 'who owns it, where is it enforced, and can we prove it works?'

Ten controls that change the risk profile of a team under twenty

For a team under twenty, a short list of consistently enforced controls usually reduces more risk than a shelf of security products nobody owns. Begin with the accounts and systems that could stop the business: primary email, payroll, banking, cloud storage, customer records, domain/DNS, and the devices used to administer them. Assign one named owner to each control so 'we should enable MFA' becomes a completed change with a date.

Separate administrator access from daily work

Require MFA on high-value accounts, use a shared-business password manager instead of spreadsheets or chat messages, turn on supported automatic updates, separate administrator accounts from daily work, maintain tested backups, and inventory systems that hold sensitive data. The backup test matters: a green status icon is not proof of recovery until someone restores a sample file or system and records the result.

Then make the environment legible. Inventory laptops, phones, cloud services, privileged accounts, and the sensitive data the business keeps. Give people only the access their role needs and remove it during offboarding. Establish a phishing-report route and basic email-domain protection such as SPF, DKIM, and DMARC with competent configuration. Finally, write down insurer, IT, legal, and leadership contacts so a real incident does not begin with a search for phone numbers.

Make backups prove themselves with restore tests

A 3-2-1 backup slogan is useful only when the copies fail differently and someone has proved that a restore works. Pick one critical system—accounting records, customer files, or the document store—and restore a sample into a safe location. Record how long the restore took, which credentials were needed, and whether the copy was reachable from the same administrator account as production. If ransomware or one stolen cloud-admin credential can encrypt both production and every backup, the business has copies, not a recovery plan.

Inventory data before buying another security tool

NIST CSF 2.0 gives small organizations a risk-management vocabulary without requiring an enterprise security department. Use its Govern, Identify, Protect, Detect, Respond, and Recover functions as a coverage check after the first practical controls are in place. If your plan has twenty protection tools but nobody knows who calls the insurer or how to restore data, the framework helps expose that imbalance.

A 30-day microbusiness rollout

At day 30, judge the baseline by evidence, not purchases. The team should be able to show which privileged accounts require MFA, who owns the password vault, when a restore last succeeded, which former workers still have access, where the critical-system inventory lives, and who can call the insurer or outside IT provider during an incident. Anything that cannot be demonstrated becomes the next month’s work; there is no value in declaring a maturity level the team cannot operate.

Turn the baseline into named owners and evidence

Once the baseline controls exist, assign each one a human owner and a piece of evidence. The MFA owner should be able to show which privileged accounts are enrolled; the access owner should know who can administer payroll, banking, domains, and cloud services; the endpoint owner should know which devices are unsupported; and the backup owner should have a dated restore result. For a tiny team, this ownership map is more useful than a long policy because it exposes orphaned controls immediately when someone leaves or a vendor changes.

Add one exception register for the controls you cannot yet meet. If a legacy system cannot use MFA, record why, who approved the exception, what compensating control limits access, and when the exception will be reviewed. If a vendor keeps broad access because the business lacks a better integration, record that dependency instead of pretending least privilege is complete. This gives the owner a concrete backlog and makes outside help easier to buy: a consultant can see the unresolved risks without rediscovering the environment from scratch.

Do not spend the first month writing a forty-page policy nobody follows. Pick a weekly change window and close the largest gaps: exposed admin accounts, reused passwords, unsupported endpoints, missing backups, and vendor access that never expires. Training should use the scams your organization actually receives and include a safe reporting path so a worker can say “I clicked this” quickly. Once the baseline is stable, map it to the CSF functions—Govern, Identify, Protect, Detect, Respond, Recover—to see what is missing and decide which risks justify additional tools or outside expertise.