The vendor with nothing to assess

Somebody wants a tool. It does one job well, costs very little, and the team has already tried it and likes it.

There is no audit report. No certification. No security page. No obvious company login. No provisioning. No audit log.

At first glance there is nothing to assess. That is not the same as having nothing to say.

You cannot prove what the evidence does not show

A vendor with no independent assurance gives you very little basis for claiming that its security controls have been tested. That should be stated plainly.

The mistake is turning that limitation into either of two conclusions:

• We found nothing wrong, so it is fine.
• They have no certification, so the answer is automatically no.

Neither is much of a risk assessment.

If the evidence is weak, the review has to move from proving the vendor's controls to understanding the exposure created by using the service:

• What will go into it?
• Who will have accounts?
• How would those accounts be removed?
• What evidence would exist after an incident?
• What contractual rights are you accepting?
• How important is the job the product is being asked to do?

Those questions can still be answered.

A refusal can create a different problem

Sometimes the right answer is no. A tool handling sensitive customer data with no meaningful security information may simply be outside the organization's risk tolerance.

But a blanket refusal is not automatically the safest outcome either. When a tool solves an urgent problem and the approval process offers no usable alternative, adoption can move outside the approval process instead.

A company account becomes a personal account. A paid subscription becomes a free tier on somebody's credit card. A visible exception becomes invisible shadow IT.

The review should therefore produce something operational: a yes, a conditional yes, or a no with a specific reason and, where practical, a viable alternative.

A security process that can only say no eventually stops seeing what people are doing.

Make sure you are reviewing the right company

Before assessing anything, confirm who the vendor actually is. This sounds trivial. It is not.

Products with similar names, shared origins or related file formats are easy to conflate. Search results can mix security pages, certifications and documentation belonging to different companies.

Start with the exact product domain. Confirm the legal entity behind it where possible. Then make sure every policy, security statement and certification you find belongs to that organization and product.

A beautiful SOC 2 page from the wrong company is worth exactly nothing.

Read the terms, especially the part about your content

When there is little security documentation, the legal terms are often one of the few substantial documents available. Read the sections covering customer content:

• What rights do you grant the service over material you upload?
• Are those rights limited to operating the product?
• Can content be used to improve the service or train models?
• Can it be sublicensed beyond the parties needed to provide the service?
• What happens after deletion?
• How long can data remain in backups?
• Does the license over your content end when the content or account is removed?

Broad language is not automatically suspicious. A SaaS product needs rights to store, transform and display information simply to work.

The question is whether the grant is proportionate to what you intend to put there. A marketing animation and a customer dataset are not the same decision.

Missing vendor controls become your work

This is where the review becomes useful.

• No SSO means accounts live outside your identity control plane.
• No automated provisioning means somebody has to create and remove them manually.
• No audit log means an incident may leave little evidence of who changed or accessed something.
• No role model may mean everybody receives the same level of access.
• No central administration may mean you cannot even enumerate every account reliably.

These are not findings that magically appear inside the vendor. They become limitations your own environment has to compensate for.

Ten small tools with manual offboarding are not ten small exceptions. They are ten separate account inventories somebody now needs to remember.

That is the cost the free tier does not show.

Data protection belongs in the decision too

If the service will process personal data on your behalf, establish what your privacy and legal obligations require. That may include a data-processing agreement, information about subprocessors, data location, deletion commitments or other contractual terms depending on the data and jurisdictions involved.

Do not turn the absence of a particular document into a universal legal conclusion. Do establish whether the arrangement gives your organization what it needs for this specific use.

If it does not, that is a real reason to restrict the data or reject the service.

A conditional approval needs actual conditions

If the tool is approved despite limited assurance, write down what makes that approval acceptable. Be specific.

Instead of “Do not put sensitive data in it,” define what is allowed. Instead of “Accounts must be reviewed,” name the owner and frequency.

Record how offboarding will work when there is no automated lifecycle. Decide how the organization will know the subscription exists. Set a review date.

Also state what would cause the decision to be reconsidered: wider adoption, a new data type, a security incident, a new enterprise tier, or the vendor later publishing stronger assurance. The weaker the vendor's own control evidence is, the more important those conditions become.

The check worth running

Pick one SaaS tool already being used somewhere in the business that never went through a formal review. Find out who has accounts. Then ask one question:

How would you know if one of those people left the company last month and still had access?

If nobody can answer without asking every user individually, you have already found part of the cost. The vendor review is deciding whether that cost is acceptable and who is going to own it.

Explore this expertise: Security Readiness & Response

All technical notes