Security Tools Don’t Fix Bad Security Processes

One thing I've learned from working across different cybersecurity environments is that organisations can have very good security tools and still have security gaps.

You can deploy EDR.

You can implement a SIEM.

You can buy advanced email security.

You can enable Microsoft Defender.

You can have vulnerability scanning, backup, mobile security and identity protection.

And still have incidents that should have been prevented or detected earlier.

Why?

Because buying a security product and building an effective security capability are two different things.

A tool can generate an alert.

But someone still needs to know:

Who investigates it?

How quickly?

When is it escalated?

What happens after containment?

Who owns the underlying problem?

That's why I've increasingly come to believe that cybersecurity maturity isn't measured by how many security products an organisation owns.

It's measured by how effectively people, processes and technology work together.

The Expensive Dashboard Problem

Imagine an organisation invests in several security platforms.

The environment now has:

EDR
SIEM
Email security
Identity protection
Vulnerability management
Backup
Cloud security
Mobile security

On paper, that looks mature.

But then I start asking questions.

Who checks the alerts?

Nobody is completely sure.

What happens to a critical alert after hours?

There's no defined process.

How quickly should a high-severity vulnerability be remediated?

There's no agreed SLA.

When should an incident be escalated?

It depends on who sees it.

When were backups last restored and tested?

Nobody remembers.

Suddenly, the number of security products matters much less.

A Detection Without a Response Process Is Just Information

Suppose an EDR detects suspicious behaviour.

The tool has done its job.

It generated an alert.

But imagine the alert sits untouched for two days.

The organisation technically had detection capability.

Operationally, it didn't have effective response capability.

I think about it like this:

Detection
    ↓
Triage
    ↓
Investigation
    ↓
Decision
    ↓
Containment
    ↓
Remediation
    ↓
Recovery
    ↓
Lessons learned

If those steps aren't defined, the technology can only take the organisation so far.

Automation Doesn't Remove Ownership

Modern security products can automate a lot.

They can:

• Block files

• Quarantine threats

• Isolate endpoints

• Correlate alerts

• Remove malicious emails

• Trigger workflows

• Generate incidents

Automation is valuable.

But I don't think automation removes the need for human judgement.

Suppose an EDR automatically blocks malware.

Great.

I still want to know:

How did the malware arrive?

Did anything execute before the block?

Did the user enter credentials somewhere?

Did other endpoints receive the same file?

Was persistence created?

Does the attack expose a larger security weakness?

Automation can perform an action.

An investigation needs to understand the story.

Security Processes Need Clear Ownership

One of the simplest questions I like asking is:

Who owns this?

Imagine a vulnerability scanner identifies a critical vulnerability.

Security identifies the risk.

But who patches it?

Maybe infrastructure.

Maybe the application owner.

Maybe a third-party provider.

Maybe nobody has clearly defined ownership.

Then the vulnerability remains open.

Not because the security tool failed.

Because the process after detection failed.

Vulnerability Management Is a Good Example

Running a vulnerability scan isn't vulnerability management.

A scanner can give you thousands of findings.

The real work begins afterward.

Discover
   ↓
Validate
   ↓
Prioritise
   ↓
Assign owner
   ↓
Remediate
   ↓
Verify
   ↓
Report

Without those stages, an organisation doesn't really have vulnerability management.

It has vulnerability discovery.

Those aren't the same thing.

Severity Alone Isn't Enough

Security products often label findings:

Critical

High

Medium

Low

Those ratings are useful.

But organisations still need context.

Suppose I have two high-severity vulnerabilities.

One affects an internet-facing production system.

The other affects an isolated test machine.

Do I treat them exactly the same?

Probably not.

I want to understand:

Is it exploitable?

Is the system exposed?

What data does it contain?

What privileges could an attacker gain?

Is there active exploitation?

What business service depends on it?

That's where process and analyst judgement turn scanner output into risk management.

The Same Problem Happens With SIEM

An organisation can deploy Microsoft Sentinel or another SIEM and say:

"We now have centralised security monitoring."

But I would ask:

Which logs are actually connected?

Are critical systems represented?

Are analytics rules tuned?

Who investigates incidents?

What is the escalation path?

Are detections tested?

Are false positives being reviewed?

Are playbooks documented?

Because this:

SIEM deployed ✓

doesn't necessarily mean:

Effective security monitoring ✓

More Alerts Can Actually Make Things Worse

Another mistake is believing that more alerts automatically mean better security.

Imagine a SOC receives:

10,000 alerts per month

but most are low-quality or repetitive.

Analysts eventually become overwhelmed.

Important detections can disappear into the noise.

That's alert fatigue.

A better security programme asks:

Which detections provide value?

