Information Security Risk Management for Automotive Suppliers

Risk management is the part of a management system that most often exists on paper and least often changes what anyone does. The register is populated, colour-coded, occasionally reviewed, and entirely disconnected from how the organisation spends its security budget.

Fixing that is less about methodology than about four specific disciplines.

A method that two people would apply the same way

The test of a risk method is not sophistication. It is reproducibility: if two people assess the same situation independently, do they arrive at comparable results?

Most home-grown methods fail this test, because the scales exist but the definitions do not. "Impact: high" means whatever the assessor felt that afternoon.

What fixes it is unglamorous — written definitions with examples from your own organisation:

• Impact scales anchored to something concrete: production stoppage duration, customer notification obligations, number of records, contractual consequence.
• Likelihood scales anchored to frequency or plausibility, not to intuition.
• Worked examples for at least the middle of each scale, because the middle is where disagreement lives.

Write these down and keep them with the register. Reproducibility comes from the definitions being external to the assessor's head.

Risks that belong to a person

An owner column reading "IT" for forty rows means the register has no owners.

An owner is one named person who can actually influence the risk and who knows they own it. Both halves matter — an owner who was never told is functionally identical to no owner, and an owner without the authority to change anything produces polite escalation rather than treatment.

For risks that genuinely span departments, name one owner and one contributor rather than two owners. Shared ownership is the most reliable way to produce no ownership.

Treatment with a date, and a decision behind it

Every risk above your acceptance threshold needs a treatment action, an owner, and a target date that the owner agreed to.

The four treatment options are conventional and worth stating explicitly, because organisations often use only one: modify the risk, avoid the activity, share the risk, or accept it. Registers that only ever "modify" tend to accumulate actions nobody has capacity for. Accepting a risk deliberately is a legitimate decision; accepting it by not getting round to it is not.

Residual risk that someone accepted

This is the discipline most often missing, and the one that generates the most awkward moment in an assessment.

Risks get identified. Treatment happens. Something remains — it always does. And nobody ever formally accepts it, so the question "who decided this level of remaining risk was acceptable?" has no answer.

The fix costs one meeting per cycle: a dated record showing which residual risks were reviewed, who accepted them, and on what basis. The person accepting needs the authority to accept — which usually means it is not the security manager.

Automotive-specific inputs

Suppliers in the automotive chain have risk inputs that a generic register often misses:

• Customer information under specific handling obligations, where the consequence of mishandling is contractual as well as operational.
• Prototype and pre-series material, where the risk is disclosure ahead of a launch rather than system compromise, and where physical controls matter more than technical ones.
• Production continuity, where a security incident's real cost is line stoppage and the downstream effect on a customer's own production.
• Deep supply chains, where information reaches subcontractors you have no direct relationship with.
• Long-lived engineering data, which retains value far longer than most IT risk models assume.

These are ISAREADY observations from readiness work, not framework requirements. They are worth an explicit pass through your register, because generic threat catalogues do not surface them.

Connecting risk to everything else

A register that is not connected to anything is a register that will not be maintained.

Three connections do most of the work:

Risk to treatment plan to implementation. Treatment actions should be the same actions your improvement plan tracks, not a parallel list.

Incidents to risk. Every incident is evidence about the accuracy of your assessment. If an incident occurs in an area you rated as unlikely, that is information — and updating the register in response is what makes it a live document.

Audit findings to risk. Internal audit findings frequently indicate that a control you relied on in your risk assessment is not operating as assumed.

Reviewing on a cycle, and after change

Define a review cycle and hold to it, and additionally reassess after significant change: a new site, a new major customer, a substantial system change, a significant incident, a change in what information you hold.

A register last modified eighteen months ago tells an assessor — and tells you — something you would rather it did not.

What the evidence looks like

For readiness purposes, the records that demonstrate risk management are: the documented method with its scales and definitions; the register itself with owners, actions and dates; dated residual risk acceptance by an authorised person; and review records showing the register was revisited on the defined cycle.

If you can produce those four, risk management is demonstrable. See our evidence management guide for how that fits with the rest.