The short answer
Five questions cover most of it: how do users prove who they are, where does the data live, who can reach production, how do you know your dependencies are patched, and what happens if there is a breach. You do not need to evaluate the answers technically. You need them to be specific.
A supplier who answers all five clearly has thought about it. One who answers generally has not.
Authentication and access
- How do users log in, and is multi-factor available for privileged accounts?
- How are permissions structured, and can they be fine-grained enough for your needs?
- What happens when someone leaves your organisation?
- Is there an audit trail of who accessed what?
- Are there any shared accounts, and if so, why?
Shared accounts are the answer to watch for. They are always convenient and they remove accountability entirely.
Where the data lives
| Question | Why you care |
|---|---|
| Which country and region? | Data residency obligations |
| Whose cloud account? | Ownership if the relationship ends |
| Encrypted at rest and in transit? | Baseline expectation |
| Who else can access it? | Subprocessors you inherit |
| How are backups stored and tested? | A backup never restored is a hope |
The second row matters commercially as well as technically. Infrastructure in the supplier's account is a dependency that surfaces at the worst possible moment.
Keeping dependencies patched
Modern software is mostly other people's code, and vulnerabilities are found in it continuously. The question is whether anyone is watching.
A good answer describes automated scanning, a process for acting on findings, and who is responsible. A weak answer is that they use up-to-date libraries, which describes a moment rather than a process.
Breach response
- Who do they tell, and how quickly?
- What logging exists to work out what happened?
- Who is responsible for notifying your customers or a regulator?
- What does the contract say about liability?
- Has the process ever been tested?
Point two is the practical one. Without adequate logging, nobody can tell what was accessed, and the answer defaults to assuming the worst.
Proportionate, not maximal
A small internal tool does not need the controls of a payment system. Asking for everything drives cost without reducing meaningful risk.
Decide what would actually be damaging if it leaked, and spend accordingly. That conversation is more useful than a generic security checklist.