Inside an Automotive OEM Vendor Cybersecurity Assessment: The 19 Control Families and What They Actually Ask For

An OEM vendor cybersecurity assessment is not an audit in the sense most manufacturers understand the word. It is a scored, weighted evaluation issued by a customer, and suppliers to Indian vehicle manufacturers are now receiving them routinely. This article sets out what a vendor cybersecurity assessment format contains, how the scoring works, what evidence is requested, and why suppliers operating reasonable controls still score badly.

Why a supplier information security questionnaire is not a certification audit

A certification audit tests conformity against a published standard and results in a certificate. A vendor assessment tests a supplier against a customer’s own criteria and results in a number. It is comparative, so suppliers are ranked. It is weighted, so checkpoints carry different marks. And it is generally owned by the customer’s supply chain or business continuity function rather than its information technology department, which tells you what the customer is actually worried about.

Governance and culture come first

The instrument opens on governance, and weights it heavily. It asks whether information security is addressed by a documented policy, whether responsibilities are defined and assigned to a named individual within the existing management structure, whether a contact list exists, and whether the policy is reviewed, revised and improved rather than written once.

This is worth stating plainly because suppliers routinely treat governance as preamble and spend their preparation effort on technical controls. The weightings say otherwise. The absence of a named accountable person is among the most expensive single failures in the instrument and costs nothing to correct. Policies, defined responsibilities and demonstrable continuous improvement are the foundation, and they are requirements in any organisation, automotive or not. They map to ISO/IEC 27001 Clause 5 and Clause 10.

The nineteen control families

The families below describe what is asked and the standard each maps to. Annex A references use ISO/IEC 27001:2022 numbering. Fourteen of the nineteen follow the control family structure of NIST Special Publication 800-171, the United States standard for protecting controlled unclassified information in non-federal systems, and the vocabulary travels with it, which is why suppliers in Manesar and Chakan find themselves reading checkpoints about Controlled Unclassified Information. The CUI meaning in supplier assessment documents is simply the customer’s confidential technical and commercial information. The remaining five families address areas that framework does not cover.

• Access Control. Role-based access control, segregation of duties, least privilege, session timeout, remote and wireless access, mobile devices and removable media. Normally the largest family. Annex A 5.15 to 5.18 and 8.1 to 8.5.
• Awareness and Training. Induction and periodic education, defined responsibilities, evidence of effectiveness rather than delivery alone. Clause 7.2 and 7.3, Annex A 6.3.
• Audit and Accountability. Log generation, protection, retention and review, with actions attributable to individuals. Retention commonly specified in months. Annex A 8.15 and 8.16.
• Configuration Management. Baseline configurations, change control with approval records, security impact analysis before implementation, removal of unnecessary functions and ports. Annex A 8.9, 8.19 and 8.32.
• Identification and Authentication. Asset and user inventories, authenticator management, multi-factor authentication, prohibition of shared accounts. Annex A 5.16, 5.17 and 8.5.
• Incident Response. Defined roles, documented procedures, agreed allocation of responsibility with the customer where shared information is involved. Annex A 5.24 to 5.28.
• Maintenance of information security assets. Controlled maintenance, management of maintenance tools and diagnostic media, secure disposal. Annex A 7.10, 7.13 and 7.14.
• Media Protection. Inventory, marking, transport, protection and sanitisation of media, including controls on items carried into and out of the premises. Annex A 7.10 and 8.10.
• Personnel Security. Background verification before access, defined action on termination or reassignment, with scope extending to outside employees including temporary staff. Annex A 6.1, 6.2 and 6.5.
• Physical Protection. Controlled areas, visitor registration, access logging, issue and recovery of access devices, surveillance. Annex A 7.1 to 7.6.
• Risk Assessment. Operational impact assessment, vulnerability scanning, remediation within defined timelines. Clause 6.1, Annex A 8.8.
• Security Assessment. Control effectiveness evaluation, plans of action with milestones, continuous monitoring. Clause 9.1 to 9.3.
• System and Communications Protection. Boundary protection, segmentation, denial by default, cryptography and key management, protection of shared resources. Annex A 8.20 to 8.24.
• System and Information Integrity. Flaw remediation, malicious code protection, monitoring of advisories, handling of customer personal information. Annex A 8.7, 8.8 and 8.16.
• Information Security Certifications. Certifications held, with ISO/IEC 27001 commonly named. A single checkpoint of modest weight, categorised as desirable.
• Data Privacy. Identification and classification of personal data, sensitive and normal categories, safeguards, controller and processor roles. ISO/IEC 27701 and the Digital Personal Data Protection Act, 2023.
• Artificial Intelligence Security. Whether AI systems operate in decision-making processes, whether any run without human oversight, and whether that risk has been formally assessed. Categorised as mandatory. ISO/IEC 42001.
• Data Privacy on Cloud. Personal data processed or stored in cloud environments and approval of services used. ISO/IEC 27017 and ISO/IEC 27018.
• Business Continuity. Continuity plan, recovery point and recovery time objectives, disaster recovery, business impact analysis, drills, management review. ISO 22301. Among the most heavily weighted.

