Whether it’s improving products, understanding customer behaviour, conducting research or training machine learning models, anonymisation has often been viewed as the safest way to extract value from data without exposing the people behind it.

The logic seems straightforward: remove names, email addresses and other obvious identifiers, and the privacy risk largely disappears.

I’m not convinced that’s a safe assumption anymore.

As AI systems become more capable, the conversation is shifting from what data organisations collect to what can be inferred from the data they already have.

That’s a very different problem.

A decade ago, identifying someone from an anonymised dataset would have required a determined analyst, access to additional datasets and a significant amount of time.

Today, AI can process millions of records, identify subtle patterns and uncover relationships that a human would never realistically find on their own.

The concern isn’t that AI can see a name hidden in a spreadsheet. The concern is that it may not need to.

Think about the information organisations routinely collect:

• Usage patterns

• Location data

• Device information

• Login behaviour

• Purchase history

• Activity timestamps

None of these data points necessarily identify an individual by themselves. Combined, however, they can create a remarkably distinctive profile.

The more datasets that exist, the easier it becomes to connect those dots.That’s where I think many organisations underestimate the risk.

When discussing anonymisation, the focus is often on the dataset in isolation.

But attackers don’t operate in isolation, neither does AI.

An anonymised dataset might appear perfectly safe when viewed on its own. The problem arises when it is combined with publicly available information, leaked datasets, social media activity or data obtained from third parties.

Suddenly, information that seemed anonymous starts looking much less anonymous.

What’s particularly interesting is that a dataset doesn’t have to change for the risk to increase. The data sitting in storage today may be exactly the same data sitting there in five years’ time.

What changes is the technology available to analyse it.

That’s the part I think organisations need to pay more attention to.

So What Should Organisations Do?

The answer isn’t to stop using data altogether. The answer is to recognise that anonymisation is just one layer of defence.

Organisations should start by collecting less data in the first place. If information isn’t essential to a business objective, there is little value in retaining it indefinitely.

Organisations should also look beyond simply removing names and email addresses. Techniques such as data aggregation (grouping data together rather than focusing on individuals), tokenisation (replacing sensitive information with substitute values) and differential privacy (adding small amounts of uncertainty to prevent people being singled out) can make it much harder to reconnect data to a specific person.

Access controls matter too.

Not every employee, contractor or third party needs access to large datasets simply because direct identifiers have been removed. Data should still be treated according to its potential impact if it were misused or reconstructed.

Most importantly, organisations should regularly reassess datasets that were anonymised years ago.

A dataset considered low risk in 2020 may present a very different risk profile in 2026 because of advances in AI and the availability of external data sources.

Security teams routinely conduct vulnerability assessments on systems.

Perhaps it’s time we treated datasets the same way.

A Different Question

Too often, anonymisation is treated as a compliance exercise:

“We removed the identifiers. Job done.”

From a governance perspective, that may satisfy a requirement.

From a security perspective, it probably isn’t enough.

The more useful question isn’t:

“Did we remove personal information?”

It’s:

“What could a sufficiently capable AI system learn from what’s left?”

Because that’s increasingly the threat model we’re dealing with.

The reality is that AI is exceptionally good at finding patterns, and privacy is often lost through patterns rather than explicit identifiers.

Anonymisation isn’t dead. It’s still an important control.

But organisations should be careful not to mistake anonymisation for anonymity.

Those are becoming two very different things.

What do you think?

Should organisations start treating anonymised datasets as sensitive assets by default, regardless of whether personal identifiers have been removed?

Which usually means one of two things:

• it’s outdated

• or it’s quietly useful

In this case, it’s probably the second.

At a basic level, it’s simple: a risk event in the middle, causes on one side, consequences on the other, and controls sitting in between. Nothing particularly complex, but that simplicity is doing more work than it looks like.

What the bow tie does well is force clarity.

It moves the conversation away from:

• abstract risk descriptions

• generic scoring

• broad categories

And towards something more grounded:

