AI Vendor Risk Scorecard for Small Businesses

TL;DR: Use a 100-point AI vendor risk scorecard before an AI tool touches customer data, CRM records, or ad accounts. Verify evidence, apply hard stops, and limit the first pilot instead of trusting a polished demo.

An AI vendor risk review answers one practical question: can this tool do its job without creating a data, security, contract, or operating risk your small business cannot carry? Run the review before you connect a CRM, upload customer files, grant ad-account access, or let an agent act for an employee.

If you searched for an AI vendor risk checklist small business teams can actually finish, the scorecard below is the working version. It also covers the full AI Vendor Risk Checklist for SMB Marketing and Sales Tools use case: lead scoring, email drafting, call transcription, enrichment, chatbots, creative generation, and campaign optimization.

This is an operating checklist, not a compliance certificate. A strong score supports a limited decision for a stated use case; it does not prove that a vendor is safe for every workflow, customer, state, or regulated industry.

What is AI vendor risk for a small business?

AI vendor risk is the chance that an outside AI product mishandles data, exposes an account, produces harmful output, changes without warning, fails at a critical moment, or locks the business into a bad contract. For an SMB, the risk is concentrated because one marketing or sales tool may connect to email, CRM, call recordings, ad platforms, and customer records at once.

NIST says its AI Risk Management Framework is voluntary and is meant to bring trustworthiness into the design, development, use, and evaluation of AI systems. Its July 2024 Generative AI Profile adds risks specific to generative AI. An SMB does not need a governance department to use that logic; it needs a named owner, a bounded use case, evidence, and a decision record.

AI vendor risk rises with the sensitivity of the data, the reach of the integration, and the harm a bad action could cause. Review depth should rise with those three factors rather than with the vendor's brand recognition.

Verizon's 2025 DBIR analyzed more than 22,000 security incidents, including 12,195 confirmed data breaches. Third-party involvement in breaches doubled to 30% in Verizon's 2025 DBIR. The Verizon report covers organizations of many sizes, so those results are a risk signal rather than an SMB-specific probability.

IBM's 2025 breach research adds an AI-specific warning. IBM reported that 13% of studied organizations experienced breaches of AI models or applications. Of the organizations in IBM's study that were compromised through AI models or applications, 97% reported having no AI access controls. IBM's 2025 report was based on data breaches experienced by 600 organizations globally from March 2024 through February 2025. That sample is not representative of US small businesses.

The review should get deeper as the tool gains reach. These six common SMB uses deserve different levels of scrutiny:

• E-commerce creative tools: low risk with public product copy; higher risk when the tool receives customer segments, order history, or ad-account write access.
• Local-service call transcription: higher privacy risk because recordings may contain addresses, payment details, health information, or minors' voices.
• B2B lead enrichment: higher data-provenance risk because the vendor may append personal information from sources you cannot verify.
• CRM lead scoring: higher decision risk when a model changes who gets contacted, ignored, routed, or prioritized.
• Sales email assistants: higher account risk when the tool can read the inbox, send messages, or act through a shared employee credential.
• Customer-facing chatbots: higher output and brand risk when the system can quote prices, make claims, or create service commitments.

That is why AI vendor risk belongs next to your broader AI governance operating plan, not in a forgotten procurement folder.

Treat vendor review as one control inside a wider AI automation plan for small business, with clear owners, boundaries, and human review before scale.

What should an AI vendor risk assessment check?

An AI vendor risk assessment should check the exact data sent, how the vendor may use it, who can reach it, what evidence supports security claims, what the AI is allowed to do, and how the relationship ends. A logo wall, a generic privacy policy, or a salesperson's “we never train on your data” is not enough evidence by itself.

The FTC's small-business cybersecurity guidance tells businesses to put security and data-handling requirements in vendor contracts, verify compliance, limit access, use encryption and MFA, and define retention and deletion. The FTC also warns that an AI service provider's drive to collect data can conflict with privacy and confidentiality commitments, including promises about using customer data for model training.

Ask for an evidence pack before scoring. The pack should include the current contract and data processing addendum, security overview, subprocessor list, retention schedule, incident-notice terms, access-control documentation, audit or assessment evidence, and a plain answer about model training. If a control matters to the purchase, capture the answer in writing and link the evidence in the vendor risk assessment template.

