A practical security baseline for a small team

Start with identity, because that is where the incidents start

1. 01Enforce phishing-resistant multi-factor authentication on email, identity provider and remote access. Passkeys or hardware keys where you can; app-based codes as the floor. SMS is the last resort, not the plan.
2. 02Remove standing administrative rights. Admin work happens through a separate account, elevated when needed.
3. 03Inventory every account with access, including contractors, service accounts and shared logins. Delete what you cannot attribute to a person or a documented process.
4. 04Write the leaver process down and make it a checklist with a named owner. Orphaned access is often a process gap rather than a technical one.

If you only ever complete one section of this article, complete this one.

Then make patching boring

The goal is not perfect currency. It is a known, defensible cadence with the internet-facing edge treated as urgent.

• —Internet-facing systems — VPN appliances, firewalls, web servers, remote access gateways — patched on a defined short clock.
• —Endpoints on automatic updates, with a report you actually read for the machines that fail to apply them.
• —A named owner per system, so no device sits between two people who both assume the other has it.
• —A written exception list for what cannot be patched, with the compensating control beside it.

Make backups something you have tested, not something you have bought

An untested backup is a belief. Ransomware specifically targets backups reachable from production credentials, so both isolation and restore practice matter.

1. 01Keep at least one copy that production credentials cannot delete or encrypt — immutable or genuinely offline.
2. 02Restore something real on a schedule, and write down how long it took.
3. 03Confirm the backup covers the systems people actually depend on, including SaaS data and configuration, not just servers.
4. 04Record the restore time against your recovery target and close the gap, or change the target honestly.

Give yourself the ability to see what happened

You do not need a security operations centre. You need enough retained log data to answer, after the fact, who signed in, from where, and what changed.

• —Identity provider sign-in logs, retained long enough to investigate something discovered weeks later.
• —Endpoint detection with alerts going somewhere a person reads, not only to a dashboard.
• —Email security events, including mailbox rule creation and forwarding changes — a classic post-compromise move.
• —Change history for cloud and infrastructure configuration.

Rehearse the response before you need it

An incident plan is tested by reading it aloud with the people who would use it. Ninety minutes around a table finds the gaps that matter: nobody has the phone number, nobody can authorise disconnecting a system, nobody knows who tells clients.

• —Who decides to disconnect or shut something down, and who can be reached at 2am.
• —How you communicate if email and chat are the compromised systems.
• —Which contractual and regulatory notifications apply, and inside what window.
• —Which external help you would call, agreed in advance rather than mid-incident.

Only then reach for the next layer

Network segmentation, application allow-listing, formal frameworks and third-party assurance are all worth doing. They are also the controls most often bought first as evidence of seriousness, while the basics stay half-finished.

A useful test before any new security purchase: name the specific attack path it closes, and confirm no earlier item on this list leaves that path open anyway.