Happy New Year! Many have made plans, goals, and resolutions for 2026 – diet, exercise, business, and finance are just some of the determinations to make personal and professional changes.

While the categories are common, how each of those plays out is completely individual. How one goes about losing weight or getting fit; how much money to save or how much debt to pay off; what certifications need to be made or university classes to take – it all depends on what you want to do, where you want to go, who you are, and who you want to be.

When reviewing vendors, there are almost just as many factors. Are you in a regulated industry? What kind of data do you hold? What’s the maturity of the vendor review process? Public or Private sector? How much revenue is available? What role and risk classification do the potential vendors play in the org? There’s no one-size-fits-all for the vendors, and, therefore, no way to present a single approach to solve the Gordian knot that is third-party management.

However, knowing more about what’s involved can help create a better approach than one had before learning more.

This is NOT a best-practice guide, but I hope the following ideas will help you as you create an AI vendor vetting strategy appropriate to your company.

And just like New Year’s resolutions, having your “Why?” in place is important. Proper vetting of AI vendors better protects your corporate and customer data and reputations. Not protecting these personal, private, and proprietary details could easily land an organization in legal and regulatory hot water, incurring high fines and legal fees.

Disclaimer: I’m not employed by anyone I mention below, nor do I receive any kind of kickbacks, incentives, etc. There are no sponsored links or anything of the kind. Everything I link to is just to provide information.

Main Questions

In short, the main information to get from the vendor includes:

·        Where is the data is going?

o   What and where are the subprocessors?

·        Do they train anything on your data?

o   Many AI vendors train on your data depending on the pricing model. It’s “privacy at a price,” but at least they’re transparent about it (often only in the fine print, unfortunately).

·        What is done to secure the data?

·        What protections are in place for cross-border transfers?

o   Even if it’s transferring just username and email, that could be enough to warrant a DPA (Data Protection Agreement/Addendum) or SCC (Standard Contractual Clause).

An aspect that complicates what matters is that the information, if available, can be anywhere on the vendor’s site. A security statement, the Privacy Policy, DPA, Terms of Service, T7Cs (Terms and Conditions), MSA (Master Subscription Agreement), GDPR/CCPA/CPRA notice, Trust Center. It’s fine that every company has its own site layout - it just makes it tougher when reviewing and assessing when the site designers don’t have security review in mind. Be prepared for a trip on the ethereal highway. There have been several vendors where it was faster to go to ChatGPT or Perplexity and ask “Does ABC have a Trust Center?” and it gives me the URL much faster than it took me not to find it by going directly to the vendor.

Think also about those in your company, your internal customers, coworkers, and employees. What do you need them to tell you so you can make an appropriate review?

·        What is the application being used for?

o   Is it dev? Trial? Production? On your site or in your app?

·        How many people will use it?

o   One department only? Corporate-wide?

·        Would any customer data be involved?

·        Will corporate data be moved?

·        Is there another app already in use that would fulfill the function?

·        Is GenAI involved? If so, to what extent?

·        If there are multiple options, which option is under consideration?

Each organization has its own regulatory, compliance, security, and contractual needs, so apply the above and the following as you see fit.

Keep track of the requests! You don’t want to get caught up in any corporate spitting matches such as “why did you approve this?” Actually, you could easily be caught up in those, but the primary concern is having a good and documented approach and response.

You don’t want to have to vet the same vendor (believe me – there are more vendors than can be kept in memory, especially when they have similar names!). Sometimes, one department doesn’t know that another department already has it, so it could save on licensing, too (and saving money is always a plus for the business).

Have an AI AUP (Acceptable Use Policy) in place to point your company to as a constant reference. As often as possible, point to an authoritative internal source document; this will prevent lots of time with extra typing, lots of time in communicating, and prevent others from using you as the source of info each time.

If you want to get quite technical - both for questions for vendors and for answering your own customers’ questions - the AI questions in the HECVAT is an excellent resource for questions. As of this writing, it’s version 4.1.4. https://www.educause.edu/higher-education-community-vendor-assessment-toolkit

 For internal risk assessment - something you can use yourself or pass to your coworkers to fill out (though you may want to simplify it because of its complexity), this is an excellent spreadsheet from FS-ISAC here: https://www.fsisac.com/hubfs/Knowledge/AI/FSISAC_GenerativeAI-VendorEvaluation&QualitativeRiskAssessmentTool.xlsx

