Third-Party Risk Management: What Enterprise Procurement Teams Actually Look For

If you are selling a B2B product to enterprise accounts, you are a vendor in someone's third-party risk management program. Understanding how enterprise TPRM processes actually work — not how they appear from the outside, but what the security and procurement teams on the other side are actually evaluating — is one of the most commercially valuable pieces of knowledge a growth-stage company can have.

Enterprise organizations have been burned by vendor security failures: the Target breach through an HVAC vendor, major healthcare breaches through billing software providers, financial services incidents through payment processors. TPRM programs exist because enterprise security teams have learned that their security posture is only as strong as their most exposed vendor relationship. That reality shapes how they evaluate you.

Step 1: Vendor Tiering

Every enterprise TPRM program begins with tiering — classifying vendors by the risk they represent before determining how much scrutiny to apply. Tiering inputs include:

• Data sensitivity: Does the vendor process, store, or transmit personally identifiable information (PII), protected health information (PHI), payment card data, or confidential intellectual property? Higher-sensitivity data categories trigger higher tiers.
• Data volume: A vendor accessing 100 records is categorized differently from one accessing 10 million records, even if the data type is the same.
• Integration depth: A vendor with API access to production systems or single sign-on integration represents a different risk profile than one receiving periodic data exports.
• Failure blast radius: If this vendor's systems become unavailable or compromised, what is the impact on the enterprise customer's operations? A critical SaaS dependency that would halt business processes if unavailable receives critical tier treatment regardless of data access.

Typical tiers are critical, high, medium, and low. A critical-tier vendor can expect a full assessment including questionnaire, evidence review, and potentially a virtual or on-site deep-dive session. A low-tier vendor may simply need to sign a standard vendor agreement and complete a brief questionnaire. Knowing which tier you will be assigned helps you calibrate the depth of your security documentation investment.

Step 2: Inherent Risk Questionnaires

Before a full assessment, most enterprise TPRM programs send an initial screening questionnaire to understand your inherent risk profile — the risk you represent before considering your controls. These questions typically cover:

• What categories of data do you process on behalf of this customer?
• How do you connect to our systems (API, network integration, user access)?
• Where is data stored (geography, cloud provider)?
• Who are your material sub-processors that may have access to our data?
• Do you operate in any regulated industries (healthcare, finance, government)?

Your answers to these questions determine your tier classification and the subsequent depth of review. Being accurate here is important — misrepresenting your inherent risk profile creates legal exposure and will typically be discovered during the deeper assessment or during incident investigation.

Step 3: Evidence Collection

The evidence collection stage is where most vendor assessments surface gaps. Enterprise security teams are not simply accepting answers to questionnaire questions — they are requesting artifacts that substantiate your claims. The typical evidence package for a high or critical tier vendor includes:

• SOC2 Type 2 report: Reviewers read this document, not just the existence of a certificate. They look for the audit period (must be recent — typically within 12 months), the scope of systems covered, the number and severity of exceptions noted by the auditor, and whether exceptions have associated remediation evidence. A SOC2 report with multiple exceptions and no remediation documentation is less valuable than a clean first-year report.
• Penetration test executive summary: The scope, recency, methodology, finding severity distribution, and remediation status all matter. A pentest conducted 24 months ago with no subsequent testing is a significant gap flag. Many enterprise reviewers will specifically ask whether new features or integrations developed since the last test have been assessed.
• ISO 27001 certificate: If applicable, with scope statement and surveillance audit evidence.
• Cyber insurance certificate: Enterprise customers want to see that you carry adequate cyber liability insurance. Typical minimum thresholds for critical vendors are $5M–$10M in coverage, though this varies by contract value and industry.
• Business continuity and disaster recovery documentation: Written BCP/DR plans with evidence of testing — not just the documents themselves.

Step 4: Deep-Dive Assessments for Critical Vendors

For critical-tier vendor relationships — particularly those involving API access to production systems or large volumes of sensitive data — enterprise TPRM teams often conduct a deeper assessment beyond questionnaire and evidence review. This may take the form of a virtual assessment meeting where your security team walks through specific controls in detail, or in some cases a right-to-audit exercise where the enterprise customer's security team directly reviews your configuration or conducts limited testing.

The right-to-audit clause is increasingly standard in critical vendor contracts. Even if it is rarely exercised, the clause signals that the enterprise customer takes vendor security seriously and wants contractual standing to investigate if an incident occurs. Being unprepared for audit-right exercise — having undocumented controls or configurations that don't match your policy representations — is a significant compliance and reputational risk.

Step 5: Ongoing Monitoring and Annual Renewal

Enterprise TPRM programs don't end at onboarding. Critical and high-tier vendors are subject to ongoing monitoring including:

• Annual re-assessment — updated questionnaires and evidence packages
• Breach notification obligations — contractual requirements to notify the enterprise customer within 24–72 hours of a confirmed incident affecting their data
• Continuous monitoring via threat intelligence platforms that track dark web data exposure, credential leaks, and public breach disclosures related to your organization
• Change notification requirements — some contracts require you to notify the enterprise customer of material changes to your infrastructure, sub-processors, or security posture

Evidence aging is one of the most common causes of annual renewal friction. A pentest conducted in January that is submitted for an October renewal review is already 9 months old — often past the 12-month threshold enterprise teams apply. Building a calendar-driven evidence maintenance process ensures you always have current artifacts available.

Step 6: Contractual Requirements

Before a contract is signed, enterprise legal and security teams will require several security-specific contractual provisions:

• Data Processing Agreement (DPA): Required for any vendor processing personal data under GDPR, CCPA, or other privacy regulations. The DPA specifies permitted processing purposes, data subject rights obligations, and cross-border transfer mechanisms.
• Security addendum: Specifies minimum security control requirements — encryption standards, access control requirements, incident notification timelines — that you must maintain as a condition of the contract.
• Right-to-audit clause: Gives the enterprise customer the right to assess your security controls, either directly or through a third-party assessor.
• Sub-processor disclosure: Requires you to maintain and disclose a current list of sub-processors with access to customer data, and to notify the customer before adding new sub-processors.

Building a Proactive Vendor Security Package

The most effective approach to enterprise TPRM reviews is preparation before you receive the questionnaire, not response after. A proactive vendor security package — maintained and updated on a regular schedule — allows your sales team to provide evidence immediately when requested, eliminating the multi-week delays that result from scrambling to produce documentation under deal-stage pressure.

A complete proactive vendor security package includes: current SOC2 Type 2 report (or equivalent), recent penetration test executive summary with remediation evidence, completed CSA CAIQ or equivalent self-assessment, cyber insurance certificate, written security policies (access control, incident response, data handling, vendor management), a current sub-processor list, and a security contact designation.

Lorikeet Security helps companies build this package from the ground up — conducting the penetration testing, advising on compliance programs, and ensuring the documentation produced by each engagement is enterprise-procurement-ready. Book a consultation to understand what your current package looks like and where the gaps are. See also our full service areas for how assessment and compliance work fit together.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.