Vendor Security Assessment: Questions to Ask Before You Buy

By Grocito15 October 2026

A vendor security assessment is a structured set of questions and evidence requests you use before buying software, to judge how safely a supplier will handle your data and access. Scale the depth to the risk: more scrutiny where the tool holds sensitive data or connects deeply to your systems, and a lighter check for low-risk tools.

Key takeaways

Every software vendor you use becomes part of your attack surface, because their weaknesses can become yours.
Be proportionate: sensitive data and deep access justify deeper checks.
Ask about data handling, access control, encryption, backups, logging, vulnerability management, incident notification, subprocessors and exit.
Independent audit reports or certifications are useful evidence, but they show a defined scope, not that nothing can go wrong.
Take contract points to a lawyer, and treat vague or evasive answers as information.
Review vendors regularly and watch for unapproved tools adopted without checks.

Why is third-party software part of your attack surface?

When you give a supplier your customer data, connect it to your systems or let staff sign in with company identities, you trust their security as well as your own. A breach at a vendor can expose your data, and a poorly protected integration can become a path into your network. You cannot outsource responsibility to customers and regulators, so careful buying is part of protecting your business.

How much due diligence is proportionate?

Match the effort to the risk. Ask:

What data will the tool hold: public, internal, confidential or sensitive?
How deeply does it connect to our systems, and can it change or delete data?
How hard would it be to work without it if it failed?
How many users, and which roles, will it have?

A simple scheduling tool with no personal data needs a quick check. A payroll, CRM, health or finance system, or one that touches your production environment, deserves a thorough review. Our build vs buy framework helps you weigh these decisions.

What questions should you ask?

Company and support

How long has the company operated, and who owns it?
Who is responsible for security, and is there a dedicated contact?
What support channels and response times do you offer?
How do you handle customer complaints and security reports from researchers?

Data handling and location

What data do you collect and store, and why?
Where is data stored and processed, and can we choose?
Who at your company can access our data, and under what controls?
Do you use our data for your own purposes, including training AI models?

Access control, MFA and SSO

Do you support MFA for all users and single sign-on?
Can we define roles and limit what each user sees or does?
Is there an audit of administrator access?
How are accounts and sessions protected?

See authentication, roles and SSO for business apps for what good looks like.

Encryption

Is data encrypted in transit and at rest?
Who manages the keys, and can we bring our own?
How are secrets and credentials stored?

Backups and recovery

How often is data backed up, and where are the backups kept?
Have you tested restoring from backup?
What are your recovery objectives after an outage?
Is there a disaster recovery plan?

Logging and audit

Do you log access and changes?
Can we see activity logs for our account?
How long are logs retained?

Vulnerability management and testing

How do you find and fix weaknesses, and how quickly are serious ones addressed?
Do you perform independent penetration tests, and can you share a summary?
How do you secure your development process and dependencies?

Incident notification

If you suffer a security incident affecting our data, how and how fast will you tell us?
Is this commitment written into the contract?
What information will you provide, and who is our contact?

Subprocessors and sub-contracting

Which other companies process our data on your behalf?
Do you notify us of changes, and can we object?
How do you check their security?

Exit, data return and deletion

Can we export all our data in a usable format?
How long after we leave do you delete it, and do you confirm in writing?
What happens to backups?
What happens if your company is acquired or closes?

Uptime and support commitments

Is there a service level, and what remedies apply if it is missed?
How are planned maintenance and outages communicated?

What evidence should you request?

Ask for documents that back up answers:

Independent audit reports or certifications. Examples include ISO 27001 certification or a SOC 2 report. These show that a defined set of controls was assessed by a third party within a stated scope and period.
A security overview or whitepaper.
A penetration test summary.
Data processing terms and a list of subprocessors.
A sample incident or breach policy.
Business continuity and backup descriptions.

What certifications do and do not prove

They suggest the vendor takes security seriously and has documented processes. They do not prove that the particular product or feature you plan to use is in scope, that controls worked perfectly, or that no incident can occur. Read the scope statement, the date covered and any exceptions, rather than accepting a logo.

What contract points should you discuss with a lawyer?

Laws and contracts vary by country and sector, so get qualified legal advice. Topics to raise include:

Who owns and may use your data.
Data processing terms and where data may be stored.
Breach notification commitments.
Liability and any limits on it.
Audit rights and access to evidence.
Subprocessor changes.
Termination, data return and deletion.
Service levels and credits.

What are the red flags?

Refusal to answer security questions or provide any evidence.
Vague statements such as "we use bank-grade security" with no detail.
No MFA or role-based access.
No clear way to export or delete your data.
No incident notification commitment.
Pressure to sign quickly before you finish review.
Reluctance to name subprocessors or data locations.
Claims of certification they cannot document.

How do you score vendors without false precision?

Skip made-up numbers. Use a qualitative rating for each area, such as meets expectations, partly meets or does not meet, and note the reason and any mitigation. Mark which gaps are deal-breakers for this particular tool. Compare vendors side by side and record the decision, the open risks and who accepted them. A written summary beats a score that pretends to be exact.

How often should you review vendors?

Review at renewal and when something changes: a new type of data, a new integration, an acquisition, a reported incident or a change of subprocessors. Keep a register of vendors with data types, owner, contract dates and last review. Remove access for tools you no longer use. Where a vendor exposes an interface to your systems, also check your own side with the API security checklist for business applications.

What about shadow IT?

Staff often sign up for tools, including AI tools, without telling anyone. Reduce it by making approval quick, publishing a list of approved tools, explaining why checks matter and giving people a place to ask. Your AI usage policy should say which tools may receive company data.

A worked example

Imagine a small clinic group choosing an online booking system. Because it will hold patient details, the manager runs a thorough review. The vendor answers a written questionnaire, shares an independent audit summary and lists its subprocessors. The manager notices that deletion after contract end is not described, and that incident notification has no time commitment. These go to the clinic's lawyer for contract wording, and the clinic sets a reminder to re-review at renewal. A less sensitive tool, such as a free design app with no patient data, gets only a quick check of sign-in options and terms.

FAQ

What is a vendor security assessment?

It is a review of a supplier's security practices before and during a contract. You ask structured questions, request evidence such as audit reports, and judge the risk against what data and access the vendor will have.

What questions should I ask a software vendor about security?

Ask where data is stored, who can access it, how it is encrypted and backed up, how access is controlled, how vulnerabilities and incidents are handled and how you can export and delete your data. Also ask about subprocessors and service commitments.

Does ISO 27001 or SOC 2 mean a vendor is secure?

They are helpful evidence that a defined set of controls was independently assessed. They do not show that every product is in scope or that incidents cannot happen, so read the scope and dates carefully.

How often should I review my software vendors?

Review at each renewal and whenever something significant changes, such as new data types, integrations, ownership or reported incidents. Keep a register so reviews are not forgotten.

Next steps

List the software tools that hold your most sensitive data and rank them by risk. Use the question list above for the top few, request evidence and record the gaps. If you would like help evaluating a tool or building your own software with security designed in, you can contact us.