Insider threats and shadow IT: the risks no data strategy paper covers

The data risk your security team worries about comes from external attackers. The data risk your CDO should worry about is sitting two floors below in the marketing department, running their own Tableau workbooks on a spreadsheet download from a system that hasn't been updated in six months.

Shadow IT and insider threats are the unglamorous data risks that never make the security conference keynotes, and are responsible for a significant proportion of real-world data incidents.

Shadow IT: the data risk you didn't approve

Shadow IT in data is any data processing happening outside your governed infrastructure. It looks like:

• An analyst maintaining a "personal" copy of customer data in a Google Sheet "because the official system is too slow"
• A regional team building their own dataown dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.View full definition → warehouse in Microsoft Access "because IT won't give them what they need in time"
• A product manager downloading a 500,000-row customer export "just to do some quick analysis"
• A department head using a third-party AI tool to analyze customer feedback, pasting customer data into ChatGPT

Every one of these scenarios creates data risk: GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → non-compliance, data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → inconsistency (the "spreadsheet version" diverges from the authoritative source), security exposure (data in unauthorized systems), and governance breakdown (the CDO doesn't know what data is being used, by whom, for what purpose).

Shadow IT in data is almost always a symptom of legitimate frustration. People build their own solutions because the official infrastructure doesn't meet their needs. The CDO who responds with "stop doing that" without addressing the underlying need will fail. The CDO who makes the official infrastructure fast, accessible, and self-service will eliminate most shadow IT naturally.

Insider threats: malicious vs. negligent

Malicious insiders are employees or contractors who intentionally misuse their data access. They may steal customer data for financial gain, take confidential information to a competitor, or sabotage data systems. These are relatively rare but high-impact.

Negligent insiders, far more common, are employees who cause data incidents through carelessness rather than intent. The analyst who emails a customer list to a personal email address to work from home. The engineer who commits database credentials to a public GitHub repo. The customer service rep who accesses a celebrity's account out of curiosity.

Most data loss prevention (DLP) programs focus on malicious insiders. Most incidents are caused by negligent ones. The CDO's program should address both, with different approaches: technical controls for negligent actors (you can't email sensitive files to external addresses), behavioral monitoring for malicious ones.

The Uber 2022 case

In September 2022, Uber disclosed a major security breach. The attacker was an 18-year-old who didn't use sophisticated technical exploits. They used social engineering.

The attacker contacted an Uber employee via WhatsApp, claiming to be Uber IT security. They asked the employee to approve a multi-factor authentication (MFA) request. The employee, tired of repeated notifications (an "MFA fatigue" attack), eventually approved it. The attacker had full network access.

Once inside, the attacker found a PowerShell script on a network share. The script contained hard-coded credentials for Uber's privileged access management (PAM) system. With those credentials, they had access to virtually everything: AWS, Google Cloud, Slack, HubSpot, internal tools, and a security vulnerability database.

The data risk: the attacker found confidential files, internal security information, and potentially personal data of employees and drivers.

The CDO lessons:

1. Credential management: secrets (APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → keys, passwords, database credentials) must never be stored in scripts or code repositories. Use secrets managers (AWS Secrets Manager, HashiCorp Vault).
2. Least-privilege: once inside, the attacker had access to almost everything. Proper access segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → limits the blast radius.
3. MFA fatigue attacks are a real threat: implement number-matching MFA rather than simple push approval.

Building a data risk governance program

The CDO owns data risk, in partnership with the CISO. The CISO typically owns security infrastructure; the CDO owns data governance, classification, and the policies that determine what's at risk.

A CDO data risk program includes:

• Data inventory: You can't protect data you don't know about. Monthly sweeps for unclassified data assets.
• Access reviews: Quarterly review of who has access to confidential and restricted data. Remove access that's no longer needed.
• Shadow IT detection: Monitor for unauthorized data transfers (DLP tools), unauthorized cloud storage, unauthorized AI tool usage with company data.
• Insider threat monitoring: Behavioral analytics on data access patterns, without becoming surveillance that erodes trust. Establish clear policies on what is monitored and why.
• Regular training: Most data incidents involve human error. Annual data security training for all employees; more frequent training for data handlers.