Spend time in a bank and you see a particular kind of discipline. Access is reviewed every quarter. Changes go through a board. Backups are restored to prove they work. Not always because everyone loves process, but because a regulator will ask, and the answer had better be good.
Now walk into a well run, privately owned company of a similar size. Strong sales, modern systems, smart people. Ask who reviewed administrator access last quarter and the room often goes quiet. The threats are identical. Ransomware does not check a company's licence. What is missing is the one thing that made the bank behave: someone outside asking whether the controls actually work.
What regulation quietly provides
Even people who resent regulation benefit from what it supplies:
- A baseline. A minimum set of controls that must exist, so nobody debates whether access reviews are needed.
- Board accountability. Technology risk has to be reported upward, with names attached.
- Independent testing. Internal audit, external audit and examiners check that controls operate, not just that policies exist.
- Consequences. Findings have deadlines, and missing them has a cost.
- A budget argument. "The regulator requires it" ends many funding discussions.
Remove all five and controls do not disappear overnight. They erode, slowly and silently, until an incident reveals how far they have drifted.
How controls fail when nobody is watching
The patterns repeat across sectors and countries.
Policy without practice
A policy set exists, often adapted from a template for a customer questionnaire. It describes access reviews, change approval and incident response. None of them happen. The document is accurate about intentions and silent about reality.
Access that only grows
People join and are given access. They change roles and keep the old access. They leave and their accounts stay active for months. Administrator rights are shared, because it is convenient. Nobody removes anything, because nobody is asked to.
Change by trust
Changes go straight into production because the team is small and capable. It works until the day a change breaks something important and nobody can say what was changed, by whom, or how to reverse it.
Backups nobody has restored
Backup jobs report success every night. Nobody has tried a full restore. The disaster recovery plan was written once and never tested. Both are discovered to be incomplete at the worst possible moment.
Vendors run everything, contracts say nothing
Hosting, applications and support are outsourced, which is sensible. But the contracts say little about security, give no right to audit, and set no expectations for incident notification or exit. The organisation has handed over its controls without keeping any visibility of them.
One person holds the keys
A single IT manager knows every password, every system and every workaround. That person is often excellent, and is also the largest unmanaged risk in the company.
Security bought, not run
Firewalls, antivirus and a monitoring tool are purchased. Alerts go to a mailbox nobody reads. Tools are mistaken for controls, when a control is a tool plus a process plus someone accountable for it.
Why it happens
Rarely through negligence. More often because of four ordinary forces.
- No trigger. Without an examination date, there is always something more urgent than an access review.
- Invisible risk. Weak controls cost nothing until the day they cost a great deal, so they never compete well for budget.
- Growth outruns control. Processes designed for twenty people quietly fail at two hundred.
- Governance confused with IT management. Running technology well is management. Governance is the board setting direction, deciding how much risk is acceptable and checking that it is being managed. Many organisations have the first and assume it covers the second. Frameworks such as COBIT draw exactly this line.
"We are not regulated" is less true than it sounds
Freedom from a sector regulator does not mean freedom from expectations.
- Data protection law still applies. In the UAE, for example, the federal personal data protection law covers a wide range of private organisations, whether or not they have a sector regulator.
- Customers ask. Large clients send security questionnaires and increasingly expect evidence, not answers.
- Insurers ask. Cyber insurance applications now probe multifactor authentication, backups and patching, and claims can depend on the answers.
- Attackers do not distinguish. Payment fraud, email compromise and ransomware target whoever is easiest, and weak governance is easy to find.
Governance you choose
The answer is not to imitate a bank. It is to give the organisation, by choice, the few things regulation would otherwise force on it.
- Put technology risk on the board agenda. A short quarterly update with a named owner: top risks, key control status, incidents and decisions needed.
- Pick one framework and apply it proportionately. The CIS Controls Implementation Group 1 is a strong starting baseline for smaller organisations. NIST CSF 2.0, with its Govern function, gives a broader structure. ISO 27001 makes sense when customers need certification.
- Do the essential few first. Multifactor authentication everywhere, tested offline backups, timely patching, a reliable leaver process, restricted administrator rights and basic logging. These cover a large share of real incidents.
- Make someone independent check. An internal audit function where scale allows, or an annual external review where it does not. The point is a second set of eyes with no stake in the answer.
- Fix the vendor contracts. Security obligations, incident notification, right to audit and a workable exit plan.
- Remove the single point of failure. Document critical systems, share privileged access through a controlled vault and make sure two people can recover the essentials.
- Track a handful of indicators. Overdue patches, accounts of leavers still active, last successful restore test and open findings. Five numbers, reviewed regularly, change behaviour.
Five questions for owners and boards
- Who is accountable to us for technology risk, and when did we last hear from them?
- When did we last restore our critical systems from backup, and did it work?
- How quickly is access removed when someone leaves, and how do we know?
- Which vendors hold our critical data or systems, and what do their contracts require of them?
- Who independently checks that our controls operate, rather than that our policies exist?
Regulated entities are not more virtuous; they are more often asked. Organisations without a regulator can reach the same discipline at a fraction of the cost, but only if they decide to ask the question themselves, before an incident asks it for them.