I spend most of my time around developers who think “security” means:
npm audit
and a .env file that’s definitely in .gitignore file.

If you browse our (= Espresso Labs) pitch to law firms, you realized: the threat model we’re describing for a 40-person law firm is identical to the threat model for your bootstrapped SaaS, your dev agency, or your local accounting shop.
Only the data changes.
The attacker’s playbook doesn’t.

Here’s what I learned, and what I think every SMB owner and every engineer who’s ever been “the security person by default” should take from it.

Law firms are basically unencrypted API keys with a bar license

Think about what a law firm actually is, technically: a small team with admin access to an enormous amount of high-value, high-leverage data — M&A deal terms, litigation strategy, medical records, wire transfer instructions — protected by, in a lot of cases, the same IT hygiene as your uncle’s dentist office.
(It’s ugly – I know)

That mismatch between value of data and maturity of defenses is exactly what makes a target attractive, and it’s the same mismatch that makes early-stage startups attractive. You might not have client trust funds, but you’ve got:

• Customer PII sitting in a Postgres instance with one shared root password
• Stripe and AWS keys pasted into a Slack channel from 2023
• A single Google Workspace admin account with no hardware key
• A CI/CD pipeline that, if compromised, is basically a printing press for supply-chain attacks

The page cites a few real incidents worth knowing about if you haven’t followed legal-sector security news: Jones Day disclosed a breach traced back to a phishing attack, a firm handling healthcare records exposed data on roughly 300,000 people, and suspected state-sponsored actors breached a prominent D.C. firm.
None of these firms were careless by industry standards.
They just had the same gap most SMBs have: policies on paper, nobody watching in real time.

The “5pm Friday problem” every on-call engineer already understands

The line from that page that actually stopped me was this: what happens when an alert fires at 5pm on a Friday?
Is anyone awake to triage it, understand it, and act — or does it sit in a queue until Monday morning?

Every engineer who’s carried a pager knows exactly why that question matters.
An unhandled alert isn’t a paperwork problem, it’s a live incident with a clock running.
Ransomware doesn’t wait for business hours — most operators deliberately trigger encryption routines on Friday evenings because they know IT support windows close. If your “security monitoring” is a Gmail filter and good intentions, you don’t have monitoring — you have a very slow smoke detector.

The eight controls, translated into developer

Strip the compliance language off the list Espresso Labs put together for law firms, and it maps almost one-to-one onto a hardening checklist for any small technical team:

Their framing	What it actually means for you
Access Control & MFA	Hardware keys (YubiKey/Passkeys) on your IdP, least-privilege IAM roles, no shared root logins
Encryption	TLS everywhere, encrypted volumes/backups, secrets in a vault (not .env in git)
Email Security	DMARC/DKIM/SPF actually enforced, not just configured; phishing-resistant MFA for finance approvals
24/7 Monitoring	Centralized logging + alerting (even a scrappy stack: Wazuh, Grafana + Loki, or a cheap SIEM) with someone actually on the hook to respond.
Incident Response	A written runbook you’ve actually rehearsed — who kills prod access, who calls the lawyer (ironic, I know), who notifies customers
Audit Logging	Immutable logs of who touched what — your future self debugging an incident will thank you
Vendor & Third-Party Risk	Know what your SaaS vendors and contractors can touch. That Zapier integration with full Drive access? Audit it
Security Awareness	Five minutes teaching your team to spot a fake DocuSign or invoice-change email saves you a six-figure wire fraud loss

None of this is exotic.
It’s the boring 20% that prevents 80% of real-world incidents, and it’s exactly the stuff that’s easiest to skip when you’re three people shipping features at 2am.

Build it yourself, or buy the SOC?

This is really the interesting question for an SMB owner, and it’s a classic build-vs-buy tradeoff, not a moral one.

DIY is very doable if you’re technical (and a security/IT expert).
These are some options that you might want to try (or just use EspressoLabs’ platform):

• Identity: Google Workspace/Entra ID + enforced hardware-key MFA
• Secrets: 1Password Teams or HashiCorp Vault instead of Slack pastes
• Endpoint: osquery or a lightweight EDR agent, even on a handful of laptops
• Monitoring: Wazuh (open source SIEM) or a $20/mo Grafana Cloud + Loki setup, feeding Slack alerts
• Backups: restic or borgbackup to an immutable, versioned bucket — test restores quarterly, not never
• Network: Tailscale instead of a flat VPN, so a stolen laptop doesn’t equal a stolen network

Managed makes sense when the “24/7” part is the actual bottleneck.
This is the honest pitch behind Espresso Labs and the other competitors in that space.

A two-partner law firm or a five-person agency genuinely cannot staff a real SOC.
Paying for continuous monitoring and incident response is often cheaper and more reliable than one overworked engineer trying to be security, compliance, and IT support simultaneously — which is a real, common failure mode, not a hypothetical.

The mistake I’d flag for SMB owners either way: don’t buy point solutions that don’t talk to each other.
Antivirus from one vendor, backup from another, email filtering from a third, none of it correlated — that’s the same “disconnected tools” trap regardless of whether you assembled it yourself or a vendor sold it to you piecemeal.

The goal is one place where signals actually connect into an alert a human can act on.

A minimum-viable security checklist for your next Friday afternoon

If you run or work at an SMB and want the 80/20 version of everything above, block a day (or a few hours if you are fast) and do this:

1. Turn on hardware-key or passkey MFA for your identity provider, email, and cloud console.
   No exceptions for the founder nor the lazy CEO.
2. Rotate every credential that’s ever touched Slack, email, or a shared doc in plaintext.
3. Set up DMARC enforcement (p=reject) on your domain — most companies never get past p=none.
4. Write a one-page incident response plan: who has authority to cut off access, who calls customers, who calls a lawyer.
5. Test one backup restore, today, for real.
6. Ask every SaaS vendor with write access to your data: “what happens if you get breached?” You’ll be surprised how many can’t answer.

None of this requires a five-figure retainer.
It requires about an afternoon and the discipline to actually finish it instead of filing it under “Q3 goals.”

The real takeaway

Attackers don’t care whether your letterhead says “LLP” or “Inc.”
They care whether you’re an easy, high-value target.
Law firms are having a rough couple of years for the same reason a lot of SMBs will eventually have a rough week: sensitive data, thin security staffing, and a reactive-instead-of-continuous posture.

The fix isn’t glamorous — MFA, monitoring, backups, and a plan you’ve actually rehearsed — but it’s the difference between a Friday night that’s annoying and one that ends your company.

Btw, if you found this useful, I’d love to hear what your own SMB security stack looks like.
Be strong and safe!