There are innumerable determining factors in what to look for when someone requests the use of AI in your company: How are you yourself going to use it? How will your other departments use it? Will it be used in a cloud instance? Or locally? Is it being tested for inclusion in your product? Or will it just be for educational purposes? What data is going in and through it? Does it need watermarked? Is your industry regulated? What will your customers expect from the product? In what industries do your customers live? These are just some of the options to consider (and we haven’t even touched on what resources you have to obtain, test, and maintain all-the-AI-things).

For many of the AI vendors I’ve reviewed, I’ve noticed a good number who have SOC 2 Type1 or 2, and ISO 27001. Before AI, many vendors didn’t have those. So, at least AI vendors are aware of that. But what’s strangely absent is available and solid documentation on their AI development process and internal AI use. While I’m not often expecting ISO 42001, I’m expecting at least “here’s a solid page about how we develop AI, how we address ethics, etc.” But, often, nothing is available, not even in the SDLC.

Have some idea of what you need from the potential vendor in the form of documentation, and this can be done with a simple matrix (again, this is just a sample, in the hopes that it gives a starting point for your consideration):  

Let’s get into the verbiage-laden details.

Considerations

All of these can be prepended with “as needed” or “where applicable” or “depending on your risk program” or other qualifiers. Keep that in mind when going through each – it’s not all required, and you may user different terminology.

Mapping the Data Landscape

Get a clear picture of where the data lives and moves. The vendor may be able to supply a Data Location Matrix that identifies the geographies, region, and cloud providers used for each data type - raw inputs, processed outputs, and logs. This matrix lets you verify that the storage locations align with your regulatory obligations (for example, there could be a requirement for “Acme Corp. needs EU‑West for GDPR‑covered data”).

This is often revealed in a simple Subprocessors list that shows who it is, where it’s located, and the purpose for data transfer. (hint: when you search, search for subprocessor and sub-processor - people spell things differently.)

Ask for a Data Flow Diagram (DFD) that traces the journey of information from ingestion through transformation, model inference, and any outbound transfers. This is more specific and visual than the Location Matrix. The diagram needs to expose every third‑party sub‑processor (analytics services, AI request processing, backup providers, hosts, storage) so you can confirm they are covered by the same Data Processing Agreement (DPA). If the flow involves cross‑border movement, the vendor should explain which approved mechanisms (Standard Contractual Clauses, Binding Corporate Rules, or adequacy decisions) are in place.

Again, they may only be able to supply subprocessors, and that’s generally fine; at least you know where the data goes. Also, they may not provide such detail and will only provide an overview – not to dodge the issue, but to protect details about their infra.

Understanding the privacy scope is essential. Customers need to classify the data it will handle - personal identifiers, health records, financial details, or proprietary business information - using your company’s data‑classification framework. Verify that the vendor follows the principles of purpose limitation and data minimization, collecting only what is strictly necessary for the AI service, and that a lawful basis or explicit consent is documented for each data category.

You may only get to see the Privacy Policy, perhaps even a DPA. Check both, plus anything like GDPR/CCPA/CPRA and other data privacy and security documents and statements. Make sure you print those and keep them.

Clarify retention and deletion policies. Define explicit retention periods for each class of data, and require the vendor to provide secure deletion methods (such as cryptographic erasure or physical shredding) on contract termination or upon your request. Auditable logs that prove deletion events should be part of the deliverables.

Legal and Contractual Safeguards

You probably need a Data Processing Agreement (DPA) if data travels anywhere other than just within the USA. Treat the DPA as a standalone annex that can be updated without renegotiating the entire contract. It must spell out the precise scope of processing, the security obligations the vendor assumes, a breach‑notification timeline of typically no more than 72 hours (some regulated companies may push for a quicker turnaround, so be ready to negotiate), and the process for approving any sub‑processors. Include clauses that obligate the vendor to assist with data‑subject rights (access, rectification, erasure) and that grant you audit rights. Liability caps should reflect the sensitivity of the data - typically at least the total contract value - and an indemnification provision should cover breaches caused by the vendor’s negligence.

