Security incident in SaaS: what to learn

Your company was not breached. One of your vendors was. And the practical result, for you, is almost the same.

This happens far more often than most managers imagine. In August 2026, OpenAI and Hugging Face published a joint statement about a security incident involving model evaluation. Two large companies, serious security teams, plenty of money. Even so, the problem showed up at the contact point between them. Not inside one, not inside the other: in the seam. Every SaaS security incident I have seen up close had that same smell. The hole is almost never in the vault. It is in the door someone left ajar between two systems that needed to talk.

If your company uses a cloud CRM, an email sender, a digital signature tool, a shared spreadsheet and three or so AI plugins, you have that seam in several places. Probably without knowing where.

Why the vendor's incident becomes your problem

There is a common confusion here. The SaaS contract says the vendor takes care of the infrastructure. True. But the data is yours, and so is the responsibility toward your customer.

Think about the concrete case. Your lead base sits in the CRM. The CRM has an integration with a data enrichment tool. That tool suffers a leak. Who calls the customer to explain? You. Who answers to privacy regulators? You. The vendor sends a polite statement and moves on.

And it is not only about leaks. A vendor down for 12 hours is also an incident. If your WhatsApp support depends on an API that went down, your operation stopped, no matter whose fault it was.

The risk does not live on your server. It lives in the list of things you signed up for and forgot.

The real problem is that nobody knows how many tools exist

Here comes the boring part. Run a quick test: ask your finance lead how many software subscriptions the company pays for each month. Then ask the team how many tools they actually use.

The numbers will not match. They never do.

At a 30-person company I worked with, finance listed 11 subscriptions. The actual audit found 27 tools with access to some operational data. The 16 extras were free plans, trials that became permanent, and a PDF converter someone in sales used to handle customer contracts. Contracts with tax ID, address, amount. Passing through a random website because it was convenient.

Nobody acted in bad faith. That person just wanted to get their work done. It is always like that.

What to do in the next 30 days

I am not asking you to build a security department. That is a conversation for a different size of company. I am talking about three things that fit into one afternoon.

1. Make the list. One spreadsheet, five columns: tool, who uses it, what data it touches, what it costs, who owns it internally. Pull it from the corporate card statement. That is the most honest way to find out. Then ask in the team chat: "which tool do you use that is not here?". Things will show up.

2. Cut dead access. Former employee who still has a login. Integration from a project that ended in 2024. API token created for a test and never revoked. This is the highest return per minute spent, and almost nobody does it. Dead access is the door left ajar.

3. Turn on the second factor where it hurts. Company email, CRM, banking, password manager. Those four, no exceptions and no negotiation. If someone complains that it delays login by eight seconds, compare that to the time it takes to notify 4,000 customers about a leak.

Strong opinion, and I stand by it: if your company does only those three things and nothing else, you are already above average for small and midsize businesses. The bar is low. Take advantage of it.

Where AI made the bill worse

Here is the news of the last two years, and it is exactly the kind of thing that showed up in the OpenAI and Hugging Face case.

AI tools are hungry for context. To give a good answer, they need good data. So the team feeds them good data. Meeting transcripts. Revenue spreadsheets. Customer conversation history. Candidate résumés.

And every new AI integration is one more seam. The assistant that reads your email has access to your email. Obvious when written like this, less obvious when it is just a "connect" button on a pretty screen.

Two questions that settle 80% of the decision before you connect anything:

• What does this tool do with my data after it answers? Store it? Train a model? Delete it?
• If this company disappears tomorrow, what do I lose and how long do I need to replace it?

If the answer to the first one is not written somewhere on the vendor's site, that is already an answer.

What separates who suffers a little from who suffers a lot

I noticed a difference between companies that go through a vendor incident and come out almost unharmed, and those that spend three weeks putting out fires. It is not the security budget. It is something else.

The ones who suffer little can quickly answer two questions: where is this data and who else has access to it. Within an hour, they can open the spreadsheet, see that vendor X only touched the newsletter email list, revoke the token and notify whoever needs to know. Done.

The ones who suffer a lot spend those same three days trying to find out whether that vendor had access to finance or not. The damage is not the leak itself. It is the fog.

And fog is not solved with a tool. It is solved with an up to date spreadsheet and someone responsible for it. One of the dullest things there is, and that is exactly why nobody does it.

A response plan that fits on one page

You do not need a 40-page manual. You need a document that answers, for the bad day:

• Who decides (one person, with a name, not "the board").
• Who notifies the customer and through which channel.
• Where the list of vendors and access lives.
• How to revoke access quickly in each critical system.
• What the backup is and where it lives, tested in the last 90 days.

That last item deserves its own sentence: a backup that has never been restored is not a backup, it is hope. Test it once a quarter. Restore any random file. It takes 15 minutes and keeps you from discovering the problem at the worst possible moment.

When OpenAI and Hugging Face went public, what caught my attention was not the failure itself. It was the speed of the response and the fact that a process already existed. You do not improvise that on the day. You write it beforehand, when everything is calm and it seems unnecessary.

Start with the cheapest part

If you made it this far and want to do one single thing today, make the list of tools. It costs one afternoon, it costs no money, and it will show you two or three surprises.

After that, the conversation gets easier: with the team, with the accountant, with the customer who asks how you handle their data.

I work exactly in that range, helping companies organize the tools they already use, connect the ones that make sense and shut off the ones that only take up space and risk. If you want an outside opinion on your current map, reach out for a conversation.

Your company was not breached. One of your vendors was. In practice, the problem is the same.

I asked the finance lead of a 30-person company how many software subscriptions they paid for. Answer: 11. The actual audit found 27 tools with access to operational data.

One of them was a random PDF converter where the sales team handled contracts with customer tax IDs and addresses. Nobody acted in bad faith. That person just wanted to get their work done.

When OpenAI and Hugging Face went public about their incident, what stood out was not the failure. It was having a process ready.

What separates who suffers a little from who suffers a lot is not the security budget. It is being able to answer in one hour: where is this data and who else has access to it.

Start today with the cheapest part: list your tools, cut dead access, turn on 2FA for email, CRM, banking and password manager. One afternoon, zero dollars.

If you want an outside opinion on your current map, reach out.

#InformationSecurity #DataPrivacy #ITManagement #SMBs #DigitalTransformation