Why we're writing here

We already publish a library of third-party risk management guides. They answer stable questions — what TPRM is, what SOC 2 CC9.2 asks for, how to run vendor due diligence — and we revise them as frameworks change. That library is not going anywhere.

This is for the other kind of writing: the things that are true on a particular date.

What goes here

Three kinds of posts, roughly.

Findings from assessments. We run vendors through the same pipeline every day, and patterns surface that no single report makes obvious — categories of vendor that cluster at a given risk tier, certification claims that resist independent verification, whole classes of subprocessor disclosure that simply do not exist. Individual reports answer "is this vendor safe." Aggregate patterns answer "what should I expect before I look."

Methodology changes. When we add a data source, change how the rule engine weighs evidence, or adjust what counts as independent verification, that changes the output of every assessment run afterward. If you are relying on our reports as audit evidence, you should be able to read what changed and when.

Regulatory commentary. DORA, the OCC guidance, CMMC — the rules governing vendor oversight move, and the practical question is never "what does the text say" but "what do I now have to put in the evidence file."

What does not go here

Anything evergreen. If a piece of writing will still be accurate and useful in two years with light edits, it belongs in TPRM Resources, not in a dated post. That line matters for more than tidiness — we have a large body of reference content targeting these topics already, and publishing near-duplicates on a second URL would put our own pages in competition with each other.

The test we apply:

A note on how we write about vendors

Assessment findings are evidence, not verdicts. When we write that a vendor's certification could not be independently verified, that means exactly what it says — the verification path was not available to us. It is not a claim that the certification does not exist. SOC 2 reports are not published to a central registry, so the gap is structural, and the right response is usually to request the report directly rather than to draw a conclusion.

We hold that line in posts the same way we hold it in reports.

Stripepayments · stripe.comView report →

Subscribe

Posts are available over RSS. We do not have a newsletter yet, and we will not add you to one you did not ask for.