• what actually causes this?

• what is meant to stop it?

• what happens if it still occurs?

• what limits the damage?

The bow tie brings it closer to reality. It connects events, causes, controls, and outcomes in a way that’s easy to follow. It also makes a distinction that often gets blurred in practice: the difference between controls that prevent something happening and controls that reduce the impact after the fact.

In a cyber context, for example:

Preventive controls might include:

• access controls

• MFA

• system hardening

Mitigating controls might include:

• monitoring

• incident response

• recovery capability

Seeing both sides together gives a more complete picture of how resilient a system actually is.

Its value is in making the important relationships visible:

• where risk originates

• how it’s controlled

• what happens if those controls fail

Used properly, it becomes less about the diagram and more about the conversation. Something you can use to challenge assumptions, test whether controls really exist, and ask what happens when they don’t.

It’s not trying to capture everything, and it doesn’t need to.

Its value is in making a few things visible: where risk starts, how it’s controlled, and what happens if those controls fail.

That’s probably why it’s still used today as a common practice in Risk Management.

• avoid

• mitigate

• transfer

• accept

At first glance, they seem fairly straightforward. But the interesting part isn’t really the definitions themselves - it’s understanding when each response is useful, and what trade-offs come with them.

Because none of them are inherently “better” than the others. They’re just different ways of dealing with uncertainty.

Risk avoidance is probably the simplest conceptually. If an activity creates more exposure than the organisation is comfortable with, the risk is avoided entirely.

From a cybersecurity perspective, that might mean:

• not exposing a service publicly

• not storing sensitive customer data

• avoiding unsupported legacy systems

• refusing certain third-party integrations

Avoidance is effective because it removes the exposure altogether. But it also removes flexibility, speed, or commercial opportunity.

Which is why true avoidance tends to be relatively rare.

Mitigation is usually the most familiar response operationally. Rather than removing the activity, the organisation introduces controls to reduce either:

• the likelihood of the event
  or

• the impact if it happens

In cyber environments, mitigation often includes:

• MFA

• network segmentation

• privileged access controls

• monitoring and alerting

• vulnerability management

• resilience and recovery capabilities

Good mitigation isn’t necessarily about adding more controls.

It’s about introducing controls that are proportionate, sustainable, and aligned to how systems actually operate.

Because overly complicated controls often create workarounds of their own.

Risk transfer is slightly different because the exposure still exists, but some of the consequences move elsewhere.

Cyber insurance is probably the clearest example, but transfer can also happen through:

• outsourced providers

• managed security services

• contractual security obligations

• cloud service arrangements

Transfer can help reduce financial exposure or shift certain operational responsibilities.

But it doesn’t remove accountability entirely.

If a major incident happens, the organisation still deals with:

• disruption

• recovery

• customer impact

• regulatory scrutiny

• reputational damage

Which is why transferred cyber risk is rarely fully transferred in practice.

Risk acceptance is often misunderstood because it sounds passive, but in mature environments it’s usually a conscious decision.

In cybersecurity, acceptance often happens where:

• legacy systems can’t realistically be replaced immediately

• remediation costs outweigh the exposure

• vulnerabilities are low impact

• operational constraints limit further mitigation

Not every cyber risk can be eliminated entirely.

Part of effective risk management is recognising which exposures are tolerable within the context of the organisation’s wider objectives and operating model.

What makes these categories useful is that they force a broader discussion.

Not just:
“what is the cyber risk?”

But:

• what are we trying to protect?

• what level of exposure is realistic?

• what operational trade-offs exist?

• where should controls sit?

• what happens if those controls fail quietly?

And in reality, responses are often combined.

An organisation might:

• mitigate part of a cyber risk

• transfer some financial exposure

• and consciously accept the remaining residual risk

Which is why cyber risk management is rarely about eliminating uncertainty completely.

It’s usually about balancing:

• security

• usability

• resilience

• operational efficiency

• commercial practicality

From an operational risk perspective, that balance is where most of the interesting decisions sit.

