Why 87% of Manufacturing Leaders Can't Scale AI and What It Teaches Us About Vendor Risk Management

Before we dive into vendor due diligence, here's a surprising parallel from manufacturing that reveals everything about why third-party risk management fails.

Recent Deloitte research found that 87% of manufacturing leaders have launched AI pilots, but only 10% successfully scale across their networks. The bottleneck? Not the technology, it's the data foundation.

The same pattern appears in vendor risk management programs. Companies collect due diligence questionnaires, run vendor risk assessments, and gather compliance certifications, but most VRM programs still fail when incidents occur. Why? Because like AI in manufacturing, vendor risk management doesn't fail at collection; it fails at building usable, structured risk memory.

This guide shows you how to build a vendor due diligence process that creates lasting operational value, not just compliance checkboxes.

What Is Vendor Due Diligence? (And Why Most Programs Miss the Point)

Vendor due diligence is the systematic process of evaluating third-party vendors before engagement and throughout the relationship lifecycle. It's a core component of vendor risk management (VRM) and essential for regulatory compliance across frameworks like SOC 2, ISO 27001, GDPR, HIPAA, and PCI DSS.

But here's what most compliance teams get wrong: vendor due diligence isn't about collecting documents. It's about building operational memory of third-party risk that your team can actually use when decisions matter.

The Real Purpose of Vendor Due Diligence

Every vendor integration means you're inheriting someone else's security posture:

• Their access management practices

• Their incident response capabilities

• Their data protection controls

• Their business continuity plans

Third-party risk management exists because attackers don't need to breach your walls—they pivot through your vendors. Regulators and auditors understand this, which is why Trust Services Criteria (TSC) under SOC 2 and ISO 27001 controls explicitly require evidence of vendor risk assessment and continuous monitoring.

The 3 Core Questions Every VRM Program Must Answer

Before building your due diligence questionnaire, your vendor risk management program should answer:

1. What Is the Vendor's Security Posture?

Do they maintain SOC 2 compliance, ISO 27001 certification, or meet GDPR compliance standards relevant to your business? This establishes baseline compliance fundamentals.

2. Where Could They Introduce Risk?

Evaluate exposure across:

• Data processing agreements and data access

• Infrastructure and cardholder data environment (CDE) for PCI compliance

• Business continuity and disaster recovery capabilities

• Supply chain risk and sub-processor dependencies

3. How Do They Prove They're Practicing What They Claim?

This is where vendor attestations, control evidence, and audit methodology matter. Planned security versus practiced security often differ dramatically—your vendor risk assessment process must verify both.

The Complete Vendor Due Diligence Questionnaire: Questions That Actually Reveal Risk

This due diligence questionnaire is organized around control objectives that map directly to SOC 2 reporting, ISO 27001 controls, and compliance program requirements.

1. Compliance Certifications & Assurance Framework

Why it matters: Vendor attestations and compliance certifications provide third-party validation of control activities.

Questions to ask:

• What compliance certifications do you currently hold (SOC 2 Type II, ISO 27001:2022, PCI DSS v4.x, HIPAA compliance)?

• Can you provide the latest SOC 2 audit reports or ISO 27001 certification documents?

• How often do you undergo external regulatory audit assessments?

• Do you maintain a statement of applicability (SoA) for your ISMS (information security management system)?

What to look for: Active certifications show commitment to continuous compliance and assurance framework standards. However, lack of accreditation isn't always a deal-breaker—it means deeper probing in other areas of your vendor risk assessment.

2. Security Policy & Governance

Why it matters: Policy management and governance structure reveal whether compliance controls are owned or orphaned.

Questions to ask:

• Do you maintain documented policies for your information security management system?

• How often are policies reviewed and by whom?

• Who owns risk management framework oversight?

• Do you follow privacy-by-design principles in product development?

• How do you ensure continuous improvement (PDCA cycle) in your security program?

Control mapping: This aligns with Trust Services Criteria (TSC) CC2.1 (COSO principle 2) under AICPA standards and ISO 27001 controls A.5.1.

3. Data Protection & Privacy Controls

Why it matters: Understanding data scope is essential for GDPR compliance, HIPAA Privacy Rule, and data protection impact assessment (DPIA) requirements.

Questions to ask:

• What categories of data will you process (protected health information (PHI), PII, cardholder data)?

• How is sensitive data protected at rest and in transit (data encryption standards)?

