aBmeSubscribe
SEC-008·SEC Track·Advanced·20–100 hrs saved

Stop Onboarding Vendors Blind — Assess Third-Party Risk Before the Contract Is Signed

A risk-based, evidence-driven workflow to evaluate, contract, monitor, and safely exit every vendor relationship — with AI accelerating the analysis, not making the decision.

3Phases
31Prompts
20–100Hours saved
3Deliverables

Executive Brief

Your Challenge

Your organization runs on external providers — cloud platforms, SaaS applications, managed services, payment processors, AI tools, software dependencies. Each relationship imports risk from the data the vendor receives, the access it holds, the systems it touches, and the subcontractors it uses. Yet vendors are often engaged before security review, tiered by contract value rather than dependency, and reviewed with a generic questionnaire treated as if it were evidence. When a vendor is breached or fails, you discover how little you actually knew about what they could reach.

Common Obstacles

The failure modes are consistent: assurance reports collected but never analyzed for scope, exceptions, or complementary controls; questionnaire responses accepted as verified facts; external security ratings treated as conclusions; local vendor administrator accounts bypassing SSO and MFA; fourth parties invisible; AI vendors adopted with no review of training use, prompt retention, or connector permissions. Risk gets accepted verbally without an owner, and unresolved 'temporary' exceptions quietly become permanent. Offboarding happens in procurement while access, credentials, and data persist.

The ABME Approach

This workflow imposes order: build the inventory and assign owners, assess inherent risk before commitment, then match assessment depth to a multidimensional tier that separates criticality from security risk. Due diligence validates vendor claims against ranked evidence — reading SOC exceptions, ISO scope, and penetration-test limitations rather than filing them. Contracts encode assessed risk; residual risk gets an accountable owner and an expiration; continuous monitoring supplements periodic reassessment. Every exit is designed before onboarding. AI organizes evidence and surfaces gaps at each stage — but qualified humans accept risk, interpret contracts, and approve vendors.

Insight Summary

Third-party risk management is not the collection of questionnaires and certificates — it is the disciplined evaluation of how an external relationship could affect the organization, how much credible evidence exists, and whether you can monitor and exit it safely.
phase-1

Tier vendors by dependency, data, and access — not by contract value. A low-cost vendor may hold your most sensitive data or support a critical process.

phase-1

Criticality and security risk are different dimensions. A vendor can be operationally critical yet hold little sensitive data, or security-sensitive yet trivially replaceable — collapsing them into one score hides both.

phase-2

A questionnaire response is an assertion until evidence supports it, and a clean SOC opinion is not proof every relevant control is effective — read the exceptions, scope, and complementary user entity controls.

phase-2

Treat AI vendors as both data processors and technology dependencies: whether your data trains a model, how long prompts are retained, and what connectors and agents can do are risk questions, not feature questions.

phase-3

Residual risk with no owner and no expiration is risk you have silently made permanent — accountability and an expiry date are what keep acceptance honest.

tactical

Design the exit before onboarding. If you cannot describe how you would remove access, return data, and prove destruction, you are not ready to grant the access in the first place.

The Journey

Three phases; each lists the tools you'll use there.

1

Inventory, Own, and Tier the Vendor

Build visibility, assign accountable owners, and assess inherent risk before any commitment.
  • Consolidate the vendor inventory and assign a business owner to every relationship
  • Capture intake before contract, purchase order, or data transfer
  • Run a preliminary screen for data, access, criticality, and AI use
  • Assess inherent risk across data, access, criticality, and concentration
  • Assign a multidimensional risk tier that separates criticality from security risk
Prerequisites Checklist
2

Diligence the Evidence

Validate vendor claims against ranked evidence across security, privacy, cloud, supply chain, and AI.
  • Run risk-based due diligence scoped to the service
  • Review assurance reports for scope, exceptions, and complementary user entity controls
  • Assess cloud, SaaS, identity, API, and software supply-chain risk
  • Assess AI vendor data use, connectors, and agent permissions
  • Assess fourth-party, concentration, resilience, and financial risk
  • Use the prompt pack to accelerate analysis at each step
Third-Party Risk Assessment Prompt Pack
3

Decide, Contract, Monitor, and Exit

Determine residual risk, encode contractual protections, and govern the relationship through offboarding.
  • Analyze risk and determine residual risk with evidence confidence
  • Record findings, compensating controls, and time-bound risk acceptances
  • Encode security, privacy, and incident-notification requirements in the contract
  • Route approval to the authority matching the risk level
  • Establish continuous monitoring and event-driven reassessment
  • Execute onboarding controls, and validate access removal and data destruction at offboarding
Validation Checklist

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

1. PHASE 1Checklistprotected

Prerequisites Checklist

Assemble the vendor, contract, evidence, and access artifacts the assessment depends on before beginning any analysis.
Use this to
  • Gather policy, inventory, and evidence artifacts up front
  • Confirm access, data-flow, and regulatory context is available
  • Surface missing assurance evidence early
Included with membership — $20/mo

Gather as much of the following as possible:

2. PHASE 2Prompt Packprotected

Third-Party Risk Assessment Prompt Pack

One comprehensive primary prompt plus thirty targeted follow-ups that drive AI-assisted assessment across tiering, evidence review, cloud, supply chain, AI, contracts, decisions, monitoring, and offboarding.
Use this to
  • Run a full evidence-based third-party assessment
  • Review specific evidence types like SOC 2, ISO, and penetration tests
  • Draft findings, risk acceptances, approvals, and offboarding plans
Included with membership — $20/mo

Primary AI Prompt

Start here with the vendor's intake, evidence, and contract artifacts.
You are a senior third-party risk management leader, security assessor, cloud security architect, application security specialist, privacy advisor, contract security reviewer, business continuity analyst, software supply-chain specialist, AI governance advisor, and enterprise risk consultant.I will provide some or all of the following:• Vendor intake information• Service descriptions• Business criticality• Data classifications• Data flows• System access• Network access• Privileged access• Security questionnaires• SOC reports• ISO certificates• Penetration-test reports• Vulnerability-management evidence• Secure-development evidence• Software Bills of Materials• Subprocessor lists• Privacy documentation• Data processing agreements• Contracts• Security schedules• Incident history• Business continuity plans• Disaster recovery results• Cyber insurance evidence• External security ratings• AI product terms• AI architecture• Open findings• Risk acceptances• Continuous-monitoring alerts• Offboarding evidenceYour task is to perform a comprehensive third-party security risk assessment.Do not assume that a questionnaire response is verified evidence.Do not assume that certification means every relevant control is effective.Do not assume that a favorable external security rating means the service is secure.First:1. Summarize:   • Vendor and legal entity   • Service   • Business purpose   • Business owner   • Criticality   • Data involved   • System access   • Hosting model   • Integration model   • Geographic scope   • Subprocessors   • Regulatory scope   • AI use   • Current risk tier2. Separate:   • Confirmed facts   • Independently validated evidence   • Vendor assertions   • Customer assertions   • Inferences   • Assumptions   • Unknowns3. Identify missing evidence that materially affects the assessment.4. Evaluate:   • Governance   • Asset management   • Identity and access   • Privileged access   • Authentication   • Encryption   • Key management   • Logging   • Monitoring   • Vulnerability management   • Secure development   • Application security   • API security   • Cloud security   • Tenant isolation   • Network security   • Endpoint security   • Data protection   • Privacy   • Retention   • Deletion   • Incident response   • Business continuity   • Disaster recovery   • Personnel security   • Subprocessors   • Software supply chain   • Artificial intelligence   • Contract protections   • Insurance   • Financial viability   • Concentration risk   • Offboarding5. Review all evidence for:   • Date   • Scope   • Legal entity   • Service applicability   • Locations   • Exceptions   • Qualifications   • Auditor opinion   • Limitations   • Expiration   • Consistency with other evidence6. For each weakness provide:   • Finding ID   • Domain   • Severity   • Confidence   • Evidence   • Evidence limitation   • Threat   • Business impact   • Security impact   • Privacy impact   • Compliance impact   • Operational impact   • Recommended vendor action   • Recommended customer action   • Compensating control   • Owner   • Due date   • Validation method   • Risk decision7. Identify:   • Unsupported assertions   • Outdated evidence   • Scope gaps   • Qualified audit opinions   • Control exceptions   • Missing MFA   • Excessive privilege   • Weak tenant isolation   • Unencrypted sensitive data   • Inadequate incident notification   • Weak vulnerability management   • Secure-development gaps   • Unsupported software dependencies   • Missing subprocessor controls   • AI training use   • Excessive retention   • Incomplete deletion   • Business continuity gaps   • Concentration risk   • Offboarding risk   • Contract gaps8. Classify findings as:   • Critical   • High   • Medium   • Low   • Informational9. Determine:   • Inherent risk   • Control effectiveness   • Evidence confidence   • Residual risk   • Required remediation   • Approval authority   • Reassessment frequency   • Continuous-monitoring requirementsRequirements:• Scope findings to the assessed service.• Distinguish vendor controls from customer responsibilities.• Identify complementary user entity controls.• Do not treat external ratings as definitive.• Do not assume a clean SOC opinion means there are no control concerns.• Review audit exceptions and management responses.• Identify subcontractor and fourth-party dependencies.• Treat AI vendors as data processors and technology dependencies.• Identify whether customer data is used for model training.• Identify whether prompts or files are retained.• Identify connector and agent permissions.• Require risk acceptance to have an owner and expiration.• Prioritize active compromise, public exposure, privileged-access weakness, prohibited data use, and critical resilience failures.• Identify where legal, privacy, procurement, finance, business continuity, security, or executive review is required.• State when evidence is insufficient.• Do not reproduce confidential report content beyond what is necessary.• Do not expose passwords, secrets, keys, personal data, protected health information, payment data, or confidential customer content.Then produce:1. Executive summary.2. Vendor profile.3. Inherent-risk assessment.4. Evidence inventory.5. Evidence-quality assessment.6. Security control assessment.7. Privacy assessment.8. Cloud and SaaS assessment.9. Application and API assessment.10. Identity and access assessment.11. Vulnerability and secure-development assessment.12. Software supply-chain assessment.13. AI vendor assessment.14. Fourth-party assessment.15. Incident-response assessment.16. Business continuity and resilience assessment.17. Contract and legal-control gaps.18. Concentration and exit-risk assessment.19. Findings register.20. Compensating controls.21. Residual-risk assessment.22. Approval recommendation.23. Required conditions.24. Continuous-monitoring plan.25. Reassessment plan.26. Offboarding requirements.27. Executive dashboard inputs.28. Open questions.29. Final recommendation.