Because strong cybersecurity is rarely just about technology.

It’s usually about how operational decisions, system design, and human behaviour interact over time.

Which of the four responses do you think organisations rely on most heavily in cybersecurity?

That’s partly true. But it doesn’t quite hold up when you look at where the risk actually comes from.

If incidents are shaped by things like:

• access

• process gaps

• unclear ownership

• exceptions that quietly become permanent

then the risk isn’t really being created in the security team.

Security can:

• implement controls

• monitor activity

• respond when something goes wrong

But they’re usually not the ones deciding:

• who gets access in the first place

• how systems are structured

• where shortcuts are allowed

• how work actually gets done day to day

And that’s where the exposure builds.

So you end up in a slightly awkward position. Security teams are expected to manage outcomes they don’t fully control. And the parts of the organisation that do shape the risk don’t always see it as theirs.

Which is why a lot of cyber risk ends up being managed at the edges.

Policies. Reviews. Escalations.

Things that sit slightly outside the work itself.

From an operational risk perspective, this isn’t unusual. Risk doesn’t sit neatly in one place.

It sits in decisions:

• who approves what

• what gets prioritised

• where pressure builds

• what gets ignored

Cyber just makes it more visible.

There’s also a tendency to treat cyber as something specialised. Which it is, technically. But a lot of the underlying questions are fairly basic:

• who owns this?

• why does this role have this level of access?

• what happens if this fails quietly?

• where are we relying on someone to remember something?

Those aren’t really security questions. They’re operational ones.

And if they’re not answered properly, security tends to compensate.

More monitoring. More alerts. More layers.

Trying to manage risk that’s already been designed in.

So the organisation feels covered. But the underlying drivers haven’t really moved.

Which leads to a slightly different way of looking at it.

Maybe the issue isn’t whether cyber risk is being managed. It’s where it’s being managed from.

Because if risk is created through everyday decisions, it probably needs to be addressed there as well. Not just afterwards.

Curious how others see this.

Where you are, does cyber risk feel owned by the business — or mostly handled by security?

And the reaction was basically: yes, this is right - but this has been known for years.

Most organisations already know people are central to operational risk. That’s not the problem. The problem is we haven’t really changed how anything works because of it.

We’re still very comfortable investing in frameworks, policies, governance layers, reporting packs - all the visible stuff. But much less comfortable asking: what actually happens when people are under pressure?

Because that’s where things stop looking tidy.

People:

• cut corners

• delay raising things

• make trade-offs they don’t document

• rely on workarounds that “just about work”

Not because they’re careless, but because that’s often what the system quietly rewards.

The article talks about leaders needing to be closer to the frontline. Fair enough. But even when they are, they’re not really seeing it.

They’re seeing a version of reality that’s been cleaned up; dashboards, summaries, updates that have already been softened. The interesting stuff - the friction, the near-misses, the awkward bits - rarely travels upwards properly. And that’s where most operational risk actually sits.

We also talk about “risk culture” like it’s something fixed. It isn’t. It shifts all the time:

• when targets get tighter

• when timelines get shorter

• when priorities change

• when leadership focus moves elsewhere

If you’re not actively shaping it, it just drifts.

The bit that matters most, though, is whether people feel they can actually speak up. If there’s even a small hesitation — “should I say this?”, “is this going to land badly?” - then your whole framework starts to become a bit performative.

You still get reporting. You still get metrics. But you don’t get the full picture.

And underneath all of this is something we don’t really talk about enough: incentives beat policies almost every time.

You can have a great framework on paper. But if people are rewarded for speed, delivery, and not rocking the boat, that’s what will drive behaviour.

Most operational failures aren’t surprises. They’re patterns no one wanted to confront properly.

So yes, the “human element” matters. But it’s not new. What’s missing is actually redesigning things around it, rather than just acknowledging it in another article or training session.

Interested how others see this:

Where does human behaviour create risk where you are, the kind that never quite makes it into the official view?

