Risk
A Day in the Life of a Third-Party Risk Analyst
What vendor risk work actually looks like day to day, from intake and due diligence through evidence review and remediation, and the judgment calls that separate a checklist from real risk reduction.
At 9:10 a procurement manager pings you: legal wants to sign a contract with a data analytics vendor by Friday, and someone told them "risk needs to review it." There is no ticket, no completed intake form, and no clear answer to the one question that decides everything else, what data will this vendor touch? The rest of your day is shaped by how quickly you can turn that vague request into a scoped assessment.
Third-party risk (also called vendor risk or supplier risk) is often described as sending questionnaires and collecting reports. That description misses the actual work, which is deciding how much scrutiny a relationship deserves, then defending that decision when the business wants to move faster than the evidence allows.
Intake and scoping
Nothing good happens without a clean intake. Before you assess anything, you need to know what the vendor does, what data or systems it will access, whether it is business-critical, and whether it subcontracts the work. A payroll processor handling employee bank details is not the same risk as a stock-photo subscription, and treating them the same wastes everyone's time in both directions.
Most of intake is translation. The business describes a vendor in terms of the problem it solves; you have to restate it in terms of data classification, access, and dependency. A "marketing tool" that ingests customer email addresses and behavioral data is handling personal data, whatever the sales deck calls it; whether it is a processor, an independent controller, or a service provider depends on the actual purposes, instructions, and contract. Getting this right sets the assessment tier, which determines how deep you go. Get it wrong and you either over-assess a trivial vendor or wave through one that should have had a security review.
Due diligence and questionnaires
Once scoped, you gather evidence proportionate to the risk. For a higher-tier vendor that means a security questionnaire, independent assurance where it exists (a SOC 2 Type II report or an ISO/IEC 27001 certificate), penetration-test results whose scope, date, and tester independence you verify, and confirmation of things like data residency, subprocessors, breach-notification terms, and business continuity arrangements.
The questionnaire is the least valuable part if you take answers at face value. Vendors answer "yes" to controls they aspire to, and a self-attestation is only as good as the evidence behind it. Your job is to read the answers against the artifacts: does the SOC 2 scope actually cover the service you are buying, or a different product line? Is the report current, or eighteen months stale? Read both the auditor's opinion and the detailed tests of controls and results for exceptions, scope limitations, and subservice organizations the sales team never mentioned. A confident "we encrypt everything" means little next to a report that shows encryption in transit but silence on data at rest.
Evidence review and the judgment calls
This is where the role stops being administrative. Every assessment produces gaps, and almost none of them are clean pass-or-fail. A vendor has a strong security program but no formal subprocessor list. Another has an expired certificate and a plausible explanation about a renewal in progress. You have to decide which gaps are findings, which are acceptable, and which need a compensating control or a contractual commitment before the relationship proceeds.
Good judgment here rests on a few habits:
- Tie every finding to a plausible harm, not just a missing document. "No incident response plan" matters because you cannot rely on timely breach notification, not because a box is empty.
- Distinguish inherent risk from residual risk. A vendor touching sensitive data is inherently high; strong controls can bring the residual risk down to something you can accept.
- Say what would change your mind. If a finding could be closed by one artifact or one contract clause, name it, so the vendor and the business have a concrete path forward.
The pressure is real and constant. The business has a deadline, the vendor is friendly and responsive, and you are the person slowing things down. Holding a defensible line, approve, approve with conditions, or escalate, without becoming an obstacle is the actual skill.
Remediation tracking and closing the loop
An assessment that identifies gaps and then forgets them is theater. The last part of the day is tracking: which findings were accepted, which require remediation, who owns each one, and by when. Conditional approvals need dates and reminders, because a promise to "provide the pen test next quarter" evaporates the moment the contract is signed unless someone follows up.
You also maintain the record. When an auditor, a regulator, or a customer asks why a vendor was approved, the answer lives in your documentation: what you assessed, what you found, what you decided, and why. That trail is often the most durable output of the whole role.
The rhythm repeats, intake, scope, gather, judge, track, but the value is not in running the cycle. It is in the quality of the judgment inside it, and in being able to explain that judgment to someone who wanted a faster answer.