A complete AI vendor risk assessment connects every material answer to evidence, an owner, and a recheck date. Missing evidence stays visible as risk; it does not become a passing answer because the buying team is in a hurry.

The security evidence is one input, not the entire decision. A clean audit report can still leave AI training, prompt retention, model changes, output quality, OAuth scope, and exit rights unanswered.

How should an SMB score an AI vendor?

An SMB should score an AI vendor with weighted controls, written evidence, and hard-stop rules. Give full credit only when the answer is documented and fits the proposed use; give half credit for a partial control with a dated remediation plan, and zero for an unsupported, missing, or unacceptable answer.

The 100-Point SMB AI Vendor Risk Scorecard

This AI vendor risk scorecard turns a long AI vendor security questionnaire into one decision. For each row, mark every listed test as 1 for documented, 0.5 for partial, or 0 for missing or unacceptable. Calculate category score = category weight × earned test points ÷ available test points, then add the six category scores.

Use the spreadsheet columns control, weight, vendor answer, evidence URL, evidence date, score, owner, condition, and recheck date. That structure makes the vendor risk rating auditable and prevents a “yes” answer from receiving the same credit as verified evidence.

Keep the AI vendor risk score attached to its use-case boundary. Reusing a score after adding a new dataset, integration, permission, or autonomous action creates a different decision and requires a new review.

A numeric score does not cancel a hard stop. It also does not replace the build-versus-buy decision: a vendor can be well controlled and still be the wrong economic or operational choice.

Which AI vendor answers should stop a purchase?

Stop or pause a purchase when the vendor cannot give a clear written answer about a control that could expose customer data, credentials, money, or public communications. A high total score cannot offset one unresolved failure that exceeds the business's risk tolerance.

AI vendor risk cannot be averaged away when one failure can expose the entire account or dataset. Treat each hard stop as a separate approval gate with a named owner and dated evidence.

Apply a hard stop when any of these conditions remains unresolved:

1. Training use is unclear. The vendor cannot state whether prompts, files, CRM fields, outputs, or support logs train its models or a subprocessor's models.
2. Deletion is only a promise. The contract gives no retention period, deletion procedure, backup treatment, or confirmation path.
3. Subprocessors are hidden. The vendor will not identify the companies that host, process, label, support, or model your data.
4. Incident notice is missing. There is no written duty to notify your business after a security incident affecting your information.
5. Permissions are excessive. A drafting tool demands full inbox, CRM, admin, or ad-spend access when read-only or narrower scopes would work.
6. Human review cannot be enforced. A tool can send, publish, refund, discount, delete, or change records without an approval gate or reliable rollback.
7. There is no exit. You cannot export needed records, revoke access, delete retained data, or operate during an outage.

The evidence standard should rise with the possible harm. A free tool summarizing public competitor pages may proceed with a short review; an agent that sends sales emails or changes ad budgets should not proceed until the hard stops are closed and human approval gates are tested.

How do you run the vendor risk assessment process with a small team?

A small team can perform the vendor risk assessment process in seven steps with one business owner, one technical reviewer, and outside help only for material security, privacy, or contract questions. Keep the first pass time-boxed, but never time-box away an unresolved hard stop.

1. Write the use-case boundary. Name the owner, users, workflow, systems, data categories, customer impact, and actions the tool may take. “Use AI for sales” is too broad; “draft follow-up emails from five approved CRM fields, with a rep approving every send” is reviewable.
2. Classify the data and impact. Separate public, internal, confidential, personal, financial, health, authentication, and regulated data. Clean up fields before connection; a short CRM data hygiene sprint reduces both exposure and bad model inputs.
3. Send the AI vendor security questionnaire. Ask for concise answers and evidence on training, retention, deletion, subprocessors, encryption, access, logging, incidents, model changes, human review, export, and termination.
4. Verify the evidence. Check report dates, scope, exceptions, product names, contract conflicts, and whether the cited control covers the service you will buy. Do not award full points for a broken link, an expired report, or a certification that covers a different product.
5. Score and decide. Calculate the weighted score, apply hard stops, list conditions, and have the business owner accept the residual risk in writing. “Residual risk” means the risk that remains after controls and limits are applied.
6. Run a limited pilot. Use synthetic or minimized data, a sandbox or separate account, read-only permissions, spending caps, approval gates, and logs. Test wrong outputs, prompt injection, duplicate actions, revoked tokens, outages, and deletion.
7. Sign, monitor, and reassess. Put the accepted claims into the order form, DPA, or security addendum. Recheck after a material model, subprocessor, pricing, contract, integration, incident, or ownership change, and at least annually for a material vendor.

