Identifying a cyber risk is the easy part. Cyber risk response is what you do about it — before it materializes, and when it does. This guide covers the four ways to treat any risk, how response differs from incident response, and the case that's becoming the norm: responding when the risk, or the breach itself, sits inside a vendor you don't control.
Cyber risk response is how an organization acts on identified cyber risk — treating it before it materializes (mitigate, transfer, avoid, accept) and reacting when it becomes a live threat, including threats that originate at a third party.
Every identified risk resolves to one of four decisions. This is the strategic layer of cyber risk response, and it applies whether the risk is in your own systems or inherited from a vendor:
It's worth separating two things that share a word. Incident response is the acute reaction to a confirmed security incident — the containment and recovery work covered in our guide to cyber incident management. Cyber risk response is broader: it includes the upfront treatment decisions above, made on risks that haven't materialized yet, as well as the reaction when one does. Incident response is the acute end of cyber risk response; most of the discipline happens before anything goes wrong.
Here's what has changed the shape of the problem: more and more, the cyber risk you must respond to lives in a vendor, not in your own estate. A large share of breaches now reach organizations through a third party. When that happens, your usual response toolkit is constrained in three ways:
All three are decided long before the incident, by preparation. If you already know exactly what each vendor holds of yours — and you've written notification and audit rights into the contract — you can respond in hours. If you don't, you spend the first day just working out whether you're even affected. That preparation is the whole point of sound third-party risk management, and specifically of classifying vendors by what they hold of yours rather than by an external score.
Polestead attaches external breach and exposure signals to the resolved vendor as evidence that feeds review and reassessment — scoped to the vendors that actually hold something of yours, never turned into a public grade a vendor must dispute.
How external signals work →Response isn't only reactive. Between formal reviews, certain signals should pull a vendor back onto your desk: a disclosed breach or ransomware event, a change of ownership, financial distress, a lapsed certification, or new external exposure attached to their resolved identity. The discipline is to treat these as evidence feeding a decision — mitigate, transfer, avoid, or accept — rather than as an automatic alarm. Signals inform the verdict; your own exposure context determines it. That is cyber risk response working as intended: continuous, proportionate, and grounded in what a vendor actually holds of yours.
How an organization acts on identified cyber risk — treating it before it materializes (mitigate, transfer, avoid, accept) and reacting when it becomes a live threat, including threats originating at a third party.
Mitigate, transfer, avoid, and accept. Reduce it with controls, shift its cost, stop the activity, or formally acknowledge and monitor a residual risk within appetite. Every identified risk resolves to one of these.
Confirm what of yours is exposed, invoke breach-notification clauses, assess your own reporting obligations, contain your side by rotating credentials and revoking access, communicate with affected parties, and reassess the vendor afterward. Preparation decides how fast you can move.
Incident response is the reaction to a confirmed incident. Cyber risk response is broader — it includes treating risks that haven't materialized yet, and the response when they do. Incident response is the acute end of it.