Tell HN: Compliance is not equal to Security
1 comments
Compliance is not security, but "security" is too nebulous of a term to actually implement effectively, so companies use the specific regulations and standards to have a measurable target to strive for.
In my company, we have additional security measures and guardrails on top of the bare minimum legally required, but most companies indeed see security as a cost center and decide not to invest until it's too late.
In my company, we have additional security measures and guardrails on top of the bare minimum legally required, but most companies indeed see security as a cost center and decide not to invest until it's too late.
Most startups call a security engineer or hire a security agency only when a compliance deadline is a few weeks or month away.
Whether it’s PCI DSS, ISO 27001, SOC 1, SOC 2, or the new push from the EU for MICA and DORA in the Web3 and Fintech spaces, the motivation is almost always the same. It’s a sales blocker, get it done!
In the last few years, I had the opportunity to consult for a few “fully compliant” startups that gave me deeper access: GitHub, read-only database access, CI/CD configs, etc.
That’s when things got interesting.
What I Found Inside ‘Compliant’ Startups
Here are some real examples (details anonymized):
1. Secrets lying around in GitHub repos: Even though the company had a dedicated secrets manager, old secrets, tokens, and environment variables were still scattered inside the repo — some untouched for years.
2. Non-engineering teams “vibe-coding” in public Replit: Because the company wanted “everyone to code,” non-engineers were experimenting on public Repl.it projects with ChatGPT API keys and MongoDB connection URLs. I stopped a potential data leak before DB connection URL became public.
3. A public Docker image sitting out there for 5 years: It had an old Zendesk API key inside it. Anyone could have pulled it, and with that, accessed user PII.
4. Multiple unreported exploits: Issues that would’ve become serious incidents and many unreported exploited issues, none of which were caught by their compliance process.
Yet this company was proudly:
“100% SOC2 compliant.”
And closing enterprise deals. They were green-lit 100% compliant on Vanta. They had their SOC 2 badges on the home page.
Compliance frameworks are not useless. They establish a necessary baseline, enforce good practices, and build a framework for trust. They answer the question, “Do you have a process?”
But they do not answer the critical questions: “Is your team following that process right now?” or “What chaos did innovation create yesterday that exists outside the process?”
Compliance auditors check if you have the right documents, policies, and controls at the moment of audit. Attackers look for misconfigurations, forgotten credentials, abandoned code, and human mistakes every single day.
A company can be “fully compliant” and still be one bad commit away from a major breach.
A Simple Rule Founders Should Use When evaluating a startup or when building your own:
Don’t judge security by compliance certificates or shiny 100% compliant Vanta dashboards. Judge by the number of full-time security engineers relative to the team size.
A company with 0-1 security engineer and a SOC2 certificate is not secure. They’re just compliant.
Security is a continuous effort. It is significantly more affordable to build an in-house security culture and hire a full-time engineer than it is to pay a big name security agency for a panic audit, or worse, pay for a data breach cleanup.
If You’ve Read This Far: Thanks for listening to my rant.
If you are looking for a security consultant (who cares about more than just the checkbox), feel free to reach out at [email protected].