Determine Vendor Risk Tier

Use during preliminary screening to assign a tier and assessment depth.
Determine the appropriate third-party risk tier.Evaluate:• Data sensitivity• Data volume• System access• Privileged access• Network connectivity• Business criticality• Customer impact• Regulatory scope• Geographic scope• Subprocessors• AI use• Software deployment• Replacement difficulty• Concentration riskProvide the recommended tier, rationale, required assessment depth, and reassessment frequency.

Review a Security Questionnaire

Use to separate vendor assertions from verified evidence.
Review this vendor security questionnaire.Identify:• Unsupported claims• Ambiguous responses• Incomplete responses• Inappropriate not-applicable responses• Conflicting responses• Weak controls• Missing evidence• Follow-up questions• Required remediation• Customer-side controlsSeparate vendor assertions from verified evidence.

Review a SOC 2 Report

Use when analyzing a supplied SOC 2 report.
Review the supplied SOC 2 report.Assess:• Report type• Audit period• Service scope• Legal entity• Locations• Subservice organizations• Carve-out method• Auditor opinion• Control exceptions• Management responses• Complementary user entity controls• Subsequent events• Current-period gap• Applicability to our serviceProduce findings, customer responsibilities, follow-up questions, and residual-risk implications.

Review an ISO 27001 Certificate

Use to validate scope and applicability of an ISO certificate.
Review this ISO/IEC 27001 certificate and supporting material.Validate:• Legal entity• Scope• Locations• Standard version• Certification body• Accreditation• Issue date• Expiration• Exclusions• Statement of applicability• Applicability to the assessed serviceIdentify what the certificate does and does not demonstrate.

Review a Penetration-Test Report

Use when assessing a vendor penetration-test report.
Review this vendor penetration-test report.Assess:• Date• Scope• Independence• Methodology• Authentication level• Applications• APIs• Cloud• Mobile• Findings• Open high-risk findings• Retesting• Limitations• ApplicabilityRecommend follow-up questions and risk treatment.

Review Vulnerability Management

Use to assess the vendor's vulnerability-management program.
Assess the vendor's vulnerability-management program.Review:• Asset coverage• Scan frequency• Credentialed scanning• Cloud assessment• Application testing• Container scanning• Dependency scanning• Remediation SLAs• Exploit intelligence• Exceptions• Retesting• Disclosure program• MetricsIdentify material weaknesses and evidence gaps.

Review Secure Development

Use to assess secure development and software supply-chain risk.
Assess the vendor's secure development lifecycle.Review:• Security requirements• Threat modeling• Code review• Static analysis• Dynamic testing• Software composition analysis• Secret scanning• Build pipeline• Signing• Release controls• Developer training• Vulnerability disclosure• Patch processIdentify software supply-chain risk.

Review an SBOM

Use when analyzing a Software Bill of Materials.
Analyze this Software Bill of Materials.Identify:• Unsupported components• End-of-life components• Known critical vulnerabilities• Unmaintained dependencies• License concerns• High-risk transitive dependencies• Missing version information• Missing provenance• Components requiring remediationDo not infer that the SBOM proves secure development.

Assess a SaaS Vendor

Use to assess a SaaS provider's configuration and controls.
Assess this SaaS provider.Review:• SSO• MFA• SCIM• Roles• Administrative access• Audit logs• APIs• Session controls• Encryption• Data export• Data deletion• Sharing• Backup• Tenant isolation• Support access• Mobile use• AI features• Marketplace integrationsProvide required configuration and contractual controls.

Assess Vendor Identity Controls

Use to assess the vendor's identity and access model.
Assess the vendor identity and access model.Review:• Federation• MFA• Passwordless options• Local accounts• Privileged access• Role model• Session controls• SCIM• Termination• Break-glass accounts• Support access• Logging• Access reviews

Assess Privileged Vendor Access

Use to assess third-party privileged access to your environment.
Assess third-party privileged access to our environment.Review:• Named accounts• Sponsorship• Business justification• MFA• Privileged access management• Time-bound access• Device restrictions• Session recording• Command logging• Approval• Ticket reference• Monitoring• Expiration

Review API Integration Risk

Use when assessing a vendor API integration.
Assess this vendor API integration.Review:• Authentication• Authorization• Token scope• Token lifetime• Secret storage• Certificate use• Data exchanged• Rate limits• Logging• Input validation• Encryption• Revocation• Error handling• Versioning• Customer responsibilities

Perform an AI Vendor Assessment

Use to assess an artificial intelligence vendor.
Assess this artificial intelligence vendor.Evaluate:• Customer data use• Model-training use• Prompt retention• File retention• Tenant isolation• Data location• Subprocessors• Model providers• Connectors• Agents• Read permissions• Write permissions• Destructive actions• Human approval• Logging• Deletion• Intellectual property• Output ownership• Security testing• Prompt injection• Abuse prevention• Availability• Model change notification• Exit riskProvide inherent risk, findings, required conditions, and residual risk.

Review AI Terms of Service

Use to review AI service terms for security, privacy, and data-use risk.
Review these AI service terms for security, privacy, and data-use risk.Identify provisions related to:• Training• Retention• Ownership• Licensing• Confidentiality• Subprocessors• Data location• Security• Incident notification• Deletion• Indemnification• Liability• Model changes• Suspension• Termination• ExportFlag language requiring legal review.

Review Fourth-Party Risk

Use to assess fourth-party and subprocessor risk.
Assess fourth-party and subprocessor risk.Identify:• Material subprocessors• Services provided• Data received• Locations• Critical dependencies• Security evidence• Contract flow-down• Incident obligations• Change notification• Concentration risk• Exit implications

Review Data Flows

Use to document and assess vendor data flows.
Review the vendor data flow.For each flow document:• Source• Destination• Data category• Data subjects• Purpose• Transfer method• Encryption• Storage• Processing• Location• Subprocessor• Retention• Return• Deletion• Risk• Required control

Perform a Privacy Assessment

Use to assess privacy risk for a third party.
Assess privacy risk for this third party.Review:• Personal data• Data subjects• Purpose• Legal basis• Processing locations• Cross-border transfers• Subprocessors• Retention• Deletion• Data-subject rights• Automated decisions• Training use• Sale or sharing• Incident notification• Government requestsIdentify required privacy and legal review.

Review Contract Security Terms

Use to review a contract for security and operational protections.
Review this contract for security and operational protections.Assess clauses covering:• Security program• Compliance• Encryption• Access• Vulnerability management• Secure development• Logging• Data use• Data location• Subprocessors• Incident notification• Cooperation• Audit rights• Assurance evidence• Business continuity• Data return• Data deletion• Insurance• Liability• Indemnification• Termination• Transition supportIdentify missing or weak provisions for legal review.

Review Incident Notification Terms

Use to assess vendor incident-notification requirements.
Assess the vendor incident-notification requirements.Determine whether the contract defines:• Trigger• Notification deadline• Initial content• Ongoing updates• Affected data• Affected systems• Indicators of compromise• Containment• Cooperation• Root-cause report• Regulatory support• Customer communication• Final report

Review Business Continuity

Use to assess vendor continuity and disaster recovery capability.
Assess the vendor's business continuity and disaster recovery capability.Review:• Business impact analysis• RTO• RPO• Backup• Redundancy• Disaster recovery• Test frequency• Test results• Deficiencies• Cyber recovery• Crisis communications• Manual workaround• Dependencies• Customer prioritization

Analyze Vendor Incident History

Use to analyze known incident and outage history.
Analyze the vendor's known incident and outage history.For each event identify:• Date• Event• Scope• Customer impact• Data impact• Cause• Response• Notification• Remediation• Recurrence• Relevance to our serviceDo not treat a past incident as automatic disqualification.

Assess Concentration Risk

Use to assess third-party concentration risk across the portfolio.
Assess third-party concentration risk.Identify:• Vendors supporting multiple critical processes• Shared cloud providers• Shared identity providers• Shared subprocessors• Shared regions• Shared software dependencies• Geographic concentration• Renewal concentration• Single points of failure• Exit limitationsRecommend diversification or resilience controls.

Build a Findings Register

Use to compile findings into a structured register.
Create a third-party risk findings register.For each finding include:• Finding ID• Vendor• Service• Domain• Severity• Evidence• Confidence• Risk• Vendor action• Customer action• Compensating control• Owner• Due date• Status• Validation• Risk decision• Expiration

Recommend an Approval Decision

Use to recommend a decision after the assessment.
Based on the assessment, recommend one of the following:• Approve• Approve with conditions• Approve for pilot only• Approve with reduced scope• Approve temporarily• Defer• Reject• Replace• Escalate for executive risk acceptanceExplain the required conditions, owners, deadlines, residual risk, monitoring, and reassessment frequency.

Draft a Risk Acceptance

Use to draft a risk-acceptance record with an owner and expiration.
Draft a third-party risk acceptance record.Include:• Vendor• Service• Risk• Evidence• Business impact• Security impact• Privacy impact• Reason remediation is not currently feasible• Compensating controls• Business owner• Security review• Privacy or legal review• Approval authority• Start date• Expiration• Review date• Exit condition