How the scoring works

Checkpoints are divided into mandatory and desirable categories, and the Must Have vs Good to Have distinction determines where remediation effort should go first. Each also carries a weight, so the total is not a count of passes.

Marking runs on a three-point basis. Full marks generally require the name of the internal regulation, the year it was established, and evidence of revision and adoption. Partial marks are available where measures are underway, provided current status and a scheduled completion date are stated. Nothing is awarded where a control is absent. A not-applicable response is available but must carry a reason, and an unjustified one is normally treated as zero.

Two further mechanisms catch suppliers out. The self-assessment score is recorded separately from the assessor’s validated score, so self-declaration is tested against evidence. And an outside-in score may be produced independently by scanning internet-facing infrastructure, without the supplier’s participation. A supplier can be assessed on exposure it was never asked about.

Assessment is followed by a corrective action cycle: an improvement plan against one deadline, supporting evidence against a second, each observation tracked to open, closed or partially closed. These windows are measured in weeks.

What documents does a customer cybersecurity audit ask for

The artefacts requested most consistently are an approved information security policy with proof of accessibility; an access control procedure and RBAC matrix; a segregation of duties matrix; a list of administrator accounts and privileges; sample access request and approval records; an acceptable use policy and a removable media policy; a training calendar with attendance and effectiveness records; network and data flow diagrams carrying title, version, approval and review date; a change management procedure with security impact analysis and an approved change log; a defined log retention period with review records; non-disclosure agreements extending to contractors and third party personnel; and a business continuity plan with recovery objectives, a business impact analysis and a drill record.

Almost every item is a document rather than a purchase.

ISO 27001 vs OEM cybersecurity checklist: how they relate

No Indian vehicle manufacturer has published a requirement making ISO/IEC 27001 certification mandatory, and certification appears as one checkpoint among many, categorised as desirable. Any claim to the contrary is checkable and wrong.

The structural observation is more useful. Setting aside that checkpoint, the remaining families describe an information security management system in operation: documented policy, defined responsibilities, risk assessment, asset inventory, access control, logging, supplier management, awareness, incident response, continuity and continuous improvement. An organisation running a certified ISMS answers the substantial majority of the instrument from documentation it already maintains. Certification is not the requirement. It is the efficient route to satisfying it, and it is the standard expressly recognised under the rules on reasonable security practices made under Section 43A of the Information Technology Act, 2000.

Does ISO 27001 cover the manufacturing plant

A certificate scoped to corporate information technology does not extend to the shop floor. Programmable logic controllers, supervisory control systems, human machine interfaces and plant networks sit outside that scope. A supplier can hold a valid certificate and still score poorly against checkpoints reaching into production.

Where operational technology is in scope the applicable standards are IEC 62443-2-1 for the security programme and IEC 62443-3-3 for system security requirements and security levels. These secure the industrial automation and control system itself. They should not be confused with ISO 26262 or ISO/SAE 21434, which govern functional safety and cybersecurity engineering of the vehicle as a product.

Why this is happening now

AIS-189 applies to new vehicle types from October 2027 and to all vehicle types from October 2028, on a timetable that is still being given force through draft rules, with AIS-190 covering software update management. Both are modelled on UNECE R155 and R156 and on ISO/SAE 21434, and the Ministry of Road Transport and Highways has moved to bind them through proposed Rules 125-T and 125-U.

The rules are in draft and the dates attached to them are not final. Check the current position on the Ministry of Road Transport and Highways site before planning against them.

The clause reaching suppliers requires the vehicle manufacturer to manage cybersecurity dependencies across suppliers, service providers and sub-organisations, with bilateral cybersecurity interface agreements allocating responsibility. A manufacturer cannot demonstrate an approved management system without evidence of control over its supply chain, so the requirement cascades by design. That cascade does not stop at the first tier. Tier 2 supplier cybersecurity requirements follow from the same logic.

The reference guide covers the same ground in a form built for looking things up, and business continuity is treated separately because it carries weight out of proportion to its effort. MSCi works with automotive suppliers on readiness. 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. The free readiness checklist is the quickest way to see where you stand.