Skip to content
The Cyber Security Place

Answers

Security answers: the questions that keep coming back

Competent people give opposite answers to most of these, and the disagreement is almost never technical. It is about a number nobody says out loud.

Last reviewed August 29, 2026

Most security advice silently assumes an organisation size, and reverses when that assumption changes. Under 50 people, the right answer is nearly always use the defaults: a bespoke configuration nobody maintains fails worse than a standard one. Between 50 and 5,000, the constraint is a budget argued for yearly, so measure outcomes — restore time, detection time — not activity. Above 5,000, the constraint is visibility into an estate nobody holds in their head. Four questions recur regardless of size: how to judge acloud provider, what to do about data on phones, where to start with a large data estate, and whether predictions are worth reading. The cheapest universal answers are an inventory, a tested restore, and phishing-resistant authentication.

Why does the same question get opposite answers?

4 of the questions below were put by readers of this site; the rest recur across the 423 question-shaped headlines in the archive. Each is answered three times, because the honest answer to nearly all of them begins with a number that most advice leaves out.

Each question below is answered three ways. Under 50 people: No security staff. Whoever runs IT also runs security, part time. 50 to 5,000: One to a handful of security people. A budget that must be argued for each year. Over 5,000: A security function with specialisms, and an estate nobody can hold in their head.

Cloud

How do you evaluate the security of a cloud provider?

Not by reading their security page. The provider's own controls are rarely what fails; the division of labour between you and them is. Establish which side configures identity, network exposure, encryption keys and logging, because every published breach in this category has lived in that gap.

Under 50 people

Pick a major platform and use its defaults. You will not out-engineer them, and a bespoke configuration you cannot maintain is worse than a standard one you can. Ask for two things only: where the data physically sits, and how you get it back if you leave.

50 to 5,000

Request the current audit report rather than the certificate, and read the scope section first — it names which systems and which months were actually examined. Then check whether their exception list contains anything you depend on.

Over 5,000

Negotiate the logging. At your size the constraint is not whether the provider is secure but whether you can see what happened in your own tenancy, at what latency, retained for how long, and without paying per query at the moment you most need to ask.

Mobile

What should a company do about data on employees' phones?

Decide whether the phone holds data or merely displays it. That single choice determines everything downstream, and most arguments about mobile policy are really disagreements about which of the two arrangements is in force.

Under 50 people

Keep company data off the device entirely: browser access, no local sync, screen lock enforced. Managing phones costs more attention than a small organisation has, and the version that fails is the one nobody maintains.

50 to 5,000

Separate work from personal on the device rather than managing the whole phone. Staff resist full management for good reasons, and a container you can wipe independently gets accepted where a total wipe clause does not.

Over 5,000

Assume a share of devices are compromised at any moment and design for it: conditional access that checks device posture at each request, short-lived tokens, and no standing access to anything sensitive from a phone.

Big Data

Where do you start with securing a large amount of data?

With finding out where it is. Every subsequent control depends on an inventory, and organisations that skip this step end up protecting the copies they remember rather than the copies they have.

Under 50 people

One afternoon with a list of every place data lands — laptops, shared drives, the accounting system, the three services someone signed up for — gets you most of the way. Delete what you do not need before protecting what you do.

50 to 5,000

Classify by consequence rather than by type. Two tiers are enough to start: data whose exposure would require notifying somebody, and everything else. The first tier is usually far smaller than people expect, which makes it tractable.

Over 5,000

Discovery has to be continuous, because at this scale new stores appear faster than any annual exercise can find them. The realistic target is not a complete map but a shrinking gap between when data appears somewhere and when you know about it.

General

Are the annual threat predictions worth reading?

As a record of what the industry is preparing to sell, yes. As a forecast, they have a poor and rarely audited record, because almost nobody goes back a year later to score them.

Under 50 people

Skip them. The things that will actually hurt a small organisation this year are the same ones as last year, and no prediction list is going to change what you should do first.

50 to 5,000

Read them for vocabulary rather than for direction. Knowing the terms your suppliers and your board will use in the coming year has real value; treating the list as a work plan does not.

