• Sep 21

The Insider Threat Your Board Isn't Talking About

  • ExecPacks Team

Most board-level cybersecurity conversations focus on external attackers. But some of the most damaging breaches come from inside the organisation.

When boards discuss cybersecurity risk, the conversation almost always focuses outward: sophisticated nation-state actors, ransomware groups, phishing campaigns targeting employees. These threats are real and deserve serious attention.

But the cybersecurity risk profile most organisations carry is more complicated than the external threat landscape alone suggests. A significant proportion of the most damaging breaches — both financially and reputationally — originate inside the organisation. And insider threats are, in several important respects, harder to detect, harder to prevent, and harder to recover from than external attacks.

What We Mean by Insider Threat

Insider threat does not mean disgruntled employees deliberately sabotaging systems, though that does happen. The category is broader and considerably more common than that framing suggests.

Security researchers typically distinguish between three types. Malicious insiders deliberately misuse access to harm the organisation — stealing data for a competitor, committing fraud, or causing deliberate damage. Negligent insiders create risk through carelessness — misconfiguring systems, falling for phishing attacks, sending sensitive data to the wrong recipient, using unsecured personal devices for work. Compromised insiders are employees whose credentials or access have been taken over by external actors — often without the employee's knowledge.

Each type requires a different response, and most organisations conflate them — treating insider threat as a single category when the controls and indicators for each are quite different.

Why Insider Threats Are Structurally Hard to Detect

External attackers trigger alerts because their behaviour is anomalous — they are doing things that the system does not expect them to do. Insiders, by definition, have legitimate access. Their normal behaviour patterns include accessing sensitive systems, moving data, and interacting with critical infrastructure. The signals of malicious or negligent behaviour are subtle variations on legitimate activity, not obvious intrusions.

This creates a detection challenge that technical controls alone cannot solve. User behaviour analytics — software that establishes baselines of normal activity and flags deviations — can help. But it produces significant false positive rates, requires human review, and still misses sophisticated actors who move slowly and carefully.

The organisations that detect insider threats most effectively combine technical monitoring with cultural and management signals: unusual access requests, unexplained changes in work patterns, financial pressures that create incentive, interpersonal conflicts that create motivation. These are human intelligence signals, not technical ones.

The Access Privilege Problem

One of the most consistent findings in insider threat investigations is that the individual had access they didn't need. Over time, as roles evolve, as projects change, and as organisations grow, access rights accumulate. People who moved from one role to another retain the permissions of their previous role. Contractors and former employees sometimes retain access long after their engagement ended.

The principle of least privilege — ensuring that individuals have access only to what they need to do their current job — is widely understood and widely under-implemented. It requires ongoing maintenance, not a one-time setup. And it requires someone with ownership of the problem: a role that many organisations have not clearly assigned.

For boards, the right question is not "do we have an access control policy?" but "when did we last audit who has access to what, and how does that compare to what they actually need?"

Third Parties Extend the Threat Surface

Insider threat does not stop at the organisation's own employees. Contractors, suppliers, managed service providers, and technology vendors frequently have privileged access to internal systems. The 2013 Target breach — one of the most significant retail data breaches on record — originated through a third-party HVAC contractor's credentials.

Third-party access is often less well-governed than employee access: fewer controls on what can be accessed, less monitoring of activity, and less rigorous off-boarding when engagements end. For organisations with complex supply chains and extensive third-party relationships, this is a material risk that belongs in the board's risk conversation.

What Boards Should Be Asking

Insider threat does not require technical expertise to govern — it requires the right questions. Are we monitoring privileged access? When did we last conduct an access rights review? Do we have a process for managing third-party access? What would we do if we suspected an insider incident — and have we tested that response?

These are governance questions. They belong at board level, not because boards should be managing the controls, but because they need assurance that the controls exist and are working.

Our Cybersecurity for Non-Technical Executives ExecPack gives board members and senior leaders the literacy to ask these questions with confidence — and to understand the answers they receive.

On-demand. Under 2 hours. Lifetime access.

0 comments

Joinor login to leave a comment

👇 What to Do Next

✅ Like what you’re reading?

You can add more detail in this subtitle

ExecPacks are curated learning experiences built for busy leaders. Each pack includes expert-led presentations, practical resources, and downloadable tools — all designed to help you solve real business challenges in under two hours.

📩 Want more insight?

Stay Ahead with ExecPacks Insights

Trusted Insights. Delivered Monthly.

Join our newsletter for executive-level updates, expert insights, and early access to new learning packs — straight to your inbox.

No spam. No fluff. Just strategic insight and real-world value.