Build a Continuous-Monitoring Plan

Use to create a monitoring plan for an approved vendor.
Create a continuous-monitoring plan for this vendor.Include:• Security ratings• Assurance expiration• Breach monitoring• Vulnerability alerts• Service outages• Regulatory action• Ownership changes• Subprocessor changes• Product changes• AI changes• Financial events• Incident trends• Review frequency• Escalation threshold• Owner

Perform a Renewal Review

Use before a contract renewal decision.
Perform a vendor renewal review.Assess:• Continued business need• Current usage• Data• Access• Open findings• Incidents• Service performance• Assurance• Contract• Subprocessors• AI capabilities• Cost• Alternatives• Exit feasibility• Residual riskRecommend renew, renew with conditions, renegotiate, replace, or terminate.

Design Vendor Offboarding

Use to create a vendor offboarding plan.
Create a vendor offboarding plan.Include:• Contract termination• User access• Vendor access• Privileged access• SSO• SCIM• API credentials• Tokens• Certificates• Network connections• Data export• Data return• Data deletion• Backup handling• Subprocessor deletion• Legal hold• Knowledge transfer• Transition support• Validation• Evidence

Create an Executive Dashboard

Use to design an executive third-party risk dashboard.
Design an executive third-party risk dashboard.Include:• Critical vendors• High residual risks• Critical and high findings• Vendor incidents• Risk acceptances• Concentration risk• Assurance gaps• Contract gaps• AI vendor risk• Critical vendor resilience• Overdue assessments• Offboarding failures• Major remediation initiatives• Business-unit accountability

Create an Operational Dashboard

Use to design an operational third-party risk dashboard.
Design an operational third-party risk dashboard.Include:• New intake• Assessments in progress• Overdue assessments• Evidence pending• Questionnaires pending• Open findings• Overdue remediation• Contract reviews• Expiring risk acceptances• Expiring assurance• Reassessments due• Monitoring alerts• Incidents• Offboarding tasks• Data-deletion confirmations
3. PHASE 3Checklistprotected

Validation Checklist

A domain-by-domain acceptance gate confirming the third-party risk program covers governance, evidence, security, privacy, AI, resilience, contracts, decisions, monitoring, and offboarding.
Use this to
  • Verify each program domain is fully addressed before sign-off
  • Confirm evidence, contracts, and risk decisions are complete
  • Check that monitoring and offboarding controls are in place
Included with membership — $20/mo

Confirm the program against each domain:

Governance

Vendor Inventory

Intake and Tiering

Evidence

Security

Privacy and Data

AI Vendors

Resilience

Contracts

Risk Decisions

Continuous Monitoring

Offboarding

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

A third-party security risk assessment is the structured evaluation of security, privacy, resilience, compliance, and operational risks introduced by vendors, suppliers, service providers, cloud platforms, software providers, contractors, business partners, and other external entities.

Third-party risk extends beyond the security posture of a vendor.

It includes the risk created by:

  • The data the vendor receives
  • The access the vendor receives
  • The systems the vendor supports
  • The processes the vendor performs
  • The software the vendor supplies
  • The dependencies the vendor introduces
  • The subcontractors the vendor uses
  • The jurisdictions in which the vendor operates
  • The contractual protections available
  • The organization's ability to replace or exit the relationship

A mature third-party risk management program should answer:

"What risk does this relationship create, what evidence supports the assessment, which controls reduce the risk, who accepts the remaining risk, and how will the relationship be monitored and terminated safely?"

The objective is not to eliminate all third-party risk.

The objective is to make informed, documented, risk-based decisions before, during, and after a third-party relationship.

Business Problempublic

Organizations increasingly depend on external providers for:

  • Cloud infrastructure
  • SaaS applications
  • Managed services
  • Data processing
  • Payment processing
  • Human resources
  • Customer support
  • Software development
  • Security services
  • Artificial intelligence
  • Analytics
  • Business continuity
  • Manufacturing
  • Logistics
  • Legal services
  • Marketing
  • Communications
  • Financial operations

Common third-party risk symptoms include:

  • Vendors engaged before security review
  • Incomplete vendor inventory
  • No vendor owner
  • Generic questionnaires used for every vendor
  • Unsupported vendor claims
  • Expired assurance reports
  • No review of report exceptions
  • Weak contract language
  • No breach-notification deadline
  • Broad vendor access
  • Shared vendor accounts
  • No MFA requirement
  • No subcontractor visibility
  • No data-deletion evidence
  • No offboarding process
  • No continuous monitoring
  • Critical vendors reviewed the same as low-risk vendors
  • AI services adopted without governance
  • Open-source dependencies not tracked
  • Cloud services configured insecurely by the customer
  • Security ratings treated as definitive evidence
  • Risk accepted verbally without accountability

Without a mature third-party risk process:

  • Sensitive data may be exposed.
  • Critical operations may be disrupted.
  • Regulatory obligations may be violated.
  • Incident response may be delayed.
  • Contractual leverage may be limited.
  • Fourth parties may introduce unknown risk.
  • Concentration risk may go unnoticed.
  • Vendor access may remain after termination.
  • Unsupported or vulnerable software may enter production.
  • Leadership may unknowingly accept material risk.
  • Audit findings may recur.
  • Exit costs may become excessive.

Expected Outcomepublic

After completing this workflow, the organization should have:

  • Third-party risk management strategy
  • Program charter
  • Vendor inventory
  • Vendor ownership model
  • Risk-tiering methodology
  • Inherent-risk assessment
  • Due-diligence process
  • Evidence-review standards
  • Security questionnaire strategy
  • Residual-risk methodology
  • Risk-treatment process
  • Contractual security requirements
  • Privacy and data-processing review
  • Cloud and SaaS assessment process
  • AI vendor assessment process
  • Software supply-chain assessment
  • Fourth-party risk process
  • Continuous-monitoring model
  • Issue and remediation tracking
  • Exception and risk-acceptance process
  • Incident-notification process
  • Business continuity review
  • Vendor offboarding process
  • Metrics and dashboards
  • Implementation roadmap
  • AI-assisted assessment prompts
  • Automation opportunities

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Program Objectivesprotected

The third-party risk program should answer:

  1. Which third parties does the organization use?
  2. Who owns each relationship?
  3. What services does each third party provide?
  4. Which business processes depend on each vendor?
  5. What data does each vendor receive?
  6. What system access does each vendor have?
  7. Which vendors are operationally critical?
  8. Which vendors are difficult to replace?
  9. Which vendors use subcontractors?
  10. Where is organizational data stored and processed?
  11. Which regulations apply?
  12. What assurance evidence exists?
  13. Is the evidence current and applicable?
  14. What exceptions or qualifications exist?
  15. What technical controls reduce risk?
  16. What contractual controls reduce risk?
  17. What residual risk remains?
  18. Who may accept that risk?
  19. How are remediation items tracked?
  20. How frequently is each vendor reassessed?
  21. How are security events monitored?
  22. How are incidents communicated?
  23. How is fourth-party risk addressed?
  24. How are AI vendors governed?
  25. How are software dependencies governed?
  26. How is concentration risk measured?
  27. How is financial or operational instability considered?
  28. How is vendor access removed?
  29. How is data returned or destroyed?
  30. How is program effectiveness measured?

Core Principlesprotected

Recommended principles include:

  • Every vendor must have a business owner.
  • Risk should be assessed before commitment.
  • Assessment depth should reflect risk.
  • Evidence should be current, relevant, and independently validated where possible.
  • Questionnaires should not be the only evidence source.
  • Vendor claims should be distinguished from verified facts.
  • Data access and system access should drive risk.
  • Criticality and security risk should be evaluated separately.
  • Residual risk should have an accountable owner.
  • Exceptions should expire.
  • Contracts should reflect assessed risk.
  • Fourth parties should be considered.
  • Continuous monitoring should not replace periodic reassessment.
  • Security ratings should be treated as indicators, not conclusions.
  • Offboarding should be designed before onboarding.
  • Vendor access should be least privilege.
  • Data sharing should be minimized.
  • Critical vendors should have tested continuity plans.
  • AI vendors should be evaluated as data processors and technology dependencies.
  • Automation should improve consistency without removing human accountability.

Program Foundationsprotected

Third-Party Categories

Third parties may include:

  • SaaS providers
  • Cloud service providers
  • Managed service providers
  • Managed security service providers
  • Software vendors
  • Hardware vendors
  • Payment processors
  • Payroll providers
  • Benefits providers
  • Healthcare providers
  • Data brokers
  • Analytics providers
  • Marketing platforms
  • Customer support providers
  • Call centers
  • Law firms
  • Accounting firms
  • Consultants
  • Contractors
  • Staffing agencies
  • Logistics providers
  • Manufacturers
  • Distributors
  • Resellers
  • Hosting providers
  • Telecommunications providers
  • Artificial intelligence providers
  • Open-source maintainers
  • Integration partners
  • Joint ventures
  • Affiliates
  • Acquired companies

Vendor Inventory

The vendor inventory should capture:

  • Vendor legal name
  • Trading name
  • Parent company
  • Service
  • Business owner
  • Technical owner
  • Contract owner
  • Procurement owner
  • Data owner
  • Privacy owner
  • Service start date
  • Contract renewal date
  • Contract termination date
  • Business process
  • Criticality
  • Inherent-risk tier
  • Residual-risk rating
  • Data categories
  • Data volume
  • Data subjects
  • System access
  • Network access
  • Privileged access
  • Integration type
  • Hosting model
  • Processing locations
  • Subcontractors
  • Regulatory scope
  • Assurance reports
  • Last assessment date
  • Next review date
  • Open findings
  • Exceptions
  • Incident history
  • Exit plan
  • Lifecycle status

Vendor Ownership

Every vendor should have:

  • Business owner
  • Contract owner
  • Technical contact
  • Security contact
  • Privacy contact where applicable
  • Data owner where applicable
  • Service continuity owner
  • Offboarding owner