• Do you implement data minimization practices?

• What is your data retention and deletion policy?

• How do you handle cross-border data transfers and data localization requirements?

• Do you use Standard Contractual Clauses (SCCs) for international transfers?

• Can you provide a data processing agreement aligned with GDPR Article 28?

Control mapping: Critical for GDPR compliance, HIPAA Security Rule, and PCI DSS control requirements 3.4 (encryption of cardholder data).

4. Access Management for Vendors

Why it matters: Access management failures are the leading cause of third-party breaches. This maps to least privilege and zero trust principles.

Questions to ask:

• Who on your team has access to our data or systems?

• Do you enforce MFA (multi-factor authentication) for all administrative access?

• Do you support SSO (single sign-on) integration?

• What is your onboarding/offboarding workflow process?

• How quickly can you revoke access during offboarding?

• Do you maintain audit logs of access to customer data?

Control mapping: Trust Services Criteria CC6.1, ISO 27001 controls A.9 (access control), PCI DSS requirement 8 (MFA requirements).

5. Incident Response & Breach Notification

Why it matters: Incident response maturity determines how fast you'll know when something goes wrong and whether you can meet breach notification requirements.

Questions to ask:

• Do you maintain a formal incident response plan?

• What is your breach notification timeline if an incident affects customer data?

• Have you conducted tabletop exercises or tested your incident response procedures?

• How do you handle data breach notification under GDPR (72-hour requirement)?

• Do you maintain cyber insurance coverage?

Control mapping: GDPR Article 33 (breach notification), HIPAA breach notification requirements, Trust Services Criteria CC7.3.

6. Vulnerability Management & Patch Management

Why it matters: Vulnerability management and patch management prevent known exploits from becoming incidents.

Questions to ask:

• Do you conduct regular vulnerability scanning and pen testing?

• What is your patch management SLA for critical vulnerabilities?

• Do you participate in bug bounty programs?

• How do you handle vulnerability management for third-party components?

Control mapping: PCI DSS requirements 6.2 and 11.3, ISO 27001 controls A.12.6.

7. Third-Party Risk & Supplier Risk Management

Why it matters: Third-party risk travels downstream. Sub-processors can introduce vendor risk you didn't directly assess.

Questions to ask:

• Do you use sub-processors or cloud infrastructure providers?

• How do you conduct vendor due diligence on your own suppliers?

• Will you provide a complete list of sub-processors?

• Do you have continuous monitoring tools for supplier risk?

• How do you handle vendor intake for new sub-processors?

Control mapping: Trust Services Criteria CC9.1, ISO 27001 A.15 (supplier relationships).

8. Business Continuity & Disaster Recovery

Why it matters: Business continuity and disaster recovery capabilities determine operational resilience.

Questions to ask:

• Do you maintain documented business continuity and disaster recovery plans?

• What is your RTO (Recovery Time Objective) and RPO (Recovery Point Objective)?

• How often do you test disaster recovery procedures?

• Do you maintain geographically distributed backups?

Control mapping: Trust Services Criteria A1.2 (availability), ISO 27001 A.17.

9. Change Management & Secure Development

Why it matters: Uncontrolled changes introduce risk. This is critical for SaaS vendors with frequent releases.

Questions to ask:

• Do you maintain a formal change management process?

• How do you test security in your CI/CD pipeline?

• Do you conduct code reviews and security testing before production releases?

• What is your rollback procedure for failed deployments?

Control mapping: Trust Services Criteria CC8.1, SOC 2 control activities for change management.

10. Audit Readiness & Evidence Collection

Why it matters: Audit readiness demonstrates whether controls are documented and verifiable, not just claimed.

Questions to ask:

• Do you maintain an evidence repository for compliance controls?

• How do you track remediation plan completion?

• Do you conduct internal audits in accordance with audit methodology standards?

• Can you provide control evidence samples from recent assessments?

Control mapping: Essential for SOC 2 readiness assessment, ISO 27001 internal audit requirements.

How to Turn Vendor Answers Into Risk Decisions: Vendor Risk Scoring

Collecting answers isn't enough—you need a vendor risk scoring methodology that creates risk-based compliance decisions.

Build a Simple Vendor Risk Score

Use three dimensions for vendor risk assessment:

Risk appetite calculation: Any vendor scoring 7+ becomes a high-risk vendor requiring enhanced continuous monitoring and vendor risk dashboard tracking.

