Software Compliance Certifications FAQ: SOC 2, ISO 27001, GDPR, and HIPAA

Software compliance certifications matter because they are the only independent, verifiable evidence that a vendor actually protects your data the way its marketing pages claim. When an enterprise buyer evaluates a SaaS product, a database, or a low-code platform, the vendor's security posture is invisible from the outside. Certifications and audit reports such as SOC 2, ISO 27001, GDPR compliance documentation, and HIPAA safeguards translate that invisible posture into inspectable proof.

Software compliance certifications are independent attestations, audits, or regulatory validations that verify how a software vendor secures systems and handles data. They document which controls exist, whether those controls operate effectively, and who verified them. For buyers, they replace trust-by-assertion with trust-by-evidence before a contract is ever signed.

The stakes are measurable. IBM's Cost of a Data Breach Report, released on July 30, 2025, put the global average breach cost at $4.44 million, while the average cost of a United States breach reached a record $10.22 million. This FAQ answers the questions procurement teams, CISOs, and software evaluators ask most often about the four frameworks that dominate enterprise due diligence.

What Are Software Compliance Certifications and Why Do They Matter?

Compliance frameworks fall into two distinct families, and confusing them is the single most common mistake in vendor evaluations. Voluntary frameworks — SOC 2 and ISO 27001 — are independent audits a vendor chooses to undergo to demonstrate security maturity. Regulatory frameworks — the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA) — are laws that apply whenever a company processes covered data, whether or not it wants them to.

The four frameworks every enterprise software evaluation touches are:

• SOC 2 — an attestation report governed by the American Institute of Certified Public Accountants (AICPA), focused on controls for security, availability, processing integrity, confidentiality, and privacy.
• ISO/IEC 27001 — an international standard for information security management systems (ISMS), certified by accredited third-party bodies.
• GDPR — the European Union's data protection law, enforceable since May 25, 2018, covering any organization processing EU residents' personal data.
• HIPAA — the United States law governing protected health information (PHI), enforced by the Department of Health and Human Services (HHS).

Why do buyers care so much? Because the consequences of choosing an insecure vendor land on the customer, not just the vendor. Regulators fine the data controller, patients sue the hospital, and headlines name the brand — not the subprocessor. As a result, compliance evidence has become the entry ticket to enterprise procurement.

"Cybercrime is the greatest threat to every company in the world."

— Ginni Rometty, then Chairman and CEO of IBM, speaking at the IBM Security Summit in New York on November 4, 2015

Moreover, certifications compress sales cycles. A vendor that can hand over a current SOC 2 Type II report and an ISO 27001 certificate answers hundreds of security questionnaire items in one step. That efficiency is exactly why frameworks like these appear in nearly every enterprise RFP, including evaluations of AI-powered low-code platforms and other digital transformation and AI enterprise strategy initiatives.

SOC 2 Explained: The AICPA Attestation Behind Enterprise Software Trust

SOC 2 — formally, System and Organization Controls 2 — is not issued by a government and is not technically a certification at all. It is an attestation report produced by a licensed, independent CPA firm under standards set by the American Institute of Certified Public Accountants (AICPA). The auditor examines a service organization's controls against the AICPA's Trust Services Criteria and issues a formal opinion. Because the output is a detailed confidential report rather than a badge, SOC 2 gives buyers far more substance than a logo on a trust page.

What is the difference between SOC 2 Type I and SOC 2 Type II?

A SOC 2 Type I report evaluates whether a vendor's controls are suitably designed at a single point in time — one specified date. A SOC 2 Type II report goes further: it tests whether those controls operated effectively over an observation window, typically 3 to 12 months, with 6 to 12 months being the norm for mature vendors. Type II is therefore dramatically stronger evidence, because it proves the vendor sustained its controls, not merely that the controls existed on audit day.

In practical terms, the differences break down like this:

• Type I answers "do the controls exist?" — a design snapshot, often used by younger companies as a first milestone.
• Type II answers "did the controls work?" — evidence sampled across months of real operations.
• Enterprise buyers should require Type II. A Type I alone signals a vendor early in its compliance journey.
• SOC 3 is the public summary. It contains the auditor's opinion without control-level detail and can be shared freely, while SOC 2 reports are distributed under NDA.

However, a Type I report is not meaningless. It is a legitimate stepping stone — most vendors complete a Type I, then immediately begin the Type II observation window. What matters is that the vendor can tell you exactly where it sits on that path and when the Type II report will be delivered.

What do SOC 2 auditors actually examine?

Auditors test controls against the AICPA's five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security — known as the Common Criteria, spanning control series CC1 through CC9 — is mandatory in every SOC 2 report. Vendors add the other four categories based on the commitments they make to customers, which is why two SOC 2 reports are rarely equivalent.

During the audit, the CPA firm samples evidence such as:

• Access control records — onboarding, offboarding, quarterly access reviews, and multi-factor authentication enforcement.
• Change management tickets — code review approvals, testing evidence, and deployment authorization for production changes.
• Incident response artifacts — detection logs, escalation timelines, and post-incident reviews.
• Vendor management files — risk assessments and contracts for the subprocessors the vendor itself relies on.
• Business continuity proof — backup testing, restore drills, and availability monitoring.

The report also lists exceptions — instances where a control failed testing — alongside management's responses. Consequently, reading the exceptions section and the auditor's opinion (unqualified versus qualified) tells you more about a vendor than any marketing claim ever will.

ISO 27001 Certification: Requirements, Process, and the 2022 Update

ISO/IEC 27001 is the leading international standard for information security management, jointly published by the International Organization for Standardization and the International Electrotechnical Commission. Unlike SOC 2's control-by-control attestation, ISO/IEC 27001 certifies a management system — the ISMS — that governs how an organization identifies risk, selects controls, measures effectiveness, and improves continuously. According to the ISO Survey of certifications, more than 70,000 valid ISO/IEC 27001 certificates exist worldwide, making it the most widely recognized security certification across global markets.

How does ISO 27001 certification work, and how long does it take?

A crucial nuance: ISO itself certifies no one. Certification is issued by independent certification bodies that are themselves accredited by national accreditation bodies under the International Accreditation Forum (IAF) umbrella. A certificate from a non-accredited body is close to worthless, so verifying the accreditation mark is step one of due diligence.

The certification path follows a defined sequence:

1. Build the ISMS — define scope, run a risk assessment, produce the Statement of Applicability, and implement controls. This typically takes 6 to 12 months.
2. Pass the Stage 1 audit — a documentation and readiness review by the certification body.
3. Pass the Stage 2 audit — the full certification audit testing implementation and effectiveness, usually 1 to 3 months after Stage 1.
4. Receive the certificate — valid for a three-year cycle.
5. Undergo surveillance audits — smaller annual audits in years one and two, followed by a full recertification audit in year three.

Therefore, an ISO 27001 certificate is never a one-time event. A vendor holding a current certificate has been re-examined within the last twelve months — a meaningful freshness guarantee that buyers should confirm by checking the certificate's issue date, expiry date, and scope statement.

What changed in ISO/IEC 27001:2022?

ISO published the current edition, ISO/IEC 27001:2022, on October 25, 2022, replacing the 2013 edition. The IAF set a transition deadline of October 31, 2025, after which all certificates issued against the 2013 edition became invalid. As of 2026, any vendor presenting an ISO 27001:2013 certificate is presenting an expired credential — an immediate red flag.

The 2022 revision modernized the control catalog substantially:

• Annex A shrank from 114 controls in 14 domains to 93 controls in 4 themes — organizational (37), people (8), physical (14), and technological (34).
• Eleven new controls were added, including threat intelligence, cloud services security, data leakage prevention, secure coding, and configuration management.
• Existing controls were merged and reworded to reflect cloud-first architectures rather than data-center-era assumptions.