The business owner should be accountable for:

  • Business need
  • Vendor use
  • Access justification
  • Data sharing
  • Remediation support
  • Renewal decision
  • Risk acceptance
  • Offboarding

Vendor Lifecycle

A complete lifecycle should include:

  1. Request
  2. Intake
  3. Preliminary screening
  4. Inherent-risk assessment
  5. Due diligence
  6. Evidence review
  7. Risk analysis
  8. Remediation
  9. Contract negotiation
  10. Approval
  11. Onboarding
  12. Access provisioning
  13. Continuous monitoring
  14. Periodic reassessment
  15. Renewal review
  16. Incident management
  17. Offboarding
  18. Data return or destruction
  19. Relationship closure

Intake, Screening, and Risk Tieringprotected

Intake Process

Vendor intake should capture:

  • Requesting business unit
  • Business purpose
  • Service description
  • Alternatives considered
  • Required implementation date
  • Data involved
  • Users
  • Integrations
  • Administrative access
  • Hosting model
  • Geographic scope
  • Regulatory impact
  • Criticality
  • Contract value
  • Planned term
  • Replacement difficulty
  • AI functionality
  • Subcontractor use
  • Software deployment model

Security review should begin before:

  • Contract signature
  • Purchase order
  • Data transfer
  • Integration
  • Production deployment
  • User invitation
  • Proof of concept involving sensitive data

Preliminary Screening

A preliminary screen should determine whether the vendor:

  • Receives sensitive data
  • Stores sensitive data
  • Processes regulated data
  • Connects to production systems
  • Receives privileged access
  • Provides critical services
  • Supplies production software
  • Uses artificial intelligence
  • Uses subcontractors
  • Operates in high-risk jurisdictions
  • Supports essential business operations
  • Could materially affect customers
  • Could affect safety
  • Could affect financial reporting
  • Could create regulatory exposure

Low-risk vendors may follow a streamlined process.

Inherent Risk

Inherent risk is the risk created by the relationship before considering vendor controls or contractual protections.

Assess:

  • Data sensitivity
  • Data volume
  • System access
  • Privilege
  • Network connectivity
  • Business criticality
  • Operational dependency
  • Regulatory scope
  • Geographic exposure
  • Transaction volume
  • Customer impact
  • Safety impact
  • Software supply-chain access
  • Subcontractor dependency
  • Replacement difficulty
  • Concentration risk
  • Financial materiality
  • AI use

Inherent-Risk Questions

Examples include:

  • Will the vendor process personal information?
  • Will the vendor process health information?
  • Will the vendor process payment data?
  • Will the vendor access source code?
  • Will the vendor connect to production?
  • Will the vendor have administrative privileges?
  • Will the vendor make automated decisions?
  • Will the vendor host customer-facing services?
  • Would a vendor outage materially disrupt operations?
  • Would compromise affect multiple business units?
  • Is the vendor difficult to replace?
  • Will the vendor use subprocessors?
  • Will data cross national borders?
  • Will the vendor train AI models using organizational data?
  • Will the vendor supply executable code?

Criticality Versus Security Risk

Do not combine criticality and security into one unexplained score.

A vendor may be:

  • Operationally critical but hold little sensitive data
  • Security-sensitive but operationally replaceable
  • High in both dimensions
  • Low in both dimensions

Evaluate separately:

  • Business criticality
  • Information security risk
  • Privacy risk
  • Compliance risk
  • Resilience risk
  • Concentration risk
  • Financial risk
  • Strategic risk

Risk Tiersprotected

Tier 1 — Critical

Characteristics may include critical business dependency, restricted or regulated data, privileged access, production connectivity, material customer impact, difficult replacement, and significant concentration risk.
  • Characteristics: critical business dependency, restricted or regulated data, privileged access, production connectivity, material customer impact, difficult replacement, significant concentration risk
  • Assessment requirements: full questionnaire, independent assurance reports, architecture review, penetration-test summary, business continuity review, privacy review, contract security review, executive risk approval, annual reassessment, continuous monitoring

Tier 2 — High

Characteristics may include confidential data, an important business service, integration with internal systems, and moderate operational dependency.
  • Characteristics: confidential data, important business service, integration with internal systems, moderate operational dependency
  • Assessment: targeted questionnaire, assurance evidence, privacy review, contract review, annual or biennial reassessment

Tier 3 — Moderate

Characteristics may include internal data, limited integration, low operational dependency, and standard SaaS use.
  • Characteristics: internal data, limited integration, low operational dependency, standard SaaS use
  • Assessment: streamlined questionnaire, public assurance evidence, basic contract review, periodic reassessment

Tier 4 — Low

Characteristics may include no sensitive data, no system access, low business dependency, and an easily replaceable service.
  • Characteristics: no sensitive data, no system access, low business dependency, easily replaceable service
  • Assessment: basic screening, terms review, business-owner attestation

Due Diligence and Questionnairesprotected

Due Diligence

Due diligence may include:

  • Security questionnaire
  • Privacy questionnaire
  • Architecture review
  • Data-flow review
  • Product security review
  • Compliance evidence
  • Penetration-test evidence
  • Vulnerability-management evidence
  • Incident-history review
  • Business continuity review
  • Financial viability review
  • Contract review
  • Insurance review
  • Subprocessor review
  • External attack-surface review
  • Reference checks
  • On-site assessment
  • Interview with vendor personnel

Questionnaire Strategy

Questionnaires should be:

  • Risk-based
  • Scoped to the service
  • Proportionate
  • Mapped to recognized standards
  • Evidence-driven
  • Reusable
  • Version-controlled
  • Reviewed periodically

Possible sources include:

  • Standardized Information Gathering questionnaire
  • Cloud Security Alliance CAIQ
  • HECVAT
  • NIST-based questionnaires
  • Industry-specific questionnaires
  • Organization-specific control sets

Questionnaire Limitations

Questionnaires may contain:

  • Marketing language
  • Unsupported assertions
  • Outdated responses
  • Enterprise-wide answers that do not apply to the service
  • Ambiguous answers
  • Aspirational controls
  • Incomplete scope
  • Inconsistent terminology
  • Unsupported "not applicable" responses

Questionnaire responses should be validated against evidence.

Evidence Hierarchyprotected

Ranked evidence (most to least persuasive)

Evidence may be ranked approximately as follows. The most persuasive evidence depends on the control being assessed.
  • Direct technical validation
  • Independent audit or certification
  • Current testing evidence
  • Formal policy and procedure
  • System-generated record
  • Contractual commitment
  • Management attestation
  • Questionnaire assertion
  • Marketing material

Evidence Reviewprotected

Evidence Requirements

Evidence should be:

  • Current
  • Applicable to the service
  • Applicable to the legal entity
  • Applicable to the processing location
  • Complete
  • Authentic
  • Independently produced where appropriate
  • Reviewed for exceptions
  • Reviewed for scope limitations
  • Protected appropriately

Assurance Reports

Possible evidence includes:

  • SOC 1 Type II
  • SOC 2 Type II
  • ISO/IEC 27001 certificate
  • ISO/IEC 27701 certificate
  • PCI DSS Attestation of Compliance
  • HITRUST certification
  • FedRAMP authorization
  • CSA STAR registry
  • Penetration-test report
  • Vulnerability-assessment summary
  • Business continuity test results
  • Privacy certification
  • Cyber insurance certificate

SOC Report Review

When reviewing a SOC report, assess:

  • Report type
  • Reporting period
  • Service organization
  • System in scope
  • Locations in scope
  • Subservice organizations
  • Carve-out versus inclusive method
  • Control objectives
  • Control exceptions
  • Management responses
  • Complementary user entity controls
  • Subsequent events
  • Auditor opinion
  • Qualified opinion
  • Testing period
  • Gap between report period and current date

Complementary User Entity Controls

Complementary user entity controls identify responsibilities retained by the customer.

Examples may include:

  • Configure MFA
  • Manage user access
  • Review logs
  • Secure integrations
  • Configure encryption
  • Remove terminated users
  • Maintain endpoint controls
  • Review administrative roles
  • Enable backups
  • Configure retention

These controls should become customer-owned implementation requirements.

Bridge Letters

Where an assurance report does not cover the current period, a bridge letter may address:

  • Material changes
  • New incidents
  • Control changes
  • Auditor relationship
  • Subservice changes
  • Scope changes
  • Management representation

A bridge letter does not provide the same assurance as a new audit.

ISO Certificate Review

Validate:

  • Certificate number
  • Certification body
  • Accreditation
  • Legal entity
  • Scope
  • Locations
  • Standard version
  • Issue date
  • Expiration date
  • Statement of applicability where available
  • Surveillance status
  • Exclusions

An ISO certificate should not be treated as proof that every relevant control is effective.

Penetration-Test Review

Review:

  • Date
  • Scope
  • Methodology
  • Independence
  • Authentication level
  • External versus internal testing
  • API coverage
  • Cloud coverage
  • Mobile coverage
  • Severity model
  • Findings
  • Retesting
  • Open high-risk findings
  • Report limitations

A one-page attestation may be insufficient for high-risk services.

Vulnerability Management Review

Assess:

  • Asset coverage
  • Scan frequency
  • Credentialed scanning
  • Application testing
  • Dependency scanning
  • Cloud configuration
  • Container scanning
  • Remediation SLAs
  • Exploit intelligence
  • Exception process
  • Retesting
  • Metrics
  • Disclosure program

Secure Development Review

Assess:

  • Secure development lifecycle
  • Threat modeling
  • Code review
  • Static analysis
  • Dynamic testing
  • Software composition analysis
  • Secret scanning
  • Build security
  • Signing
  • Release approval
  • Dependency management
  • Vulnerability disclosure
  • Patch process
  • Security training

Software Supply-Chain Riskprotected

