This website uses cookies

Read our Privacy policy and Terms of use for more information.

👋 Hey {{first_name|there}},

Six weeks on the failures you don't cause and still have to answer for. This is the last issue in the arc, so I want to put the whole thing in one place and in the right order, because the order turns out to matter more than the individual exercises do.

Why this matters

If you've been following along, you now have six separate exercises, and between them they'd take the better part of a fortnight, which nobody has.

What people actually have is an afternoon and a vague sense that the third-party picture is worse than the diagram suggests. So the useful thing here isn't another instrument; it's knowing which question to ask first, and I'd argue the one to ask is whichever is cheapest to answer and most likely to come back badly.

That's the same logic as killing bad ideas first, applied to exposure instead of roadmaps. You don't work through a risk assessment in tidy sequence and arrive at a verdict, because the expensive questions tend to sit at the front and the disqualifying ones at the back. You ask the cheap disqualifying ones early, and when one of them comes back badly, you stop assessing and go and fix it.

Which is why the first step below is reading something you've already written rather than booking a workshop.

Somebody will eventually ask you where you're exposed to third parties, and the version of that answer worth having is five numbers on one page. Two days across a fortnight gets you there.

🧭 The shift

From: "We should do a proper assessment of our third-party risk."
To: "We should answer the cheapest question that could tell us we have a problem."

Subscribe to keep reading

This content is free, but you must be subscribed to Tech Architect Insights to continue reading.

I consent to receive newsletters via email. Terms of use and Privacy policy.

Already a subscriber?Sign in.Not now