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.