The main point is to give contractual assurance that a customer’s data is transferred securely (meaning, “If you don’t protect our data, we’ll sue you big time”). There’s a misconception that under GDPR or other regulations that data can’t be transferred at all. That’s not the general idea; the general goals are that data transferred is a) transferred and handled properly, b) customers know as precisely as possible what data is transmitted, and c) customers know where it all goes.

This usually falls under the authority of someone who has contract signing authority, such as the Legal department or C-Suite function; it’s often beyond the scope of someone doing vendor management to sign. But the ones handling vendor management are in the middle and need to know the process.

Demand evidence of industry certifications that match your sector’s expectations. At a minimum, look for ISO 27001 (information‑security management) or SOC 2 Type II (service‑organization controls). Depending on the data you’ll be sharing, additional attestations such as ISO 27701 (privacy), PCI‑DSS (payment data), or a HIPAA Business Associate Agreement (health data) may be required. If your organization follows emerging AI‑specific frameworks - such as ISO 42001 for AI risk management - ask the vendor to demonstrate alignment.

Unless you absolutely have to, don’t combine “please provide your SOC 2 Type 2 report, ISO 27001 certificate, AND then answer these 300 questions that we could answer if we actually read the documents.” That greatly prolongs the pre-engagement phase of the procurement process. SOC 2 Type 2 and ISO 27001 - while not an ongoing assessment of vulnerabilities – when done by good auditors are rigorous assessments and attestations of the proper functioning of security controls and an infosec management system.

Minimum Security Measures

Not everyone is able to spend money on SOC2, ISO, or other standards. But there should be documentation available, even if it’s by being able to request it via a contact on the site. Because GenAI and other AI services are so new, many vendors are small in staff size, rather new to the business/security/vendor review game, and are focused on providing the services rather than having a full-service site. An encouraging trend I’ve noticed over the last few years is that vendors I re-review have an improved site, so there’s maturity in that area.

Security starts with encryption. There’s hardly anybody who doesn’t transfer data via HTTPS/TLS, but it helps to make sure (just search for data leak and breach occurrences due to lack of foundational security to reinforce the idea that one needs to cover the bases). All data at rest should be protected with AES‑256 or stronger algorithms, while data in motion must travel over TLS 1.2 or higher (TLS 1.3 is preferred). Keys should be managed by a dedicated hardware security module (HSM) or a reputable key‑management service such as AWS KMS or Azure Key Vault.

Vendors should implement strict identity and access management (IAM) based on the principle of least privilege. Every user and service account should receive only the permissions required for its function, and privileged access must be guarded by multi‑factor authentication. Regular access‑review cycles should be in place to prune stale privileges.

Security should be baked into the software development lifecycle (SDLC). Vendors should integrate static and/or dynamic application security testing (SAST/DAST) into continuous integration/continuous deployment (CI/CD) pipelines, and schedule regular penetration tests against inference APIs and model‑serving infrastructure. A public bug‑bounty or vulnerability‑disclosure program adds an extra layer of scrutiny.

Comprehensive monitoring and logging needs to be in place. Audit logs should be immutable for every data‑access event, model‑training job, and inference request, and feed them into a security information and event management (SIEM) platform that can generate real‑time alerts for anomalous behaviour. Retain logs for a period that satisfies regulatory mandates (e.g., 90 days for GDPR).

Speaking of inference requests, find out a) what is logged, and b) who sees it. These should be in line with what’s allowed contractually to protect privacy of employees and customers.

The vendor must maintain a documented incident‑response (IR) plan with clearly defined escalation contacts and response timelines. Evidence of at least a regular TTX is a bonus!

Clear backup and disaster‑recovery capabilities are also required. Be aware that cloud-hosted services in general don’t have backup tapes. I’ve seen so many questionnaires that insist on backup tapes. Perform daily encrypted backups stored in a geographically distinct region, and make sure the recovery‑time objective (RTO) recovery‑point objective (RPO) meet your org’s requirements.

Verify physical security of the data centers hosting the AI workloads. Look for certifications such as SOC 2 Type 2, ISO 27001, and on‑site controls like biometric access and 24/7 monitoring. Usually, the AI company is not the same as the host, so you’ll be redirected to the host’s site. Most likely, the AI company can’t share the host’s documentation due to being under an MNDA.

