The advice is always the same. Keep your software up to date. Use strong authentication. Review your security settings. Monitor your systems. Have a plan for when something goes wrong.
None of it is wrong, and none of it is free.
Every item on that list is an instruction to spend something. What rarely gets said is what, or how much, or what happens to an organization that cannot spend it. Telling a company with eleven employees and no dedicated IT staff to invest properly in security is not advice. It is a description of a situation they already understand and cannot currently change.
So it is worth looking at the question the way businesses actually experience it, which is as a series of trade-offs made with incomplete information and a real budget.
Security decisions are settled in one of four currencies. Money, time, in-house expertise, and accepted risk. Every choice spends at least one, and the amount is rarely obvious at the point of decision.
Consider a common example. Every Linux server already includes a capable SFTP server in OpenSSH. Enabling it is a short configuration change, and for many organizations that is genuinely the right answer for years. It costs nothing in money.
It is paid for elsewhere. Someone has to configure it correctly, which is time. Someone has to know what correct looks like, which is expertise. And a handful of things it does not do, such as per-user transfer limits, structured audit records, self-service key rotation, or surviving a server failure, either get built by that same person or quietly become risks nobody has written down.
That is not an argument against using it. Plenty of organizations run exactly that setup well for a decade. It is an observation that the bill still arrives, in currencies that never appear on a purchase order.
The same logic applies in every direction. A low-cost license from a small vendor saves money and spends risk, because you are betting on that vendor's ability to keep patching. Commercial software costs money and buys back time, expertise and some risk. Hiring someone junior costs less and spends time and expertise. None of these is the wrong answer. They are different currencies, and which one an organization can afford is a real constraint rather than a failure of seriousness.
Money and time are the visible currencies, and both are more manageable than they look.
For money, the number that matters is not the purchase price. It is what the thing costs over three to five years, whether that cost recurs, and what happens if you stop paying. Those three questions can be asked of any vendor by anyone, technical or not, and the answers vary far more than the headline prices do. Two products at the same price can differ by a factor of three across five years, and a product you stop paying for either keeps working or stops, which is a distinction worth knowing before rather than after.
For time, the useful question is how many hours a month something takes someone. Free software is paid for here, and it is the currency organizations are least likely to measure. Time never appears on a budget line, but it appears in full on a payroll. If nobody can answer how much time something consumes, that inability is itself the finding.
Expertise is the difficult currency, and the difficulty is not really about money.
If you are not technical, you cannot assess technical competence directly. You cannot read the configuration and tell whether it is sound. You cannot interview someone and know whether their answers are correct. So you fall back on proxies, which is to say you evaluate confidence, fluency, how well someone explains themselves, and whether you find them credible.
This is not a lapse in judgment. It is what anyone does when buying something they cannot inspect, and it is the same problem as evaluating a vendor's security claims or a certification you have no way to verify. The honest position is that the person making the decision is working with proxies, and the only useful question is which proxies are worth anything.
The uncomfortable answer is that most of them are worth very little. Fluency correlates with interviewing well rather than with competence. Confidence correlates with confidence. The candidate who explains things beautifully may be excellent or may simply be practiced, and the one who struggles to articulate what they know may be the stronger engineer.
It is tempting to reach for willingness to say "I don't know" as a signal, on the theory that people who know a subject are comfortable with its edges. That one does not hold up either. Comfort expressing uncertainty is a personality trait before it is a knowledge indicator. Anxious experts conceal it, confident amateurs deploy it deliberately, and an interview is a setting that actively punishes admitting ignorance, which makes it close to the worst possible context in which to read the signal.
So the honest position is that there is no reliable proxy. A non-technical evaluator cannot assess technical competence, and no interview technique fixes that. Accepting this is more useful than adopting a weak substitute, because a weak signal trusted confidently is worse than no signal at all.
What remains available is structure. Not judging the person, but examining whether the organization around them can survive their absence. That question requires no technical knowledge, and the evidence for it already exists.
Look at what has already happened. Who was called during the last outage? Who performed the last upgrade? Whose name is on the tickets? That record sits in email, calendars and ticketing systems, and reading it requires no understanding of the work itself. If one name appears every time, the answer is in front of you, and it came from history rather than from anyone's account of themselves.
Ask two people the same question separately. "If this person were unavailable for two weeks, what would break?" Matching answers indicate the knowledge is shared. Divergent answers, or a blank look from the second person, indicate it is not. You are not evaluating the technical content of the answer. You are checking whether two people hold the same picture.
Then ask the questions that have checkable answers. Is it written down, which you can verify by asking to see the document rather than by reading it. What happens at two in the morning, and who is called. When was this last tested, as distinct from last working. What would somebody need in order to take it over.
An organization that can answer those is in reasonable shape regardless of who it hired. An organization that cannot is carrying a risk that has nothing to do with the quality of its technology, or of its people.
Here is the part that tends to surprise people. Several of the highest-value security controls cost nothing, and several of the most expensive things are not the most valuable.
Removing accounts belonging to people who have left is free, takes an afternoon, and addresses a category of access that appears repeatedly in breach reporting. Nobody needs specialist knowledge to ask for a list of active accounts and compare it against a list of current employees.
Multi-factor authentication is usually already included in identity or email services an organization is paying for, and frequently switched off. Turning it on costs a decision and some short-term inconvenience.
Knowing what you have is free, and most organizations cannot produce it. An inventory of systems, who owns each, and what data each holds is not a technical artifact. It is a list. Several regulatory regimes now require exactly this, and the absence of one is usually discovered during an audit rather than before it.
Defining a patching window and holding to it costs time rather than money, and the delay between a fix existing and a fix being applied is one of the few measurable things in this field.
Writing down what happens when something breaks costs one afternoon. Who is called, in what order, who can authorize taking a system offline, who talks to customers. Organizations that have this document have a bad day. Organizations that do not have a much worse one, and the difference is not technical.
Testing a restore rather than trusting a backup costs a scheduled morning. Backups that have never been restored are a belief rather than a control.
None of these require expertise to initiate. All of them can be driven by someone who cannot read a configuration file, because each is a question about process rather than technology.
If a structured version is useful, two exist and neither costs anything. The Center for Internet Security publishes Implementation Group 1, a set of 56 safeguards it describes as essential cyber hygiene, chosen specifically to be implementable by organizations with limited IT and security expertise. It is not written for large enterprises with security teams, and it says so. CISA maintains a catalogue of free cybersecurity services and tools, drawn from both government and private sources, organized by what each one is for.
Neither is a marketing document, and neither is trying to sell anything. That makes them more useful starting points than most of what a search for this subject returns.
Budgets are real, and sometimes the honest answer is that an organization will accept a risk it would rather not. The useful distinction is not between saving money and spending it. It is between savings that can be reversed and savings that cannot.
Choosing the wrong software is reversible. Migration is unpleasant and it is possible.
Failing to document a setup is reversible, though it becomes more expensive the longer it goes and considerably more expensive after the person who knew has left.
Concentrating all knowledge in one individual is reversible right up until the moment it is not, and that moment arrives without warning.
A breach is not reversible at all.
So the question worth asking of any cost-saving decision is not whether it is prudent, but whether it can be undone later, and roughly what undoing it would cost. That produces a very different priority order than a budget conversation usually does, and it is a question anyone can ask.
There is a difference between an organization that has accepted a risk and one that has simply not noticed it, even when their technical situations are identical.
A young company that knows it is running a critical system on one person's knowledge, has said so out loud, and has decided that is the right trade for now, is doing something entirely different from a company in the same position that has never discussed it. The first has made a decision it can revisit. The second has a surprise waiting.
Most security advice assumes the reader has resources they do not have, which is why so much of it is ignored by the people who most need it. The version that survives contact with a real budget is narrower and less satisfying. Know what you are spending and in which currency. Know which of your savings can be undone. And know the difference between a risk you chose and a risk you inherited by not looking.
None of that costs anything, and it is most of the work.