Software Supply-Chain Risk

Evaluate:

  • Source-code access
  • Build pipeline
  • Dependency inventory
  • Software Bill of Materials
  • Package sources
  • Artifact signing
  • Reproducible builds
  • Code-signing keys
  • Release integrity
  • Maintainer access
  • Third-party libraries
  • Open-source governance
  • Vulnerability response
  • End-of-life dependencies

Software Bill of Materials

An SBOM may include:

  • Component
  • Version
  • Supplier
  • License
  • Dependency relationship
  • Package identifier
  • Hash
  • Known vulnerabilities
  • Support status

An SBOM provides visibility but does not prove security.

Open-Source Risk

Assess:

  • Component age
  • Maintenance status
  • Community health
  • Known vulnerabilities
  • License
  • Provenance
  • Download source
  • Typosquatting risk
  • Malicious package risk
  • Transitive dependencies
  • Patch availability
  • Internal ownership

Cloud, SaaS, Identity, and Accessprotected

Cloud Provider Assessment

Assess both:

  • Provider security
  • Customer configuration responsibilities

Review:

  • Shared responsibility
  • Identity
  • Administrative access
  • Logging
  • Encryption
  • Key management
  • Network controls
  • Data residency
  • Backup
  • Resilience
  • Incident notification
  • Support access
  • Subprocessors
  • Exit capability

SaaS Assessment

Review:

  • Authentication
  • SSO
  • MFA
  • SCIM
  • Role model
  • Administrative roles
  • Audit logs
  • API access
  • Session controls
  • Data export
  • Data deletion
  • Encryption
  • Sharing
  • Backup
  • Retention
  • Tenant isolation
  • Support access
  • Mobile controls
  • AI features
  • Marketplace integrations

Identity Federation Review

Assess:

  • SAML or OpenID Connect
  • Domain verification
  • MFA enforcement
  • Local-account fallback
  • Break-glass accounts
  • Just-in-time provisioning
  • SCIM deprovisioning
  • Session lifetime
  • Role mapping
  • Group mapping
  • Certificate rotation
  • Signing validation
  • Logout
  • Guest access

Local vendor accounts can create offboarding and policy gaps.

Vendor Access Review

Evaluate vendor access to:

  • Networks
  • Servers
  • Endpoints
  • Databases
  • Cloud platforms
  • Applications
  • Source-code repositories
  • Ticketing systems
  • Remote support tools
  • Security platforms

Require:

  • Named accounts
  • MFA
  • Least privilege
  • Time-bound access
  • Approval
  • Logging
  • Session monitoring
  • Device controls
  • Periodic review
  • Immediate termination process

Privileged Vendor Access

Privileged third-party access should include:

  • Named user
  • Sponsor
  • Business justification
  • Target resource
  • Approval
  • Activation window
  • MFA
  • Privileged access management
  • Session recording where appropriate
  • Command logging
  • Ticket reference
  • Monitoring
  • Expiration
  • Post-use review

API Security Review

Assess:

  • Authentication
  • Authorization
  • Token scope
  • Token lifetime
  • Secret storage
  • Certificate use
  • Rate limiting
  • Logging
  • Input validation
  • Encryption
  • Error handling
  • Data minimization
  • Versioning
  • Revocation
  • Testing
  • Vendor support

Data and Privacyprotected

Data Flow Review

Document:

  • Data source
  • Data destination
  • Data categories
  • Data subjects
  • Purpose
  • Transfer method
  • Storage
  • Processing
  • Encryption
  • Geographic location
  • Subprocessors
  • Retention
  • Return
  • Deletion

Unknown data flows should be treated as a material gap.

Data Minimization

Before onboarding, determine whether the vendor needs:

  • All records
  • Full identifiers
  • Production data
  • Historical data
  • Raw data
  • Administrative access
  • Continuous access
  • Local copies
  • Sensitive attributes

Use:

  • Masking
  • Tokenization
  • Aggregation
  • Pseudonymization
  • Limited fields
  • Limited duration
  • Limited population
  • Read-only access

Privacy Review

Assess:

  • Personal-data categories
  • Data subjects
  • Purpose
  • Legal basis
  • Processing locations
  • Data residency
  • Cross-border transfer
  • Subprocessors
  • Retention
  • Deletion
  • Data-subject rights
  • Security measures
  • Breach notification
  • Automated decision-making
  • Training use
  • Sale or sharing
  • Government requests

Data Processing Agreement

A data processing agreement may address:

  • Processing instructions
  • Confidentiality
  • Security
  • Subprocessors
  • Cross-border transfer
  • Assistance with rights requests
  • Incident notification
  • Audit
  • Retention
  • Return or deletion
  • Regulatory cooperation
  • Liability
  • Termination

Legal counsel should determine required language.

Artificial Intelligence Vendor Riskprotected

Artificial Intelligence Vendor Assessment

AI vendors may introduce risks involving:

  • Training use
  • Prompt retention
  • File retention
  • Model outputs
  • Data leakage
  • Connector access
  • Agent actions
  • Model provenance
  • Subprocessors
  • Geographic processing
  • Intellectual property
  • Automated decisions
  • Hallucination
  • Bias
  • Security testing
  • Abuse prevention
  • Availability
  • Model changes
  • Vendor lock-in

AI Vendor Questions

Assess:

  • Is organizational data used for training?
  • Is training disabled by default?
  • How long are prompts retained?
  • How long are uploaded files retained?
  • Who may access prompts?
  • Which subprocessors receive data?
  • Where is data processed?
  • Can retention be configured?
  • Are connectors least privilege?
  • Are actions logged?
  • Can agents perform destructive operations?
  • Are model versions disclosed?
  • Are major model changes communicated?
  • Are security evaluations performed?
  • Is tenant isolation validated?
  • Can customer data be deleted?
  • Are outputs owned by the customer?
  • How are abuse and prompt injection addressed?
  • How are AI incidents reported?

AI Connector and Agent Risk

Assess:

  • Connected systems
  • Read permissions
  • Write permissions
  • Administrative actions
  • Credential storage
  • User consent
  • Data retrieval scope
  • Action confirmation
  • Logging
  • Revocation
  • Indirect prompt injection
  • Output validation
  • Human approval

Fourth-Party, Concentration, and Jurisdictional Riskprotected

Fourth-Party Risk

Fourth parties are subcontractors or dependencies used by the primary vendor.

Assess:

  • Material subprocessors
  • Cloud providers
  • Support providers
  • Data-processing vendors
  • Development vendors
  • AI model providers
  • Content delivery networks
  • Identity providers
  • Payment processors
  • Critical software dependencies

Fourth-Party Controls

Require or assess:

  • Disclosure
  • Change notification
  • Due diligence
  • Contract flow-down
  • Security requirements
  • Privacy requirements
  • Incident notification
  • Geographic restrictions
  • Termination rights
  • Audit rights
  • Concentration risk

Concentration Risk

Concentration may arise when:

  • Many services depend on one cloud provider
  • Multiple critical vendors use the same subprocessor
  • One identity provider supports all critical services
  • One telecommunications provider supports all sites
  • One managed service provider has broad access
  • One software library is embedded across many systems
  • One AI model provider supports several products
  • One geographic region hosts critical workloads

Geographic and Jurisdictional Risk

Assess:

  • Processing countries
  • Storage countries
  • Support locations
  • Subprocessor locations
  • Government-access risk
  • Sanctions
  • Export controls
  • Political instability
  • Natural hazards
  • Legal enforceability
  • Privacy restrictions
  • Cross-border transfer mechanisms

Resilience, Viability, and Incidentsprotected

Business Continuity and Resilience

Assess:

  • Business impact analysis
  • Recovery time objective
  • Recovery point objective
  • Backup
  • Geographic redundancy
  • High availability
  • Disaster recovery
  • Test frequency
  • Test results
  • Crisis communications
  • Capacity planning
  • Dependency mapping
  • Cyber recovery
  • Manual workaround
  • Customer prioritization

Vendor Continuity Testing

Review:

  • Test date
  • Scenario
  • Scope
  • Participants
  • Recovery achieved
  • Recovery time
  • Recovery point
  • Deficiencies
  • Corrective actions
  • Retest
  • Customer involvement

A plan without testing provides limited assurance.

Financial and Operational Viability

Consider:

  • Financial stability
  • Ownership changes
  • Bankruptcy risk
  • Staffing changes
  • Product discontinuation
  • Support reduction
  • Acquisition
  • Regulatory action
  • Litigation
  • Insurance
  • Dependence on funding
  • Customer concentration
  • Geographic concentration
  • Key-person risk

This review may require finance, legal, procurement, and business leadership.

Cyber Insurance

Review where relevant:

  • Coverage amount
  • Policy period
  • Insurer
  • Major exclusions
  • Ransomware coverage
  • Privacy coverage
  • Technology errors and omissions
  • Notification
  • Subcontractor coverage

Insurance does not replace security controls.

Incident Response Review

Assess whether the vendor has:

  • Incident response plan
  • Defined roles
  • Escalation
  • Forensic capability
  • Evidence preservation
  • Legal coordination
  • Customer communication
  • Regulatory process
  • Tabletop testing
  • Lessons learned
  • Ransomware playbook
  • Supply-chain incident process

Incident Notification

Contract requirements may address:

  • Notification deadline
  • Initial notification
  • Known versus suspected incident
  • Required content
  • Ongoing updates
  • Root-cause report
  • Indicators of compromise
  • Affected data
  • Affected systems
  • Containment
  • Cooperation
  • Regulatory support
  • Customer communication
  • Final report

"Without undue delay" may be insufficient for critical services unless paired with a defined maximum.

Incident History

Review:

  • Public breaches
  • Regulatory actions
  • Material outages
  • Ransomware
  • Data exposure
  • Software supply-chain incidents
  • Privacy incidents
  • Repeated service failures
  • Litigation
  • Remediation
  • Lessons learned

