1. Start from the register, not the questionnaire
A vendor security programme is not a document set. It is an accurate list of who processes your data, what they process, and what happens if they stop. Build that list first; every control you add afterwards has something to attach to.
2. Tier by blast radius
Not every vendor deserves the same review. Tier on the damage a compromise would do — data class, availability dependence, and network reach — and let the tier decide the depth of the review. A design tool with no customer data should not consume the same fortnight as a payments processor.
3. Make the engineering team a participant
The fastest programmes are the ones where the engineer requesting the vendor can see the review’s state without asking. When the queue is invisible, procurement routes around it, and the register you spent a quarter building goes stale in a month.
“Shadow IT is usually a review process that nobody could see the end of.”
4. Write down what “done” means
An audit asks how you decided, not what you decided. A short, boring, written rule — which tier gets which evidence, who may accept residual risk, how long an exception lives — is worth more in the room than any amount of collected paperwork.
5. Rehearse the renewal
Most programmes are built for onboarding and fall over at renewal, because renewal has no procurement request to trigger it. Put the clock in the system on day one and the second year costs a fraction of the first.
About Sarah Jenkins
Sarah leads compliance at Urengi. She spent eight years running third-party risk programmes inside regulated fintechs, and now writes about the gap between what a questionnaire asks and what an audit actually accepts.