CISA's SMB vendor-assessment guide supports standardized questions for technology purchases. NIST's supply-chain quick-start guide likewise focuses on establishing a supplier-risk process and communicating supplier requirements.

Store the AI vendor risk decision with the evidence, conditions, pilot results, and next review date. That record is more useful than a long questionnaire with no clear owner or outcome.

A realistic AI vendor review

A realistic review often changes the integration more than it changes the vendor choice. The following seven-paragraph example is a That'sGonnaHelp operator composite, not a named public customer claim, and its figures illustrate the review and ROI method rather than promise an outcome.

A US B2B services firm with 18 employees handled about 75 inbound leads per month in HubSpot. Five sales reps spent roughly 20 minutes per lead reading form notes, checking the account, assigning priority, and drafting the first response. The owner wanted an AI assistant to score leads and draft emails from CRM data.

Before review, the proposed vendor asked for broad read-and-write CRM access plus a connected sales inbox. Its website said customer content was protected, but the privacy page, help center, and order form used different language about retention and product improvement. No employee owned the decision, and no one had listed which CRM fields the assistant actually needed.

The team created a one-page data map, removed call transcripts and free-text notes from the pilot, and limited input to company name, source, service interest, company size, and last-contact date. It sent the vendor risk assessment questionnaire, collected the DPA and subprocessor list, and scored the product at 68. Missing deletion evidence and excessive OAuth scope prevented full credit.

The first plan still failed the hard-stop review because the standard integration could update contact records and send email. The vendor then offered a narrower API workflow. The team used a separate HubSpot private app, read-only CRM fields, a test inbox, Zapier for the pilot handoff, and a rep approval step before every message.

During testing, the assistant invented a company-size estimate when that field was blank and occasionally classified partner inquiries as sales leads. The team added a “missing means unknown” rule, excluded partner forms, logged each recommendation, and required manual review. This complication delayed launch by one week but prevented made-up data from entering lead-routing rules.

Over a 30-day illustrative pilot, the composite team processed 82 leads and reduced review-and-draft time from about 20 minutes to 8 minutes per lead. That represents about 16.4 staff hours; at an assumed fully loaded labor rate of $42 per hour, the gross planning value was about $689. After an illustrative $249 monthly tool cost, net monthly value was about $440.

The review, contract check, setup, and testing cost an illustrative $1,700 in staff and specialist time. Dividing that one-time cost by the $440 estimated monthly net value gives a simple payback of about 3.9 months, before any attribution to revenue. The business approved the limited workflow, not blanket access: read-only data, human send approval, monthly log review, and reassessment if the model, subprocessors, or permissions changed.

Cost, ROI, and when the scorecard is not enough

An owner-led low-risk AI vendor review can cost almost nothing beyond staff time, while a sensitive or negotiated deployment may require several thousand dollars of specialist work. Treat the ranges below as That'sGonnaHelp operator planning estimates in USD, not market averages or quotes; check current scope and rates before budgeting.

Use a simple planning formula: monthly net value = hours saved × fully loaded hourly cost + measured gross-margin lift - monthly tool and oversight cost. Then calculate payback months = one-time review and setup cost ÷ monthly net value. Use measured pilot data, not a vendor's best-case ROI claim, and compare the result with a broader automation ROI model.

When it is not a good fit

The scorecard is not enough for three situations. A regulated workflow involving health, finance, children, employment, biometrics, or legal decisions needs qualified counsel and sector-specific controls. A custom model or autonomous agent that can move money, change production systems, or make high-impact decisions needs deeper architecture, security, and evaluation work.

It is also unnecessary to force a 100-point review onto every trivial tool. A product that only summarizes public text, receives no account access, stores no confidential data, and creates no consequential output may need a one-page intake and basic terms check instead. Match review depth to realistic impact.

Common AI vendor risk mistakes

The most common mistake is scoring the vendor's reputation instead of the exact product, plan, use case, data, permissions, and contract the SMB will use. A famous supplier can still have weak defaults, mismatched terms, a new subprocessor, or an integration that asks for too much access.

Treat AI vendor risk as a lifecycle decision rather than a one-time purchasing form. The approved boundary should remain visible to the people who configure integrations and renew the contract.