Over 5,000

Useful mainly as a check on your own blind spots. Where several independent forecasts agree on something absent from your risk register, that disagreement is worth a conversation — not because they are right, but because you should know why you differ.

General

What does a board actually need from security?

Three things, none of them technical: whether the organisation would survive the incident currently in the news, what the money is buying, and whether anyone would find out early. Everything else is detail in support of those.

Under 50 people

There is no board, and the equivalent conversation is with whoever signs cheques. One page, in money and downtime, beats any framework diagram.

50 to 5,000

The trap is reporting activity — patches applied, phishing tests passed — instead of outcomes. Report the measured restore time and the measured detection time, even when both are embarrassing, because a bad number you volunteer is worth more than a good one nobody believes.

Over 5,000

Expect to be asked about third parties, disclosure obligations and concentration risk before anything else. At this size the board's exposure is legal and reputational, and its questions follow that exposure rather than the threat landscape.

BYOD

Is bring-your-own-device still a policy question?

It stopped being a choice and became a description. Personal devices reach work systems in nearly every organisation, including those whose written policy forbids it, and a policy contradicted by daily practice provides no protection while creating the impression of some.

Under 50 people

Write down what is actually happening and secure that. Prohibiting personal devices in a company that has no company devices produces a rule everybody breaks, which is worse than no rule because it discourages people from mentioning problems.

50 to 5,000

The useful boundary is not the device but the session. Decide what a personal device may reach and under what conditions, and stop attempting to control the hardware itself, which staff will resist and which you cannot verify.

Over 5,000

Expect a long tail of unmanaged devices you will never enumerate, including contractors and acquired subsidiaries. Design so that a device's status is checked at each request rather than assumed from an enrolment that happened once.

Identity Theft

How do you find out whether staff credentials are already exposed?

Assume some are and design for it, because the discovery problem is genuinely hard: credentials leak through breaches at unrelated services where people reused a password, and no monitoring service sees everything. Detection helps; it is not a control.

Under 50 people

A free breach-notification service for your domain plus a password manager covers most of the realistic exposure. The reuse of a work password on a hobby forum is the specific event to design against.

50 to 5,000

Check for reuse on the way in rather than after the fact: block known-breached passwords at the point they are set. That converts a monitoring problem into a prevention one and needs no ongoing attention.

Over 5,000

The exposure that matters is rarely a password; it is a long-lived token, a service account or an API key in a repository. Those do not appear in breach-notification feeds at all, and finding them is an internal search problem rather than an external monitoring purchase.

General

Is security awareness training worth the money?

For stopping the click, the evidence is weak after twenty years. For shortening the time between somebody suspecting a problem and somebody qualified looking at it, the evidence is good — and that is the half of the breach lifecycle that runs long.

Under 50 people

Ten minutes explaining who to tell, and a promise that nobody gets blamed for reporting, will outperform any purchased course.

50 to 5,000

Measure reporting rate rather than click rate. A programme that halves clicks and leaves reporting flat has optimised the metric that is easier to move and not the one that shortens an incident.

Over 5,000

Treat it as a channel for reaching people rather than as a control. The engineering work — phishing-resistant authentication, approvals that cannot be granted by message alone — is what removes the decision, and training cannot substitute for it.

The missing variable in most security advice

Two experienced practitioners will tell a company to standardise on a large platform's defaults and to avoid depending on a single supplier's defaults, and both are giving good advice to somebody. The first is talking to an organisation with no security staff, where every bespoke decision is a maintenance burden that will be abandoned within eighteen months. The second is talking to one large enough that concentration is itself the exposure. Neither says which.

Size is the variable because it determines what is scarce. Below fifty people the scarce resource is attention: any control that needs regular human care will decay, so the correct design is the one with the fewest moving parts, even at some cost in theoretical coverage. In the middle the scarce resource is justification — the money exists but must be argued for annually against people with competing claims — which makes measurable outcomes worth more than better technology. Past a few thousand staff the scarce resource is knowledge of your own estate, and controls that assume somebody knows what is running quietly stop working.

