Controls, Controls, Controls — Everyone Gets a Control!
Somewhere in your enterprise is a threat no security control can contain: an employee determined to finish their work.
There has always been a fine line between security and usability. The only truly secure computer is one encased in concrete with no power, and even then someone would show up with a jackhammer. Every time a new threat emerges, security teams add a control to counter it. But every control adds friction, and the more friction we add, the more likely we are to break the business processes we’re supposed to protect.
The Business Goal
Here’s a scenario to illustrate how it happens.
Joe is a billing clerk at a medical clinic, and he works on denied insurance claims. There are 25 to 30 denials a day, and each one needs an appeal letter restating the clinical justification against the payer’s denial reason. The letters are formulaic, but each still takes 12 to 15 minutes, and they all have to be filed on time.
The Control
Security has blocked consumer AI domains at the firewall and runs Data Loss Prevention (DLP) on the endpoints to catch PHI in the clipboard and in uploads. It’s a reasonable, defensible control. The problem is that there’s no sanctioned alternative. The enterprise AI licensing request has been stuck in procurement since March.
The Workaround
Joe opens the denial letter and the clinical notes side by side on his PC. He takes out his personal iPhone, photographs the screen, and uploads the photo to ChatGPT over the cellular network. Moments later, he has a draft appeal, which he retypes into the EHR with a few tweaks. Fifteen minutes becomes four. In his mind, he’s being efficient, and he never “sent” anything anywhere.
What Actually Happened
- PHI left the covered entity with no proxy log, no DLP alert, and no evidence at all.
- Copies of that PHI now live in Joe’s camera roll, likely in his iCloud Photos, and in his personal ChatGPT history. There’s no BAA covering any of them.
- The clinic has a HIPAA disclosure it can’t identify, can’t scope, and can’t report if Joe’s accounts are ever compromised.
- Joe will do this 25 more times today and tell no one. He assumes that because the tool is blocked, asking to use it will get him written up.
Now check the DLP dashboard: zero PHI events involving generative AI this quarter. That number is accurate and completely meaningless. The control didn’t stop the disclosure. It moved the disclosure off the books and created extra copies on the way out.
What Could Have Happened Instead
If the clinic had provided a sanctioned tool, whether on-premises or a BAA-covered cloud service:
- The PHI would have gone somewhere the clinic has a contract with.
- No copy would exist anywhere security can’t see.
- The interaction would be logged, including who used it and what prompt they sent.
- Joe would come to IT with his next idea instead of hiding it.
By the Numbers
Joe isn’t an outlier. The 2026 Verizon Data Breach Investigations Report found that regular AI use on corporate devices tripled in a year, from 15% to 45% of employees. Of the users accessing AI services from corporate devices, 67% did so with non-corporate accounts. These people are already on managed devices, under our controls, and routing around them anyway. Pressure to get work done, do more with less, and stay relevant pushes good employees into risky choices.
Is Your Compliance Budget Balanced?
In 2008, researchers Adam Beautement, Angela Sasse, and Mike Wonham proposed the idea of a compliance budget. Every control costs the user some friction, and every user has a limited amount of friction they’ll tolerate before they start working around things. Like any budget, it forces trade-offs. Spend it on low-value controls, and there’s nothing left for the ones that matter.
Joe’s clinic spent his entire budget on a block and gave him nothing in return. So he found his own way.
Passwords are the classic example. For years we required rotation every 90 days and at least three of uppercase, lowercase, numbers, and special characters. Users complied in the easiest way possible. Run a password audit with a cracking tool and count how many Summer2026! and Fall2026! entries you find. Every one of them meets the policy, and every one is trivially guessable. Then we stacked MFA on top, and now we’re bankrupt with the user.
Even the author of those rules gave up on them. Bill Burr wrote the original 2003 NIST password guidance, and in 2017 he told the Wall Street Journal, “Much of what I did I now regret.”
NIST has since caught up. SP 800-63B-4, finalized in August 2025, says verifiers shall not impose composition rules and shall not require periodic password changes. Changes are required only when there’s evidence of compromise. Instead, NIST requires longer passwords and screening against lists of common and breached passwords.
(Yes, really. I’ll wait while you recover.)
That frees up budget to spend where it counts: MFA. No normal user loves MFA. Try getting your parents to turn it on for their home accounts and see how far you get. It’s worth the friction because it actually stops attacks.
One caveat for anyone under PCI DSS: v4 still requires 90-day rotation when a password is the only factor. That’s one more reason to make MFA the default.
No-as-a-Service Can’t Be the Default
Blocking isn’t wrong. Blocking without an alternative is. Before your next “no,” ask four questions:
- Can we actually enforce it? If a phone camera defeats the control, you aren’t preventing the behavior. You’re preventing yourself from seeing it.
- What’s the sanctioned path? Give people a tool that’s at least as good as the one you’re blocking, and give them a request process measured in days, not quarters.
- Will people tell us when it isn’t working? If asking gets you written up, nobody asks. The UK’s NCSC warns that punishing staff for shadow IT makes their peers stop reporting it, which leaves you with even less visibility.
- Did we teach the why? “Don’t paste PHI into a chatbot, and here’s the approved tool that’s allowed to see it” beats an annual 40-slide module.
Some things should stay blocked: regulated data heading to services that can’t sign a BAA, tools that train on your inputs, and anything you can’t meet your contractual obligations with. But those blocks work best when the approved path sits right next to them.
Shadow IT is a bug report. Every unsanctioned tool is a user telling you exactly which business need you didn’t meet, with a working prototype attached. The question is whether you read it, or wait for it to show up in the breach notification.
Sources
- Verizon, 2026 Data Breach Investigations Report — https://www.verizon.com/business/resources/reports/dbir/
- Beautement, A., Sasse, M.A., & Wonham, M. (2008). “The Compliance Budget: Managing Security Behaviour in Organisations.” Proceedings of the New Security Paradigms Workshop (NSPW).
- NIST, SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management (August 2025) — https://pages.nist.gov/800-63-4/sp800-63b.html
- McMillan, R. “The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d!” The Wall Street Journal, August 2017 — https://www.wsj.com/articles/the-man-who-wrote-those-password-rules-has-a-new-tip-n3v-r-m1-d-1502124118
- Free coverage of the same story: https://www.theverge.com/2017/8/7/16107966/password-tips-bill-burr-regrets-advice-nits-cybersecurity
- UK National Cyber Security Centre, Shadow IT guidance — https://www.ncsc.gov.uk/guidance/shadow-it
