Most security conversations with growth-stage companies start with confidentiality — who can see the data — and integrity — has it been tampered with. Availability, the third leg of the CIA triad, tends to get treated as an infrastructure problem instead of a governance one.

It surfaces the day a vendor your product depends on goes down and nobody can say how you'd have known sooner. A recent internal exercise made the gap concrete: a small uptime monitor covering five widely-used consumer platforms — the kind of services that quietly sit underneath authentication flows, customer communication, and marketing reach for a lot of the companies we work with. The build itself is beside the point. What it exposed is the part worth sharing.

2 of 5

services tested publish a real, machine-readable status feed you can build automated alerting on

3 of 5

publish nothing usable for that purpose — status pages, where they exist, cover internal tooling, not the consumer service

SOC 2

Trust Services Criteria include Availability as an explicit category when it's in scope

That split is the finding that matters. A vendor risk program that assumes every critical dependency will proactively tell you when it's degraded is building on an assumption that doesn't hold for a meaningful share of the SaaS stack.

If you don't independently verify reachability, you find out about an outage the same way your customers do — after it's already affecting them.

Auditors increasingly expect evidence that goes beyond "our vendors have SLAs." They want to see that a company has actually mapped its critical third-party dependencies and has some mechanism — however lightweight — for knowing when one of them is impaired. Vendor risk programs built for a SOC 2 attestation, or for enterprise sales due diligence, live or die on whether that mapping is current and whether it's backed by anything more than trust.

The same gap shows up in business continuity planning. A BCP that lists "vendor outage" as a risk without a concrete way to detect one in real time isn't a plan — it's a paragraph. Detection has to come before response.

There's a smaller lesson buried in the build that's worth calling out on its own. The monitor ended up with two separate interfaces — one conversational, one a live dashboard — but both were built to call the exact same underlying check, so there was never a version where the two disagreed about whether a service was actually reachable.

Diagram of a conversational path through Claude Desktop and a visual dashboard path through a browser, both resolving through a shared checker.py core before pinging five external services.
Same question, two front doors: conversational and dashboard paths both resolve through one shared check

That's a pattern worth insisting on inside a security program too. When an incident is unfolding, the fastest way to lose time is for different teams — engineering, support, leadership — to be looking at different, slightly inconsistent signals about what's actually down. A single source of truth for "is this dependency healthy" isn't a technical nicety; it's what keeps an incident response process from arguing with itself in the first ten minutes.

None of this requires an enterprise monitoring platform or a dedicated headcount. A short, honest inventory of the vendors a product actually can't function without, paired with a lightweight way to verify their reachability independently of what they choose to publish, is inexpensive to stand up and immediately useful — as an operational safeguard, and as evidence the next time an auditor or an enterprise buyer asks how you'd know.

Identity providers Payment processors Communication tools

It's the kind of gap that never looks urgent — until it costs you a customer or an audit finding. That's what a risk snapshot is for.