A past incident does not automatically disqualify a vendor.

The quality of response and remediation matters.

Contractual Controlsprotected

Contractual Security Requirements

Potential clauses include:

  • Security program
  • Compliance obligations
  • Encryption
  • Access control
  • Vulnerability management
  • Secure development
  • Penetration testing
  • Logging
  • Data use
  • Data location
  • Subprocessors
  • Incident notification
  • Cooperation
  • Audit rights
  • Evidence delivery
  • Business continuity
  • Data return
  • Data deletion
  • Insurance
  • Indemnification
  • Liability
  • Termination
  • Transition support

Legal counsel should approve contract language.

Right to Audit

Audit rights may include:

  • Questionnaire
  • Evidence review
  • Independent reports
  • Customer audit
  • Regulatory audit
  • On-site assessment
  • Penetration-test evidence
  • Remediation validation
  • Subprocessor evidence

The practical enforceability of audit rights should be considered.

Security Schedule

A contract security schedule may define:

  • Applicable systems
  • Applicable data
  • Required controls
  • Minimum authentication
  • Encryption
  • Personnel security
  • Logging
  • Incident response
  • Business continuity
  • Subprocessors
  • Testing
  • Reporting
  • Deletion
  • Exceptions

Risk Analysis and Decisionsprotected

Risk Analysis

Risk analysis should consider:

  • Threat
  • Vulnerability
  • Control
  • Likelihood
  • Impact
  • Evidence quality
  • Business criticality
  • Data sensitivity
  • Access
  • Exposure
  • Regulatory impact
  • Compensating controls
  • Contractual protections
  • Detectability
  • Recovery

Residual Risk

Residual risk is the remaining risk after considering:

  • Vendor controls
  • Customer controls
  • Contractual protections
  • Architectural controls
  • Monitoring
  • Insurance
  • Business continuity
  • Data minimization
  • Access restrictions

Residual risk should be:

  • Documented
  • Explained
  • Assigned
  • Approved
  • Reviewed
  • Time-bound where remediation is pending

Risk Scoring

An example model may evaluate:

  • Inherent risk
  • Control effectiveness
  • Evidence confidence
  • Criticality
  • Open findings
  • Incident history
  • Contract gaps
  • Continuous-monitoring signals
  • Concentration risk

Avoid producing a precise score that hides weak evidence.

Remediation

Possible remediation includes:

  • Vendor control improvement
  • Customer-side configuration
  • Reduced data scope
  • Reduced access
  • Stronger authentication
  • Architectural isolation
  • Contract amendment
  • Increased monitoring
  • Shorter review cycle
  • Manual verification
  • Alternate provider
  • Service restriction
  • Termination

Compensating Controls

Examples include:

  • SSO
  • Customer-enforced MFA
  • Network restriction
  • Read-only access
  • Data masking
  • Tokenization
  • Encryption
  • Proxy
  • Session recording
  • File-transfer gateway
  • Limited user population
  • Increased monitoring
  • Manual approval
  • Restricted administrator access
  • Short retention

Compensating controls should be validated, not assumed.

Risk Acceptance

Risk acceptance should include:

  • Risk description
  • Business impact
  • Security impact
  • Privacy impact
  • Evidence
  • Reason remediation is not currently feasible
  • Compensating controls
  • Business owner
  • Security reviewer
  • Privacy or legal reviewer where applicable
  • Approval authority
  • Start date
  • Expiration date
  • Review date
  • Exit condition

Risk Acceptance Authority

Approval level should reflect risk.

Example:

  • Low: vendor owner
  • Medium: department leader and security
  • High: executive risk owner
  • Critical: senior executive or risk committee

Security should advise on risk but should not silently accept business risk on behalf of the organization.

Exceptions

Exceptions should:

  • Be specific
  • Be documented
  • Include compensating controls
  • Have an owner
  • Have an expiration date
  • Be monitored
  • Be reviewed before renewal
  • Be escalated if overdue

Approval Decision

Possible decisions include:

  • Approve
  • Approve with conditions
  • Approve for pilot only
  • Approve with reduced scope
  • Approve temporarily
  • Defer
  • Reject
  • Replace
  • Escalate to executive risk acceptance

Conditional Approval

Conditions may include:

  • Complete SSO integration
  • Enable MFA
  • Close high-risk findings
  • Sign data processing agreement
  • Restrict data
  • Restrict privileged access
  • Complete penetration test
  • Provide assurance report
  • Add incident-notification clause
  • Confirm data deletion
  • Limit deployment to a pilot group

Evidence Confidenceprotected

High

Strong, current, independently validated evidence with consistent support.
  • Current independent evidence
  • Applicable service scope
  • Direct technical validation
  • Consistent supporting evidence

Medium

Partial or management-produced evidence with some ambiguity.
  • Partial independent evidence
  • Current management evidence
  • Some scope ambiguity

Low

Vendor assertion or outdated, conflicting, or unvalidated evidence.
  • Vendor assertion
  • Outdated evidence
  • Material scope gaps
  • Conflicting information
  • No validation

Findingsprotected

Each finding should include:

  • Finding ID
  • Vendor
  • Service
  • Domain
  • Severity
  • Risk
  • Evidence
  • Evidence confidence
  • Business impact
  • Security impact
  • Privacy impact
  • Compliance impact
  • Recommended action
  • Vendor owner
  • Vendor contact
  • Due date
  • Status
  • Compensating controls
  • Validation
  • Risk decision
  • Expiration

Finding Severityprotected

Critical

Examples of critical findings.
  • Confirmed active compromise
  • Public exposure of restricted data
  • Unsupported privileged access
  • No viable incident-notification capability
  • Critical unremediated vulnerability under active exploitation
  • Material service with no recovery capability
  • Prohibited data use

High

Examples of high findings.
  • Missing MFA for administrative access
  • Weak tenant isolation
  • No effective termination process
  • Unencrypted sensitive data
  • Material assurance exceptions
  • Long-lived privileged credentials
  • Inadequate subprocessor controls

Medium

Examples of medium findings.
  • Incomplete documentation
  • Limited logging
  • Delayed review cycle
  • Minor contract gaps
  • Partial recovery evidence

Low

Examples of low findings.
  • Administrative improvement
  • Low-risk documentation gap
  • Minor policy inconsistency

Onboarding, Monitoring, and Reassessmentprotected

Onboarding Controls

Before production use, confirm:

  • Contract signed
  • Security requirements included
  • Risk accepted
  • SSO configured
  • MFA enforced
  • SCIM configured where appropriate
  • Administrative roles assigned
  • Logging enabled
  • Data flows approved
  • Integration secrets secured
  • Data minimization applied
  • Vendor contacts recorded
  • Incident contacts tested
  • Business continuity requirements recorded
  • Review date scheduled
  • Offboarding plan documented

Continuous Monitoring

Continuous monitoring may include:

  • External security ratings
  • Domain and certificate changes
  • Exposed services
  • Data breaches
  • Regulatory actions
  • Security advisories
  • Vulnerability disclosures
  • Product end-of-life
  • Ownership changes
  • Financial events
  • Service outages
  • Subprocessor changes
  • Assurance expiration
  • Contract renewal
  • Incident trends
  • News
  • Threat intelligence

Security Ratings

Security-rating platforms may provide useful signals regarding:

  • Exposed services
  • Patch posture
  • Certificates
  • DNS
  • Email security
  • Malware
  • Breach indicators
  • Application security

Limitations include:

  • Attribution error
  • Shared infrastructure
  • Incomplete visibility
  • Lack of internal control evidence
  • False positives
  • Weak service-level specificity

Ratings should trigger investigation, not automatic conclusions.

Event-Driven Reassessment

Trigger reassessment after:

  • Security incident
  • Material outage
  • Acquisition
  • Ownership change
  • New subprocessor
  • New processing location
  • New AI capability
  • Material product change
  • Major integration
  • Expanded data use
  • Privileged-access change
  • Regulatory action
  • Assurance lapse
  • Critical vulnerability
  • Financial distress
  • Contract renewal

Renewal Review

Before renewal, assess:

  • Continued business need
  • Usage
  • Data scope
  • Access
  • Open findings
  • Incident history
  • Service performance
  • Assurance evidence
  • Contract gaps
  • Subprocessor changes
  • Cost
  • Alternatives
  • Exit feasibility
  • Risk acceptance
  • Owner approval

Automatic renewal should not bypass risk review for critical vendors.

Reassessment Frequencyprotected

Tier 1

Example reassessment cadence for critical vendors.
  • Annual full assessment
  • Continuous monitoring
  • Event-driven review

Tier 2

Example reassessment cadence for high vendors.
  • Every one to two years
  • Continuous or periodic monitoring
  • Event-driven review

Tier 3

Example reassessment cadence for moderate vendors.
  • Every two to three years
  • Renewal review
  • Event-driven review

Tier 4

Example reassessment cadence for low vendors.
  • Business-owner attestation
  • Renewal review where appropriate

Offboarding and Exitprotected

Vendor Offboarding

Offboarding should address:

  • Contract termination
  • User access
  • Vendor access
  • API credentials
  • SSO
  • SCIM
  • Service accounts
  • Tokens
  • Certificates
  • Network connections
  • Remote support
  • Data return
  • Data export
  • Data deletion
  • Backup deletion
  • Subprocessor deletion
  • Legal hold
  • Ownership transfer
  • Documentation
  • Knowledge transfer
  • Transition support
  • Final evidence

Data Return and Destruction

Require evidence where appropriate:

  • Data returned
  • Export validated
  • Data deleted
  • Replicas deleted
  • Backups expired or isolated
  • Subprocessors instructed
  • Keys destroyed
  • Certificates revoked
  • Customer tenant closed
  • Deletion certification received

Access Removal Validation

