If you build software that touches customer data — especially a SaaS product hosted in the cloud — a prospect's security questionnaire has probably already asked you for a SOC 2 report, an ISO 27001 certificate, or a signed self-attestation under NIST SP 800-218. These are, in practice, the cloud security compliance standards that dominate B2B vendor reviews today. Most engineering teams don't fail these audits because their code is insecure — they fail because they can't produce evidence fast enough, or because nobody mapped "we scan our containers" to the specific control an auditor is checking. SOC 2 Type II alone requires 3 to 12 months of continuous evidence collection before an auditor will even sign off, and ISO 27001 recertification happens every three years with annual surveillance audits in between. This cheat sheet breaks down the standards that come up most often — SOC 2, ISO 27001, PCI DSS 4.0, HIPAA, and the federal SBOM mandate under Executive Order 14028 — with the actual numbers, deadlines, and control mappings you need to plan around, not the vague "many organizations struggle with compliance" filler that doesn't help you pass an audit.
What cloud compliance standards actually apply to a software company?
The answer depends on who you sell to, but five standards cover the overwhelming majority of B2B software deals. SOC 2 Type II is the default ask from any US enterprise buyer and covers five "trust service criteria" — security, availability, processing integrity, confidentiality, and privacy — audited by a licensed CPA firm over an observation window that AICPA guidance sets at a minimum of three months, though most buyers expect six to twelve months of history. ISO 27001:2022 is the international equivalent, built around an Information Security Management System (ISMS) and 93 controls in Annex A, and is issued by an accredited certification body for a three-year cycle with annual surveillance audits. PCI DSS 4.0 applies if you touch cardholder data at all, and its final set of "future-dated" requirements — including mandatory multi-factor authentication for all access to the cardholder data environment — became enforceable on March 31, 2025, replacing PCI DSS 3.2.1 entirely. HIPAA applies if you process protected health information for a covered entity, and it's not certifiable — there's no HIPAA "badge," only a Security Rule risk assessment you have to document and defend. FedRAMP, and the NIST SP 800-218 (Secure Software Development Framework) self-attestation CISA began collecting from federal software vendors in 2023, apply if you sell to US government agencies.
How long does SOC 2 certification actually take, start to finish?
Plan on 9 to 12 months for a first-time SOC 2 Type II, not the 6-week timelines some auditors advertise. That timeline breaks into three phases: a readiness assessment and gap remediation (typically 4-8 weeks), a Type I "point in time" audit some companies do first to prove controls are designed correctly (2-4 weeks to complete once ready), and then the Type II observation period itself, which AICPA requires to run at least 3 months but which most enterprise buyers won't accept below 6 months of evidence. Costs run from $20,000 to $80,000+ per year once you include the audit firm's fee, a compliance automation platform (Vanta, Drata, or similar), and the engineering hours spent producing evidence — access reviews, vulnerability scan results, change-management tickets, and incident response logs — every single audit cycle. The single biggest cause of delayed SOC 2 timelines isn't a failed control; it's engineering teams that can't produce a complete, current SBOM or vulnerability remediation record on demand when the auditor asks for it mid-cycle.
What's actually different between SOC 2 and ISO 27001?
SOC 2 is an attestation report written by a CPA firm for a specific audience (usually your customers' security teams), while ISO 27001 is a certification issued by an accredited body against a published international standard, and buyers in Europe and APAC generally ask for the latter. A SOC 2 report is only as good as the trust service criteria you scope into it, and it expires the moment your observation window ends, meaning you're re-auditing every 6-12 months indefinitely with no multi-year cycle. ISO 27001 gives you a 3-year certificate with lighter-weight annual surveillance audits in years one and two, which is why many companies pursuing global enterprise deals eventually get both: SOC 2 for US buyers, ISO 27001 for everyone else. Roughly 70% of the underlying control objectives overlap — access control, encryption, vendor risk management, incident response — so companies that build a single control library mapped to both frameworks cut their combined audit prep time by roughly half compared to running two separate compliance programs.
Why do all of these standards now require a software bill of materials?
Because Executive Order 14028, signed May 12, 2021, made SBOMs a baseline requirement for any software sold to the US federal government, and every major compliance framework updated its guidance to match within two years. NIST SP 800-218 (SSDF) and NTIA's "minimum elements" guidance from July 2021 now show up as explicit control references inside SOC 2 vendor-risk sections and ISO 27001's supplier relationship controls (A.5.19-A.5.23). This isn't a paperwork exercise: the Log4Shell vulnerability disclosed in December 2021 took most enterprises weeks to scope because they had no inventory of which applications embedded the affected Log4j versions, and the discovery of the deliberately planted backdoor in xz-utils versions 5.6.0 and 5.6.1 in March 2024 showed regulators exactly why an auditable, machine-readable component inventory — not a spreadsheet updated quarterly — is now treated as a baseline control rather than a nice-to-have. If your SBOM only lists direct dependencies and misses the transitive ones, you'll fail the intent of the control even if you technically "have an SBOM."
Which compliance gaps do auditors flag most often in software companies?
Vulnerability remediation SLAs and unpatched critical CVEs in production are the two findings that show up most consistently across SOC 2 and ISO 27001 audits of engineering organizations. Auditors expect a documented SLA — commonly 15 days for critical severity and 30 days for high severity, mirroring CISA's Binding Operational Directive 22-01 timelines for federal systems — and then evidence that you actually met it, not just a policy stating the SLA exists. The second most common gap is scanning coverage that stops at the manifest file: a team runs npm audit or a similar SCA tool, gets 400 flagged CVEs across its dependency tree, and either ignores the noise or burns weeks triaging vulnerabilities in code paths that are never actually called at runtime. Auditors increasingly ask not just "do you scan," but "how do you prioritize," because a compliance program that treats every CVE as equally urgent produces evidence of activity without evidence of risk reduction — which is precisely the gap that reachability-aware triage is built to close.
How Safeguard Helps
Safeguard turns the compliance grind described above into continuous, audit-ready evidence instead of a quarterly fire drill. Our reachability analysis traces every flagged CVE against your actual call graph, so instead of handing an auditor a 400-item vulnerability report, you show a short list of issues that are genuinely exploitable — the same prioritization logic auditors are starting to expect under SSDF and PCI DSS 4.0's risk-based patching language. Safeguard generates a complete SBOM (including transitive dependencies) directly from your build pipeline and can ingest SBOMs from acquired products or vendors, closing the exact NTIA-aligned, EO 14028-driven gap that's now referenced inside SOC 2 and ISO 27001 supplier-risk controls. Griffin AI, Safeguard's security agent, correlates findings across your SCA, container, and IaC scans to explain why a given vulnerability matters in your specific environment, and our auto-fix PRs resolve remediable findings — dependency bumps, config drift, misconfigured IAM policies — before they age past your documented SLA. The result is a control environment where evidence generates itself continuously, which is what actually shortens your next audit cycle.