Security Governance Isn't Just for Big Companies  

Quick question. If ransomware locked your servers at 11 pm on a Friday, who decides whether you pay? Not who could decide. Who actually would?

I ask because I keep noticing something about growing companies. They usually have a firewall, antivirus on the laptops, and a shared folder called "IT Policies FINAL v3" that nobody has opened since it was uploaded. Then you ask the Friday night question, and people just look at each other. Somebody mumbles that it'd probably be whoever picks up the phone first.

Security is the doing. Patching, backups, passwords, someone squinting at logs. Governance is the deciding part. How much risk are we okay with? Who answers for it when things go wrong? And how does leadership even find out we're exposed before a customer tells them?

Big banks have whole teams for this. You've probably got an IT manager, a couple of vendors, and a founder who still signs off on every laptop. That's okay. Governance at your size isn't a smaller copy of what a bank does. It's more like a handful of agreed rules about who decides what, written down, with actual names next to them. Honestly, it can fit on two pages.

The written-down version has a proper name too: a security governance framework. It's the roles, the policies, how often you check in, and how you measure whether any of it is working. You don't need to invent one. People have been borrowing from the NIST Cybersecurity Framework and ISO 27001 for years, and adjusting it to fit. We also wrote a plainer walkthrough on our security governance framework page if you'd like to see what one looks like in a normal company.

This is where most programs quietly fall apart. Everybody assumes somebody else has it. IT thinks leadership handles the risk side. Leadership thinks IT handles security. Legal hears about a breach from a news alert, which is a miserable way to find out.

The usual fix is something called a RACI. Fancy name, simple idea: for each job, who does it, who's accountable, who gets asked, and who just needs to be told. You don't need a colour-coded sheet. A page of notes after one honest conversation works fine.

Start at the top. The board or founders don't need to understand firewalls, and I'd say they shouldn't have to. What they do need is a picture of the biggest risks in terms of money and reputation, and a short update every quarter. If something goes badly wrong, the buck lands on their table anyway, so they might as well see it coming.

People ask me this a lot, and the answer is they share the work but not the job. The CIO keeps technology running and useful. The CISO checks that it's safe enough, and says no when it isn't. Ideally, the CISO doesn't report to the CIO, because that's like marking your own exam paper. In a smaller company, you often can't split it cleanly, and I think that's acceptable as long as leadership knows about the trade-off and somebody senior keeps an eye on it.

The rest is more every day. IT does the daily grind of patching, access, and backups. Legal needs to be in the room during an incident because those notification clocks start ticking immediately. HR matters more than people admit, since a surprising number of access problems start with onboarding and offboarding (the laptop that was never collected from someone who left last year is a classic). And every employee carries a tiny slice of cybersecurity governance responsibilities too, even if it's only not clicking the strange invoice link that lands at 6 pm.

Here's my theory on why these programs fail. They get built like a project, with a start date and an end date, when they really want to be a habit. Projects finish, and everybody moves on. Habits just keep going. So I'd focus on four, roughly in this order.

First, policies. Most companies I come across have a forty-page security policy that a consultant wrote once, and nobody reads it. Try five or six short ones instead, a page or two each: how people use devices and accounts, who gets access to what, what happens in an incident, how data is handled, how you check vendors, and how backups and recovery work. Plain language. If someone who joined your sales team last week can't follow it in five minutes, rewrite it. A policy people understand beats one that looks impressive on a shelf.

Second, the cadence, which is just a fancy word for rhythm. A thirty-minute monthly security check-in with IT, legal, and whoever owns risk. A quarterly update to the leadership team. A yearly look at the policies and that RACI page. Put them in calendars as recurring invites. I know, it sounds almost too simple, but a recurring calendar invite might be the most effective piece of governance I know of. Things that aren't scheduled don't happen. That's just life, not a security rule.

Third, a few numbers. This is where people over-engineer. Nobody needs a dashboard with forty widgets that no one trusts. Pick maybe five to eight things you can honestly collect: how long critical patches take to roll out, how many people finished awareness training, how many clicked the last phishing test, how fast you notice and respond to an incident, and how many vendors with access to your data have actually been reviewed. The direction matters more than the number itself. If patch time is dropping, lovely. If it's creeping up, now you've got something real to talk about at the monthly meeting.

Fourth, learn from every incident. Something will go wrong eventually. A phishing email that worked, a lost phone, a vendor who leaked something. After each one, even a small one, sit down for twenty minutes and ask what happened, why, and what changes now. No blaming, or people start hiding things, which is much worse. Companies that treat small incidents as free lessons tend to dodge the big, expensive ones.

Do these four for a year, and you'll start to see where you actually stand. That's what people mean by security maturity: basically how repeatable and measured your practices are. Most growing companies begin at the stage where things do get done, only when somebody remembers. Nothing embarrassing about that. We've described the usual stages of our security maturity, in case you're curious where you'd land.

This one gets left out of governance talks, and I think that's a mistake. When people hear cyber risk, they picture servers and databases. Customers never see your servers, though. They see your brand. The website, the emails, the social handles, the app. Attackers figured that out a long time ago.

Think about a fake domain that looks like yours with one letter swapped. Or an email pretending to come from your finance team. Or a fake "customer support" account on social media, picking on someone who just wants a refund. None of this touches your internal network. Your customers still get hurt, and they blame you, fairly or not.

I don't want to make up a company and pass it off as real, so here's a composite instead. It's the honest way to show the pattern. Picture a business software company, around 150 people, small IT team of four, no CISO. A big customer asks for a detailed security assessment before renewing a large contract. The team scrambles for three weeks, stitches answers together from whoever remembers what, and just about scrapes through.

Afterwards, leadership does something sensible. The head of IT becomes the named owner, and a part-time advisor comes in. They write five short policies, start a monthly meeting, give the founders a quarterly update, and choose six numbers to follow. Six months on, the next customer questionnaire takes two days. Same questions, but the answers already exist, and someone owns them.

Give yourself ninety days. In the first month, just find out what you've got. A rough list of your most important systems and the data in them. Pick the person accountable for security and say it out loud in a leadership meeting. Don't build anything yet.

How do you build a cybersecurity governance program?  

Decide who's accountable first, then write the roles down in a simple RACI. Add a few short policies people can read, set a regular rhythm of meetings and leadership updates, and track a handful of numbers you can measure honestly. Look at the whole thing once a year. Aim for something light and repeatable because perfect on day one isn't happening.

Who is responsible for cybersecurity, the CIO or the CISO?  

Both, but for different things. The CIO is responsible for running technology and keeping it dependable. The CISO owns the security strategy and challenges risky decisions. The final accountability sits with senior leadership and the board. If you don't have a CISO, name one accountable person anyway so the role doesn't just float around.

What is a security governance framework?  

It's the structure that turns good intentions into a working program. It covers roles, policies, how often things get reviewed, how risk is measured, and how leadership stays informed. You can base yours on something established like NIST CSF or ISO 27001 and trim it to your size.

Does a smaller company really need this?  

• Security governance is about deciding who owns what and how risk is handled. The tools just do the work.

• Write down cybersecurity governance responsibilities for leadership, the CISO or equivalent, the CIO, IT, legal, and HR, with names.

• Keep policies short, meet on a schedule, track a few numbers, and review every incident.

• Treat fake domains and fake profiles as part of your digital risk.

• Start small. Ninety days is enough to get the basics moving.