For buyers, the practical takeaway is simple: ask which edition the certificate covers and whether cloud-specific controls are inside the certified scope. A scope statement that excludes the product you are actually buying renders the certificate irrelevant to your risk decision.

GDPR and HIPAA Compliance: When the Law Is the Framework

SOC 2 and ISO 27001 are optional credentials; GDPR and HIPAA are enforceable law. That distinction changes everything about how you evaluate vendor claims. No vendor gets to "choose" GDPR compliance if it processes EU personal data, and no vendor handling protected health information can opt out of HIPAA. The right question is never "is the vendor certified?" but "can the vendor demonstrate, contractually and technically, that it meets its legal obligations?"

Can software be "GDPR certified"?

Mostly no — and vendors who claim a generic "GDPR certification" are overstating. The General Data Protection Regulation (Regulation (EU) 2016/679) was adopted on April 27, 2016 and became enforceable on May 25, 2018. It is a law with obligations — lawful bases for processing, data subject rights, 72-hour breach notification under Article 33, and Data Protection Impact Assessments under Article 35 — not a certificate program. Article 42 does allow approved certification mechanisms, and the European Data Protection Board approved Europrivacy as the first European Data Protection Seal in October 2022, but such seals remain rare and narrowly scoped.

Enforcement, by contrast, is anything but rare. GDPR fines reach €20 million or 4% of global annual turnover, whichever is higher, and on May 22, 2023 the Irish Data Protection Commission fined Meta a record €1.2 billion over unlawful EU–US data transfers, following a binding decision by the European Data Protection Board (EDPB).

"The unprecedented fine is a strong signal to organisations that serious infringements have far-reaching consequences."

— Andrea Jelinek, Chair of the European Data Protection Board, in the EDPB's announcement of May 22, 2023

So what should a buyer actually verify? Look for concrete artifacts rather than slogans:

• A signed Data Processing Agreement (DPA) meeting Article 28 requirements.
• Standard Contractual Clauses or another valid transfer mechanism for data leaving the EU.
• A published subprocessor list with change notifications.
• Data residency options and documented retention and deletion procedures.
• Support for data subject requests — export, rectification, and erasure — within statutory deadlines.

What does HIPAA compliance mean for software vendors?

HIPAA — signed into United States law on August 21, 1996 — governs protected health information handled by covered entities and their business associates. Software vendors that create, receive, maintain, or transmit PHI on behalf of a covered entity are business associates, and they must sign a Business Associate Agreement (BAA) and comply with the HIPAA Security Rule, whose compliance date for most organizations was April 20, 2005. The HITECH Act of February 17, 2009 extended direct liability to business associates and created the breach notification regime, which requires notifying affected individuals within 60 days of discovering a breach.

Here is the fact that surprises many buyers: there is no official HIPAA certification. The Department of Health and Human Services does not certify software, endorse any third-party seal, or recognize "HIPAA certified" as a legal status. A vendor claiming to be "HIPAA certified" is, at best, describing a private assessment. What actually demonstrates HIPAA readiness includes:

• Willingness to sign a BAA without hesitation or extra-cost gatekeeping.
• A documented Security Rule risk analysis and risk management program.
• Technical safeguards — encryption in transit and at rest, unique user identification, access controls, and audit logging.
• An independent audit, such as a SOC 2 Type II with HIPAA-mapped criteria or a HITRUST assessment, as supporting evidence.

Regulatory pressure is also rising. On December 27, 2024, HHS announced a proposed update to the HIPAA Security Rule — the first major revision proposed since 2013 — that would make multi-factor authentication, encryption, and asset inventories explicitly mandatory rather than "addressable." Civil penalties already carry inflation-adjusted annual caps of roughly $2.1 million per violation category, so healthcare buyers should ask vendors how their roadmaps anticipate the strengthened rule.