NOTE RE: ATTESTATIONS: Several AI vendors rely only on their hosts attestations yet note on their own site that “We are SOC 2 Type 2 certified and ISO 27001 compliant!” Check closely. This kind of statement may not be purposely misleading, but rather an indication that the vendor isn’t aware of how the attestation game needs to be played.

Your company needs to have a good handle on what it needs for the risk levels. E.g., “for a department to use an AI-something to share notes internally, we just need Privacy Policy, basic security policies, and know where the host is,” whereas, “If we might embed this in our product or use it to make corporate decisions, then we need to see ISO 27001, ISO 27701, ISO 42001, SOC 2 Type 2, and the AI policies.”

Vendor management was complicated before AI. Do what you need to do to vet properly, but don’t make it harder than it has to be.

AI Governance Within the Vendor’s Organization

A mature AI vendor will manage the model lifecycle with version control for datasets, code, and trained weights—using tools like Git combined with DVC or ML flow. Each model release should be accompanied by a model card that outlines its intended use, performance metrics, training‑data provenance, and known limitations. Automated regression testing should be triggered for every new version to guarantee that updates do not degrade accuracy or introduce regressions.

Reality: You may not need a card, and the vendor may not share model cards, but could instead point you to the model’s site for the cards used. But at least expect a solid answer if you ask.

Bias and fairness MUST be actively assessed. Before any model goes live, the vendor should run fairness metrics (e.g., disparate impact, equal‑opportunity scores) on representative test sets. A documented bias‑mitigation plan should be in place, and periodic re‑evaluations -at least annually - must be performed to catch drift or emerging inequities.

For high‑risk decisions, consider asking the vendor for explainability artifacts such as SHAP or LIME visualizations, feature‑importance rankings, and, where feasible, an API endpoint that returns a decision rationale. This transparency helps you satisfy regulatory demands (e.g., GDPR Article 22) and builds trust with end users.

The organization should publish an ethical AI policy that addresses safety, human oversight, privacy, and non‑discrimination.

If the AI solution is mission-critical to your company, you need to have access to the AI ethics policy or statement. Insist on it. If they don’t have it, then it doesn’t mean it’s a bad product - it just can’t be used for a critical solution. You will be asked – even audited – to ensure that your critical vendors are on the up-and-up.

With all the AI madness (remember – “slop” is the Merriam-Webster word of 2025), many AI vendors may have overlooked the need to be upfront about how they treat and approach AI.

You may not have the authority to say Yay or Nay, but make sure that, when applicable, you phrase your recommendations - in a professional way - to say what issues could crop up. With so much uncertainty about AI, you want to cover yourself as much as possible (cautions, date/time stamps, controls needed, implementation guidance, etc.).

Compliance with sector‑specific regulations must be demonstrable. Map AI processes to relevant statutes - GDPR, the upcoming EU AI Act, or industry‑specific rules - and maintain a compliance register that is refreshed with each model release. You need the vendor to demonstrate compliance, but it’s usually only done through their DPA, GDPR/CCPA/CPRA/etc. statements, Terms of Service/Terms & Conditions. And a refreshed compliance register? Not likely that you can get that from each vendor, but your creativity will make it possible to put something together.

If the vendor incorporates third‑party pretrained models, request a license‑compliance matrix and evidence that those external assets meet the same security and privacy standards you expect from the primary provider.

Transparency Through Open Source

Open‑source visibility is a strong indicator of a vendor’s commitment to accountability. If the AI solution’s codebase should is hosted in a public GitHub repo, ensure that your developers and implementers keep an eye on the Issues. That Issues page is public-facing, so criminals will know about the vulnerabilities, too.

Request a Software Bill of Materials (SBOM).

Assess the health of the open‑source community around the project. Active commit frequency, a diverse contributor base, and prompt issue responses are signs of a well‑maintained project; stagnation could indicate abandonment and heightened risk.

How old is the project? If it’s just a few months old, with not many contributors, issues, or responses, it might not be for you. This doesn’t mean that it’s bad, but if your org is counting on a good reputation, then having a brand new vendor may harm your reputation. The project could well be worth bookmarking and revisiting later on.

 Practical Vetting Checklist

