Rehearse a cyber incident as a vehicle operations problem

A vehicle cyber incident can begin as a backend alert, a supplier report or an unusual workshop observation. The organisation must then connect evidence across systems whose owners have different priorities. A security team may want immediate containment while service operations needs to understand what that containment will do to customers' vehicles.

A useful rehearsal tests those hand-offs. It should examine whether the company can decide, communicate and recover with the information and authority actually available. Reading a response document aloud does not demonstrate that the organisation can operate it.

Choose a bounded scenario

Select an incident scenario appropriate to the architecture, such as suspected misuse of a remote service or compromise of a release account. State what is known at the beginning and what remains uncertain. Avoid a scenario so broad that participants can make any assumption needed to reach a reassuring conclusion.

NHTSA's automotive cybersecurity best practices provide non-binding technical context for lifecycle security and incident handling. They are not UK legal requirements. The rehearsal should remain grounded in the company's own systems, risks and support responsibilities rather than claiming compliance through participation.

Test access to evidence

Ask teams to identify the records they would need and whether they can retrieve them with their ordinary permissions. Include vehicle configuration, relevant service activity and supplier release information. Sensitive evidence should be handled through the organisation's established controls, but it also needs a usable investigation route.

Examine what happens when a service is unavailable or the responsible supplier is outside normal working hours. If the incident depends on one person's knowledge, record that dependency. The exercise should distinguish information that exists somewhere from information that an authorised responder can obtain in time to make a decision.

Make containment a joint decision

Consider the consequences of disabling access, suspending a campaign or isolating a service. An action that contains one threat may interrupt a function or block maintenance. Security, engineering and operations should explain those consequences before the designated authority chooses a course of action.

Record who can authorise containment and who can challenge it with new evidence. Keep a log of the assumptions supporting the decision. As the incident develops, participants need a way to revise the response without losing track of why an earlier action was reasonable.

Carry the exercise through recovery

Do not stop when the suspected attack is contained. Ask how trust is restored, affected configurations are identified and corrective software is verified. Include vehicles that remain offline and customers who seek help before receiving a remote remedy. Those cases connect the cyber response to normal service work.

Convert findings into owned changes with an observable completion criterion. A missing contact requires more than adding a name; the route should be tested. A missing log requires a decision about collection and retention. The rehearsal's value lies in improving the operating system around the vehicle, where small unresolved hand-offs can otherwise become large delays under pressure.