SOC 2 vs ISO 27001 vs GDPR vs HIPAA: Side-by-Side Comparison

Each framework answers a different question, so mature vendors typically hold several at once. The table below compares the four across the dimensions buyers ask about most.

Dimension	SOC 2	ISO/IEC 27001	GDPR	HIPAA
Who issues or governs it	Licensed CPA firms under AICPA standards	Accredited certification bodies under IAF-member accreditation	EU law enforced by national data protection authorities and the EDPB	US law enforced by HHS Office for Civil Rights
What it covers	Controls for security, availability, processing integrity, confidentiality, privacy	The information security management system (ISMS) and 93 Annex A controls	Personal data of EU residents — rights, lawful processing, transfers, breaches	Protected health information — privacy, security, breach notification
Output	Confidential attestation report (Type I or Type II)	Certificate with defined scope, valid 3 years	No certificate; contracts (DPAs), records, and rare Article 42 seals	No certificate; BAAs, risk analyses, and audit evidence
Audit frequency	Annual re-issuance of Type II report	Annual surveillance audits; recertification every 3 years	Ongoing accountability; regulator investigations as triggered	Ongoing; OCR audits and breach investigations as triggered
Geographic relevance	Strongest in North America	Global, dominant in Europe and Asia-Pacific	EU/EEA data, applied extraterritorially	United States healthcare ecosystem
Typical first-time timeline	2–6 months readiness plus 3–12 month observation window	6–12 months ISMS build plus Stage 1 and Stage 2 audits	3–9 months to implement a defensible program	3–6 months to implement safeguards and BAA processes

The key takeaway: SOC 2 and ISO 27001 prove security governance, while GDPR and HIPAA impose legal duties on specific data types — a credible enterprise vendor can usually show evidence across all four categories that apply to its market.

Which compliance framework should you prioritize first?

For vendors deciding where to start, and for buyers judging whether a vendor's portfolio fits, the sequencing logic is consistent across the industry. Regulatory obligations always come first because they are non-negotiable; voluntary attestations follow based on target markets.

1. Start with the laws that already apply — GDPR if you touch EU personal data, HIPAA if you touch PHI. These are compliance floors, not options.
2. Add SOC 2 Type II if you sell to North American enterprises — it is the de facto entry requirement in US procurement.
3. Add ISO 27001 for global reach — European and Asia-Pacific buyers frequently require it, and its ISMS structure makes future frameworks cheaper to adopt.
4. Layer specialized frameworks last — HITRUST for healthcare depth, PCI DSS for payment card data, or FedRAMP for US government workloads.

Because SOC 2 and ISO 27001 overlap heavily — access control, risk assessment, incident response, vendor management — many organizations pursue both through a single unified control set, cutting duplicate evidence collection significantly.

How to Verify a Vendor's Software Compliance Claims

Trust pages are marketing; reports are evidence. The verification stage is where software compliance certifications either hold up or fall apart, and it rarely takes more than a few hours of focused review. Buyers who skip it inherit risks that were visible all along.

How do you verify a vendor's SOC 2 report and bridge letter?

Never accept a badge, a logo wall, or a one-line "we are SOC 2 compliant" statement. Instead, work through a short checklist:

1. Request the full SOC 2 report under NDA — reputable vendors have a standard process for sharing it with prospects, not just customers.
2. Check the report type and period — confirm it is a Type II, note the observation window's end date, and treat reports older than 12 months as stale.
3. Read the auditor's opinion — an unqualified ("clean") opinion is the goal; a qualified opinion means at least one criterion was not met.
4. Study the exceptions and management responses — a few minor exceptions with credible remediation is normal; repeated access-control failures are not.
5. Confirm the scope — verify the audited system is the actual product and infrastructure you are buying, not a different business unit.
6. Ask for a bridge letter — because reports cover a past window, vendors issue a bridge (or gap) letter, typically covering up to three months, stating whether material control changes occurred since the period ended.

