Vendor Assessment: A Risk Checklist Before You Integrate Any Service
Every new service connected to a website is not just a feature. It is someone else’s code running on your visitors’ machines, and someone else’s company receiving your data. It connects in five minutes and the consequences stay for years.
Vendor assessment sounds like something for large companies with a procurement department. In reality it is ten questions worth asking before rather than after.
What you are actually connecting
A typical third-party service receives more than it appears:
- Visitor data. At minimum their address and browser, often behaviour and identifiers.
- Permission to execute code. A script on your page can technically do almost anything, including reading what someone types into a form.
- Influence over speed. A slow response from someone else’s server slows your page.
- Influence over availability. If the service goes down, parts of your site may stop working.
The last point is the most underestimated: a failure in a support chat or a reviews widget can break your layout or block form submission.
The assessment checklist
| Area | What to establish |
|---|---|
| Data | What exactly it collects, where it stores it, for how long, whether it trains on it |
| Jurisdiction | Country of processing, whether a region can be chosen |
| Contract | Whether a data processing agreement exists and can be obtained |
| Sub-processors | Who it passes data to further, whether a list exists |
| Reliability | Availability guarantees, incident history |
| Security | Two-factor authentication, roles, audit log |
| Impact on the site | Script weight, whether it loads asynchronously |
| Exit | How to export your data, what happens after termination |
| The company | How long in the market, who owns it, whether support exists |
| Cost over time | What the pricing depends on and how it scales |
This is not a five-page questionnaire. Most answers are in the documentation within twenty minutes, and if they are not, that is itself an answer.
Red flags
- No clear data processing policy, or one written so vaguely you cannot tell what is collected.
- No way to export your data. It means leaving will be expensive.
- No list of sub-processors. You do not know where the data goes next.
- The script demands loading at the very top of the page. That is a direct hit to speed, and usually avoidable.
- Support only through a form with no response times. Test it before buying with a single email.
- Pricing tied to a metric you do not control. Visitor count including bots, for example.
- A young free service with no visible business model. It will either shut down or monetise your data.
What to record in writing
The minimum that protects you in a dispute:
- Which data is transferred and for what purpose.
- Where it is processed and how long it is kept.
- Who else gets access.
- What happens to the data after the relationship ends.
- Response times for incidents and for data requests.
The last point matters particularly: if a deletion request reaches you and the service replies in a month, the deadline missed is yours, not theirs.
After connecting
Assessment does not end here, and this is usually where it falls apart.
- Measure speed before and after. Server response time and page weight. Half a second of difference is a reason to reconsider.
- Verify the service does not fire before cookie consent. Violations most often appear precisely when a new tool is added.
- Add it to your data map. The same system list used for deletion requests and for knowing where everything sits.
- Set a reminder to review in a year. Half the services on a site are no longer needed twelve months later.
Auditing what is already connected
A one-hour exercise that usually delivers the biggest result:
- Open developer tools, the network tab, and look at the list of external domains your homepage contacts.
- For each, answer two questions: what is it and who added it.
- Anything with no answer is a candidate for removal.
In most cases that list contains scripts from three-year-old advertising campaigns, analytics nobody uses, and widgets installed “to have a look”. Each of them slows the site and collects data for no reason.
Vendor assessment pays off not because you will catch a bad actor. It pays off because afterwards you know what your website is made of. That knowledge is needed in every conversation about speed, security and data, and it is almost never there.
