When a customer publishes a SOC 2 Type II audit-report cover page or executive summary that names your product as a sub-service organization or as an in-scope technology component, ships an ISO 27001 certification scope statement that names your product among the in-scope information assets, releases an ISO 27017 cloud-security-extension certificate that names your product among the in-scope cloud services, maintains a CSA STAR (Security, Trust, Assurance, and Risk) Level 1 self-assessment or Level 2 third-party-audited attestation that names your product in the cloud-controls-matrix evidence, or hosts a customer-facing trust-portal page that publishes the SOC 2, ISO 27001, ISO 27017, ISO 27018, or CSA STAR document set with your product listed in the sub-service-organization complementary-user-entity-controls disclosure scope, they have left a category of endorsement that almost no marketing-elicited testimonial can replicate. The trust-services attestation has been written under the audit-engagement commitment of a CPA-firm-attested AICPA Trust Services Criteria framework, archived in the customer's trust-portal vault and on third-party certification-body registries like the IAF CertSearch global ISO certification registry, the CSA STAR Registry, and the customer's vendor-risk-management distribution scope where any future security engineer, auditor, customer, regulator, or competing vendor can retrieve it, scrutinized by independent CPA audit firms and ISO-accredited certification bodies who have direct engagement-letter and accreditation-renewal incentives to dispute any inaccuracy, and frequently re-referenced in subsequent vendor-risk-management questionnaires, RFP responses, and procurement security-review pipelines for years after the original attestation. The trust-services attestation carries the customer's compliance-program testimony, the CPA-firm or certification-body signature carries the audit-engagement ratification, and the surrounding context establishes that the attestation entry was written under one of the most procedurally constrained public-compliance-disclosure environments any customer-facing organization encounters.
Almost no developer-tools, security-platform, observability, infrastructure-platform, or B2B SaaS vendor systematically extracts product mentions from public SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR attestation archives. The omission is the natural extension of the same blind spots we documented in our SBOM and VEX extraction guide, our Terraform module extraction guide, our Kubernetes manifest extraction guide, our changelog extraction guide, our bug bounty extraction guide, and our status page postmortem extraction guide. SBOM and VEX attestations cover supply-chain-security-attested cryptographic-component mentions. Terraform modules cover declarative-infrastructure-deployment mentions. Kubernetes manifests cover declarative-cluster-state mentions. Changelogs cover release-process-attested version-anchored mentions. Bug bounty disclosures cover researcher-attested security-program mentions. Status page postmortems cover operations-pressured reliability mentions. SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR content covers CPA-firm-attested, ISO-accredited-certification-body-bound, audit-archive-permanent, vendor-risk-management-load-bearing, third-party-witnessed product mentions made under the most procedurally constrained public-compliance-disclosure environment any customer-facing organization publishes into — a pillar of the structurally durable public corpus that no other extraction surface can replicate, and the only one where the customer's testimony has been tied specifically to a procurement-security-review pathway that the customer's enterprise-customer revenue actively depends on as an annual recertification contract.
This guide describes the extraction workflow for the SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR corpus.
Why a SOC 2 or ISO 27001 attestation mention beats almost every marketing-elicited testimonial
A SOC 2, ISO 27001, ISO 27017, ISO 27018, or CSA STAR attestation mention is a category of endorsement that has passed through filters no marketing-elicited testimonial encounters. Seven properties stack to make it one of the most adversarially credible compliance-attestation endorsement formats in modern B2B marketing.
First, the attestation has been written under an audit-engagement framework the customer has committed to follow. Public trust-services attestations are governed by published criteria — the AICPA Trust Services Criteria (TSC) 2017 with 2022 Points of Focus, the ISO/IEC 27001:2022 information-security-management-system standard, the ISO/IEC 27017:2015 cloud-services-extension code of practice, the ISO/IEC 27018:2019 personally-identifiable-information-in-public-cloud code of practice, the CSA Cloud Controls Matrix (CCM) v4.0.10, and the CSA STAR Continuous Auditing-Monitoring (STAR Level 2-CM) program. A product mention in an attestation published under any of these frameworks is being made under a process that the customer has publicly committed to follow as a recurring annual-audit commitment. The audit-engagement-framework property is what makes attestation mentions more credible than mentions in any format that does not pass through a comparable procedural commitment.
Second, the attestation is archived permanently in trust portals and certification registries. Attestation entries are preserved in the customer's trust-portal vault (Vanta Trust, Drata Trust, Whistic, OneTrust Trust Center, Conveyor, SafeBase), on third-party-administered ISO certification registries (IAF CertSearch, ANAB Accreditation Search, UKAS Accredited Certificate Search, BSI Verifeye Directory), in the CSA STAR Registry, in the customer's enterprise-customer-distributed vendor-risk-management package, and in a long tail of compliance archives operated under the customer's regulator-disclosure obligations. A product mention in an attestation publication is therefore preserved across multiple independent archives where any future engineer, auditor, customer, regulator, or competing vendor can retrieve the attestation entry and compare it against the customer's current compliance posture. The cross-archive-permanence property is what makes attestation mentions more durable than mentions in any format without comparable multi-archive preservation.
Third, the attestation has been scrutinized by CPA audit firms and ISO-accredited certification bodies. The AICPA, the IAAB, the IAF, ANAB, UKAS, JAS-ANZ, ENAC, DAkkS, and the CSA accreditation pathways operate an active scrutiny culture in which attestations are reviewed under engagement-letter responsibility, examined in peer-review and quality-assurance audits, and challenged in regulatory enforcement actions, in AICPA Peer Review reports, in ISO accreditation-body witness audits, on the CSA Trusted Cloud Provider stage, and in subsequent vendor-risk-management dispute pipelines. A product mention in an attestation publication is being read by auditors who have direct CPA-license and ISO-accreditation incentives to surface any inaccuracy. The audit-firm-scrutiny property is what makes attestation mentions more adversarially tested than mentions in any format without comparable audit-firm-community exposure.
Fourth, the attestation is anchored to a CPA-firm engagement letter and an ISO certification-body accreditation reference. Attestation entries are routinely tied to a specific CPA-firm AICPA member-firm registration number, a specific ISO certification-body IAF member-accreditation-body registration, a specific report-issuance date, and a specific audit-period coverage window — and the audit-engagement reference becomes a stable identifier that the customer's enterprise-customer security-review distribution depends on as a vendor-risk-management contract. A product mention in an attestation publication therefore inherits a CPA-firm-and-certification-body-anchored authority that establishes the mention was made at a precise, audit-engaged point in the customer's compliance history. The audit-engagement-anchor property is materially stronger than the equivalent on any format without comparable immutable-identifier coverage.
Fifth, the attestation is cross-referenced by vendor-risk-management and procurement-security-review infrastructure. Vendor-risk-management tools — Whistic, OneTrust Vendorpedia, ProcessUnity, BitSight, SecurityScorecard, UpGuard, Panorays, Prevalent — and procurement-security-review tools — RFP-response automation platforms, customer-supplier-questionnaire automation platforms, security-questionnaire-automation platforms like Conveyor and SafeBase — routinely cross-reference attestation entries against the customer's vendor-risk-management posture and against the customer's enterprise-customer security-review pipeline. A product mention in an attestation publication therefore inherits a vendor-risk-and-procurement cross-reference that establishes the mention's authenticity at the highest level of public vendor-risk-management infrastructure. The vendor-risk-and-procurement-cross-reference property is what makes attestation mentions more authority-anchored than mentions in any format without comparable globally indexed vendor-risk coverage.
Sixth, the attestation is required by enterprise-customer procurement contracts. SOC 2 Type II reports and ISO 27001 certificates are mandated for enterprise-customer procurement in the customer's master-services-agreement security-exhibit clauses, in the customer's data-processing-addendum sub-processor requirements, in the customer's vendor-risk-management onboarding gates, in the customer's RFP-response security-section requirements, and in the customer's continuous-monitoring vendor-risk-management posture-checks. A product mention in a procurement-required attestation is being made under contract clauses the customer cannot opt out of without losing enterprise-customer revenue. The procurement-mandate property is what makes attestation mentions more enterprise-customer-load-bearing than mentions in any format without comparable contract-pathway exposure.
Seventh, the attestation is actively referenced by the customer's annual-recertification pipeline. Subsequent annual audit-renewal engagements, surveillance-audit cycles, recertification-audit cycles, and continuous-monitoring (STAR Level 2-CM) cycles continuously re-read the attestation entry as the source-of-truth for the customer's compliance disclosure. A product mention in an attestation publication is therefore not a one-time disclosure but a continuously referenced disclosure contract that the customer's annual-recertification pipeline is actively responsible for maintaining. The annual-recertification-pipeline-reference property is what makes attestation mentions more operationally load-bearing than mentions in any format without comparable recertification-pipeline coverage.
The corpus you should be extracting
The SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR corpus spans seven primary surfaces. Each surface produces a different attestation register, a different vocabulary register, and a different testimonial-extraction workflow.
First, the SOC 2 Type II audit-report corpus — the AICPA Trust Services Criteria attestation engagement under SSAE 18 AT-C 205 that produces the SOC 2 Type II audit report. SOC 2 Type II reports are published in the customer's trust-portal vault, distributed to enterprise-customer vendor-risk-management teams under NDA, and disclosed in the customer's RFP-response security-section. A typical SOC 2 Type II audit report contains an Independent Service Auditor's Report (Section 1) listing the CPA firm name and engagement-period coverage, a Management's Assertion (Section 2) listing the system description and the in-scope controls, a Description of the System (Section 3) listing the in-scope products, sub-service organizations, and complementary-user-entity-controls (CUEC), a Trust Services Criteria and Related Controls (Section 4) listing the Security, Availability, Processing Integrity, Confidentiality, and Privacy criteria with the test-of-controls results, and an Other Information (Section 5) listing additional management-prepared narrative content. The Section 3 sub-service-organization disclosure and the Section 4 in-scope-controls evidence references are the primary product-mention extraction points. The Section 1 Independent Service Auditor's Report captures the CPA-firm signature attribution.
Second, the SOC 2 Type II report bridge-letter and gap-letter corpus — the management-prepared interim disclosure that bridges the audit-report-issuance gap between the audit-period coverage end and the next audit-period coverage start. Bridge letters are published in the customer's trust-portal vault and distributed to enterprise-customer vendor-risk-management teams under NDA. A typical bridge letter contains a management-prepared interim-period attestation that confirms continued operating-effectiveness of the in-scope controls, a sub-service-organization continued-engagement attestation, and a continued-product-inclusion attestation. The continued-product-inclusion attestation is the primary product-mention extraction point.
Third, the ISO 27001:2022 certificate and Statement of Applicability corpus — the ISO/IEC 27001:2022 information-security-management-system certification by an IAF-accredited certification body. ISO 27001:2022 certificates are published in the customer's trust-portal vault, on the IAF CertSearch global registry, on the certification-body's directory (BSI Verifeye, DNV Certificate Search, TÜV Rheinland Certipedia, SGS Certificate Search, LRQA Online), and in the customer's enterprise-customer RFP-response security-section. A typical ISO 27001:2022 certificate contains a certified-organization-name reference, a certification-body name and IAF member-accreditation reference, a certificate-issuance-date and certificate-expiry-date, an in-scope-statement listing the certified information-security-management-system boundary, and a referenced Statement of Applicability (SoA) listing the Annex A 4-domain ninety-three-control selection-and-exclusion rationale. The in-scope-statement and the SoA control-selection rationale are the primary product-mention extraction points.
Fourth, the ISO 27017:2015 cloud-services-extension certificate corpus — the ISO/IEC 27017:2015 code of practice for information-security-controls based on ISO/IEC 27002 for cloud services. ISO 27017 certificates are typically issued as an extension of the ISO 27001 certification by the same IAF-accredited certification body and published alongside the ISO 27001 certificate. A typical ISO 27017 certificate contains a certified-organization-name reference, a certification-body name and IAF member-accreditation reference, a certificate-issuance-date and certificate-expiry-date, an in-scope-cloud-services-statement listing the certified cloud services and the cloud-service-customer and cloud-service-provider responsibility model, and an Annex-A extension reference. The in-scope-cloud-services-statement is the primary product-mention extraction point.
Fifth, the ISO 27018:2019 cloud-PII-extension certificate corpus — the ISO/IEC 27018:2019 code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors. ISO 27018 certificates are typically issued as an extension of the ISO 27001 certification by the same IAF-accredited certification body and published alongside the ISO 27001 and ISO 27017 certificates. A typical ISO 27018 certificate contains a certified-organization-name reference, a certification-body name and IAF member-accreditation reference, a certificate-issuance-date and certificate-expiry-date, an in-scope-PII-processor-services-statement listing the PII-processor-role services, and a PII-processor-controls extension reference. The in-scope-PII-processor-services-statement is the primary product-mention extraction point.
Sixth, the CSA STAR Level 1 self-assessment and Level 2 third-party-audited attestation corpus — the CSA STAR program that publishes Cloud Controls Matrix-aligned self-assessments and third-party-audited attestations. CSA STAR entries are published on the CSA STAR Registry, on the customer's trust-portal vault, and on the customer's enterprise-customer RFP-response security-section. A typical CSA STAR Level 1 self-assessment contains a Consensus Assessments Initiative Questionnaire (CAIQ) response set listing the customer's responses to the CSA CAIQ v4.0.3 questions, an in-scope cloud-services-statement listing the assessed cloud services, and a self-assessment attestation. A typical CSA STAR Level 2 third-party-audited attestation contains an underlying SOC 2-based or ISO 27001-based attestation, an additional CSA-Cloud-Controls-Matrix-aligned attestation by a CSA-approved auditor, and an in-scope cloud-services-statement. The CAIQ response set and the in-scope cloud-services-statement are the primary product-mention extraction points.
Seventh, the customer trust-portal published-document corpus — the customer-operated trust-portal that publishes the SOC 2, ISO 27001, ISO 27017, ISO 27018, CSA STAR, HITRUST, FedRAMP, C5, and PCI-DSS attestation document set in a single curated location. Trust portals are operated on Vanta Trust, Drata Trust, Whistic, OneTrust Trust Center, Conveyor, and SafeBase, and are typically gated by a click-through NDA. A typical trust-portal page contains a curated document set, a sub-service-organization list, a complementary-user-entity-controls (CUEC) section, and a vendor-relationship-and-fourth-party disclosure. The sub-service-organization list and the fourth-party disclosure are the primary product-mention extraction points.
The extraction workflow
The workflow has five stages. Each stage is operated by a separate team with separate tooling and separate output-format requirements. The workflow is designed to convert a customer's trust-services-attestation-archive history into a deployable testimonial library in approximately forty-eight hours per attestation, with full audit-trail anchoring to the CPA-firm and certification-body engagement-reference infrastructure.
Stage one: corpus identification. Identify every SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR attestation in which the customer has named your product as a sub-service organization, an in-scope technology component, a fourth-party vendor reference, or a CCM-aligned control-evidence dependency. Search the IAF CertSearch registry for the customer's certification-body issuance scope. Search the CSA STAR Registry for the customer's CSA STAR Level 1 self-assessment and Level 2 third-party-audited attestation. Search the customer's trust-portal vault for SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR document references. Search the customer's RFP-response security-section archive for vendor-risk-management-distributed attestation copies. Search the customer's vendor-risk-management distribution-scope for fourth-party vendor disclosures. The corpus-identification stage typically surfaces between ten and forty attestation artifacts per established enterprise-customer-active customer. Store each artifact with its CPA-firm engagement reference, its ISO certification-body IAF accreditation reference, its issuance-and-expiry date, and its full archived attestation content.
Stage two: product-mention extraction. Extract every mention of your product from the identified attestation artifacts. The extraction pattern depends on the attestation format. For SOC 2 Type II reports, scan Section 3 Description of the System for sub-service-organization-list matches and in-scope-product matches, and scan Section 4 Trust Services Criteria for in-scope-controls evidence-reference matches. For SOC 2 bridge letters, scan the continued-product-inclusion attestation for product matches. For ISO 27001 certificates and Statements of Applicability, scan the in-scope-statement for product matches and scan the SoA control-selection rationale for control-evidence-dependency matches. For ISO 27017 certificates, scan the in-scope-cloud-services-statement for product matches. For ISO 27018 certificates, scan the in-scope-PII-processor-services-statement for product matches. For CSA STAR Level 1 self-assessments, scan the CAIQ response set for product matches. For CSA STAR Level 2 third-party-audited attestations, scan both the underlying SOC 2-or-ISO 27001-based attestation and the additional CSA-Cloud-Controls-Matrix attestation for product matches. For trust-portal published documents, scan the curated document set and the sub-service-organization and fourth-party-disclosure lists for product matches. Record the in-scope-statement reference, the audit-period coverage, the CPA-firm or certification-body name, the issuance-date, the surrounding attestation context, and the published archive URL for each extracted mention.
Stage three: audit-engagement-anchor verification. Verify the CPA-firm or ISO certification-body engagement anchor for every extracted mention. Confirm the CPA-firm AICPA member-firm registration. Confirm the ISO certification-body IAF member-accreditation-body registration. Confirm the certificate-issuance and certificate-expiry windows against the IAF CertSearch registry or the certification-body's directory. Confirm the audit-period coverage against the SOC 2 Type II report Section 1 Independent Service Auditor's Report. Document the audit-engagement-anchor verification for each mention. Mentions without verified audit-engagement anchors are downgraded to lower-credibility tier and excluded from procurement-pathway-specific testimonials.
Stage four: procurement-pathway classification. Classify each extracted mention by the procurement-security-review pathway it supports. Mentions that appear in SOC 2 Type II Section 3 sub-service-organization disclosure or in ISO 27001:2022 in-scope-statement are classified as enterprise-procurement-load-bearing. Mentions that appear in ISO 27017 or ISO 27018 cloud-services-extension certificates are classified as cloud-procurement-load-bearing. Mentions that appear in CSA STAR Level 1 self-assessments are classified as cloud-controls-matrix-disclosure-load-bearing. Mentions that appear in CSA STAR Level 2 third-party-audited attestations are classified as audited-cloud-controls-matrix-load-bearing. Mentions that appear in trust-portal sub-service-organization or fourth-party disclosures are classified as vendor-risk-management-distribution-load-bearing. The classification determines the appropriate testimonial-deployment surface.
Stage five: testimonial-asset packaging. Package each verified, classified product-mention into a deployable testimonial asset. The testimonial asset contains the customer-company attribution, the customer-product-name reference, the attestation-format reference (SOC 2 Type II, SOC 2 bridge letter, ISO 27001:2022, ISO 27017:2015, ISO 27018:2019, CSA STAR Level 1, CSA STAR Level 2, or trust-portal page), the issuance-and-expiry date anchor, the CPA-firm or certification-body engagement reference, the audit-period coverage window, the published archive URL, the procurement-pathway classification, and the audit-engagement-anchor verification record. The packaged asset is then released through the proof-deployment pipeline.
Where to deploy trust-services-attestation-extracted testimonials
Trust-services-attestation-extracted testimonials deploy most effectively in five surfaces. First, on the enterprise-customer-acquisition page — where enterprise-procurement-team buyers explicitly look for trust-services-attestation evidence and where an enterprise-procurement-load-bearing testimonial proves the SOC 2-and-ISO 27001-compatibility claim. Second, on the vendor-risk-management page — where vendor-risk-management-team buyers explicitly look for sub-service-organization and fourth-party disclosure evidence and where a vendor-risk-management-distribution-load-bearing testimonial proves the vendor-risk-program-maturity claim. Third, on the cloud-security-trust page — where CISO-tier viewers explicitly look for cloud-services-extension evidence and where an ISO 27017-and-CSA STAR-archived testimonial proves the cloud-security-program-maturity claim. Fourth, on the data-protection-trust page — where data-protection-officer viewers explicitly look for PII-processor evidence and where an ISO 27018-archived testimonial proves the PII-processor-program-maturity claim. Fifth, on the continuous-monitoring page — where security-engineering-team viewers look for continuous-monitoring evidence and where a CSA STAR Level 2-CM-archived testimonial proves the continuous-monitoring-program-maturity claim.
The asset-packaging stage produces the same artifact for all five surfaces. The deployment stage decides which surface each asset is most credibility-load-bearing for, and applies the corresponding presentation pattern.
What ProofShow automates
ProofShow operates the corpus-identification, the product-mention extraction, the audit-engagement-anchor verification, the procurement-pathway classification, and the testimonial-asset packaging stages as a single end-to-end pipeline. Customers connect their trust-portal monitoring scope and their IAF CertSearch and CSA STAR Registry query scope, and ProofShow operates the pipeline continuously, surfacing newly published SOC 2, ISO 27001, ISO 27017, ISO 27018, and CSA STAR attestation entries as they are issued and committed to the certification-registry infrastructure. The customer's marketing team receives a continuously refreshed library of audit-engagement-anchored, procurement-pathway-classified, trust-services-attested product mentions that no marketing-elicited testimonial-collection program could ever match.
For the structural-format guidance that informs the testimonial-asset packaging stage, see the SBOM and VEX extraction guide, the Terraform module extraction guide, the Kubernetes manifest extraction guide, the changelog extraction guide, and the status page postmortem extraction guide.