For ISO 27001, verification is even faster: ask for the certificate, confirm the certification body's accreditation through an IAF-member registry, and read the scope statement line by line. In addition, cross-check that the certificate references the 2022 edition of the standard, since 2013-edition certificates expired on October 31, 2025.

What does "compliance certification in progress" really mean?

"In progress" is the most elastic phrase in vendor security. It can honestly describe a company whose Type II observation window closes next month — or a company that purchased a compliance automation subscription last week. The phrase itself tells you nothing; the specifics tell you everything.

Pin the claim down with four questions:

• Which stage are you in — readiness, remediation, observation window, or report drafting?
• Is an audit firm engaged, and when is fieldwork scheduled?
• When does the observation window end, and when will the report be issued?
• Can you share a Type I report, a readiness assessment, or completed security questionnaires in the meantime?

Watch for red-flag language as well. "SOC 2 certified" is technically wrong (it is an attestation, and precision matters in this domain), "HIPAA certified" describes a credential that does not exist, and "ISO 27001 compliant" without an accredited certificate means self-assessed. Vendors that use language carefully tend to run controls carefully; vendors that refuse to share any report under NDA are telling you something important.

What does shared responsibility mean in cloud compliance?

Every certification has a boundary, and the customer owns everything outside it. A platform's SOC 2 report covers the platform's infrastructure, application security, and operational controls — it does not cover how your team configures roles, shares data, or builds workflows on top. This shared responsibility model applies to hyperscale clouds and equally to application platforms, including AI-powered low-code platforms such as Informat, where the platform secures the underlying service while customers govern their own users, permissions, and data models.

In practice, the split looks like this:

• Platform responsibilities: physical and network security, encryption implementation, vulnerability management, availability, and the controls tested in its audits.
• Customer responsibilities: user provisioning and deprovisioning, role-based access design, data classification, integration credentials, and monitoring of what internal builders deploy.
• Shared responsibilities: incident communication, configuration standards, and breach notification workflows defined in the contract.

A certified platform can still be deployed insecurely, which is why governance practices — covered in depth in this guide to low-code security best practices for enterprises — matter as much as the vendor's paperwork. Certification reduces vendor risk; it never eliminates customer-side configuration risk.

Compliance Audit Costs, Timelines, and Continuous Monitoring

Budget and calendar questions dominate compliance planning, and realistic expectations prevent the two classic failures: underfunding the program or promising customers a report date the audit math cannot support. Compliance audit economics also explain why smaller vendors stage their certifications over several years rather than pursuing everything at once.

How much do software compliance audits cost, and how long do they take?

Costs vary with company size, scope, and auditor, but market ranges are well established. A SOC 2 Type I audit commonly runs $7,500 to $25,000 in auditor fees, while a SOC 2 Type II for a small-to-mid-size vendor typically runs $20,000 to $60,000 or more. Initial ISO 27001 certification audits generally fall between $15,000 and $50,000, with annual surveillance audits costing a fraction of that. The audit fee, however, is only part of the picture.

A realistic first-year budget also includes:

• Readiness and gap assessment — 2 to 6 months of preparation, either internal or consultant-led.
• Compliance automation tooling — evidence collection and continuous monitoring platforms, typically billed annually.
• Penetration testing — an annual test is expected evidence for both SOC 2 and ISO 27001 audits.
• Staff time — often the largest hidden cost, as engineers document controls and remediate gaps.

All told, first-year programs frequently land in the $50,000 to $150,000 range once tooling, testing, and labor are counted. End-to-end timelines follow the same logic: roughly 4 to 9 months from a standing start to a SOC 2 Type I, 9 to 18 months to a first Type II, and 8 to 14 months to an ISO 27001 certificate. For buyers, these figures are useful leverage in reverse: a vendor that treats compliance as an investment rather than a checkbox is also making a statement about product maturity — the same discipline explored in this analysis of low-code ROI and enterprise value economics.