1. Data Mapping – Obtain a Data‑Location Matrix, a detailed Data‑Flow Diagram, and a data‑classification report. Keep signed copies of these artifacts for audit purposes.
2. Legal Review – Secure the DPA, the URL to the vendor’s trust center, and copies of all relevant certifications (ISO 27001, SOC 2, etc.).
3. Security Audit – Request the most recent penetration‑testing report and the scope of the vendor’s ISO 27001 Information Security Management System.
4. AI Governance – Collect model cards, bias‑audit results, and the vendor’s AI ethics policy. These documents should be version‑controlled and regularly refreshed.
5. Open‑Source Transparency – Verify the public repository link, examine the issue backlog, and obtain an SBOM for the current release.
6. Ongoing Monitoring – Establish a quarterly review cadence for security and compliance, and define key‑performance indicators such as the percentage of issues resolved within 30 days.
7. Exit Planning – Confirm the procedures for data return and secure deletion at contract termination, and obtain a certification of completion once the process is executed.

A Plea to AI Vendors

AI vendors, please help ease the path of prospects and customers reviewing your product. I know the Privacy Policy is always at the bottom of a website for a reason – many people are only concerned with how a product operates. Yet more security, IT, Dev, and Engineering teams are tasked with ensuring more than just a good UX.

It’s surprising after all these years and technological innovations that there are so many companies that still operate slower than expect on information transfer. So often, there’s a slowdown somewhere along the way. The internet has gotten faster, automation capabilities are incredible, and the demand for diminishing friction in all areas so that Sales can be lean is at an all-time high. And yet, even many AI companies take days before they respond to a request for security documentation.

Reviews by security and IT teams are increasing, and AI companies need to know that. Until it’s reviewed accordingly, a sale doesn’t happen.

Security and IT teams need to do their part, too! They need to know that they are an integral part of the operations and sales pipelines. So, the process is not always slowed by the potential vendor.

If vendors want to streamline the process, thereby making more sales and money, then it’s critical to transfer that information as quickly as possible

It helps to have a Trust Center. I know – brand-name Trust Centers are expensive; even if done in-house, they’re expensive in the sense of hosting costs and maintenance hours. Even something like  Ally Security’s Trust Center (https://ally-security.notion.site/Ally-Security-Trust-Center-1be299d5994b45bb8c0769a32af33917) is of great value to those of us who have to review apps. It can be a simple and well-structured page.

The individuals reviewing the ever-increasing list of items to ensure their corporate and customer data stays safe face a concomitant increase in what they have to look through. Is the data center noted in the MSA, or the DPA, or the Privacy Policy, or, or…? Where’s the list of subprocessors? What security attestations, if any, do you have? I’ve seen so many that say they have SOC 2 and/or ISO 27001, but there’s no sign of it on their site other than a badge. Often, I resort to ChatGPT or Perplexity to find out if there’s a Trust Center for company ABC. Many times, I only find it via the bots. Be proud of those attestations! They’re expensive – so if you went through it, make it EASY to find them. Sure, you’ll want an MNDA, especially for the confidential information in many of those reports. But make it feasible.

A couple good items to invest the time and effort in are the following free self-assessments:

1.     CAIQ – CSA STAR Level 1

a.     https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4/

2.     HECVAT

a.     https://www.educause.edu/higher-education-community-vendor-assessment-toolkit

ISO 42001 – Artificial Intelligence (AI) Risk Management

What good AI conversation can be had without talking about ISO 42001?

ISO 42001 establishes a system‑wide framework for identifying, assessing, treating, and monitoring risks that arise from the design, development, deployment, and use of AI systems. Its purpose? Help organizations embed responsible AI practices while still being able to reap AI’s benefits. The standard is built around a set of guiding principles that shape every step of the AI‑risk‑management lifecycle.

If a vendor shows the ISO 42001 badge, great! But that’s pricey, so they may say “we are compliant with ISO 42001 principles.” That means that, while they haven’t passed an ISO 42001 audit, at least their AIMS (Artificial Intelligence Management System) is tracking with the international Standards. And that’s a good thing.

While there’s no official chart, below is an unofficial summary of those principles. I hope this chart helps in figuring out what a good AI governance program looks like.

Happy New Year!