Not in the automotive sector? It doesn't matter: two Regulations adopted by UNECE (a United Nations body) on cybersecurity and software updates in the automotive sector may shape your products and services – even if your sector is completely different.
These Regulations provide sector-agnostic lessons on how to approach information security requirements in data protection rules and similar legislation and could be a blueprint for new cybersecurity laws in the future.
Here are some takeaways, from insights into the need for and scope of a cybersecurity management system to detailed lists of threats and mitigation measures. And what better time to put these on your organisation's agenda than the European Cybersecurity Month (and even Cybersecurity Week in Luxembourg)?
Which Regulations?
These Regulations come from the World Forum for Harmonization of Vehicle Regulations, WP.29 (not to be confused with data protection’s “WP29”, the Article 29 Working Party). WP.29 is part of UNECE, the United Nations Economic Commission for Europe (with members well beyond Europe's borders), and it defines various requirements that vehicles, equipment and parts have to meet.
As cars have become computers on wheels, cybersecurity has become a key concern, with many examples of car hacking over the years (from killing a Jeep on the highway to stealing even recent Tesla cars), and the yearly DEF CON hacker convention has featured a Car Hacking Village since 2015.
In addition to the need to address vulnerabilities, these computers on wheels are meant to evolve gradually, with new or refined functionality and bug fixes.
This led to the creation of two UNECE regulations:
- Regulation 155 (Cyber security and cyber security management system), with requirements regarding the cybersecurity management system (“CSMS”) to be put in place by several kinds of vehicle manufacturers, and
- Regulation 156 (Software update and software update management system), with requirements regarding the development, release and maintenance of software updates for an even broader range of vehicles.
The task force working on Regulation 155 in particular overlapped with the industry team working on ISO/SAE 21434:2021. This standard on cybersecurity engineering for road vehicles can therefore be a good reference for technical compliance, as confirmed in the Regulation 155 Interpretation Document endorsed by WP.29.
Regulation 155 requirements will be mandatory for new vehicle types as from July 2022 both in the European Union and in Japan, with the result that many compliance projects are still ongoing (if started). So if your company is in that sector, it may not be too late to start, but it is high time.
Lessons from Regulation 155 (cybersecurity)
Regulation 155 contains many considerations that are useful when considering compliance with other legal requirements in terms of information security. First, it defines a CSMS as “a systematic risk-based approach defining organisational processes, responsibilities and governance to treat risk associated with cyber threats to vehicles and protect them from cyberattacks”. Replace “vehicles” with “assets”, “personal data” or “information”, and a CSMS should be the cornerstone for your company’s cybersecurity approach. Regulation 155 makes the CSMS central to compliance: without a CSMS, a vehicle manufacturer cannot obtain a specific certificate, which in turn means that it cannot place its products on the market. The same idea is present in embryonic form in the NIS (Network & Information Security) Directive and its national implementations, and even under the broader data protection rules, given that inadequate cybersecurity can make an entire processing activity unlawful and lead to fines as well as an order to stop the processing activity.
Lesson: having a good cybersecurity approach can be crucial to the quality of products or services and sometimes even to the right to place them on the market. Companies must devise a global cybersecurity strategy, and document it. Our article on How to explain the legal aspects of cybersecurity to the Board of Directors may come in handy.
Next, just having a CSMS at one point in time is insufficient – the vehicle manufacturer must demonstrate to the approval authority that the CSMS applies to three phases of the vehicle lifecycle: development, production and post-production (i.e. between end-of-production and end-of-life). In addition, CSMS certificates of compliance are valid for maximum three years, and a new assessment is required prior to renewal. Just like data protection must be taken into account from the design phase until the end of a processing activity, cybersecurity is a continuous process that requires review.
Lesson: ensure that your company’s cybersecurity approach applies to the entire lifecycle of the product or service, and that there are processes in place to keep on (re-)evaluating the overall risk level as well as specific threats even after a particular product or service ceases to be provided. Given that new regulatory requirements can impact the level of risk, (in-house or external) lawyers should also be involved in such reviews.
In Regulation 155, the CSMS requirements apply to the vehicle manufacturer, not directly to its suppliers, but vehicle manufacturers must “demonstrate how their [CSMS] will manage dependencies that may exist with contracted suppliers, service providers or manufacturer’s sub-organizations”, and must “identify and manage, for the vehicle type being approved, supplier-related risks”. This rule is slightly more detailed than the “due diligence” obligation found in Art. 28(1) GDPR regarding the selection of processors, but the overarching principle is similar: the principal can often be held liable for the actions of the service provider. This leads to imposing security obligations on suppliers through a contract.
Lesson: even if your company is not involved in the building of a particular component or the provision of a specific service, it must check (within reason) that its supplier or subcontractor acts responsibly in relation to information security. Build such verifications into a supplier onboarding process or consider a contract negotiation playbook.
There are also requirements on risk identification and mitigation. The CSMS must cover notably processes for identifying risks, with 32 examples of threats being listed in an annex to Regulation 155, and there must be processes to assess, categorise and handle those risks and to “ensure that the risk assessment remains current”. In addition, Regulation 155 lists nearly 70 examples of mitigation measures, each linked to a specific threat. These detailed threat and mitigation lists are in stark contrast with the global requirement in most other laws to have “appropriate technical and organisational measures to ensure a level of security appropriate to the risk” (as in Art. 32 GDPR, but see also Art. 14 NIS Directive, Art. 95 PSD2, Art. 4 ePrivacy Directive, etc.).
Lesson: ensure that cybersecurity compliance is not merely left to IT – a multidisciplinary approach (Legal, IT, Business, Communication etc.) is crucial, to ensure that as many risks and mitigation measures are identified and, in the case of mitigation measures, put in place. The detailed approach in Regulation 155 is uncommon today but may be a blueprint for tomorrow’s laws, and these lists should serve as an inspiration for internal risk identification and mitigation efforts.
Regarding incident and vulnerability response, Regulation 155 first looks less strict than data protection rules on personal data breaches or other rules on security incidents. For instance, in terms of timing, it requires mitigation of threats and vulnerabilities “within a reasonable timeframe”. However, authorities will likely use the detailed list of threats and associated mitigation measures when assessing the quality and effectiveness of a manufacturer’s incident response efforts: if one of the listed threats occurs and the suggested mitigation measure is not implemented, this will likely be used against the manufacturer.
Lesson: after preparing a risk assessment, with identification of both threats and mitigation measures, ensure consistency with the incident response plan, so that the company can show that its risk assessment is a good starting point. If needed, ensure that any risk assessment weaknesses discovered during an incident are used as an opportunity to improve. In addition, in the event of an incident, check that the processes put in place are properly observed, to limit the legal risk that could arise from the response itself.
Lessons from Regulation 156 (software updates)
Regulation 156 concerns software updates in general, but is less detailed than Regulation 155.
It requires manufacturers to have various processes and documentation in place, in particular as regards the impact of updates on (i) the safe operation of the vehicle (i.e. the product) and (ii) market approvals, the need for notifications to users regarding updates at their request and finally the security of the process for deploying updates. Some of these can be very relevant if your company provides software internally or externally, irrespective of the sector.
On the first point, Regulation 156 essentially requires manufacturers to determine the impact of a software update prior to its deployment. For instance, if an update changes a vehicle system, it may have an impact on the approval granted in relation to that system; likewise, if an update affects any other system required for the safe and continued operation of the vehicle, it is crucial for the manufacturer to make this determination before the update is deployed. Moreover, as indicated hereunder, users have to be informed of changes, so determining the impact also helps ensure transparency.
Lesson: build assessments into an update process, as even in other sectors failure to anticipate the impact of an update (and to inform users – see below) could facilitate claims for damages regarding the direct consequences of the update.
On software update notifications, Regulation 156 states that there must be a process “whereby the vehicle user is able to be informed about updates”, and that this information must include (a) the purpose of the update, (b) any changes implemented by the update on [vehicle] functions, (c) the expected time to complete execution of the update (in other words: installation time), (d) any [vehicle] functionalities which may not be available during the execution of the update and (e) any instructions that may help the [vehicle] user safely execute the update.
Lesson: transparency is key. Operational teams must pay attention to the need to manage user expectations and avoid a situation that could lead to a complaint or to liability, and being transparent can strongly help here.
Finally, Regulation 156 requires manufacturers to ensure that update processes are secure (i) to (reasonably) prevent manipulation before the update process is initiated and (ii) to (reasonably) prevent them being compromised, including development of the update delivery system. In addition, it is crucial to ensure that “[t]he processes used to verify and validate software functionality and code for the software used in the vehicle are appropriate”. In other words, malicious actors should be kept out of the development and deployment process of software updates.
Lesson: security of a particular software package is not all that matters – security of the update mechanism is just as crucial. Flawed update security can have a significant legal impact, so ensure that processes are secured against such risks.
All in all, Regulation 156 has less sector-agnostic relevance, but it shows points of attention that may appear in future legislation or even in liability-related case law.
The overall lesson? As laws become more technical, a dialogue between legal and technical teams is no longer just best practice; it becomes a necessity. If they do not speak the same language, be sure to bring in outside help!