But most “hacks” aren’t hacks at all.
They’re the natural outcome of weak design.

Attackers simply walk through the gaps created long before they arrive:

• vague roles

• sloppy access control

• poor logging

• silent failure modes

• over-privileged systems

• handoffs no one has ever mapped

• controls that only work if someone remembers them perfectly

The real threat isn’t the hacker.
It’s the architecture you’ve normalised.

And this is where Operational Risk and Cyber align.

What looks like a technical failure is usually an operational one in disguise:

• someone had access they didn’t need

• monitoring wasn’t set up properly

• exceptions were granted “just this once”

• ownership of key processes was unclear

• a workaround became the unofficial process

• risk signals were ignored because they were inconvenient

By the time an attacker shows up, the organisation has already weakened itself.

Operational Risk exists to challenge this.
To ask the awkward questions:

• Who actually owns this?

• What happens when this breaks quietly?

• Why does this role have unnecessary access?

• Which processes rely on memory or goodwill?

• Where is the real dependency we pretend isn’t there?

Cyber incidents look technical from the outside.
On the inside, they’re almost always operational.

The breach is the symptom.
The design is the cause.
And behaviour is the bridge between the two.

If you only focus on the attacker, you’re already reacting.
If you focus on the design, you’re preventing.

“Operational risk is just about protecting the downside.”

No, operational risk is the strategy.

You can’t scale anything - payments, onboarding, customer support, tech releases, if your operational underbelly is held together with goodwill and spreadsheets.

The companies winning now aren’t the ones with perfect products.
They’re the ones that:

• recover quickly

• learn quickly

• change safely

• communicate honestly

• treat controls as part of the product, not an afterthought

Operational risk isn’t the handbrake.
It’s the grip that lets you accelerate.

Leave a comment

But my journey into risk started much earlier, long before I ever stepped into a formal risk role.

I was working in a customer advisor role at EE (the mobile network provider) in the heart of Kings Road (up the Chels), doing compliance paperwork the old-fashioned way - manually checking forms, tracing mistakes, verifying information, and backtracking customer interactions to understand what had actually happened. Most people hated that part of the job. I genuinely enjoyed it. There was something about finding the root of a problem, spotting inconsistencies, and piecing together what went wrong that made more sense to me than hitting sales targets. Looking back, that was probably my first real exposure to risk thinking - even if I didn’t recognise it at the time.

I didn’t take the traditional route into this field either. I didn’t go to university; I came in through an apprenticeship. It meant I learned on the job, I learned quickly, and I learned from real problems rather than lecture slides. That background is probably why I’ve always been drawn to the practical side of risk - the processes that don’t quite work, the challenges teams face, and the gaps between how things should happen and how they actually do.

Outside of work, I try to keep myself balanced with things that have nothing to do with MI or governance packs. I’m into football and badminton, recently started running to improve my fitness, and I’ve developed a bit of a hobby for hiking; the longer the incline, the quieter the mind.

This Substack is my space to share what I’m learning, what I’m questioning, and what I think we could all do better when it comes to Operational Risk and risk management more broadly. Expect observations, small provocations, and the occasional rant about processes that should have been redesigned ten years ago. Whether you work in risk, touch it occasionally, or just find the mechanics of organisations interesting, welcome. I’m glad you’re here.

But the reason people think it’s boring is simple:

Most organisations still manage operational risk like it’s the early 2000s.
No curiosity. No data. No experimentation. Just heritage processes and hope.

If you treated marketing the way most companies treat risk:

• no testing

• no lessons learned

• just old frameworks and tick box exercises

…it would look equally lifeless.

Operational risk is actually fascinating when you give it half a chance. It’s:

• MI that leads to improved decision making

• Engineering control objectives which actually manage risk

• Identifying trends and themes

• Awareness of vulnerabilities

If your risk function feels tedious, it’s not the discipline —
it’s how you’re doing it.

What’s the most outdated risk practice you’ve seen recently?

Share Mahir Chowdhury