Ideas, observations, and useful links from CTS Companies.

People often say documentation is important in the same tone they use for exercise. Everyone agrees. Very few people want to do it at the end of a long day.

The problem is not that organizations lack information. It is that the information they need most is often trapped in someone’s memory.

What memory hides

Memory is excellent at preserving the shape of a problem and poor at preserving the exact detail required to solve it six months later. Someone remembers that a vendor “handles the phones,” but not which portal contains the administrator account. Someone knows a backup exists, but not whether it has ever been restored.

These are not failures of intelligence. They are failures of external memory.

Write the reason, not just the setting

A useful record says more than “port 4 connects to the firewall.” It explains what depends on that connection and what would break if it changed. A useful access record says more than “Jane is an admin.” It explains why that access exists and when it should be reviewed.

The stranger test

Documentation is ready when a competent stranger can use it without a guided tour from the person who wrote it. The stranger does not need every detail. They need the sequence, the owner, the dependency, and the warning.

This is why short documentation often beats a giant manual. A two-page recovery map can be more valuable than a hundred pages of screenshots that no longer match the system.

Documentation as continuity

For a 20–100-person organization, documentation is not bureaucratic overhead. It is how the business preserves decisions when people are unavailable, roles change, or an incident compresses three days of work into thirty minutes.

The best time to write it is before the emergency. The second-best time is immediately after discovering that nobody knows.

Every application arrives with a persuasive little story. It will save time. It will make collaboration easier. It will finally organize the thing everyone has been organizing badly in spreadsheets.

Sometimes that story is true. The trouble begins later, when the app becomes part of the organization’s nervous system without anyone deciding that it should.

The app is never only the app

A new service creates at least five new questions. Who owns the account? Which people can administer it? What data enters it? How does it connect to email, identity, or file storage? What happens when the champion who introduced it leaves?

Those questions are not arguments against buying software. They are the difference between adopting a tool and accumulating a dependency.

The invisible support queue

Every system creates small requests. A password reset. A new employee. A former employee whose access remains open. A report that only one person knows how to produce. A vendor invoice that no longer has an obvious owner.

None of these requests feels large enough to stop a purchase. Together, they form a second job.

The exit test

Before adopting an application, ask how the organization would leave it. Can data be exported in a useful format? Are integrations documented? Does the company own the administrator account? Is there a contract renewal that will surprise someone?

The exit test improves the entry decision because it forces the organization to see the relationship as reversible—or to admit that it is not.

A better purchase conversation

Instead of asking only whether an application solves today’s problem, ask what new system it creates around the problem. Who will maintain it? Who will notice when it fails? What information will become difficult to retrieve if the tool disappears?

For a small or midsize business, the best technology stack is not the one with the fewest applications. It is the one whose dependencies are understood.

1. NIST small-business cybersecurity resources

NIST’s small-business material is a useful antidote to the idea that security begins with buying the largest tool. It begins with understanding the systems the organization actually depends on.

2. The FTC on vendor security

Third parties create a peculiar kind of risk: they can be outside the organization while still being inside its systems. The remedy is explicit access and explicit responsibility.

3. CISA Cybersecurity Performance Goals

These goals are useful because they turn broad security ambitions into observable practices. A goal is easier to manage when someone can tell whether it happened.

4. NIST cybersecurity basics

The basics are not beneath sophisticated organizations. They are the floor beneath everything sophisticated organizations build.

5. CISA incident-response basics

An incident plan is not a document that proves preparedness. It is a way to reduce the number of decisions people must invent under pressure.

6. FTC data-breach response guide

The guide is a reminder that response includes communication, legal questions, and business continuity—not only technical cleanup.

7. Microsoft’s small-business Zero Trust guidance

“Verify explicitly” is less a slogan than a challenge to assumptions about trusted devices, users, and locations.

8. CISA threat and advisory resources

The useful habit is not reading every alert. It is knowing which alerts could change an actual business decision.

“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.