Before signing with a software vendor, get written answers to twelve questions covering data handling, access control, incident response and what happens when the relationship ends. Most breaches involving third parties trace back to something on this list that nobody asked about, and under GDPR and Turkish data protection law, your supplier's failure is still your obligation to your customers.
This guide is the checklist, what a good answer looks like, and how to tell a real security posture from a marketing page.
Key takeaways
- Their breach is your liability: Processing personal data through a supplier does not transfer responsibility.
- Ask for evidence, not assurance: A certificate, an audit report, or a policy: not "we take security seriously."
- Sub-processors are the hidden surface: Your vendor's vendors also hold your data.
- Exit terms belong in the contract: What is deleted, when, and how you get your data out.
The twelve questions
1. Where is our data stored and processed? Country and region, including backups and any support access from elsewhere. This decides whether the arrangement is lawful before anything else matters.
2. Who are your sub-processors? A current list, and whether you are notified before it changes. Your vendor's analytics, hosting and support tools also touch your data.
3. Is data encrypted in transit and at rest? Expect yes to both. Ask who holds the keys.
4. How is access to our data controlled internally? Role-based access, least privilege, and whether staff access to customer data is logged and reviewed. "Only senior engineers" is not an answer; a logged, reviewable process is.
5. Do you have a recognised certification or audit report? ISO 27001 or SOC 2 Type II are the common ones. Ask for the report rather than the badge, the scope statement matters more than the logo, and a certificate covering only one product is common.
6. What is your incident response process and notification commitment? Under GDPR a controller has 72 hours to notify a supervisory authority. If your processor takes a week to tell you, you cannot comply. Get the notification window in the contract.
7. When was your last penetration test, and can we see a summary? Annual is the norm. A vendor who has never had one is telling you something.
8. How do you handle vulnerabilities in dependencies? Ask about the patching cadence and how a critical vulnerability is handled out of cycle.
9. What is your uptime commitment and what happens when you miss it? A number, a measurement method, and a remedy. Uptime claims without a definition of downtime are marketing.
10. What is your backup and recovery position? Frequency, retention, where backups live, and, the question that matters, when a restore was last tested.
11. Can we export our data, in what format, and how quickly? Test this during evaluation rather than during a dispute. "Contact support for an export" is a warning sign.
12. What happens to our data when we leave? Deletion timeline including backups, and written confirmation. Contracts frequently specify this and vendors frequently cannot do it.
Scale the review to the risk
Not every purchase deserves twelve questions. Match the depth to what the vendor touches.
| Risk level | What the vendor handles | Review depth |
|---|---|---|
| Low | No personal data; isolated tool | Questions 1, 3, 11 |
| Medium | Internal data, some personal data | Full checklist, self-assessment accepted |
| High | Customer personal data, payments, health | Full checklist plus evidence and contractual terms |
| Critical | Core operations; outage stops the business | The above plus references and an exit plan |
Get the contract terms right
The security questionnaire is a filter; the contract is the protection. For anything touching personal data, a data processing agreement should specify the purpose and scope of processing, sub-processor approval, breach notification timelines, audit rights, data residency, retention and deletion, and what happens to data on termination.
Vendors who work with regulated customers have these documents ready. One who treats the request as unusual is telling you they have not been asked before, which is itself a finding.
Read the answers for shape, not vocabulary
Good answers are specific and include limitations. A vendor who says "we encrypt at rest with keys managed in our cloud provider's KMS, and support staff can access customer data only through a logged break-glass process requiring approval" has thought about it.
A vendor who says "security is our top priority" and links to a marketing page has not answered. Neither has one who claims no limitations at all, every real system has trade-offs, and a vendor unwilling to name one is either not technical enough to know or not straight enough to say.
Review it again later
A vendor assessment is a snapshot. Companies get acquired, move regions, change sub-processors and reduce support.
Reassess annually for high-risk vendors, and always after an acquisition or a significant product change. Keep a register of who holds what data, with an owner, because the practical failure is not a bad assessment, it is nobody remembering that a tool signed up three years ago still receives a nightly customer export.
Related guides
- Alongside Software Vendor Security Checklist: 12 Questions to Ask, continue with AI Workflow Automation: Use Cases, Risks, and Roadmap.
- Alongside Software Vendor Security Checklist: 12 Questions to Ask, continue with Admin Dashboard Development: Features, Architecture, and Cost Drivers.
If the work prompted by Software Vendor Security Checklist: 12 Questions to Ask leads to a funded initiative that needs product strategy, design, engineering, or integration support, Discuss Your Platform Foundation.
Ali Boran Gazel