Cybersecurity Basics for Teams in 2026: The Controls That Actually Matter

Why do the same basics keep failing?

Because most teams implement the label rather than the control. They have MFA, but the phishable kind. They patch, but on a monthly cadence that ignores which flaws are actually being exploited. They have backups nobody has ever restored from. The gap between "we have it" and "it works" is where nearly every incident lives.

This is not a list of everything you could do. It is a short list of what changes outcomes, with the specific failure mode of each and what published guidance recommends instead. Where a claim comes from a standard, the standard is named so you can check it rather than take my word for it.

Which controls are worth doing first?

Ordered by what they prevent relative to what they cost. If you only get through the first three this quarter, you will still have moved further than a team that started everything at once and finished nothing:

Note what is absent: annual awareness training as a headline control, antivirus procurement, and password rotation policies. The first has weak evidence as a standalone measure, the second is table stakes, and the third is actively discouraged by current guidance — see below.

Why is most MFA still phishable?

This is the single most misunderstood control on the list, so it is worth being precise. "MFA" is not one thing, and the common kinds do not survive a competent phishing attack.

An adversary-in-the-middle phishing kit does not steal your code and use it later. It proxies the real login page in real time: you type your password on the attacker's server, it forwards it to the real site, the real site asks for your one-time code, the attacker relays that prompt to you, you type it, and the attacker forwards it. They then capture the session cookie the real site issues. Your second factor worked perfectly, and it made no difference — the attacker now holds a valid authenticated session.

The reason FIDO2 holds is structural rather than a matter of degree: during registration the authenticator binds the key pair to the site's origin, and it will only sign a challenge for that origin. A phishing site on a different domain cannot obtain a valid signature, because the browser will not ask the authenticator to produce one. There is no code for the user to be tricked into relaying, so user vigilance stops being the control.

On passwords themselves, NIST SP 800-63B changed the advice years ago and many policies have yet to catch up: stop forcing periodic rotation, stop mandating composition rules, and instead screen new passwords against lists of known-breached values. Forced rotation produces predictable patterns, which is the opposite of the goal.

How do you patch when you can't patch everything?

You cannot patch everything, and treating every CVE as equally urgent guarantees the important ones get lost in the queue. Severity scores describe how bad a flaw could be in theory; they say nothing about whether anyone is exploiting it.

The practical fix is to let observed exploitation drive the order. CISA maintains the Known Exploited Vulnerabilities catalogue, a public list of flaws confirmed to be exploited in the wild. It is free, machine-readable, and a far better prioritisation signal than severity alone.

1. 1Anything on the KEV catalogue that touches an internet-facing system, first. This is the category that gets organisations breached at scale.
2. 2Anything internet-facing with a public exploit, next — edge devices, VPN concentrators, mail gateways, anything unauthenticated.
3. 3Everything else on a predictable cadence, accepting that it will lag.

The second bullet deserves emphasis. Edge devices are consistently attractive because they are exposed by definition, often run vendor firmware nobody inventories, and frequently sit outside the patch process that covers laptops and servers. If you do not know what of yours is reachable from the internet, that inventory is the prerequisite for everything else here.

What makes a backup actually survive ransomware?

The 3-2-1 convention — three copies, two media types, one off-site — is still a reasonable baseline, but ransomware changed which part matters. Modern operators look for backups before they encrypt, precisely because destroying them is what makes payment likely.

So the property that counts is not off-site. It is whether the backup can be reached and destroyed using credentials that exist on the production network. If your backup server is domain-joined and your backup account is an ordinary domain account, an attacker with domain admin already owns your recovery plan.

• At least one copy offline or immutable — write-once storage, object lock, or media genuinely disconnected.
• Backup credentials separate from production identity: not the same directory, not the same admin.
• Test the restore, on a schedule, end to end. An untested backup is an assumption, not a control.
• Measure how long a full restore actually takes. Teams routinely discover the real figure during the incident, which is the worst moment to learn it.
• Back up the things nobody remembers: identity configuration, firewall rules, and the documentation describing how to rebuild.

What should you log if you can only log a little?

Logging prevents nothing. It determines whether, after an incident, you can answer what was accessed and when — which is the question regulators, customers and your own leadership will ask, and the one you cannot answer retroactively.

On Windows, a small number of event sources carry most of the investigative value:

Two settings matter more than the list. Command-line capture in 4688 is off by default and the event is close to useless without it. And retention has to exceed the time an intrusion typically goes unnoticed — if you keep thirty days and the intrusion started in month three, the evidence is gone before you start looking.

What do you do in the first hour of an incident?

The plan does not need to be elaborate. It needs to exist before you need it, and to be written down somewhere reachable when the network is not.

1. 1Contain without destroying evidence. Isolate affected machines from the network, but do not power them off — memory-resident evidence disappears when you do, and it is often the only record of what ran.
2. 2Preserve logs immediately. Export before rotation, before retention expiry, and before an attacker with access clears them.
3. 3Know who to call. Legal, insurer, and any incident response retainer. Those numbers should be on paper, not only in the systems that may be down.
4. 4Assume identity is compromised. Revoke sessions and rotate credentials for affected accounts; a password change alone does not invalidate a stolen session cookie.
5. 5Keep a timeline from the first minute. Reconstructing what you did and when, days later, is far harder than writing it down as you go.

What to take away

• MFA is not a checkbox. Only FIDO2 or WebAuthn survives real-time relay; codes and pushes do not.
• Let exploitation drive patching, not severity scores or the calendar. The CISA KEV catalogue is free and made for this.
• A backup is only a control once you have restored from it and measured how long it took.
• Log authentication and process creation, turn on command-line capture, and keep it long enough to matter.
• Write the first hour down before you need it, including phone numbers that work when the network does not.
• Stop rotating passwords on a schedule. NIST stopped recommending it; the practice produces predictable passwords.

None of this requires a large team or a large budget. It requires picking the right few things and finishing them. If you want to build the practical side — recognising a phishing campaign, reconstructing what happened from logs — that is what our Phishing with OSINT and Threat Hunting paths cover hands-on.