Confirm:

  • Vendor users removed
  • Privileged access removed
  • Remote access removed
  • API access revoked
  • Tokens revoked
  • Certificates revoked
  • Shared secrets rotated
  • Integration accounts disabled
  • Support access removed
  • Physical access removed

Exit Planning

Critical vendors should have an exit plan covering:

  • Alternative provider
  • Data portability
  • Export format
  • Transition time
  • Contractual assistance
  • Knowledge transfer
  • Parallel operation
  • Data validation
  • Technical dependencies
  • Cost
  • Business continuity
  • Security during transition

Concentration and Systemic Risk

Monitor:

  • Vendors used by multiple business units
  • Shared subprocessors
  • Shared cloud regions
  • Shared identity providers
  • Shared software dependencies
  • Shared managed-service providers
  • Geographic clustering
  • Contract renewal clustering
  • Single points of failure

Metrics and Dashboardsprotected

Metrics

Useful metrics include:

  • Total active vendors
  • Vendors by tier
  • Vendors without owners
  • Vendors not assessed
  • Assessments due
  • Overdue assessments
  • Average assessment time
  • Critical vendors assessed
  • Open findings
  • Overdue findings
  • Findings by severity
  • Risk acceptances
  • Expired risk acceptances
  • Vendors with missing assurance
  • Assurance reports nearing expiration
  • Vendors without incident clauses
  • Vendors without deletion requirements
  • Vendors using subprocessors
  • Vendors with privileged access
  • Vendor accounts overdue for review
  • Vendors lacking SSO
  • Vendors lacking MFA
  • Vendors processing restricted data
  • AI vendors
  • Vendors using customer data for training
  • Continuous-monitoring alerts
  • Vendor incidents
  • Time to vendor notification
  • Offboarding completion
  • Data-destruction evidence
  • Concentration risk
  • Business-owner responsiveness

Metrics to Avoid Misusing

Avoid relying solely on:

  • Number of questionnaires completed
  • Average security-rating score
  • Number of vendors approved
  • Number of certifications collected
  • Number of findings created
  • Number of contracts reviewed

These metrics do not necessarily demonstrate risk reduction.

Executive Dashboard

Include:

  • Critical third-party exposure
  • Critical vendors
  • High residual risks
  • Open critical and high findings
  • Risk acceptances
  • Vendor incidents
  • Concentration risk
  • Assurance gaps
  • Contract gaps
  • AI vendor risk
  • Critical vendor resilience
  • Overdue assessments
  • Offboarding failures
  • Major remediation initiatives
  • Business-unit accountability

Operational Dashboard

Include:

  • New intake requests
  • Assessments in progress
  • Assessments overdue
  • Evidence pending
  • Questionnaires pending
  • Findings pending vendor response
  • Remediation overdue
  • Contracts pending security language
  • Risk acceptances expiring
  • Assurance reports expiring
  • Reassessments due
  • Monitoring alerts
  • Vendor incidents
  • Offboarding tasks
  • Data-deletion confirmations
  • Owner escalations

Third-Party Risk Maturity Modelprotected

Level 1 — Ad Hoc

Early, informal program with no complete inventory.
  • No complete vendor inventory
  • Security review after purchase
  • Generic questionnaires
  • No risk tiers
  • Informal risk acceptance

Level 2 — Developing

Basic structures with manual tracking.
  • Basic inventory
  • Preliminary screening
  • Some security reviews
  • Limited contract language
  • Manual tracking

Level 3 — Defined

Risk-based, standardized processes.
  • Risk-based tiering
  • Standard due diligence
  • Evidence review
  • Formal findings
  • Contract requirements
  • Periodic reassessment
  • Offboarding process

Level 4 — Managed

Integrated, monitored, and governed program.
  • Integrated procurement workflow
  • Continuous monitoring
  • Strong evidence validation
  • Fourth-party assessment
  • Risk metrics
  • Executive governance
  • Automated reminders

Level 5 — Optimized

Continuous, predictive, technically enforced risk management.
  • Continuous risk intelligence
  • Dynamic reassessment
  • Concentration-risk modeling
  • Integrated technical enforcement
  • Predictive vendor-risk indicators
  • Automated control validation
  • Measurable residual-risk reduction

Governance and Responsibilitiesprotected

Governance

Define standards for:

  • Vendor inventory
  • Vendor ownership
  • Intake
  • Risk tiering
  • Due diligence
  • Questionnaires
  • Evidence
  • Architecture review
  • Privacy review
  • AI vendor review
  • Software supply chain
  • Fourth-party risk
  • Contract requirements
  • Findings
  • Remediation
  • Risk acceptance
  • Exceptions
  • Monitoring
  • Reassessment
  • Incidents
  • Renewal
  • Offboarding
  • Metrics
  • Program review

Roles and Responsibilities

Third-Party Risk Management is responsible for:

  • Program policy
  • Risk-tiering methodology
  • Assessment workflow
  • Evidence review standards
  • Findings
  • Risk reporting
  • Reassessment
  • Program improvement

Business Owner is responsible for:

  • Business justification
  • Service need
  • Data and access description
  • Vendor relationship
  • Remediation support
  • Renewal
  • Risk acceptance
  • Offboarding

Procurement is responsible for:

  • Intake
  • Commercial process
  • Contract timing
  • Vendor coordination
  • Renewal visibility
  • Approved purchasing channels

Security is responsible for:

  • Security assessment
  • Architecture review
  • Technical findings
  • Compensating controls
  • Monitoring
  • Incident coordination

Privacy is responsible for:

  • Personal-data assessment
  • Processing requirements
  • Cross-border transfer
  • Data processing agreement
  • Privacy incidents
  • Data-subject obligations

Legal is responsible for:

  • Contract language
  • Legal obligations
  • Liability
  • Audit rights
  • Notification
  • Termination
  • Regulatory interpretation

Business Continuity is responsible for:

  • Criticality review
  • Recovery requirements
  • Continuity evidence
  • Resilience testing
  • Exit planning

IT Operations is responsible for:

  • Integration
  • Access
  • Logging
  • Configuration
  • Technical offboarding
  • Data export

Finance is responsible for:

  • Financial viability
  • Concentration exposure
  • Contract value
  • Insurance review where applicable

Responsibility Matrix

CapabilityBusiness OwnerTPRMSecurityPrivacyLegalProcurement
Vendor requestResponsibleConsultedInformedInformedInformedAccountable
Inherent-risk assessmentResponsibleAccountableConsultedConsultedInformedSupports
Security assessmentConsultedCoordinatesAccountableConsultedInformedSupports
Privacy assessmentConsultedCoordinatesConsultedAccountableConsultedSupports
Contract requirementsConsultedSupportsConsultedConsultedAccountableResponsible
Risk acceptanceAccountable business ownerFacilitatesAdvisesAdvisesAdvisesInformed
Continuous monitoringInformedAccountableResponsibleConsultedInformedInformed
Renewal reviewResponsibleConsultedConsultedConsultedConsultedAccountable
OffboardingAccountableGovernsSupportsConsultedConsultedResponsible

Example Environmentprotected

Organization

A 9,000-person regulated enterprise with:

  • More than 1,200 active vendors
  • 180 SaaS applications
  • Microsoft Azure and AWS
  • Multiple managed service providers
  • Outsourced payroll and benefits
  • Customer support providers
  • Cloud-based analytics
  • Artificial intelligence tools
  • Third-party developers
  • Payment processors
  • Critical telecommunications providers

Current State

  • Vendor inventory is maintained by procurement.
  • Security review occurs for some technology vendors.
  • Risk tiers are based primarily on contract value.
  • Questionnaires are sent manually.
  • SOC 2 reports are collected but exceptions are not consistently analyzed.
  • Contract language varies by business unit.
  • Continuous monitoring is limited to external security ratings.
  • Vendor offboarding is informal.
  • AI vendors are not assessed through a distinct process.
  • Several vendors retain local administrator accounts.

Example Executive Findingsprotected

SEC-008-001 — Critical Vendors Are Not Reliably Identified

Severity: Critical

Confidence: High

Evidence: Vendor risk tiers are based primarily on annual contract value rather than business dependency, data sensitivity, access, or replacement difficulty.

Business Impact: Operationally critical vendors may not receive sufficient assessment, continuity review, or executive oversight.

Recommendation: Implement a multidimensional inherent-risk model that separately evaluates criticality, information security, privacy, resilience, and concentration risk.

SEC-008-002 — Vendor Administrative Access Is Not Centrally Governed

Severity: Critical

Confidence: High

Evidence: Multiple vendors maintain persistent local administrative accounts in production systems without central ownership, time limits, or consistent session monitoring.

Security Impact: Compromise of a vendor identity could provide direct privileged access to critical systems.

Recommendation: Inventory all third-party privileged access, require named accounts, MFA, privileged access management, time-bound activation, approval, logging, and periodic review.

SEC-008-003 — SOC 2 Reports Are Collected but Not Analyzed

Severity: High

Confidence: High

Evidence: Reports are stored as evidence, but complementary user entity controls, control exceptions, subservice organizations, and current-period gaps are not systematically reviewed.

Recommendation: Create a formal SOC report review procedure, map complementary controls to internal owners, track exceptions, and obtain bridge evidence where necessary.

SEC-008-004 — AI Vendor Data Use Is Not Understood

Severity: High

Confidence: High

Evidence: Several business units use AI services without documented review of training use, prompt retention, uploaded-file retention, subprocessors, data location, or connector permissions.

Privacy Impact: Confidential or personal information may be retained or processed beyond intended purposes.

Recommendation: Establish an AI vendor assessment, restrict unapproved services, require enterprise terms, validate training and retention settings, and govern connectors and agent actions.

SEC-008-005 — Incident Notification Language Is Inconsistent

Severity: High

Confidence: Medium

Evidence: Many contracts require notification only "without undue delay" and do not define initial information, update cadence, cooperation, or root-cause reporting.

