Five Cyber Security Basics to Review Before Buying More Tools

Before choosing another security product, review the controls that protect accounts, access, recovery, secrets and incident decisions. CISA includes these areas in its voluntary Cross-Sector Cybersecurity Performance Goals, which are intended to help organizations prioritize a limited set of high-impact actions. The five sections below are a practical review sequence, not a complete security program.

Who this is for

This guide is for small and mid-size organizations with limited dedicated security capacity. Addressing these controls can reduce common and avoidable exposure, but the appropriate priority depends on the systems, data and threats relevant to the organization.

1. Multi-factor authentication — everywhere, not just email

An MFA review needs to extend beyond company email to remote access, administrative interfaces, cloud consoles and delivery systems. A strong factor on one entry point does not protect another account that still accepts only a password.

Systems to include in the review:

• The VPN that was set up years ago with username + password only
• Admin panels of internal tools ("it's not public, so it's fine" — until it is)
• The cloud provider console, where one compromised login can delete everything
• CI/CD systems and container registries, which can push code straight to production
• Database GUIs and remote-desktop jump hosts

Practical rule: require MFA for accounts that can change production or read sensitive data, including internal tools. CISA recommends phishing-resistant MFA where it is available and treats SMS or voice as a last-resort factor.

A rollout should begin with an inventory of accounts that reach production or sensitive data, followed by the highest-consequence systems such as email administration, cloud consoles and remote access. Review legacy authentication paths as part of the same work; otherwise an older path may bypass the stronger factor. Set the schedule from the inventory and operational constraints rather than an arbitrary universal deadline.

2. Nobody owns offboarding

When a colleague or contractor leaves, one named process should remove or adjust access across every relevant system. Unowned or forgotten accounts increase exposure because they may remain usable without an accountable person monitoring them.

What good looks like:

• A joiner/mover/leaver checklist that names every system: email, VPN, cloud, code hosting, CI/CD, databases, SaaS tools, shared drives — and a named owner for the process
• Offboarding completed the same day someone leaves, not "at the end of the month"
• A recurring review for dormant accounts, with inactivity thresholds and disablement steps defined by policy
• No shared accounts. If a team "needs" one, it needs a password manager and individual accounts instead — shared credentials can't be revoked for one person and can't be audited at all

Contractors deserve special attention: give their access an expiry date on day one. An account that disables itself when the contract ends beats a process that relies on someone remembering.

3. Backups exist, restores were never tested

A successful backup job does not establish that the required data can be restored within the business recovery window. A restore exercise tests the complete path, including access, dependencies, data integrity and timing.

Make it real with a scheduled restore drill:

1. Pick a system at random — genuinely at random, not the easy one
2. Restore it to an isolated environment, not over the top of production
3. Time it, and check the restored data actually works (applications start, recent records are present)
4. Record gaps, owners and the date for a follow-up exercise

Two details matter more than most: keep at least one copy offline or immutable, because modern ransomware looks for backups first and encrypts or deletes them before touching production; and know your recovery time honestly. If a full restore takes three days and the business can survive three hours, you don't have a backup problem — you have a business-continuity problem, and it's better to learn that in a drill than in an incident.

4. Secrets live in chat and code

API keys in chat, passwords in configuration files and tokens in git history can become long-lived credentials with a wider audience than intended. Their actual exposure depends on access and retention, but rotation is necessary when confidentiality cannot be established.

The cleanup, in order of impact:

1. Adopt a secrets manager (your cloud provider has one built in) and move production credentials into it
2. Rotate anything that ever touched a chat message or a committed file — assume it's compromised, because you can't prove it isn't
3. Add secret scanning to your CI pipeline so new leaks are caught at commit time, not in an incident review
4. Remember that deleting a secret from the latest commit doesn't remove it from git history — rotation, not deletion, is the fix

This is also a culture fix: make "never paste credentials in chat" an explicit rule, and make the sanctioned path (the secrets manager) easier to use than the shortcut.

5. No one knows what "incident response" means until the incident

You don't need a 40-page plan. You need one page that answers:

• Who is in charge when something happens?
• How do we communicate if email/Slack is compromised?
• Who can decide to take systems offline?
• Which external parties (lawyer, insurer, authorities) do we call, and when?

Print it. An incident at 2 a.m. is the wrong time to design a process.

Then test the page on a planned cadence with a time-boxed tabletop exercise. Gather the named participants, choose a plausible scenario and walk through the first decisions. Record outdated contacts, unclear authority and missing dependencies, then assign the follow-up work.

Failure patterns to avoid

• Buying tools before fixing basics. A threat-detection platform on top of shared passwords is an expensive alarm on an unlocked door.
• Treating security as a one-time project. Access reviews, restore drills and incident exercises need named owners and a cadence based on risk, change rate and applicable obligations.
• Assuming "too small to target". Internet-exposed services receive automated scanning regardless of whether an attacker selected the organization by name.
• Doing everything at once. Pick the gap that scares you most after reading this, fix it in the next 30 days, then take the next one.

Start here, not with a new tool

Several items above are process or configuration changes rather than new product purchases. Prioritize them by business consequence and current exposure, verify that the controls work, and use the result to decide which additional security investment is justified.