Information Security Due Diligence: Certs, Disclosure & Incidents
Information security due diligence tries to answer a question no company will answer honestly about itself: how likely is this vendor or target to suffer a breach that becomes your problem? You rarely get to run a penetration test during diligence. What you can do is read the signals a company puts into the public record — its certifications, its disclosure practices, its incident history — and tell the difference between a mature security program and a hopeful one.
Certifications: useful, but read them carefully
A SOC 2 report or an ISO 27001 certificate is the headline signal, but each proves something specific and narrow. ISO 27001 certifies that a company has an information security management system covering a defined scope; SOC 2 reports on whether controls were designed (Type I) or operated effectively over a period (Type II). The details are what matter: the scope of the certificate, the period the report covers, and whether it is current. A three-year-old SOC 2, or an ISO scope that excludes the product you actually use, is far weaker than the badge suggests.
It is also worth being precise about whose certification you are seeing. A company hosted on a certified cloud provider inherits the provider's infrastructure controls — which is real, but is not the same as the company itself being certified for how it builds and operates its own software.
Vulnerability disclosure is a maturity tell
One of the most reliable signals is whether a company has a way for outsiders to report security problems. A published vulnerability disclosure policy, a security contact, or a security.txt file says the company expects to receive bug reports and has a process to handle them. A bug bounty program goes further, showing it actively invites scrutiny. Companies without any disclosure channel are often the ones where a researcher's email goes unanswered until the finding shows up publicly instead.
Incident and breach history
Past breaches are not automatically disqualifying — how a company responded often matters more than the fact of an incident. Look for a history of disclosed breaches, the scope of what was affected, and whether the company notified users and regulators promptly and transparently. A pattern of repeated incidents, or a breach that came to light through others rather than the company's own disclosure, is a different signal from a single well-handled event with a clear post-mortem.
Public posture signals
Beyond certifications, a company's public surface leaks information about how seriously it takes security. A trust or security page that describes encryption in transit and at rest, multi-factor authentication, single sign-on support, regular penetration testing and a clear architecture is a company that has invested in the program and wants customers to know. The absence of any such page, for a product handling sensitive data, is itself worth noting — not proof of weakness, but an absence where mature vendors usually have something to show.
Encryption, access and testing cadence
The substance behind the posture is worth probing where it is disclosed. Is data encrypted at rest and in transit? Is access controlled with MFA and least privilege? Does the company run penetration tests on a regular cadence and remediate findings? You will not verify all of this from outside, but a company that states its practices clearly is easier to trust than one that speaks only in vague assurances of being "enterprise-grade."
Signals, not certainty
No public review replaces a real security assessment with the company's cooperation. What an external review does is triage — it tells you which vendors clear the bar on the visible signals and which ones warrant a deeper look or a hard question before you onboard them. Read certifications for their scope and date, weight disclosure and incident handling heavily, and treat the public posture as the start of the conversation. This is general information, not security or legal advice.