Most security due diligence on a software supplier is a certification check and a questionnaire. Both are worth something, and both are answered by whoever in the organisation is best at answering questionnaires, a skill unrelated to how the software was built.
These seven questions are harder to answer without having done the work. We are on the receiving end of them often enough to know which ones we would not want to be asked unprepared.
1. How is authorisation enforced, and where?
Not “is there authentication”, because everyone has authentication. Ask where the check that this user may see this record lives. If the answer is “in the frontend” or “in each endpoint, by convention”, that is a tenancy bug waiting for a customer to find it. The good answer names a single layer that every data path goes through, and describes what happens when someone forgets.
2. Where do secrets live, and who can read them?
Follow the API key from where it is issued to where it is used. The answer should include a secret manager, a rotation story, and a plain statement about who on the team can read a production credential. If the honest answer is a short list of names, that is fine. A small supplier with a precise answer is safer than a large one with a vague one.
3. What happens when a dependency has a critical advisory?
Ask about a specific recent one. You are listening for whether they know what is in their dependency tree and how fast a patch reaches production. A supplier who cannot say how long a deploy takes cannot ship a security fix quickly, whatever the policy document says.
4. What is in the logs, and how long do they live?
Two failure modes, opposite directions. Logs full of personal data, retained forever, are a breach waiting to be larger than it needed to be. Logs with nothing useful in them mean nobody can reconstruct what happened. The good answer distinguishes audit trails from debug output and treats them differently.
5. Who has production access, and what does it take to get it?
Access to production is where most real incidents originate, and it is the question certifications cover best, which is exactly why it is worth asking directly rather than reading in a report. Named people, a reason it is that set of people, and what happens when someone leaves.
6. What does a restore actually look like?
Backups are universal; tested restores are not. Ask when the last restore was performed, how long it took, and how much data would have been lost. A supplier who has actually done it will answer in minutes and hours. One who has not will answer in policy.
7. What do we get on the day we leave?
The exit question is a security question. Your data in a usable format, on what timeline, and what happens to the copies. For custom software, add: who owns the code, and can your own engineers run it without the supplier. A vendor whose answer to that is uncomfortable has told you something about the rest of the relationship.
On certifications
None of the above replaces a certification where you need one. Plenty of procurement processes require it, and that is a legitimate reason to insist.
But the two failure modes are worth naming. A certification can be held by an organisation whose product is nonetheless sloppy, because it audits process rather than code. And it excludes small suppliers who build carefully but cannot justify the audit cost, which is most good boutiques. We are in that second group: we build to the standard, we are not certified against it, and we would rather say so than let a logo imply otherwise.