Your vendor questionnaire is stale the day you finish it — running TPRM as a continuous loop

The classic vendor assessment follows these steps:

• A vendor list is produced (usually by procurement)
• Each one receives a questionnaire (SIG-Lite, internal template, etc.)
• Responses are collected manually
• A risk score is assigned
• The folder is closed

The questionnaire is true at the moment of answering

A vendor tells you which controls they had in place on the day they answered. Three months later the architecture may change, a sub-processor may be added, a key control owner may leave. The text in the questionnaire still looks correct but is disconnected from reality.

Evidence rots

A SOC 2 report is valid for 12 months, an ISO 27001 certificate for three years. Between renewals the vendor's controls look solid on paper — in practice they may be hollow.

No incident notification

When something breaks at a vendor, it can take weeks for word to reach you — sometimes it never does. The questionnaire asks "had any breach?" on an annual cadence; the actual breach passes you by.

Communication is one-way

Once you have the answers, there's no systematic way to learn that a vendor has added a new sub-processor, changed data centre location, or downgraded a mandatory control.

Standard questionnaires like SIG-Lite, HECVAT and CAIQ are valuable — you can start with industry-accepted questions instead of writing a custom template from scratch. But they draw a baseline by their nature; they do not capture your specific context.

In a mature TPRM program the layers look like:

• Floor (standard questionnaire): SIG-Lite plus a company-specific addendum that includes GDPR Art. 28 / KVKK Art. 9 questions
• Evidence (asset attestation): latest SOC 2, pen-test result, ISO certificate, sub-processor list
• Monitoring (continuous signal): breach disclosure feeds, certificate renewal alerts, sub-processor change notices
• Trigger (event-driven re-assessment): if a critical vendor is named in a public breach, the questionnaire is automatically re-issued

Without these layers the questionnaire becomes a form filled out for the archive.

A classic mistake: "this vendor is critical to us, so they must be high-risk." In fact the two axes are entirely separate:

• Criticality: if this vendor disappears, does your business stop? (Payroll provider, ERP, primary CRM)
• Risk: how maturely does this vendor handle your data and operations? (Certifications, controls, breach history, sub-processor discipline)

A critical vendor — say, a major cloud provider — may be low-risk; a less critical but undisciplined niche SaaS may be high-risk. CenseCloud recommends modeling these as two separate axes, because single-axis ranking misses the small-but-dangerous vendor.

A TPRM process that doesn't go stale runs in four steps — and these are not annual, they form an infinite loop.

Step 1 — Assessment

• The standard questionnaire (SIG-Lite + internal addendum) is sent to the vendor
• Where available, SOC 2 / ISO / pen-test evidence is collected
• KVKK Art. 9 / GDPR Art. 28 / ISO 27036 references are attached to each control

Step 2 — Evidence

• Responses are recorded as claims and don't turn into a score without supporting evidence
• Every piece of evidence carries a validity date (SOC 2 ≈ 12 months, ISO 27001 ≈ 3 years)
• When validity expires, evidence auto-decays and is re-requested

Step 3 — Continuous monitoring

• Notification stream for new sub-processors at the vendor
• Public breach-disclosure feeds
• Certificate renewal and expiration alerts
• Anomaly signals on the vendor's domains

Step 4 — Notify and act

• Decayed evidence, an incoming breach signal, or a control change opens a case
• The case is routed to the right owner — typically procurement and security together
• Action leaves an audit trail

KVKK Art. 9 and GDPR Art. 28 both say the same thing: a personal data breach at a vendor remains under your control. Your role as data controller does not change. The regulator levies the administrative fine on you; the auditor places the vendor's mistake on your desk.

This pattern has played out repeatedly in supply-chain breaches over the last few years. When a major incident becomes public, the audience looks for the brand they recognize — they may not even know the sub-processor's name.

That is why TPRM has to evolve from "fill this out before procurement" into a continuous operational discipline.

CenseCloud models TPRM not as a separate module but as a natural extension of CenseRisk — because vendor risk is a subset of SaaS risk management.

What we deliver in practice:

• Vendor inventory: auto-fed by SaaS discovery; manual addition supported
• Two-axis ranking: criticality and risk modeled independently
• Magic-link external assessment portal: vendors don't need a corporate account to respond
• Automated dispatch: auto_send is opt-in, not default
• SIG-Lite + KVKK templates: firm-specific editing supported; version-locked at send time
• Evidence lifecycle and decay alerts: expired evidence is flagged automatically
• N:N multi-partner model: you can be a customer of one vendor and a vendor of another firm — both relationships live in one inventory

Success in TPRM is not measured by how thick a folder you have filled. Success is being able to answer, in seconds, for each vendor, the auditor's question: "what is the current risk state, what evidence backs it, when was it last refreshed?"

The classic model can't answer because the answer is already frozen on paper. Continuous TPRM keeps the answer current.

For more, see the TPRM solution page→ or the CenseRisk module→.