Cybersecurity Across the Automotive Lifecycle: Production, Operational Technology and the Scope Gap

Cybersecurity in an automotive organisation is usually discussed as a technology problem. In practice it is a governance problem first, an operational technology problem second, and a privacy problem throughout. Looking at it across the full lifecycle of a vehicle, from the systems that design and build it to the systems that support it after sale, makes clearer where the real exposure sits and why an existing certificate may not address it.

It begins with governance and culture

Whatever else cybersecurity contains, it contains policies, defined responsibilities and continuous improvement of the system. That is true of an automotive organisation and equally true of one that has nothing to do with vehicles. An organisation without a documented policy, without named ownership, and without a mechanism for reviewing and improving what it does has no cybersecurity posture to speak of, regardless of what technology it has purchased.

This matters commercially as well as conceptually. Customer assessments weight governance heavily, and the absence of a named accountable individual is among the most expensive failures available in them. It is also among the cheapest to correct. In ISO/IEC 27001 terms this is Clause 5 on leadership and Clause 10 on improvement, the part of the standard most often treated as paperwork by organisations that then struggle with everything downstream.

Production: where information security meets the shop floor

Manufacturing operations carry exposure that corporate information security programmes frequently never examine. There is a great deal of software and programming involved in production. There are cryptographic keys. There is firmware flashed into electronic control units on the line. And there is the operational technology of the shop floor itself: the programmable logic controllers, supervisory control and data acquisition systems and human machine interfaces that run the plant. OT security for manufacturing in India sits outside most corporate information security scopes entirely.

The applicable standards here are IEC 62443-2-1 for the security programme and IEC 62443-3-3 for system security requirements and security levels. It is worth being precise about what they do. IEC 62443-3-3 implementation secures the industrial automation and control system. These are not the standards governing the safety of the vehicle itself, which is ISO 26262 for functional safety and ISO/SAE 21434 for cybersecurity engineering of the product. The risks are related but distinct, and conflating IT and OT, or either with product safety, leads organisations to assume a control in one area covers the other.

The exposure on a production line is immediate and commercial. A compromised operational technology environment stops the line, corrupts flashing parameters or process data, or serves as the route into the corporate network. Any of those reaches the customer quickly, which is why a PLC SCADA security assessment increasingly appears within the scope of customer questions.

Post-production: monitoring, response and the product in the field

Once production is complete the risk does not end, and it changes character. Faults in a vehicle in service can affect the safety of the people driving it. That raises the question of what an organisation does when an incident occurs, and how quickly it knows one has occurred at all.

Continuous monitoring of systems in the field is therefore not optional, and neither is a defined response capability. A Product Security Incident Response Team, or PSIRT, is the mechanism. Its requirement derives from ISO/SAE 21434 post-development monitoring and from UNECE R155, which AIS-189 follows, and which require continuous monitoring, threat detection and response after the vehicle is sold.

This should be distinguished from enterprise incident response. ISO/IEC 27001 Annex A 5.24 to 5.28 covers incident management for the organisation: the compromised server, the ransomware event, the leaked file. A PSIRT addresses vulnerabilities in the product in customers’ hands. Most suppliers have neither properly established. They are different capabilities, both are required, and both are inseparable from business continuity, because an organisation that cannot detect or respond cannot recover either.

Software, vulnerability and the systems that hold the information

Most organisational information now sits in software, in cloud services, or on servers, and many manufacturers run their own CRM or ERP connected to those servers. That is where vulnerability management becomes unavoidable rather than theoretical. The attack surface is the software estate, and it changes every time something is updated.

Which makes the software development lifecycle central rather than peripheral. Regular, controlled software updates applied through a defined process are what keep the estate from drifting into exposure. ISO/IEC 27001 Annex A 8.25 to 8.31 covers secure development. For vehicle software specifically, AIS-190 and its software update management requirements, together with ISO 24089, govern how updates are engineered and delivered. Where data sits in cloud environments, ISO/IEC 27017 and ISO/IEC 27018 address the controls and the handling of personal information respectively.

Privacy is not a separate subject

An automotive organisation holds a great deal of information critical both to itself and to the people who use its products. Information security and privacy are interrelated concepts, not sequential ones, and treating them as separate programmes produces duplicated effort and inconsistent answers.

ISO/IEC 27001 provides the management system. ISO/IEC 27701 extends it to privacy information management, and ISO 27701 privacy certification in India is increasingly relevant as DPDP Act compliance for manufacturing companies moves from advisory to expected. The Digital Personal Data Protection Act, 2023, the DPDP Act, is the statutory layer sitting on top of both. These frameworks are complementary by design: ISO/IEC 27701 is written as an extension to ISO/IEC 27001 rather than as a standalone, so an organisation that has done the first has already done much of the second.

Does ISO 27001 cover the manufacturing plant?

This brings the lifecycle back to a practical point. An ISO 27001 certificate is only ever as wide as the scope statement printed on it. An ISO 27001 scope covering corporate information technology does not extend to the shop floor. It does not cover the programmable logic controllers, the supervisory systems, the plant network, or the systems that flash firmware onto electronic control units. An organisation can hold a valid certificate, in good standing, and still carry the exposure that matters most to a customer assessing its ability to keep supplying.

That is not an argument against certification. It is an argument for scoping it honestly, and for treating IT OT convergence security in manufacturing as a scope question rather than a technology question. IT OT convergence security manufacturing programmes fail most often at the scope statement, not at the firewall. The question worth asking of any existing certificate is not whether it is valid but what it actually covers, and whether the answer includes the part of the operation where a stoppage would reach the customer first.

The control families reference and the continuity section cover what an assessment asks for in detail. ISO/IEC 27001 provides the management system and ISO/IEC 27701 extends it to privacy; scope is the question worth settling first. MSCi advises automotive organisations on exactly that. MSCi is a consulting organisation: we prepare organisations for assessment and certification, we do not issue certificates, and we are not an approved or empanelled assessor for any manufacturer. Begin with the free readiness checklist.