What is the difference between point-in-time and continuous compliance?

Every audit artifact is historical. A Type II report describes a window that has already closed; an ISO certificate reflects the last audit visit; a DPIA describes processing as designed. Continuous compliance closes that gap by monitoring controls in near real time — automated checks that flag a disabled MFA policy, an unreviewed access grant, or an unencrypted storage bucket the day it happens rather than at the next annual audit.

"Security is a process, not a product."

— Bruce Schneier, security technologist and author, in his essay "The Process of Security", published in April 2000

Mature vendors increasingly demonstrate both layers. Ask prospective vendors whether they:

• Run automated control monitoring between audits, and with what tooling.
• Publish a live trust center with control status, subprocessors, and uptime.
• Commit contractually to maintaining certifications throughout the subscription term.
• Notify customers when material control changes or incidents occur mid-cycle.

The distinction matters because threats change faster than audit cycles. A vendor whose compliance posture is verified once a year is betting that nothing drifts for the other 364 days; a vendor with continuous monitoring is not making that bet.

What "Enterprise-Grade Security" Should Mean in Your Next RFP

"Enterprise-grade security" appears in nearly every software proposal and means nothing by itself. An RFP converts that slogan into testable requirements, and compliance certifications supply the vocabulary. Rather than asking vendors whether they are secure — every vendor says yes — ask them to attach evidence to each claim.

A strong RFP security section requires, at minimum:

• A current SOC 2 Type II report (shared under NDA) with observation window dates and a bridge letter if the window closed more than 90 days ago.
• An ISO/IEC 27001:2022 certificate whose scope explicitly covers the product being purchased.
• A GDPR-ready contract package — DPA, transfer mechanism, subprocessor list, and data residency options.
• A signed BAA where any protected health information is involved.
• Technical specifics — encryption standards in transit and at rest, SSO and MFA support, role-based access control, audit log retention, and API security posture.
• Operational commitments — breach notification timelines, penetration test cadence with summary results, uptime SLAs, and disaster recovery objectives.

Platforms serving regulated enterprises increasingly publish this evidence proactively; when evaluating any vendor in the low-code and AI application space, including Informat's AI-powered low-code platform, the same standard applies — claims should map to documents, and documents should map to the product in scope. Furthermore, weight vendor answers by precision: exact report dates, named audit firms, and scoped certificates outrank adjectives every time. An RFP that demands evidence instead of assurances filters out weak vendors before a single security review meeting is scheduled.

Conclusion: Treat Software Compliance Certifications as Evidence, Not Decoration

Software compliance certifications work only when buyers read them the way auditors write them — as scoped, dated, testable evidence. SOC 2 Type II proves controls operated over months, not that they exist today. ISO 27001 certifies a management system within a defined scope and a three-year cycle. GDPR and HIPAA are laws demonstrated through contracts, safeguards, and records rather than badges. Each answers a different question, and a serious vendor can show you which questions it has answered and which are on its roadmap.

For evaluation teams, the durable habits are few and simple:

• Request the actual report, certificate, and scope — never accept the badge.
• Check dates, editions, and bridge letters — stale evidence is not evidence.
• Map shared responsibility explicitly — the platform's audit does not cover your configuration.
• Prefer vendors with continuous monitoring — annual snapshots age quickly.
• Write RFPs that demand artifacts, not adjectives.

The direction of travel is clear: regulators tightened HIPAA's proposed technical requirements in December 2024, the ISO 27001:2022 transition completed in October 2025, and GDPR enforcement has already produced a €1.2 billion penalty. As enterprises push more critical workloads onto cloud services and low-code platforms as part of broader AI-driven digital transformation strategies, software compliance certifications will keep functioning as the shared language between vendors who claim security and buyers who must verify it. Learn to read that language fluently, and every future procurement decision gets faster, cheaper, and safer.