Ideas, observations, and useful links from CTS Companies.

“We have backups” sounds like an answer, but it is usually the beginning of the conversation.

A backup can exist and still be too old, too slow to restore, too dependent on one administrator, or too connected to the same environment it is meant to rescue. The practical question is: if the primary system disappeared this morning, what would we do first, and how long would that step take?

That question shifts attention from the product to the recovery sequence. Who declares the incident? Who knows which systems matter most? Where are the instructions? What can be restored without waiting for a vendor representative to explain the interface?

For a 20–100-person organization, a small recovery exercise is often more informative than another backup dashboard. Pick one important system. Restore a representative file or service. Write down every surprise.

The backup is the stored data. The real safeguard is the organization’s ability to use it.

Multi-factor authentication is often treated like a light switch: turn it on, receive a compliance-shaped glow, and move on.

But MFA changes the question. Once a business asks people to prove who they are with more than a password, it also has to decide what happens when the phone is lost, the authenticator is replaced, an employee leaves, or an attacker convinces someone to approve a request.

The useful question is not “Do we have MFA?” It is “Can the right person recover access without creating a new hole?” That requires documented recovery, a short list of people who can reset authentication, and a review of which accounts have more power than they need.

MFA is valuable because it makes stolen passwords less useful. It becomes much more valuable when the surrounding process does not turn account recovery into an informal help-desk conversation with no record.

For a small business, the next step after enabling MFA is simple: test the recovery path with someone who is not the person who designed it.

1. CISA on stronger MFA

CISA makes the useful distinction that MFA is not one uniform technology. The interesting implication is that “MFA enabled” is an incomplete operational description; the method and the recovery process matter.

2. CISA guidance for small and midsize organizations

This guidance connects backups, MFA, least privilege, and vendor access. It is a good reminder that security failures often cross organizational boundaries.

3. The FTC’s small-business cybersecurity guide

The FTC’s advice is intentionally unglamorous: update software, back up data, train people, and plan for incidents. That is precisely why it is useful.

4. NIST Cybersecurity Framework

The framework is best read as a way to organize conversations, not as a badge. Its categories help a leadership team ask what is known, protected, detected, responded to, and recoverable.

5. FIDO’s passkey overview

Passkeys are a useful example of security changing the user experience instead of merely adding another warning. The business question is where they fit in the identity lifecycle.

6. CISA StopRansomware

The value here is not the scary headline. It is the emphasis on preparation, response, and recovery before an incident forces a rushed decision.

7. NIST’s cyber history

The history shows that incident response became a discipline because organizations needed a way to coordinate, not because someone found a perfect security product.

8. FTC vendor-security guidance

Vendor access deserves the same clarity as employee access: who has it, why, for how long, and what happens when the relationship changes.