Security foundations controls: signal versus noise

A control is not a setting. A setting is a value in a console. A control is that value plus a person who owns it plus something you can look at later to know it is still true.

That distinction sounds pedantic until you go looking. Turning things on is a project with a finish date. Keeping them on is an ongoing obligation that nobody scheduled. The gap between those two is where most of the damage in a small business happens: the protection was bought, configured, and then quietly stopped applying to half the estate.

What to take away

The gap between configured and effective

Ask a small business whether multi-factor authentication is on and you will usually get a yes. Ask which accounts have no strong method registered and the answer is a pause, because the first question is about a policy and the second is about reality.

The difference is almost never negligence. Policies apply to sets, and sets change without notifying anyone. A rule scoped to a group protects the people in that group.

An account created outside the usual path, a license type change, or a device enrolled by someone not shown the process leaves the account outside the set. No error appears. The console still says the policy is enabled.

So the useful question about any control is not "is it on" but "what is it on for, and how would I notice something falling outside that".

Write each control so it can be checked

Five short fields turn a good intention into something a colleague can verify in your absence. Name what it prevents, who owns it, the one fact that proves it is working, how often that fact is checked, and what happens when the check fails.

The third field is the one that does the work. Pick a fact you can actually read off a screen, not a state of mind.

None of those facts takes more than a few minutes to retrieve. That is deliberate. A check that needs an afternoon gets done once.

Coverage is a fraction, so know the denominator

"Encryption is enabled on our laptops" is a statement about a numerator. It becomes useful when you can say how many laptops there are, because the interesting device is always the one missing from the list.

This is why the inventory work described in security foundations is not administrative throat-clearing. Without a denominator, every coverage claim is a guess, and the gap in the guess is exactly where the unmanaged machine sits. When a tool reports a coverage percentage, the number you need is the remainder, by name.

Knowing what you own before claiming to protect it is the first of the actions in the United States Cybersecurity and Infrastructure Security Agency's Cyber Essentials, for exactly this reason. Device inventory is the hardest denominator to keep honest, and the reasons are set out in endpoint security.

Check the mix, not just the count

Controls do three different jobs, and it is easy to buy several of one kind and none of another.

Preventive controls stop the thing happening. Detective controls tell you it happened. Recovery controls get you back. A set that is all preventive feels strong and leaves you learning about incidents from a customer, weeks late, with no logs old enough to answer any question worth asking. A set that is all detective produces alerts about damage you cannot undo.

Sort your list into those three buckets once. The empty bucket is usually detection, and the cheapest fix is usually longer log retention rather than a product. The recovery bucket is the one people believe is full when it is not, for the reasons set out in backup and recovery.

The five functions used by the United States National Institute of Standards and Technology in its Cybersecurity Framework are a free way to structure that sort if you would rather borrow a vocabulary than invent one.

Exceptions need an expiry date

Every real control acquires exceptions. Someone travels and cannot receive a prompt. A machine runs software that breaks under the new policy. A supplier needs access for a week.

Granting the exception is fine and refusing all of them makes people work around you, which is worse. The failure is that exceptions have no natural end. Nothing prompts anyone to reverse them, nobody complains when they persist, and the person who granted it has moved on.

Keep one list with four columns: what the exception is, who asked, why, and the end date. Review it whenever you review the control.

An exception without a date is a permanent change to the control never approved as one. It is usually granted at the worst possible moment, while something is broken and somebody waits.

Ownership, and what happens when it fails

Two things separate a control that survives from one that does not.

Someone owns it by name, not by team. "IT owns patching" means nobody looks at the report. A named person looks, and says so.

And there is a stated consequence for a failed check. Not a punishment: a decision. If the restore test fails, what happens next, and who is told? If three devices are behind on updates, who chases them, and by when? A check with no consequence attached is a number in a spreadsheet, and after two quarters people stop collecting it.

Where a control genuinely cannot be operated at your size, write down what you do instead. A second pair of eyes from the owner is a real compensating measure. Pretending you have segregation of duties in a team of four is not. Choosing tooling against that reality is what best security foundations software 2027 is for.

Common questions

How many controls should a small business track?

Fewer than you think, checked properly. A dozen you genuinely verify beats forty on a list. Start with the ones whose failure would cost you money or the business itself, and add only when the existing set is honestly maintained.

How often should the facts be checked?

Tie the cadence to how fast the control drifts rather than to the calendar. Account and administrator lists drift weekly because people join and move, so monthly is reasonable. Restore capability drifts slowly, so annually is defensible if you actually do it. Anything that changes only when you change it can be checked when you change it.

What if a check has never once found a problem?

Look at whether the check can find a problem. Many cannot: they read a policy setting rather than an outcome. Change the check so it reads reality, then decide. A check that reports clean for two years is either measuring nothing or measuring something stable, and those need opposite responses.

Does any of this need a tool?

No. For most small organizations, one page listing each control, its owner, its one fact, and the date it was last checked is enough. That page is more likely maintained than a platform nobody logs into.

Tools help when the number of accounts or devices exceeds what one person can read in one sitting. Detection and response obligations follow the same logic and are covered in incident response.