PCI DSS. SOC 2. The deal moves forward, because those three acronyms appear to mean the vendor has been checked by someone qualified.
Two of those three are not certifications at all. One of them cannot be certified by anyone, ever. And the third can be issued in a form that proves almost nothing about whether the vendor's controls actually work.
Understanding the difference is not pedantry. It is the difference between a vendor assessment that protects your organisation and one that produces a folder of PDFs nobody can act on.
HIPAA is a law, not a badge
The Health Insurance Portability and Accountability Act is United States federal law. It governs how protected health information is handled by covered entities and their business associates. What it does not have is a certifying body. There is no HHS-approved auditor who issues a HIPAA certificate, and no registry of HIPAA-certified vendors.
So when a vendor's website says "HIPAA certified," they are describing something that does not exist. What they usually mean is one of three things: they have had a third party assess their controls against the Security Rule, they have written internal policies mapped to it, or they are willing to sign a Business Associate Agreement.
Only the third of those creates a legal obligation to you. The BAA is the instrument that binds a vendor to HIPAA obligations as your business associate. If a vendor claims HIPAA readiness but will not sign a BAA, or will only sign one on a higher pricing tier, the claim is decorative.
Enforcement is real. Penalties are tiered and adjust annually for inflation, with the willful neglect tier running well into six figures per violation category and capped in the low millions annually, alongside potential criminal exposure. Recent settlements have consistently turned on the same failure: no accurate, thorough risk analysis.
One thing worth tracking. HHS published a Notice of Proposed Rulemaking in January 2025 that would modernise the Security Rule, removing the long-standing distinction between "required" and "addressable" safeguards and making encryption, multi-factor authentication, and annual penetration testing mandatory rather than discretionary. The comment period closed in March 2025 and the rule is not final. The current Security Rule remains in effect, but vendors who have treated addressable safeguards as optional are sitting on a gap that a final rule would expose.
PCI DSS is contractual, and the deadline already passed
The Payment Card Industry Data Security Standard is not law either. It is a contractual obligation imposed by the card brands on anyone who stores, processes, or transmits cardholder data. Enforcement runs through your acquiring bank rather than a regulator, which in practice means fines, increased transaction costs, or losing the ability to accept cards.
The version history matters more than most buyers realise. Version 3.2.1 retired in March 2024. Version 4.0 retired at the end of December 2024. Version 4.0.1 is now the only active version of the standard.
More importantly, v4.0 introduced 64 new or updated requirements, and 51 of those were designated as best practices until 31 March 2025, at which point they became mandatory. There is no remaining grace period. A vendor who validated against v4.0 in 2024 and treated the future-dated requirements as optional will fail their next assessment.
For buyers, this creates a specific and useful question: ask when the vendor's most recent Attestation of Compliance was issued, and against which version. An AOC dated before April 2025 tells you nothing about whether the vendor meets the standard as it exists today.
Also ask which validation level applies. PCI DSS levels are determined by transaction volume, and a Level 4 self-assessment questionnaire is a fundamentally different artifact from a Level 1 assessment performed by a Qualified Security Assessor. Both are legitimate. They are not equivalent.
SOC 2 is an audit report, and the type is the whole story
SOC 2 is an attestation framework from the AICPA. An independent auditor examines a service organisation's controls against the Trust Services Criteria, of which Security is mandatory and Availability, Processing Integrity, Confidentiality, and Privacy are optional.
That optionality is the first thing to check. A SOC 2 report covering only the Security criterion is common and perfectly valid, but if your use case depends on uptime guarantees or data confidentiality commitments, a Security-only report does not address them.
The second thing, and the more consequential one, is Type I versus Type II.
A Type I report says the controls were suitably designed as of a single date. It is a photograph. A Type II report says the controls operated effectively across a defined observation period, usually six to twelve months. It is a film.
Vendors under time pressure often obtain a Type I, then present it in sales conversations as "our SOC 2." It is not dishonest, exactly, but a Type I proves the vendor had the right controls written down on one particular Tuesday. Enterprise procurement teams in regulated sectors have largely stopped accepting it as sufficient, and for good reason.
Ask for the report itself, not the badge. Then check the scope section, because the report covers named systems and services rather than the vendor's entire business. A SOC 2 Type II covering the vendor's core platform does not automatically cover the acquired product you are actually buying.
Where vendor claims quietly fall apart
Three failure patterns show up repeatedly in software procurement.Tier-splitting. Some vendors gate compliance behind pricing plans. HIPAA capability sits on the enterprise tier, the BAA is available only above a certain contract value, or data residency options require an add-on. This is legal and reasonably common, but it means the quoted plan may not include what your security review assumed. When comparing enterprise compliance certifications for software, check whether coverage is uniform across plans or dependent on what you spend. Platforms like FormAssembly extend their full certification set across the product rather than splitting it by tier, while others do not, and the difference only surfaces when you read the plan comparison closely.
Inherited compliance. A vendor built on a compliant cloud provider will sometimes present their host's certifications as their own. AWS being FedRAMP authorised says nothing about whether the application layer running on it is. Ask whose name is on the report.
Stale artifacts. SOC 2 Type II reports cover a defined period and go stale. An AOC has an issue date. A risk analysis performed three years ago before two product launches is not a current risk analysis. Ask for dates on everything, and ask what the vendor's reassessment cadence is.
The questions that actually separate vendors
If you take nothing else into your next vendor review, take these:
● Will you sign a BAA, and is it included at our contract tier?
● May we see the SOC 2 report, not the badge, and which criteria and systems does it scope?
● Is it Type I or Type II, and what observation period does it cover?
● What version of PCI DSS was your most recent AOC issued against, and on what date?
● Which certifications are yours versus your infrastructure provider's?
● Does any compliance capability change if we move between pricing plans?
None of these are hostile questions. A vendor with a mature compliance programme answers all six in a single email, because they have the documents on hand and no reason to hedge.
The ones who cannot answer are telling you something useful. Compliance in enterprise software is not really about whether a framework applies. It is about whether the vendor can produce evidence, on request, that someone independent has looked. The logos on the website are the claim. The report is the proof, and they are not the same thing.