Avoid these five failures:

• Reviewing after connection. Once real CRM or customer data has flowed, the team has less leverage and may already have a deletion problem.
• Accepting labels without scope. SOC 2, ISO 27001, encryption, and “enterprise-grade” claims do not answer training, retention, AI quality, or integration questions.
• Giving partial evidence full credit. Record the report date, product scope, exception, owner, and remediation deadline.
• Ignoring the pilot boundary. A pilot with production data, admin access, automatic sends, and no logs is a launch wearing a smaller name.
• Forgetting reassessment. Model changes, acquisitions, new subprocessors, new permissions, incidents, and contract renewals can invalidate the original AI vendor risk decision.

The FTC's Amazon and Ring guidance describes allegations involving private recordings, algorithm training, access, retention, and deletion. Preserve that legal status: these were FTC complaint allegations and lessons, not findings this article independently verified.

FAQ

These short answers cover the recurring vendor risk management questions that do not need another full section. They are operating definitions for an SMB review, not legal or compliance advice.

What is AI vendor management?

AI vendor management is the ongoing process of approving, recording, limiting, monitoring, and retiring outside AI products. It includes the initial review, contract conditions, access control, incident handling, performance checks, renewal, and exit.

What is an AI vendor security questionnaire?

An AI vendor security questionnaire is a structured set of questions about data use, model training, retention, deletion, subprocessors, encryption, identity controls, logs, incidents, evaluations, human review, contracts, and exit. Its value comes from evidence and written commitments, not the number of questions.

What is a third party AI risk assessment?

A third party AI risk assessment evaluates the harm an outside AI supplier could cause through its product, people, subprocessors, integrations, data handling, model behavior, outage, or contract. It adds training data use, output risk, model changes, and autonomous actions to a standard third-party vendor review.

Why is third-party risk a concern in AI?

Third-party risk is a concern because an AI tool may combine sensitive prompts and files with broad account permissions, external model providers, and fast-changing behavior. The business remains exposed to customer harm and operational disruption even when the failure begins at a supplier.

How often should an AI vendor be reassessed?

Reassess a material AI vendor at least annually and whenever the model, use case, data, permissions, subprocessors, ownership, contract, pricing, or incident history changes. High-impact tools may need quarterly evidence and access reviews.

Does a SOC 2 report make an AI vendor safe?

No. A relevant, current SOC 2 report can support part of the security review, but it does not prove that every control is effective for your product or answer AI-specific questions about training, retention, outputs, evaluations, permissions, and model changes.

Answer clarity notes

Use the scorecard as planning guidance for a bounded business decision, not as proof of safety, compliance, or guaranteed ROI. The evidence and interpretation limits below should travel with any summary of this article.

• Dates: NIST, CISA, FTC, Verizon, and IBM dates refer to the linked publication or study context; check current vendor pricing, terms, platform rules, and regulations before acting.
• Scope: this article is for US SMB operating decisions, not legal, financial, tax, privacy, cybersecurity, compliance, employment, or platform-policy advice.
• Evidence: public sources support the linked facts; the That'sGonnaHelp case is an operator composite and is not a named public customer claim.
• Study limits: Verizon and IBM findings cover their reported study populations and must not be read as the probability that a particular SMB will suffer a breach.
• Do not infer: costs, labor rates, scores, ROI, payback, timelines, vendor capabilities, and reassessment intervals are estimates or recommendations, not guarantees.
• Decision limit: an 80-plus score supports only the stated use, data, permissions, evidence date, and contract. It does not certify the vendor for every purpose.

Sources

These sources support the public facts and framework choices in the scorecard. Vendor-specific decisions still require current product evidence and contract review.

• NIST AI Risk Management Framework
• NIST Cybersecurity Framework 2.0 supply-chain quick-start guide
• CISA: Assisting SMBs in assessing vendors and suppliers
• FTC Cybersecurity for Small Business: Vendor Security
• FTC: AI companies should uphold privacy and confidentiality commitments
• FTC: Amazon and Ring data-use complaint lessons
• Verizon 2025 Data Breach Investigations Report announcement
• IBM 2025 Cost of a Data Breach report announcement

If you want help turning this scorecard into a review for one marketing or sales tool, That'sGonnaHelp can map the data, permissions, evidence, pilot boundary, and decision record with your team. The result should be a smaller, clearer risk—not a promise that risk disappears.