The questionnaire you get from your customer exists because the law obliges them to assess their supply chain. That same logic runs on: your system administrator, your software vendors and your cloud providers are your chain, and a customer who digs deeper wants to know whether you have that side in order too.
Where do I start: who are my suppliers, actually?
With a supplier register. Per party: which service do they provide, what access do they have to your systems, which data do they touch, and which contract sits underneath. The party most often forgotten is the one with the most access: the IT administrator who can reach everything.
Such a register is an afternoon's work and immediately answers a question that appears on virtually every customer questionnaire.
Which agreements belong in a supplier contract?
Three topics: incident reporting (does the supplier report to you, and within what deadline), access control (who may get in and how is that kept up to date), and what happens to your data at the end of the contract. For new contracts that is an annex; for existing contracts, renewal is the natural moment to arrange it.
The reporting deadline deserves extra attention. Without that agreement you hear about an incident at your supplier only when it is in the papers, and by then you can no longer make your own 24-hour deadline towards your customers.
How often do I have to assess suppliers?
The law asks for an ongoing process, not a one-off check when the contract is signed. Going through your critical suppliers once a year and recording the outcome is appropriate for most companies. That does not have to be an audit: a short questionnaire or a shared security overview is often enough.
That is exactly what the supply chain register in Ketenpas is for: you invite suppliers to share their passport and see in one overview how your chain is doing, with an export for your accountant or a regulator.
Which suppliers are critical and which are not?
Two questions decide that, and neither is about the size of the supplier. First: does this party have access to your systems or your data? Second: does your service stop if they fail? Two yesses means critical, one yes means attention, two noes means register them and nothing further.
That split saves the most work, because most suppliers sit in the last category. The office stationery shop does not need a security questionnaire; the party managing your servers or processing your customer data does. Put the split in your register, because then your answer to "how do you decide which suppliers you assess" is already written.
What if a supplier will not cooperate?
It happens, especially with large cloud parties who do not answer questionnaires from individual customers. The answer then is not to insist but to use what is already there: their certifications, their audit reports and their public security documentation exist precisely to answer this question in bulk.
If a smaller supplier without such documents keeps refusing, that is itself the outcome of your assessment. Record that you asked, what you did not get, and which risk you are accepting as a result; see risk analysis and security policy. At the next contract renewal that also gives you your negotiating point.
What if I use subcontractors myself?
Then you are your customer's point of contact, and you stay that. The chain does not stop at you: if a subcontractor works on your customer's site or gets access to their data, that is the same risk to your customer as if you had done it yourself.
So arrange two things. Pass the agreements you make with your customer into your own contracts, at the very least the incident reporting deadline and the requirements on access. And say so when you outsource work to a party your customer does not know; more and more contracts contain a consent clause for that, and being found out afterwards is considerably more expensive than saying so beforehand.
What exactly comes up in such an assessment is set out in all ten measures.