Field Note 1: The Night I Accidentally Became the CISO

A nonprofit, ten superadmins, and one very tired privacy technologist.

* Disclaimer: Based on a real-world incident. Names, roles, and details modified for confidentiality.

The Breach

It started, as most security disasters do, with one small administrative failure.

Our VP’s Google Workspace account had been compromised. The attacker didn’t just steal their password—the attacker weaponized the vacation auto-reply. Anyone suspicious enough to write back “Did you really send this?” got an instant reassurance: “Yes, that email was real. Please fill out the form.” Even after the VP reset their password, the auto-reply kept firing. The trap was elegant in its cruelty.

When the VP called me, I wasn’t the designated superadmin. I was just the one person who actually read documentation. Our only other tech-savvy contact—the contractor who manages our social media—was hospitalized that week. So the hot potato landed squarely in my hands.

I logged into the admin console and nearly passed out: more than ten superadmins. Some were former staff, others long-gone volunteers. Accountability was nonexistent.

The Containment

Then one panicked superadmin suspended the VP’s account, reset their password, and reactivated it—all within minutes. I immediately suspended the suspicious superadmin account and called the superadmin.

“Oh, that was me. Why did you suspend me?”

I had to pause, count to three, and explain that was exactly what an attacker would do—reset, reactivate, and start exfiltrating donor data.

At that point, I couldn’t trust anyone. I began deleting and demoting every superadmin who wasn’t absolutely essential. I suspended both the VP and the clueless admin until I was sure their accounts were clean. Then I flipped the switch: mandatory password resets and MFA enforcement for everyone.

And that’s when the noise started.

Because Google Workspace doesn’t provide a grace period when enforcing MFA, users had to reset their passwords and complete the two-factor setup immediately to regain access. Those who followed the prompt could log back in without issue. But several skipped the MFA step—Google didn’t warn them clearly—and then discovered they’d locked themselves out.

Yes, it inconvenienced them. But when your VP’s account is still auto-replying “Yes, that email was real” and you don’t yet know how deep the compromise goes, user convenience isn’t the priority. Containment is.

The Log Dive and the Backlash

By 3:00 a.m., I was deep in activity logs, combing through every line. Around 2:30 or 3:00, I spotted the suspicious OAuth token pretending to be legitimate access. I killed it, confirmed no further anomalies, and kept reviewing logs to ensure the breach was contained.

Then, at 3:30 a.m., my phone buzzed. A director texted:

“I cannot log in. My analyst couldn’t log in today. This is inappropriate!”

I stared at the screen. Inappropriate? The system had been compromised for more than 12 hours and this was the priority? (and why are you trying to log in at 3:30 a.m.?)

By 6:00 a.m., I was re-issuing recovery codes from my Microsoft org account to their personal email addresses because they were locked out and still confused. Meanwhile, I was just trying to make sure Google itself wasn’t still compromised.

The breach was contained. Apparently my real offense was making people set up MFA.

A few days later, we pulled in a cybersecurity firm. They didn’t praise my technical fixes. They praised the documentation. Every timestamp, every action, every log entry. After two hours, they concluded, “You’re fine. Your posture’s good.”

That was the first time anyone had ever called our ragtag nonprofit’s posture good, and it almost felt like redemption.

Governance by Absence

By sunrise, the inbox was quiet again. The system was clean. But what broke wasn’t the tech—it was the culture.

This wasn’t heroism. It was simply triage that should never have been necessary.

Most small organizations live in Governance by Default—trust and good intentions posing as controls. They think they’re too small to be targeted and say, “We don’t need a CISO.” They’re right, until they’re spectacularly wrong.

Our failure wasn’t technical—it was cultural. Security was treated as optional because convenience always won. Four-character passwords, no enforced changes, no MFA, and endless grumbling whenever people had to verify from a new device.

The attack didn’t exploit a zero-day. It exploited human impatience.

Principle: Least Privilege. Missing Control: A maintained, accountable list of privileged users.
Principle: Separation of Duties. Missing Control: A defined incident triage owner vs. the admin doing the cleanup.
Principle: Audit Trail. Missing Control: A playbook describing what evidence to capture during a live breach.

By sunrise, the breach was gone. The real infection—complacency—remained.

Start Here If You Have No CISO

If your organization will still be CISO-free in a hundred years, start here. No budget, no consultants, no excuses:

Prune the Admin Accounts.

Log into your identity management console (Google Workspace, Microsoft 365, etc.). Delete or demote every superadmin who isn’t essential and accountable. Two superadmins max—three if you enjoy chaos.

Enforce MFA—Today.

Require multi-factor authentication on all accounts, especially admin ones. Google won’t wait for your users to find the “set up later” button.

Create a One-Page Triage Doc.

A simple page or Markdown file listing:

- Who to call first (Legal, PR, IT).

- Where to find your audit logs (URLs for Google/Azure/AWS).

Congratulations—you now have your first Incident Response playbook.

The easiest security drama is the one that never happens.

Because sometimes ‘security policy’ is just you, caffeine, and a to-do list no one else reads.