COMMENTARY: Compliance does not always mean strong security. There are many certifications like SOC 2, HIPAA, and ISO 27001, but these only show that a company passed an audit at a certain point in time. They do not always show how well customer data is protected every day. The bigger thing is to ask who controls the encryption keys, how the vendor tracks new data flows, when it last ran a penetration test, and whether security is treated as a real priority. So it's not just about the "certification", but who is "actually" protecting.
Early in my career, I was responsible for the technology infrastructure supporting one of the country's largest crisis intervention platforms.
Every day, people reached out through that system in the most vulnerable moments of their lives. They weren't thinking about encryption standards or subprocessor agreements. They were trusting — implicitly, completely — that the platform holding their words would protect them.
That experience shaped how I think about security. Not as a compliance exercise. As a moral obligation.
Which is why what I'm seeing across the AI industry right now concerns me.
We built a remarkably efficient system for "appearing" secure
Don't get me wrong — implementing the controls behind SOC2, HIPAA, and ISO 27001 dramatically helps establish important security baselines. The industry that has grown up around helping companies pass these audits is doing meaningful work. The controls matter.
But controls are only as effective as the culture they sit inside. A SOC2 report tells you a company implemented the right technical measures on the day the auditor checked. It doesn't tell you whether an engineer three levels down feels safe raising their hand when they spot a problem. It doesn't tell you whether an executive will hold a launch to fix a security issue under a tight deadline, or quietly ship and patch later. Security has to be a value the company refuses to trade against. And that only happens when the very top of the organization treats it as existential.
The tools that help companies complete audits are good at checking boxes. None of them can install that belief.
Which is why the result is predictable: two organizations can hold identical certifications with radically different actual security postures. The frameworks allow for it. They require
sufficient controls, not
specific ones. What counts as sufficient is a judgment call made at audit time, not an engineering standard baked into the architecture.
It's also worth noting how audits actually work. An auditor reviews a dashboard, validates the evidence a company hands them, and confirms the controls exist. They don't ask probing questions. They don't go into the code or the production environment to verify anything the way a penetration tester would. A certification ultimately reflects the integrity of the organization being audited, because the auditor is trusting the company to report honestly about itself.
That model worked reasonably well when software was shipped on quarterly cycles and threat landscapes moved slowly. It strains badly in a world where companies push code to production multiple times a day and the threat model shifts between audit windows.
For IT channel professionals advising clients on vendor selection, this is a quiet problem that rarely surfaces until something goes wrong.
A certification tells you that a vendor has passed a review. It doesn't tell you where the keys live, who can access the data, or what happens when the threat model changes after the audit closes.
There are three gaps where I see the most meaningful exposure in AI platforms handling sensitive data today.
Who actually controls the encryption keys? Most compliance frameworks are satisfied when data is encrypted in transit and at rest. What they rarely interrogate is
"whose keys are doing the encrypting." A meaningful number of vendors rely on the default encryption keys their cloud providers supply — which means a compromise of that cloud provider, or an insider with the right access at that cloud provider, can read customer data. Vendors that manage their own keys (rather than relying on vendor defaults) meaningfully narrow that blast radius. It's not an exotic control. It should be a baseline question in any security review.
Static compliance against a dynamic data surface. AI platforms don't stay still. New models get integrated. New subprocessors get added. New data flows emerge between product releases. A compliance audit captures a snapshot of the environment at a specific moment in time. The gap between that snapshot and the live system grows every time the product ships, and most frameworks don't require continuous monitoring at that layer.
Auditors validate evidence, not reality. As noted above, audits rely on self-reported evidence. That's a structural feature of the model, not a failure of any individual auditor — but it means a certification is a strong signal only when the organization behind it has a culture of honesty about its own gaps. Penetration tests, by contrast, validate the environment directly. For vendors handling sensitive conversation data, the presence of regular external testing matters as much as the certifications on the website.
The industry is measuring the wrong thing.
Security teams are trained to quantify breach risk in financial terms. Regulatory fines. Remediation costs. Reputational damage. That framework works well for most threat scenarios.
It breaks down completely when the data being protected isn't financial, and when the organizations protecting it aren't operating under frameworks like HIPAA in the first place. Many crisis services and behavioral health organizations aren't covered entities. A breach there doesn't trigger a regulatory penalty. But the people using those services disclosed something in a moment of acute need — a late-night conversation, a first admission, a call made because someone finally trusted the platform enough to be honest.
The stakes in those environments aren't financial. They're human, and they're larger than any dollar figure a risk model produces.
We need to stop measuring security risk exclusively in dollars and start measuring it in human outcomes.
That shift in framing changes what questions get asked, what controls get prioritized, and what "good enough" actually means.
I'm not suggesting certifications are worthless. They're a floor. The problem is when the industry treats them as a ceiling and forgets that the floor is only as solid as the integrity of the company standing on it.
For AI platforms handling sensitive conversations, the questions worth adding to any security review are practical: Who controls the encryption keys: the vendor, or a default provided by their cloud provider? How does the vendor track new data flows and subprocessors between audit cycles? When was the last independent penetration test, and what changed as a result? Is quantum-resistant cryptography on the roadmap for platforms with cross-border data capture? And, harder to assess but arguably most important: does the company's leadership treat security as a value they won't trade against, or as a checkbox they clear once a year?
None of these are exotic requirement. They're the next layer the standards haven't caught up to yet.
MSSPs and IT channel professionals are often the last line of scrutiny before a client commits to a vendor. That's a significant position to be in when the clients are healthcare organizations, crisis services, or any platform where the people using the software are already in a vulnerable position.
The certification a vendor shows you in a review doesn't tell the whole story.
MSSP Alert Perspectives columns are written by trusted members of the managed security services, value-added reseller and solution provider channels or MSSP Alert's staff. Do you have a unique perspective you want to share? Check out our guidelines here and send a pitch to [email protected].