The practical use of this is defensive. When a recommendation arrives — from a supplier, a consultant, a conference talk, an article — the first question worth asking is what size of organisation the speaker had in mind. Frequently the answer is the one they work for, and frequently that is not yours.

Growth is where this becomes expensive rather than merely confusing. The arrangements that carried an organisation through its first hundred people — one person who knows where everything is, shared accounts for a handful of systems, decisions made by asking in a corridor — do not degrade gracefully. They work, and then at some point they have quietly stopped working while still appearing to, because the individual who held the whole picture no longer can and nothing has replaced them. The signal is usually mundane: somebody asks a question about the estate that would have taken a minute two years ago and now takes a week.

Recognising that transition matters more than the specific controls adopted on either side of it. An organisation that notices it has outgrown its arrangements and writes things down has the harder half behind it, whatever it buys next. One that does not will keep applying advice suited to a company it no longer is, and will conclude that security guidance is contradictory when the contradiction is entirely internal.

What the sector kept asking itself

Across the archive, 423 headlines are questions rather than statements. Read together they form a fair picture of what went unresolved, and the striking thing is how many remain open.

Industry Insights141Software74Hardware/Network49IT Compliance43Identity Theft38Cloud25Artificial Intelligen…24Mobile11

The shape is the finding. The broad business-and-industry section carries more unresolved questions than the next two technical sections put together, and the pattern is consistent: questions with a technical answer get asked, answered, and drop out of circulation, while questions about whether the work is worth doing recur for a decade in almost identical words.

Some of these were answered by events. Others — whether boards genuinely care, whether training delivers value, whether detection keeps pace — were being asked in the same words a decade apart, which is usually a sign that the question is badly posed rather than that the answer is hard. "Do boards care about security" has no answer; "what does this board need in order to decide" does.

How do you tell a real answer from a plausible one?

Security answers fail in recognisable ways, and the failures are easier to spot than the underlying technical questions are to settle. A real answer names what it assumes. A plausible one is written to be true of everybody, which requires it to be specific about nothing.

A real answer also says what it costs, in attention rather than only in money. The expensive part of most controls is not the purchase but the standing obligation to keep it working — the weekly review, the exception process, the person who notices when it stops reporting. Advice that omits the ongoing cost is describing a purchase, not a control, and the difference shows up two years later as a tool that nobody has looked at since it was installed.

The third test is whether it can be wrong. "Adopt a risk-based approach" cannot fail any inspection, which is what makes it useless: it excludes nothing and forbids nothing. "Keep authentication logs for at least a year" can be checked, disagreed with, and shown to be inadequate in a particular case. Answers that can be wrong are the only ones that can be right.

None of this requires technical depth to apply, which is the point. Someone with no security background can ask what size of organisation an answer assumes, what it will cost to keep running, and what would show it to be mistaken — and those three questions eliminate most of what circulates.

What holds at every size

Three things survive the change of scale, and it is worth being clear that they are few. An inventory of what you have, because every other decision refers to it. A restore that somebody has actually performed and timed, because the gap between having backups and being able to recover is the most reliably underestimated distance in the field. And authentication that cannot be handed to a stranger, because the whole identity family of attacks depends on the fact that most factors can be.

Everything else moves. Whether to write your own detection rules, whether to run anything on your own hardware, whether a dedicated security hire is a better use of money than a managed service — all of these have defensible answers that flip somewhere between fifty and five thousand people, and arguing them without stating the size is arguing about nothing.

The eight subject areas this section was organised around — Big Data, BYOD, Cloud, General, Hardware/Network, Identity Theft, Mobile, Software — have aged unevenly. Big data became ordinary data, BYOD became simply how work happens and stopped being a policy question, and identity moved from a specialism to the centre of nearly everything. The questions people bring have followed that movement, and the ones that recur across the whole period are the ones above.

Should you trust an answer that comes from a supplier?