Which repeatedly generate false positives?

Which alerts should be automated?

Which require immediate escalation?

Which can be tuned?

The goal isn't maximum alerts.

The goal is meaningful detection.

Playbooks Matter

If a suspicious account login happens today and again six months from now, the investigation shouldn't depend entirely on which analyst happens to be working.

That's where incident-response playbooks help.

For a suspected account compromise, for example, a playbook could guide analysts through questions such as:

Validate alert
     ↓
Review authentication
     ↓
Check MFA changes
     ↓
Review mailbox rules
     ↓
Check forwarding
     ↓
Determine affected services
     ↓
Revoke sessions
     ↓
Reset credentials
     ↓
Hunt related indicators
     ↓
Document findings

A playbook doesn't replace analyst judgement.

It creates consistency.

But Playbooks Need Testing Too

Writing a beautiful incident-response document doesn't mean the organisation is ready for an incident.

That's why I like the idea of tabletop exercises.

Take a scenario:

A privileged Microsoft 365 administrator account has been compromised.

Then ask:

Who receives the alert?

Who has authority to disable the account?

What if the attacker changes authentication methods?

How do we revoke sessions?

How do we determine what they accessed?

Who informs management?

What if sensitive information was accessed?

Who handles external communication?

Suddenly, weaknesses in the process become visible without needing a real attacker to expose them first.

Documentation Should Survive the Person Who Wrote It

Another lesson I've learned is that a process shouldn't exist only inside someone's head.

If the only person who knows how to respond to a particular incident is unavailable, that's a security risk.

Processes should be documented clearly enough that another capable person can follow them.

That includes:

• Escalation paths

• Incident procedures

• System ownership

• Contact information

• Security baselines

• Exceptions

• Recovery procedures

• Decision criteria

Good documentation creates operational resilience.

Tools Also Need Maintenance

Security products aren't "set and forget."

Environments change.

Users change.

Applications change.

Attack techniques change.

Business requirements change.

A detection rule that worked two years ago may no longer be useful.

An exclusion created temporarily might still exist.

An administrator account might still have permissions it no longer needs.

An endpoint might stop reporting.

A data connector might fail.

Security controls need continuous validation.

I like asking:

Is the control merely configured, or is it still effective?

Those are different things.

The People Matter Too

Security processes can also fail when they're unrealistic for the people expected to follow them.

For example, a policy might say:

"Users must never use unsanctioned applications."

Fine.

But what if the approved application doesn't allow them to perform an essential part of their job?

People will find another way.

This is why security teams need to understand how people actually work.

The strongest security process isn't necessarily the strictest one.

It's the one that reduces risk and can realistically be followed.

Security Maturity Is About Connections

I've worked across environments involving different endpoint, email, backup, mobile and Microsoft security technologies.

One thing that becomes obvious when working with multiple tools is that security doesn't happen inside one console.

An attack might move through:

EMAIL
   ↓
IDENTITY
   ↓
ENDPOINT
   ↓
CLOUD
   ↓
DATA

Meanwhile, the response might involve:

SOC
 ↓
Endpoint team
 ↓
Identity team
 ↓
Cloud team
 ↓
Management
 ↓
Business owner

Technology needs to connect.

But so do people.

What I Look for Beyond the Tool

When I see a security product in an environment, I increasingly ask five questions.

1. What risk is this tool supposed to reduce?

If we can't answer that, why do we have it?

2. Is it configured properly?

Having a licence isn't the same as having protection.

3. Who owns it?

Someone needs responsibility for maintaining and reviewing it.

4. What happens when it detects something?

There should be a defined operational process.

5. How do we know it's working?

Controls need validation and measurement.

Those questions apply whether I'm looking at EDR, SIEM, email security, vulnerability management, backup or cloud security.

The Bigger Lesson

Security technology is important.

I enjoy working with security tools.

But tools aren't the security programme.

A mature security capability looks more like:

PEOPLE
   +
PROCESS
   +
TECHNOLOGY
   ↓
SECURITY CAPABILITY

Remove one of those and the others become weaker.

Technology without process creates alerts nobody handles.

Process without technology can leave teams without visibility.

Technology and process without capable people can lead to poor decisions.

All three need to work together.

Final Thoughts

When evaluating an organisation's cybersecurity maturity, I wouldn't start by asking:

"How many security products do you have?"

I'd rather ask:

What risks are you trying to manage?

What controls address those risks?

Who owns those controls?

How do you detect when they fail?

What happens when an incident occurs?

How quickly can you respond?

Can you recover?

And how do you know any of this actually works?

Because an expensive security platform with nobody monitoring it is just an expensive dashboard.

The real value comes when technology supports a security process that people understand, own and continuously improve.