At some point in a technology engagement, somebody from outside your firm gets access to something. A folder, a system, an account, a copy of a file. It usually happens quickly, because by then everyone is keen to make progress and the access is the thing standing in the way.
Five questions are worth settling before that point. They are short, the answers are checkable, and a vendor who has thought about the work will have them ready.
1. Where does the data go
Not "is it secure". That question has only one answer and everybody gives it.
Ask where the data physically ends up. Does it stay inside systems your firm controls, or is it copied somewhere the vendor controls, or does it pass through a third service on the way? If it is processed by a model, whose account is that model running under, yours or theirs?
The reason this matters is that each hop is a place where your client information exists, and your obligations follow it. A firm that can say exactly where client data goes can answer a security review. A firm that assumed it stayed put and was wrong will find out during one.
Ask also whether anything is retained after processing, and for how long. Systems commonly keep inputs for a period for debugging or abuse monitoring, which is a reasonable engineering choice and a thing you need to know about.
2. What gets logged, and can you see it
A log answers the question you will eventually have, which is some version of "who looked at what, and when".
Ask what is recorded when the vendor's people or software access your systems. Ask whether you can read those logs yourself, on demand, rather than requesting them. Ask how long they are kept.
This is the least glamorous of the five and it is the one that matters most if anything ever goes wrong. An engagement with no access log leaves you unable to answer a basic question about your own systems after the fact.
3. Who is on the engagement, and where are they
Firms often assume they are hiring the people in the room. Sometimes that is right.
Ask who will actually have access. Named people, or at least named roles and a count. Ask whether any of them are subcontractors rather than employees, because that changes who has signed what. Ask which country each of them works from.
Location is a real question and not a xenophobic one. Where a person sits determines which laws apply to the data they can see, what your client agreements permit, and what you will have to disclose when a client asks. Some of your clients will have contractual restrictions on this, and the time to find out is before access is granted.
Ask what agreements those people are under. Confidentiality is the obvious one. Assignment of what they produce is the one firms forget, and it is the one that determines whether you own the thing you paid for.
4. What happens when it ends
Every engagement ends. The version where it ends well is one that was described at the start.
Ask what happens to your data in the vendor's possession when the work stops. Deleted on what timeline, confirmed how, and does the confirmation cover backups. Ask what happens to the access itself, which accounts get disabled and who is responsible for disabling them.
Ask what you are left holding. Documentation of what was built, credentials to the systems it runs on, and the ability to keep operating it without the vendor. A system you cannot maintain or modify without the people who built it is a dependency that was created quietly.
Ask the same question about a bad ending. If the relationship fails in month two, the same answers should apply, and they should not require goodwill.
5. What does the vendor do that you would have to disclose
Your clients ask you about your subprocessors. Anyone who touches their data on your behalf is on that list, including a vendor and including the services that vendor uses.
Ask for that list. Ask whether it includes the model providers, the hosting, the storage, the monitoring. Ask how you will be told when it changes, and how much notice you get.
A vendor who maintains this already is a vendor who has been through a security review. A vendor who has never been asked will need to assemble it, and assembling it under time pressure during your client's review is how something gets left off.
Why ask before rather than after
All five of these are answerable after access is granted. They are simply much harder to act on then.
Before access, an unsatisfactory answer is a conversation. After access, it is a remediation project, and the data has already been where it has been.
The other reason is what the asking reveals. A vendor who answers all five without preparation has thought about the obligations your firm operates under. A vendor who treats the questions as an obstacle has told you something useful about what working with them will be like.
We would expect to be asked these, and we would expect to answer them in writing.