Often, and with a specific correction applied. Suppliers employ some of the most experienced practitioners in the field, and much of what they publish is accurate. The systematic distortion is not dishonesty; it is that they see what their products see, and their advice reflects the shape of that view. A firm selling endpoint software observes attacks arriving at endpoints, because that is where its sensors are, in the estates of organisations that decided endpoints were their problem.

The correction is to keep the finding and discount the emphasis. When such a report says a technique is being used, that is direct evidence and worth having. When it says the technique is the most important thing happening, that is an inference from a sample the report rarely characterises, and it will consistently favour the class of problem the supplier addresses. Both statements arrive in the same paragraph, in the same tone, and separating them is most of the work.

Consultants carry a different distortion. Their sample is organisations that called someone, which skews toward the worse cases and toward the moment after something went wrong. That makes their sense of what typically fails sharper than a supplier's and their sense of what is typical much less reliable — the population that never needed to call is invisible to them. Advice from that quarter is best read as a catalogue of realistic failure modes rather than as a distribution.

The least distorted answers usually come from people running an organisation like yours who will describe what did not work. That source is scarce, unpublished, and worth more than the rest combined, which is the main practical argument for the professional networks that exist around this field. Failing that, prefer an answer that names its sample to one that sounds confident.

Common questions

Why do two competent people give opposite security advice?

Usually because each is answering for a different size of organisation without saying so. Advice that keeps a fifty-person company alive — use the defaults, do not build anything bespoke — is negligent at fifty thousand, and the advice that fits fifty thousand is unaffordable at fifty. The disagreement is about the unstated assumption, not the technique.

What is the first thing a small organisation should do?

Find out what of yours is reachable from the internet, and turn off what does not need to be. It is the only part of your estate an attacker can survey without any access at all, which makes it the one place your view and theirs can be compared directly.

How do I check a supplier's security without a security team?

Ask for the audit report rather than the certificate, and read its scope section before anything else — it names which systems were examined and over what months. A certificate covering one product line reads identically in marketing to one covering everything.

Should we manage employees' personal phones?

Decide first whether the phone holds company data or merely displays it. If it only displays it — browser access, no local copy, screen lock enforced — most of the management question disappears, and so does the argument with staff about wiping their photographs.

Is multi-factor authentication enough?

It depends entirely on the factor. Codes sent by message or generated in an app can be read out to a convincing caller, and routinely are. Factors bound to the site they authenticate to cannot be handed over that way, which is a different security property rather than a stronger version of the same one.

How often should we run a penetration test?

The frequency matters less than what happens to the findings. An organisation that tests annually and fixes everything is in better shape than one that tests quarterly and accumulates a backlog, and the second pattern is far more common. Fix rate is the number worth tracking.

Do we need cyber insurance?

It transfers some financial consequence and no operational consequence: the policy does not restore your systems or answer your customers. Read the conditions precedent closely, because several common ones — multi-factor coverage, patching windows, backup testing — are the controls you would want anyway, and failing them at claim time is the standard unpleasant surprise.

What logs should we keep, and for how long?

Authentication, administrative action and network egress, for longer than you think. With a mean of roughly six months between compromise and discovery, retention shorter than that guarantees the investigation begins after the evidence has already rotated away.

Is it safe to use free security tools?

The licence cost is not the risk; the maintenance is. A well-maintained free tool with an active project behind it is a better bet than a purchased one whose vendor was acquired last year. Check the date of the last release before checking the price.

How do we know our backups actually work?

By restoring one. Not verifying it, not checking a green tick — restoring a production system, timing it, and writing down what was still missing afterwards. Organisations discover the gap between backup and recovery at the worst possible moment with striking regularity.

Who should security report to?

Less important than whether the reporting line can say no to the business and survive it. The arrangement fails the same way regardless of the box on the chart: when the person raising the risk is also the person whose project it delays, the risk stops being raised.

What should we do first if we think we have been breached?

Write down the time and what made you think so, then stop changing things. The instinct to clean up destroys the evidence that determines scope, and scope determines what you are legally obliged to tell whom. Preserve first, then contain, then remediate.

Keep reading