Recommendation: Adopt risk-based incident-notification standards with defined deadlines, required content, continuing updates, cooperation, and final reporting.

SEC-008-006 — Vendor Offboarding Does Not Validate Data Destruction

Severity: High

Confidence: High

Evidence: Terminated vendors are removed from procurement systems, but data return, account revocation, API credential removal, and destruction certification are not centrally tracked.

Recommendation: Implement a formal offboarding workflow with access removal, data export, deletion requirements, subprocessor confirmation, and retained evidence.

Automation Opportunitiesprotected

  • Vendor intake
  • Ownership assignment
  • Risk-tier calculation
  • Questionnaire selection
  • Evidence requests
  • Evidence expiration
  • Questionnaire reminders
  • Initial evidence extraction
  • SOC report control mapping
  • Complementary-control extraction
  • Certificate validation
  • Finding generation
  • Remediation reminders
  • Risk-acceptance expiration
  • Contract-clause comparison
  • External monitoring
  • Incident alerts
  • Renewal review
  • Reassessment scheduling
  • Offboarding tasks
  • Data-deletion confirmation
  • Executive reporting
  • Operational dashboards
  • A mature automated workflow could: receive a vendor request; collect business, data, access, integration, and criticality information; calculate a preliminary risk tier; select the appropriate assessment; request relevant evidence; extract key information from reports; identify scope gaps and exceptions; route specialized reviews to security, privacy, legal, continuity, or finance; generate findings; assign vendor and customer actions; track remediation; calculate residual risk; route approval to the appropriate authority; schedule continuous monitoring; trigger event-driven reassessment; review the relationship before renewal; coordinate technical and contractual offboarding; validate access removal and data destruction; produce executive and operational reporting; and require human approval for material risk decisions.

Pro Tipsprotected

  • Build the vendor inventory before optimizing assessments.
  • Assign a business owner to every relationship.
  • Assess risk before contract signature.
  • Separate business criticality from security risk.
  • Use risk-based questionnaires.
  • Ask only questions relevant to the service.
  • Validate answers with evidence.
  • Review assurance scope carefully.
  • Read SOC report exceptions.
  • Assign complementary user entity controls internally.
  • Track evidence expiration.
  • Require named vendor accounts.
  • Eliminate standing vendor privilege where practical.
  • Minimize data shared with vendors.
  • Review subprocessors.
  • Treat AI vendors as both data processors and technology dependencies.
  • Review model training, retention, connectors, and agents.
  • Include security requirements in contracts.
  • Define incident-notification deadlines.
  • Require expiration for risk acceptances.
  • Monitor critical vendors continuously.
  • Reassess after material changes.
  • Review vendors before renewal.
  • Design the exit before onboarding.
  • Validate access removal.
  • Obtain deletion evidence where risk warrants.
  • Measure residual-risk reduction rather than questionnaire volume.
  • Keep accountable humans responsible for final decisions.

Common Mistakesprotected

  • Assessing vendors after purchase — security review should occur before data, access, or contractual commitment is provided.
  • Tiering vendors by contract value alone — a low-cost vendor may hold highly sensitive data or support a critical process.
  • Sending the same questionnaire to every vendor — assessment depth should reflect the service and inherent risk.
  • Treating questionnaires as evidence — questionnaire responses are assertions unless supported by reliable evidence.
  • Collecting reports without reviewing them — SOC reports, certificates, and penetration tests must be reviewed for scope, exceptions, dates, and applicability.
  • Ignoring complementary user entity controls — the customer may retain critical responsibilities that must be implemented internally.
  • Treating certification as proof of security — certifications provide assurance within a defined scope and period, not universal proof.
  • Treating external security ratings as definitive — ratings are useful indicators but may be incomplete or incorrectly attributed.
  • Ignoring local vendor accounts — local accounts may bypass SSO, MFA, and centralized termination.
  • Allowing permanent vendor privilege — third-party privilege should generally be named, monitored, limited, and time-bound.
  • Ignoring fourth parties — a vendor's cloud provider, model provider, payment processor, or support vendor may materially affect risk.
  • Ignoring AI data use — AI vendors may retain prompts, train on customer data, connect to internal systems, or perform automated actions.
  • Failing to distinguish provider and customer responsibilities — cloud and SaaS risk often depends on customer configuration.
  • Using a single composite score without explanation — a score should not hide criticality, evidence quality, or major control failures.
  • Allowing risk acceptance without expiration — temporary unresolved risk can silently become permanent.
  • Letting security accept business risk — security should advise and document; accountable business leadership should accept residual business risk.
  • Performing continuous monitoring without reassessment — external alerts cannot replace evidence-based periodic review.
  • Renewing automatically — renewal should reconsider need, risk, performance, incidents, findings, and exit options.
  • Offboarding only in procurement — technical access, credentials, integrations, data, and subprocessors must also be addressed.
  • Assuming data was deleted — destruction should be contractually required and validated where risk warrants.
  • Sharing confidential reports unnecessarily — vendor reports may contain confidential security information and should be protected.
  • Letting AI make final approval decisions — AI can organize evidence and identify gaps but should not independently approve, reject, or accept risk.

Security Considerationsprotected

  • Third-party assessments may involve highly sensitive information, including security architecture, vulnerabilities, penetration-test findings, audit reports, incident history, customer data, employee data, contracts, pricing, insurance, financial information, subprocessor details, credentials, integration secrets, proprietary source code, and artificial intelligence configurations.
  • Before using an AI system: remove passwords, tokens, private keys, and active secrets; minimize personal information; mask customer identifiers.
  • Avoid uploading full confidential reports unless approved; use excerpts where sufficient; protect contractual information.
  • Use an approved enterprise AI platform; review retention settings; review model-training settings; restrict generated reports.
  • Follow confidentiality obligations, privacy, and regulatory requirements.
  • AI-generated analysis should not independently determine vendor approval, vendor rejection, legal compliance, regulatory applicability, contract interpretation, breach status, risk acceptance, financial viability, termination, or destructive technical action — these decisions require qualified human review.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Design a Secure Cloud Landing ZoneReview Cloud Security and ConfigurationPrepare a Cloud Workload for ProductionPerform an Enterprise Security AssessmentDevelop an Enterprise Incident Response ProgramBuild a Vulnerability Management ProgramDesign Identity Governance and AdministrationDesign a Zero Trust Security ArchitectureDesign and Optimize a Security Operations Center (SOC)Design an Enterprise Data Protection and DLP ProgramDesign an Enterprise Security Awareness and Human Risk Management ProgramAssess and Improve Enterprise Ransomware Readiness

⚠ Normalization Warnings — 10 for review

  • GROUPING: This ARC-scale doc has ~70 H1 sections. Domain sections were grouped by theme (Program Foundations, Intake/Screening/Tiering, Due Diligence, Evidence Review, Software Supply Chain, Cloud/SaaS/Identity/Access, Data/Privacy, AI Vendor, Fourth-Party/Concentration, Resilience/Viability/Incidents, Contractual Controls, Risk Analysis/Decisions, Onboarding/Monitoring/Reassessment, Offboarding/Exit, Metrics/Dashboards, Governance/Responsibilities) to avoid a flat 70-item list. Group boundaries are editorial judgments — confirm the theme assignments.
  • CLASSIFICATION TO CONFIRM: 'Risk Tiers', 'Evidence Hierarchy', 'Evidence Confidence', 'Finding Severity', 'Reassessment Frequency', and 'Third-Party Risk Maturity Model' classified as body/reference (tiered taxonomies the practitioner consults). Alternative for Risk Tiers/Finding Severity: could be argued as matrices, but they are consulted definitions, not columnar fill-in tools.
  • CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items). Alternative: body/prose.
  • CLASSIFICATION TO CONFIRM: 'Validation Checklist' is unambiguously a checklist tool; its 12 domain sections were mapped to checklist groups verbatim.
  • RESTRUCTURE: 'Primary AI Prompt' and 'Follow-Up Prompts' (2 source H1s, 31 prompts total) combined into one prompt_pack tool. Prompt text is verbatim including original inline bullet formatting (no line breaks were present in extraction between list items); 'when' guidance lines are editorial additions.
  • EXAMPLES: 'Example Environment' and 'Example Executive Findings' classified as body/example (concrete filled-in instances). Findings SEC-008-001 through 006 rendered as HTML with subheads rather than a matrix, preserving the doc's own wording.
  • RESPONSIBILITY MATRIX: The RACI table was preserved inside a body/prose section as an HTML table rather than promoted to a matrix TOOL, because it is a reference RACI the reader consults, not an empty-skeleton fill-in tool. Confirm — could alternatively be a matrix with example_rows.
  • OVERLAY STATS: prompts=31 (1 primary + 30 follow-ups); deliverables=3 (prerequisites-checklist, tprm-prompt-pack, validation-checklist). No separate matrix/template tools were identified in this doc.
  • No standard Quick Wins horizon stated as '0–90 days' in source heading ('Quick Wins: First 90 Days'); mapped to horizon '0–90 days'.
  • AUTOMATION OPPORTUNITIES: the 20-step mature-workflow ordered list was condensed into a single trailing narrative item to preserve it without losing the flat-list format; confirm or restore as separate items.

SEO Block

  • Title tag: Third-Party Security Risk Assessment Workflow | ABME (52 chars)
  • Meta: Assess vendor security risk with evidence, not questionnaires — tier by real dependency, validate assurance reports, and design the exit before onboarding. (155 chars)
  • Schema: HowTo · noindex: false
  • Related: sec-001, sec-002, sec-003, sec-004, sec-005, sec-006, sec-007, sec-009, sec-010, cl-002, cl-008, cl-010
  • Keywords: third-party risk assessment, vendor risk management, tprm, soc 2 report review, vendor security questionnaire, fourth-party risk, ai vendor assessment, software supply chain risk, vendor offboarding, residual risk acceptance, complementary user entity controls, vendor risk tiering
Copied