Separate Red Flags From Noise

Focus on structural risk, not paperwork volume:

High-Impact Red Flags

• No incident response plan or breach notification timeline

• Unknown or undisclosed sub-processors (third-party risk blindspot)

• No access management or offboarding workflows

• Missing data processing agreement for GDPR compliance

• No security policy ownership (governance failure)

• No vulnerability scanning or patch management program

Low-Impact Noise

• No fancy compliance certifications (acceptable for early-stage vendors if controls are documented)

• Long policy PDFs with little operational substance

• Overly technical questionnaire language

What matters: Operational maturity and control evidence, not paperwork volume.

Map Vendor Answers to Control Objectives (For SOC 2 & ISO Programs)

For SOC 2 readiness and ISO 27001 programs, align vendor answers to control mapping categories:

This is what auditors examine during SOC 2 audit procedures—proof that third-party risk management is actively managed, not passively collected.

Operationalize Your VRM Program: From Due Diligence to Continuous Monitoring

Most vendor risk management programs fail at operationalization—they build something too heavy that teams abandon.

Step 1: Maintain a Vendor Register

Build a vendor risk dashboard tracking:

• Vendor name and service category

• Risk appetite score (1-9 scale)

• Compliance certifications status

• Last vendor risk assessment date

• Remediation tracking status

Tools: VRM software like risk and compliance platforms automate this, but a structured spreadsheet works for smaller programs.

Step 2: Risk-Based Monitoring Cadence

Step 3: Evidence Collection & Gap Assessment

Request updated control evidence annually:

• Latest SOC 2 reporting or ISO 27001 certification

• Vulnerability scanning results

• Incident response test documentation

• Updated sub-processor lists

Run a gap assessment against your compliance program requirements and create a remediation plan for identified gaps.

Step 4: Contract Risk Management

Embed compliance controls into contracts:

• Data processing agreement (GDPR Article 28)

• Business associate agreement (BAA) for HIPAA compliance

• Breach notification timeline (72 hours for GDPR)

• Right to audit clause

• Vendor due diligence refresh requirements

Contract management with compliance ensures the legal enforceability of your control objectives.

Common VRM Program Mistakes (And How to Avoid Them)

Mistake 1: Treating Due Diligence as a One-Time Activity

Third-party risk evolves. Vendors get acquired, suffer breaches, or change infrastructure. Continuous monitoring isn't optional.

Solution: Implement annual reassessments for moderate-risk vendors, quarterly for high-risk.

Mistake 2: Overweighting Certifications

SOC 2 vs ISO 27001 comparisons matter, but a vendor with SOC 2 Type II and poor incident response is riskier than an early-stage vendor with mature vulnerability management.

Solution: Use certifications as a starting point, not a finish line. Verify with control testing and evidence collection.

Mistake 3: No Clear Risk Appetite

Without a defined risk appetite, every vendor risk assessment becomes a negotiation instead of a decision.

Solution: Document risk appetite thresholds and incorporate them into your vendor intake process.

Mistake 4: Ignoring Sub-Processors

Supplier risk travels downstream. Your vendor's vendors are your risk, too.

Solution: Require complete transparency from sub-processors and apply vendor due diligence to critical sub-processors.

What This Really Solves: From Compliance Theater to Operational Value

Like the manufacturing leaders who learned that AI needs data foundations before automation, effective vendor risk management needs operational memory before compliance checkboxes.

Your VRM program should answer:

• Who touches your systems (complete vendor risk dashboard)

• What could go wrong (vendor risk scoring with risk appetite thresholds)

• How fast you'll know when it does (continuous monitoring and breach notification SLAs)

That's what compliance frameworks like SOC 2, ISO 27001, GDPR, and PCI DSS expect and what customers, regulators, and audit readiness assessments demand.

Build Your VRM Program the Right Way

Vendor due diligence isn't about collecting documents. It's about building structured, usable risk memory that protects your organization when third-party incidents occur.

The factories that scale AI aren't the ones with the flashiest demos; they're the ones that quietly build data foundations first.

The companies that succeed at vendor risk management aren't the ones with the longest questionnaires; they're the ones who build operational memory into their compliance program.

Ready to transform your vendor risk management program? DSALTA's AI-powered compliance platform automates vendor risk assessment, continuous monitoring, and evidence collection—turning third-party risk into a strategic advantage rather than a compliance burden.