Security on a small-bank budget

Security guidance is mostly written for institutions with a security team. If you have eleven people in IT and no dedicated security function, most of it is unusable — not wrong, just unaffordable — and the usual response is to buy a product, tick a box, and hope.

Having spent a lot of time inside small banks and microfinance institutions, we would rank the spending very differently from the way most vendors do.

Start with multi-factor authentication on everything that faces outward, and on every administrative account without exception. This is close to free and it removes the single most common path to a serious incident. Credential reuse is the actual threat. Nobody is writing a bespoke exploit for your core banking system when a director's password from a breached forum still works. If you do exactly one thing this year, do this one.

Second, get privileged access under control. Small institutions accumulate shared administrator accounts the way houses accumulate keys, and the same three people know all of them. Individual named accounts, admin rights granted only for the task and removed after, and a hard rule that nobody administers a system using the account they read email with. None of that costs money. All of it costs discipline, which is why it usually doesn't happen.

Third, back up in a way you have actually tested. Not "we have backups" — a restore, performed on a schedule, into an environment where somebody confirms the data is correct and usable, with the time it took written down. An untested backup is a belief, not a control. Ransomware has taken more small financial institutions offline than any targeted attack, and the ones that recovered quickly are without exception the ones who had restored before, deliberately, in daylight.

Fourth, patch the perimeter fast and everything else on a rhythm. Anything reachable from the internet — VPN concentrators, mail gateways, remote access, the online banking front end — is where speed matters most. Internal systems can follow a monthly cycle. The failure mode we see is the reverse: a rigorous internal patching schedule and an edge device three years out of date because nobody wanted to schedule the downtime.

Fifth, log the things you would need after an incident, and keep them somewhere the attacker cannot edit. Authentication events, privilege changes, large or unusual transactions, configuration changes. You do not need a SIEM to start. You need the logs to exist, to be centralised, and to be retained long enough to be useful — most incidents are discovered weeks after they began.

Now the things that eat budget without moving risk much at this size.

Annual penetration tests, before the basics are done. A test that produces a forty-page report telling you your admin accounts lack MFA has converted money into a document. Fix the known problems first; test to find the unknown ones.

Security awareness training as an annual compliance slideshow. People click the same links afterwards. Short, frequent, specific and relevant beats an hour once a year, and simulated phishing that is used to educate rather than to punish beats both.

And large detection platforms bought before anyone is available to watch them. A tool that generates alerts nobody triages is worse than no tool, because it creates a documented record of warnings your institution ignored.

The pattern is consistent. At this scale, risk is reduced by a handful of unglamorous controls applied consistently, not by any product. The institutions that get breached rarely lack tooling. They lack MFA on a forgotten account, or a restore they never tested, or a firewall someone opened for a project in 2023 and never closed.

Do the boring things properly and you will be in better shape than a lot of organisations spending twenty times as much.