Status: Publication Candidate - Open Review Gates
Publisher: ODA3 Institute
Legal entity: ODA3 Pvt Ltd
Edition date: 1 July 2026
Methodology and evidence note. Authoritative GAISSF identifiers and titles are sourced from GAISSF-NOR-001 [T1]. Automotive interpretations, classifications, use cases, threat scenarios, metrics, and crosswalks are analytical implementation guidance [T3] unless a record cites a different tier. No proprietary vehicle telemetry, client data, or internal incident dataset was used.
Automotive artificial intelligence can affect release authority, product liability exposure, warranty and recall cost, type-approval schedules, supplier accountability, vehicle availability, and customer trust. Leadership therefore needs one governed assurance model linking AI security to vehicle cybersecurity, functional safety, Safety of the Intended Functionality (SOTIF), privacy, product safety, software updates, and evidence-based release decisions. [T3]
This guide translates the authoritative 59-control GAISSF baseline into operational automotive contexts. It does not alter the normative controls or claim legal compliance, homologation, safety approval, cybersecurity approval, accredited certification, or prevention of harm. [T1]
The guide applies to vehicle manufacturers, suppliers, semiconductor and software providers, cloud and connected-service providers, fleets, mobility platforms, charging operators, dealerships, aftermarket providers, laboratories, approval functions, and assurance teams. Applicability varies by actor, system boundary, vehicle category, jurisdiction, authority, connectivity, lifecycle stage, and operating design domain. [T3]
The exact GAISSF control identifiers and titles are authoritative [T1]. Every automotive interpretation, implementation example, evidence record, metric, classification profile, use case, threat scenario, and external cross-standard mapping is informative [T3]. “Shall” is reserved for reproduced normative language.
The relevant system boundary can include perception, sensor fusion, driver and occupant monitoring, vehicle-control functions, battery and energy-management systems, telematics, gateways, infotainment, connected-vehicle backends, mobile applications, public-key infrastructure, mapping, charging, fleet platforms, model-development pipelines, simulation, hardware-in-the-loop environments, manufacturing inspection, and engineering assistants. [T3]
Automotive AI risk is differentiated by physical consequence, fleet-scale common-mode failure, long support periods, complex supplier chains, constrained field remediation, signed software and model updates, connected-service dependencies, and the need to reconcile security changes with safety assumptions. [T3]
Risk should be reviewed across six separate impact vectors: Mission, Human, Security, Legal and Policy, Strategic, and Financial. Do not collapse them into one score where aggregation could conceal an unacceptable human or safety impact. A practical review can rate each vector Low, Medium, High, or Critical, record the evidence and uncertainty, and require cross-functional approval where any vector exceeds the organisation’s threshold.
Profiles A-E are informative implementation aids, not GAISSF conformance levels, vehicle automation levels, Automotive Safety Integrity Levels, assurance levels, maturity levels, or legal classifications. Profile A covers low-impact support; B operational assistance; C material decision support; D safety- or security-relevant automation; and E high-consequence vehicle authority. Classification depends on actual authority, autonomy, safety relevance, connectivity, scale, data sensitivity, reversibility, fallback, supplier dependency, and failure propagation. [T3]
Days 0-30: establish governance; inventory systems; classify authority and consequence; identify critical suppliers; open evidence repositories and specialist review gates.
Days 31-60: complete priority mappings; perform integrated threat analysis; verify model and data provenance; assess suppliers; define monitoring, incident, and Over-the-Air (OTA) update controls.
Days 61-90: test operating effectiveness; execute representative scenarios; validate monitoring and escalation; close critical evidence gaps; conduct independent readiness review; document residual risk.
Metric: Percentage of applicable in-scope systems with current approved evidence and no overdue high-risk exception.
Example: Five systems are in scope. Four have current approved evidence and no overdue high-risk exception. The result is 4 ÷ 5 = 80%. The report must retain the denominator, exclusions, evidence date, and exception status so the figure cannot be improved by silently narrowing scope.
Mappings are directional and do not establish equivalence or compliance inheritance. Primary official publications are treated as [T1]. The automotive interpretation and crosswalk are analytical [T3] until clause-level specialist review is completed.
UN Regulation No. 155 - Cyber security and cyber security management system [T1]: Vehicle cybersecurity governance, lifecycle risk management, monitoring and response. Analytical mapping [T3]. Limitation: Jurisdiction and vehicle-category applicability require legal/type-approval review.
UN Regulation No. 156 - Software update and software update management system [T1]: Software/AI update governance, integrity, records, compatibility and controlled release. Analytical mapping [T3]. Limitation: Current series of amendments and national implementation must be verified.
ISO/SAE 21434:2021 - Road vehicles - Cybersecurity engineering [T1]: Cybersecurity engineering across concept, development, production, operations, maintenance and decommissioning. Analytical mapping [T3]. Limitation: No equivalence or compliance inheritance is claimed.
ISO 26262 series:2018 - Road vehicles - Functional safety [T1]: Functional-safety management and lifecycle coordination for safety-related E/E systems. Analytical mapping [T3]. Limitation: AI security does not replace functional-safety analysis or confirmation measures.
ISO 21448:2022 - Road vehicles - Safety of the intended functionality [T1]: Performance limitations, foreseeable misuse, scenario analysis and unknown unsafe conditions. Analytical mapping [T3]. Limitation: Clause-level mapping requires lawful access and specialist SOTIF review.
ISO 24089:2023 - Road vehicles - Software update engineering [T1]: Software update engineering and coordination with AI/model releases. Analytical mapping [T3]. Limitation: Applicability to model-only changes must be determined in system context.
ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system [T1]: AI governance, objectives, controls, documented information and continual improvement. Analytical mapping [T3]. Limitation: Management-system conformity does not establish vehicle safety or cybersecurity.
NIST AI RMF 1.0 - Artificial Intelligence Risk Management Framework [T1]: Govern, map, measure and manage AI risks. Analytical mapping [T3]. Limitation: Not automotive-specific and not a legal compliance instrument.
Apply this domain through data provenance, model integrity, adversarial testing, drift monitoring, signing, conversion and release controls. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through prompt, multimodal, tool-call and cross-context controls for generative and interactive automotive functions. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through authority limits, agent communication, memory, embodied action, fallback, oversight and command verification. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through AI bills of materials, model scanning, registry vetting, third-party APIs, shadow AI and software composition analysis. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through output integrity, privacy, personal information leakage, copyright and privacy-preserving machine learning. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through human oversight, auditability, model cards, incident response, decommissioning, supplier governance and resilience. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through training, authentication, social-engineering response and AI-enhanced external-attack defence. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through applicable-law mapping, management-system alignment, technical documentation and secure-development evidence. [T3] The Control Master and Annex A define the exact automotive implementation records.
Apply this domain through physical boundaries, safe states, override, cyber-physical detection, environmental monitoring and evidence preservation. [T3] The Control Master and Annex A define the exact automotive implementation records.
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Dataset Provenance & Poisoning Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-028; AUC-029
Related threat scenarios: None assigned
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-009; AEV-015
Assessment question: Is dataset provenance & poisoning prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Model Extraction Resistance to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-028; AUC-029; AUC-030
Related threat scenarios: ATS-001
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-015
Assessment question: Is model extraction resistance implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Behavioral Drift Detection to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-001; AUC-029; AUC-030
Related threat scenarios: ATS-002
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-007; AEV-010; AEV-014; AEV-016; AEV-019; AEV-020; AEV-025
Assessment question: Is behavioral drift detection implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Federated Learning Poisoning Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-001; AUC-029; AUC-030; AUC-031
Related threat scenarios: ATS-003
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-009
Assessment question: Is federated learning poisoning prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Embedding Space Robustness to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-001; AUC-002; AUC-030; AUC-031
Related threat scenarios: ATS-004
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-014
Assessment question: Is embedding space robustness implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Post-Quantum Model Signing & Crypto Hardening to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-001; AUC-002; AUC-030; AUC-031; AUC-032
Related threat scenarios: ATS-005
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-017; AEV-018
Assessment question: Is post-quantum model signing & crypto hardening implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Lora/Adapter Integrity Verification to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-001; AUC-002; AUC-003; AUC-031; AUC-032
Related threat scenarios: ATS-006
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-018
Assessment question: Is lora/adapter integrity verification implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Model Merge Attack Detection to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-002; AUC-003; AUC-031; AUC-032
Related threat scenarios: ATS-007
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-018
Assessment question: Is model merge attack detection implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Quantization Backdoor Screening to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-002; AUC-003; AUC-004; AUC-032
Related threat scenarios: ATS-001; ATS-008
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-018
Assessment question: Is quantization backdoor screening implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Direct Prompt Injection Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Vehicle security monitoring; In-vehicle AI component
Related use cases: AUC-003; AUC-004; AUC-032
Related threat scenarios: ATS-002; ATS-009
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-008; AEV-015
Assessment question: Is direct prompt injection prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Indirect Prompt Injection Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-003; AUC-004; AUC-005
Related threat scenarios: ATS-003; ATS-010
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-008; AEV-015
Assessment question: Is indirect prompt injection prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Jailbreak Resistance Testing to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-004; AUC-005
Related threat scenarios: ATS-004; ATS-011
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-014; AEV-015
Assessment question: Is jailbreak resistance testing implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Multi-Modal Injection Defense to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-004; AUC-005; AUC-006
Related threat scenarios: ATS-005; ATS-012
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-008; AEV-014; AEV-015
Assessment question: Is multi-modal injection defense implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Function Call/Tool Call Injection Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-005; AUC-006
Related threat scenarios: ATS-006; ATS-013
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-004; AEV-015; AEV-017
Assessment question: Is function call/tool call injection prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Cross-Context Hijacking Mitigation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-005; AUC-006; AUC-007
Related threat scenarios: ATS-007; ATS-014
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-004; AEV-015
Assessment question: Is cross-context hijacking mitigation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Least Agency Enforcement to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-006; AUC-007
Related threat scenarios: ATS-001; ATS-008; ATS-015
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-004; AEV-017
Assessment question: Is least agency enforcement implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Inter-Agent Communication Security to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-006; AUC-007; AUC-008
Related threat scenarios: ATS-002; ATS-009; ATS-016
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-004; AEV-008
Assessment question: Is inter-agent communication security implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Agentic Prompt Chaining Detection to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-007; AUC-008
Related threat scenarios: ATS-003; ATS-010; ATS-017
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is agentic prompt chaining detection implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Embodied Ai Safety Controls to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-007; AUC-008; AUC-009
Related threat scenarios: ATS-004; ATS-011; ATS-018
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-005; AEV-006; AEV-007; AEV-016
Assessment question: Is embodied ai safety controls implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Multi-Agent Trust Chain Attestation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Vehicle security monitoring; In-vehicle AI component
Related use cases: AUC-008; AUC-009
Related threat scenarios: ATS-005; ATS-012; ATS-019
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is multi-agent trust chain attestation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Persistent Memory Exfiltration Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-008; AUC-009; AUC-010
Related threat scenarios: ATS-006; ATS-013; ATS-020
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is persistent memory exfiltration prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Secure Memory Lifecycle Management to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-009; AUC-010
Related threat scenarios: ATS-007; ATS-014; ATS-021
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is secure memory lifecycle management implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Bill Of Materials (Ai Bom) Maintenance to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-009; AUC-010; AUC-011
Related threat scenarios: ATS-001; ATS-008; ATS-015; ATS-022
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-012; AEV-018
Assessment question: Is ai bill of materials (ai bom) maintenance implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Model File & Artifact Scanning to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-010; AUC-011
Related threat scenarios: ATS-002; ATS-009; ATS-016; ATS-023
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-012; AEV-017; AEV-018; AEV-025
Assessment question: Is model file & artifact scanning implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Model Hub & Registry Vetting to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-010; AUC-011; AUC-012
Related threat scenarios: ATS-003; ATS-010; ATS-017; ATS-024
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-012
Assessment question: Is model hub & registry vetting implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Mcp Server Behavioral Monitoring to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-011; AUC-012
Related threat scenarios: ATS-004; ATS-011; ATS-018; ATS-025
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-019; AEV-020
Assessment question: Is mcp server behavioral monitoring implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Third-Party Ai Api Security Assessment to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-011; AUC-012; AUC-013
Related threat scenarios: ATS-005; ATS-012; ATS-019; ATS-026
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-004; AEV-005; AEV-008; AEV-012; AEV-013
Assessment question: Is third-party ai api security assessment implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Shadow Ai Discovery & Governance to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-012; AUC-013
Related threat scenarios: ATS-006; ATS-013; ATS-020; ATS-027
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is shadow ai discovery & governance implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Software Composition Analysis (Sca) to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-012; AUC-013; AUC-014
Related threat scenarios: ATS-007; ATS-014; ATS-021; ATS-028
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-011; AEV-012; AEV-017
Assessment question: Is ai software composition analysis (sca) implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Harmful Content Blocking to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Vehicle security monitoring; In-vehicle AI component
Related use cases: AUC-013; AUC-014
Related threat scenarios: ATS-008; ATS-015; ATS-022; ATS-029
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is harmful content blocking implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Pii Leakage Prevention to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-013; AUC-014; AUC-015
Related threat scenarios: ATS-009; ATS-016; ATS-023; ATS-030
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-009
Assessment question: Is pii leakage prevention implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Copyright Detection to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-014; AUC-015
Related threat scenarios: ATS-010; ATS-017; ATS-024; ATS-031
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is copyright detection implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Watermarking Robustness to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-014; AUC-015; AUC-016
Related threat scenarios: ATS-011; ATS-018; ATS-025; ATS-032
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is ai watermarking robustness implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Privacy-By-Design Verification to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-015; AUC-016
Related threat scenarios: ATS-012; ATS-019; ATS-026; ATS-033
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-009
Assessment question: Is privacy-by-design verification implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Privacy-Preserving Ml Validation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-015; AUC-016; AUC-017
Related threat scenarios: ATS-013; ATS-020; ATS-027; ATS-034
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-009
Assessment question: Is privacy-preserving ml validation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Human-In-The-Loop For High-Risk Actions to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-016; AUC-017
Related threat scenarios: ATS-014; ATS-021; ATS-028
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-003; AEV-006; AEV-007; AEV-022; AEV-023
Assessment question: Is human-in-the-loop for high-risk actions implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Audit Trail Completeness to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-016; AUC-017; AUC-018
Related threat scenarios: ATS-015; ATS-022; ATS-029
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-001; AEV-003; AEV-019; AEV-021; AEV-022; AEV-024; AEV-025
Assessment question: Is audit trail completeness implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Model Card Completeness to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-017; AUC-018
Related threat scenarios: ATS-016; ATS-023; ATS-030
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-010
Assessment question: Is ai model card completeness implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Incident Response Readiness to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-017; AUC-018; AUC-019
Related threat scenarios: ATS-017; ATS-024; ATS-031
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-019; AEV-020; AEV-021; AEV-023; AEV-024; AEV-025
Assessment question: Is ai incident response readiness implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Model Deprecation & Decommissioning to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Vehicle security monitoring; In-vehicle AI component
Related use cases: AUC-018; AUC-019
Related threat scenarios: ATS-018; ATS-025; ATS-032
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is model deprecation & decommissioning implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Third-Party Ai Vendor Governance to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-018; AUC-019; AUC-020
Related threat scenarios: ATS-019; ATS-026; ATS-033
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-001; AEV-012; AEV-013; AEV-022; AEV-023; AEV-024
Assessment question: Is third-party ai vendor governance implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Resilience & Business Continuity to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-019; AUC-020
Related threat scenarios: ATS-020; ATS-027; ATS-034
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-019; AEV-020; AEV-021; AEV-022; AEV-024; AEV-025
Assessment question: Is ai resilience & business continuity implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai-Generated Phishing Simulation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-019; AUC-020; AUC-021
Related threat scenarios: ATS-021; ATS-028
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-023
Assessment question: Is ai-generated phishing simulation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Deepfake Detection Training to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-020; AUC-021
Related threat scenarios: ATS-022; ATS-029
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-023
Assessment question: Is deepfake detection training implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Out-Of-Band Authentication to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-020; AUC-021; AUC-022
Related threat scenarios: ATS-023; ATS-030
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-023
Assessment question: Is out-of-band authentication implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai Social Engineering Ir to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-021; AUC-022
Related threat scenarios: ATS-024; ATS-031
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-021; AEV-023
Assessment question: Is ai social engineering ir implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Ai-Enhanced External Attack Defense to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-021; AUC-022; AUC-023
Related threat scenarios: ATS-025; ATS-032
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is ai-enhanced external attack defense implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Eu Ai Act Risk Tier Mapping to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-022; AUC-023
Related threat scenarios: ATS-026; ATS-033
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-001; AEV-003; AEV-013; AEV-022; AEV-024
Assessment question: Is eu ai act risk tier mapping implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Iso 42001 Gap Analysis to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-022; AUC-023; AUC-024
Related threat scenarios: ATS-027; ATS-034
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-001; AEV-003; AEV-024; AEV-025
Assessment question: Is iso 42001 gap analysis implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Gpai Technical Documentation Verification to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Vehicle security monitoring; In-vehicle AI component
Related use cases: AUC-023; AUC-024
Related threat scenarios: ATS-028
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-010; AEV-013
Assessment question: Is gpai technical documentation verification implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Dora Ict Incident Reporting (Financial Sector) to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: ADAS/automated-driving function; Connected-vehicle backend
Related use cases: AUC-023; AUC-024; AUC-025
Related threat scenarios: ATS-029
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: To be determined
Assessment question: Is dora ict incident reporting (financial sector) implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Nist Sp 800-218A Compliance Check to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Driver or occupant monitoring; OTA update infrastructure
Related use cases: AUC-024; AUC-025
Related threat scenarios: ATS-030
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-013; AEV-017; AEV-025
Assessment question: Is nist sp 800-218a compliance check implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Physical Harm Boundary Enforcement to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: In-vehicle AI component; Fleet analytics platform
Related use cases: AUC-024; AUC-025; AUC-026
Related threat scenarios: ATS-031
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-003; AEV-006; AEV-007; AEV-016; AEV-022
Assessment question: Is physical harm boundary enforcement implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Safe State And Graceful Degradation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Connected-vehicle backend; Engineering AI assistant
Related use cases: AUC-025; AUC-026
Related threat scenarios: ATS-032
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-006; AEV-007; AEV-014; AEV-016
Assessment question: Is safe state and graceful degradation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Data Governance Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Human Override And Emergency Stop to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: OTA update infrastructure; Manufacturing AI system
Related use cases: AUC-025; AUC-026; AUC-027
Related threat scenarios: ATS-033
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-006
Assessment question: Is human override and emergency stop implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: AI Security Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Cyber-Physical Attack Detection to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Fleet analytics platform; Battery and energy-management AI
Related use cases: AUC-026; AUC-027
Related threat scenarios: ATS-034
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-005; AEV-008; AEV-015; AEV-019; AEV-020; AEV-021
Assessment question: Is cyber-physical attack detection implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Automotive Cybersecurity Lead / Privacy Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Physical Environment Integrity Monitoring to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Engineering AI assistant; Vehicle security monitoring
Related use cases: AUC-026; AUC-027; AUC-028
Related threat scenarios: None assigned
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-007; AEV-014; AEV-016; AEV-019; AEV-020
Assessment question: Is physical environment integrity monitoring implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Vehicle Software Lead / Independent Assessor
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Actuator Command Verification to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Manufacturing AI system; ADAS/automated-driving function
Related use cases: AUC-027; AUC-028
Related threat scenarios: None assigned
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-002; AEV-004; AEV-006; AEV-008; AEV-017; AEV-018
Assessment question: Is actuator command verification implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Functional Safety Lead / Product Security Lead
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Authoritative GAISSF requirement [T1]: Refer to GAISSF-NOR-001 v1.0.
Automotive interpretation [T3]: Apply Physical Incident Evidence Preservation to automotive AI components and their vehicle, backend, engineering, manufacturing, supplier, update, and monitoring dependencies using a documented risk-based scope.
Applicability: Determine for every in-scope system; record Not Applicable only with approved rationale.
Representative systems: Battery and energy-management AI; Driver or occupant monitoring
Related use cases: AUC-027; AUC-028; AUC-029
Related threat scenarios: None assigned
Minimum credible implementation: Approved scope and owner; documented applicability; baseline technical or procedural safeguard; retained evidence; defined exception and escalation route.
Enhanced implementation: Automated enforcement and telemetry; independent testing; fleet correlation where relevant; supplier attestations backed by evidence; change-triggered reassessment.
Illustrative evidence: AEV-006; AEV-020; AEV-021; AEV-025
Assessment question: Is physical incident evidence preservation implemented across the approved automotive system boundary, including suppliers, updates, field monitoring, exceptions, and operating evidence?
Owner / reviewer: Supplier Assurance Lead / Functional Safety Reviewer
Safety coordination: Reconcile security assumptions and mitigations with functional-safety and SOTIF artefacts; do not alter safety mechanisms without impact analysis.
Notably absent: No claim of automatic legal compliance, homologation, functional-safety approval, cybersecurity approval, or prevention of harm.
Review status: Open - automotive specialist review required
Context: Automotive AI application supporting object and pedestrian detection within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-1 supplier
Authority / safety relevance: High / High
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-03; D1-CTL-04; D1-CTL-05; D1-CTL-06; D1-CTL-07
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting lane detection and lane keeping within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-2 supplier
Authority / safety relevance: High / High
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-05; D1-CTL-06; D1-CTL-07; D1-CTL-08; D1-CTL-09
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting traffic-sign recognition within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Automotive semiconductor supplier
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-07; D1-CTL-08; D1-CTL-09; D2-CTL-01; D2-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting driver-state monitoring within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle software platform provider
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-09; D2-CTL-01; D2-CTL-02; D2-CTL-03; D2-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting occupant classification within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Cloud or backend provider
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D2-CTL-02; D2-CTL-03; D2-CTL-04; D2-CTL-05; D2-CTL-06
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting automated emergency braking within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Fleet operator
Authority / safety relevance: High / High
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D2-CTL-04; D2-CTL-05; D2-CTL-06; D3-CTL-01; D3-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting path planning and motion prediction within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Mobility platform
Authority / safety relevance: High / High
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D2-CTL-06; D3-CTL-01; D3-CTL-02; D3-CTL-03; D3-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting parking assistance within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Charging infrastructure operator
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D3-CTL-02; D3-CTL-03; D3-CTL-04; D3-CTL-05; D3-CTL-06
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting route optimisation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Aftermarket provider
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D3-CTL-04; D3-CTL-05; D3-CTL-06; D3-CTL-07; D4-CTL-01
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting battery state-of-health prediction within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle OEM
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D3-CTL-06; D3-CTL-07; D4-CTL-01; D4-CTL-02; D4-CTL-03
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting battery thermal-risk detection within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-1 supplier
Authority / safety relevance: High / High
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D4-CTL-01; D4-CTL-02; D4-CTL-03; D4-CTL-04; D4-CTL-05
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting predictive maintenance within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-2 supplier
Authority / safety relevance: Medium / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D4-CTL-03; D4-CTL-04; D4-CTL-05; D4-CTL-06; D4-CTL-07
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting vehicle-network anomaly detection within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Automotive semiconductor supplier
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D4-CTL-05; D4-CTL-06; D4-CTL-07; D5-CTL-01; D5-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting remote diagnostics within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle software platform provider
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D4-CTL-07; D5-CTL-01; D5-CTL-02; D5-CTL-03; D5-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting vehicle identity verification within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Cloud or backend provider
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D5-CTL-02; D5-CTL-03; D5-CTL-04; D5-CTL-05; D5-CTL-06
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting fleet-driver scoring within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Fleet operator
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D5-CTL-04; D5-CTL-05; D5-CTL-06; D6-CTL-01; D6-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting insurance telematics within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Mobility platform
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D5-CTL-06; D6-CTL-01; D6-CTL-02; D6-CTL-03; D6-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting charging optimisation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Charging infrastructure operator
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D6-CTL-02; D6-CTL-03; D6-CTL-04; D6-CTL-05; D6-CTL-06
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting manufacturing quality inspection within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Aftermarket provider
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D6-CTL-04; D6-CTL-05; D6-CTL-06; D6-CTL-07; D7-CTL-H01
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting robotic process control within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle OEM
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D6-CTL-06; D6-CTL-07; D7-CTL-H01; D7-CTL-H02; D7-CTL-H03
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting supplier-risk analytics within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-1 supplier
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D7-CTL-H01; D7-CTL-H02; D7-CTL-H03; D7-CTL-H04; D7-CTL-H05
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting software-defect prediction within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-2 supplier
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D7-CTL-H03; D7-CTL-H04; D7-CTL-H05; D8-CTL-01; D8-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting vulnerability prioritisation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Automotive semiconductor supplier
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D7-CTL-H05; D8-CTL-01; D8-CTL-02; D8-CTL-03; D8-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting incident triage within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle software platform provider
Authority / safety relevance: Medium / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D8-CTL-02; D8-CTL-03; D8-CTL-04; D8-CTL-05; D9-CTL-01
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting simulation and scenario generation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Cloud or backend provider
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D8-CTL-04; D8-CTL-05; D9-CTL-01; D9-CTL-02; D9-CTL-03
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting synthetic sensor-data generation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Fleet operator
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D9-CTL-01; D9-CTL-02; D9-CTL-03; D9-CTL-04; D9-CTL-05
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting engineering coding assistant within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Mobility platform
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D9-CTL-03; D9-CTL-04; D9-CTL-05; D9-CTL-06; D9-CTL-07
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting requirements analysis assistant within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Charging infrastructure operator
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D9-CTL-05; D9-CTL-06; D9-CTL-07; D1-CTL-01; D1-CTL-02
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting test-case generation within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Aftermarket provider
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D9-CTL-07; D1-CTL-01; D1-CTL-02; D1-CTL-03; D1-CTL-04
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting safety-case evidence assistant within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Vehicle OEM
Authority / safety relevance: Medium / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-02; D1-CTL-03; D1-CTL-04; D1-CTL-05; D1-CTL-06
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting compliance evidence analysis within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-1 supplier
Authority / safety relevance: Low / Low
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-04; D1-CTL-05; D1-CTL-06; D1-CTL-07; D1-CTL-08
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Context: Automotive AI application supporting customer-service assistant within a defined vehicle, engineering, manufacturing, fleet, or service boundary.
Actors: Tier-2 supplier
Authority / safety relevance: Low / Medium
Failure modes: Incorrect inference, distribution shift, unavailable service, unsafe automation, stale data, or inadequate human escalation.
Applicable controls: D1-CTL-06; D1-CTL-07; D1-CTL-08; D1-CTL-09; D2-CTL-01
Evidence expectations: Approved scope, architecture, threat model, data/model provenance, test results, release decision, monitoring records, and exception log.
Limitations: Classification depends on actual authority, operating design domain, connectivity, scale, and fallback design.
Description: A threat or failure scenario involving adversarial perception manipulation in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-02; D1-CTL-09; D3-CTL-01; D4-CTL-01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving sensor spoofing or blinding in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-03; D2-CTL-01; D3-CTL-02; D4-CTL-02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving training-data poisoning in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-04; D2-CTL-02; D3-CTL-03; D4-CTL-03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving compromised simulation data in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-05; D2-CTL-03; D3-CTL-04; D4-CTL-04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving mapping-data compromise in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-06; D2-CTL-04; D3-CTL-05; D4-CTL-05
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving model tampering or substitution in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-07; D2-CTL-05; D3-CTL-06; D4-CTL-06
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving insecure model update in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-08; D2-CTL-06; D3-CTL-07; D4-CTL-07
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving rollback attack in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D1-CTL-09; D3-CTL-01; D4-CTL-01; D5-CTL-01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving unauthorised calibration change in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-01; D3-CTL-02; D4-CTL-02; D5-CTL-02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving third-party ai component compromise in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-02; D3-CTL-03; D4-CTL-03; D5-CTL-03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving unsafe model compression in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-03; D3-CTL-04; D4-CTL-04; D5-CTL-04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving loss of model provenance in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-04; D3-CTL-05; D4-CTL-05; D5-CTL-05
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving prompt injection in engineering copilots in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-05; D3-CTL-06; D4-CTL-06; D5-CTL-06
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving indirect prompt injection through service data in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D2-CTL-06; D3-CTL-07; D4-CTL-07; D6-CTL-01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving excessive ai-agent authority in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-01; D4-CTL-01; D5-CTL-01; D6-CTL-02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving unsafe generated code in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-02; D4-CTL-02; D5-CTL-02; D6-CTL-03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving hallucinated diagnostic guidance in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-03; D4-CTL-03; D5-CTL-03; D6-CTL-04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving driver-monitoring evasion in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-04; D4-CTL-04; D5-CTL-04; D6-CTL-05
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving vehicle-data leakage in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-05; D4-CTL-05; D5-CTL-05; D6-CTL-06
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving location-data misuse in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-06; D4-CTL-06; D5-CTL-06; D6-CTL-07
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving fleet-wide correlated model failure in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D3-CTL-07; D4-CTL-07; D6-CTL-01; D7-CTL-H01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving automation bias in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-01; D5-CTL-01; D6-CTL-02; D7-CTL-H02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving inadequate fallback behaviour in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-02; D5-CTL-02; D6-CTL-03; D7-CTL-H03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving loss of observability in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-03; D5-CTL-03; D6-CTL-04; D7-CTL-H04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving insecure ota infrastructure in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-04; D5-CTL-04; D6-CTL-05; D7-CTL-H05
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving signing-key compromise in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-05; D5-CTL-05; D6-CTL-06; D8-CTL-01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving supplier compromise in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-06; D5-CTL-06; D6-CTL-07; D8-CTL-02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving shadow ai in engineering in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D4-CTL-07; D6-CTL-01; D7-CTL-H01; D8-CTL-03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving manipulated test evidence in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-01; D6-CTL-02; D7-CTL-H02; D8-CTL-04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving post-release model drift in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-02; D6-CTL-03; D7-CTL-H03; D8-CTL-05
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving environmental distribution shift in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-03; D6-CTL-04; D7-CTL-H04; D9-CTL-01
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving rare-event failure in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-04; D6-CTL-05; D7-CTL-H05; D9-CTL-02
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving unsafe ai-deterministic control interaction in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-05; D6-CTL-06; D8-CTL-01; D9-CTL-03
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Description: A threat or failure scenario involving cross-discipline assurance failure in an automotive AI lifecycle or operating environment.
Initiating condition: External attacker, malicious insider, compromised supplier, defective process, environmental condition, or unintentional operator action.
Pathway: Compromise or degradation of data, model, software, interface, update, identity, monitoring, or governance controls.
Consequences: Human - Potential ranges from inconvenience or privacy harm to injury depending on vehicle authority and fallback capability.; Security - Loss of confidentiality, integrity, availability, authenticity, or accountability.; Operational/mission - Degraded vehicle, fleet, engineering, manufacturing, or service objective.; Financial - Investigation, remediation, recall, downtime, litigation, contractual, or regulatory cost.
Relevant controls: D5-CTL-06; D6-CTL-07; D8-CTL-02; D9-CTL-04
Observed status: Plausible scenario; not asserted as a confirmed field incident.
Evidence tier: T3 - analytical or research-supported
Limitations: Occurrence, exploitability, and consequence depend on implementation and operating context.
Purpose: Demonstrate the design, implementation, operation, or review of ai system inventory.
Owner: AI Governance Lead
Lifecycle: Concept; use-case approval; change control
Control linkage: D6-CTL-02; D6-CTL-06; D8-CTL-01; D8-CTL-02
Linkage justification: Establishes the governed population to which controls, assessments, exceptions and review obligations apply.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of system boundary record.
Owner: Systems Engineering Lead
Lifecycle: System definition; architecture; integration
Control linkage: D3-CTL-01; D3-CTL-02; D3-CTL-04; D9-CTL-01; D9-CTL-02; D9-CTL-06
Linkage justification: Defines interfaces, authority, trust boundaries and physical-control influence needed to test control applicability.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of automotive applicability decision.
Owner: AI Governance Lead
Lifecycle: Use-case approval; concept; management review
Control linkage: D6-CTL-01; D6-CTL-02; D8-CTL-01; D8-CTL-02; D9-CTL-01
Linkage justification: Records why each control applies, does not apply or requires enhanced treatment in the automotive context.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of architecture and interface description.
Owner: Systems Engineering Lead
Lifecycle: Architecture; design; integration
Control linkage: D2-CTL-05; D2-CTL-06; D3-CTL-01; D3-CTL-02; D4-CTL-05; D9-CTL-06
Linkage justification: Supports verification of interfaces, tool permissions, trust boundaries and command paths.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of threat analysis and risk assessment.
Owner: Automotive Cybersecurity Lead
Lifecycle: Concept; cybersecurity analysis; change assessment
Control linkage: D1-CTL-01; D1-CTL-03; D2-CTL-01; D2-CTL-02; D3-CTL-04; D4-CTL-05; D6-CTL-04; D9-CTL-04
Linkage justification: Documents attack paths, initiating conditions, consequence vectors, controls and residual risk.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of functional-safety coordination record.
Owner: Functional Safety Lead
Lifecycle: Safety analysis; verification; release; material change
Control linkage: D3-CTL-04; D6-CTL-01; D9-CTL-01; D9-CTL-02; D9-CTL-03; D9-CTL-06; D9-CTL-07
Linkage justification: Shows that AI-security changes and assumptions were reconciled with functional-safety artefacts and release decisions.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of sotif coordination record.
Owner: SOTIF Lead
Lifecycle: SOTIF analysis; scenario validation; release; field monitoring
Control linkage: D1-CTL-03; D3-CTL-04; D6-CTL-01; D9-CTL-01; D9-CTL-02; D9-CTL-05
Linkage justification: Shows treatment of performance limitations, foreseeable misuse, triggering conditions and unknown unsafe scenarios.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of cybersecurity concept or case.
Owner: Automotive Cybersecurity Lead
Lifecycle: Concept; architecture; cybersecurity validation
Control linkage: D2-CTL-01; D2-CTL-02; D2-CTL-04; D3-CTL-02; D4-CTL-05; D9-CTL-04; D9-CTL-06
Linkage justification: Provides the automotive cybersecurity rationale, control strategy and assurance argument.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of data provenance record.
Owner: Data Governance Lead
Lifecycle: Data acquisition; labelling; model development; retraining
Control linkage: D1-CTL-01; D1-CTL-04; D5-CTL-02; D5-CTL-05; D5-CTL-06
Linkage justification: Demonstrates origin, rights, transformations, quality controls, access and lineage of training and evaluation data.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of model card.
Owner: AI Model Owner
Lifecycle: Model development; validation; release; material change
Control linkage: D1-CTL-03; D6-CTL-03; D8-CTL-03
Linkage justification: Records intended use, limitations, evaluation basis, dependencies, release status and known risks.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of model provenance and bill of materials.
Owner: AI Security Lead
Lifecycle: Acquisition; model development; integration; release; update
Control linkage: D1-CTL-06; D1-CTL-07; D1-CTL-08; D1-CTL-09; D4-CTL-01; D4-CTL-02; D4-CTL-03; D4-CTL-07
Linkage justification: Establishes model/component identity, provenance, dependency, licence, integrity and approved release lineage.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of supplier assessment.
Owner: Supplier Assurance Lead
Lifecycle: Supplier sourcing; onboarding; periodic review; change
Control linkage: D4-CTL-01; D4-CTL-02; D4-CTL-03; D4-CTL-05; D4-CTL-07; D6-CTL-06
Linkage justification: Evaluates supplier capability, evidence, incident obligations, support period, subcontractors and change controls.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of contractual security requirements.
Owner: Legal Counsel and Supplier Assurance Lead
Lifecycle: Contracting; sourcing; renewal; change
Control linkage: D4-CTL-05; D6-CTL-06; D8-CTL-01; D8-CTL-03; D8-CTL-05
Linkage justification: Creates enforceable obligations for security evidence, notification, audit, support, change and end-of-life.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of robustness test report.
Owner: AI Validation Lead
Lifecycle: Model verification; robustness testing; release; material change
Control linkage: D1-CTL-03; D1-CTL-05; D2-CTL-03; D2-CTL-04; D9-CTL-02; D9-CTL-05
Linkage justification: Demonstrates performance and failure behaviour across representative perturbations, environments and degradation conditions.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of adversarial test report.
Owner: AI Security Lead
Lifecycle: Security validation; red teaming; release; material change
Control linkage: D1-CTL-01; D1-CTL-02; D2-CTL-01; D2-CTL-02; D2-CTL-03; D2-CTL-04; D2-CTL-05; D2-CTL-06; D9-CTL-04
Linkage justification: Records adversarial test scope, methods, results, exploitability, limitations, remediation and retest evidence.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of scenario-coverage report.
Owner: SOTIF Lead and AI Validation Lead
Lifecycle: Scenario development; simulation; verification; field update
Control linkage: D1-CTL-03; D3-CTL-04; D9-CTL-01; D9-CTL-02; D9-CTL-05
Linkage justification: Shows coverage of operational, environmental, misuse, rare-event and safety-relevant scenarios.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of software verification report.
Owner: Vehicle Software Lead
Lifecycle: Software verification; integration; production release; update
Control linkage: D1-CTL-06; D2-CTL-05; D3-CTL-01; D4-CTL-02; D4-CTL-07; D8-CTL-05; D9-CTL-06
Linkage justification: Demonstrates software and integration verification for the approved build, configuration and command paths.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of ota release and signing record.
Owner: Vehicle Software and OTA Lead
Lifecycle: Production release; OTA deployment; rollback; post-update review
Control linkage: D1-CTL-06; D1-CTL-07; D1-CTL-08; D1-CTL-09; D4-CTL-01; D4-CTL-02; D9-CTL-06
Linkage justification: Proves authorised signing, release approval, compatibility, deployment scope, rollback readiness and update traceability.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of monitoring configuration.
Owner: Vehicle Security Operations Lead
Lifecycle: Deployment; monitoring; incident detection; tuning
Control linkage: D1-CTL-03; D4-CTL-04; D6-CTL-02; D6-CTL-04; D6-CTL-07; D9-CTL-04; D9-CTL-05
Linkage justification: Defines monitored signals, detection logic, thresholds, escalation, retention and known visibility gaps.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of fleet anomaly report.
Owner: Vehicle Security Operations Lead
Lifecycle: Fleet operations; monitoring; incident response; field action
Control linkage: D1-CTL-03; D4-CTL-04; D6-CTL-04; D6-CTL-07; D9-CTL-04; D9-CTL-05; D9-CTL-07
Linkage justification: Supports fleet-level correlation, common-mode detection, triage, containment and post-event analysis.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of incident record.
Owner: Incident Response Lead
Lifecycle: Incident response; product-safety escalation; recovery; lessons learned
Control linkage: D6-CTL-02; D6-CTL-04; D6-CTL-07; D7-CTL-H04; D9-CTL-04; D9-CTL-07
Linkage justification: Preserves event facts, decisions, communications, containment, recovery, safety escalation and corrective actions.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of exception and risk-acceptance record.
Owner: Risk Owner
Lifecycle: Risk treatment; exception approval; periodic review; expiry
Control linkage: D6-CTL-01; D6-CTL-02; D6-CTL-06; D6-CTL-07; D8-CTL-01; D9-CTL-01
Linkage justification: Records the accountable acceptance decision, compensating controls, monitoring, expiry and residual risk.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of training and competence record.
Owner: Competence and Training Lead
Lifecycle: Role assignment; onboarding; periodic training; change
Control linkage: D6-CTL-01; D6-CTL-04; D6-CTL-06; D7-CTL-H01; D7-CTL-H02; D7-CTL-H03; D7-CTL-H04
Linkage justification: Demonstrates that assigned personnel have role-relevant competence and current training.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of management review record.
Owner: Executive Risk Committee
Lifecycle: Periodic management review; major release; material incident
Control linkage: D6-CTL-02; D6-CTL-04; D6-CTL-06; D6-CTL-07; D8-CTL-01; D8-CTL-02
Linkage justification: Documents leadership review of performance, exceptions, incidents, resources, residual risk and corrective action.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
Purpose: Demonstrate the design, implementation, operation, or review of corrective-action record.
Owner: Control Owner
Lifecycle: Remediation; verification; closure; continual improvement
Control linkage: D1-CTL-03; D4-CTL-02; D6-CTL-02; D6-CTL-04; D6-CTL-07; D8-CTL-02; D8-CTL-05; D9-CTL-07
Linkage justification: Links findings to accountable remediation, verification evidence, closure criteria and recurrence prevention.
Integrity / limitations: Version controlled, attributable, tamper-evident where material, and linked to approved scope. Possession of the artefact does not alone prove control effectiveness.
The package retains 16 open gates: automotive cybersecurity engineering; functional safety; SOTIF; vehicle software and OTA; automated driving; product safety; homologation and type approval; automotive privacy; AI security; legal and regulatory; supplier assurance; assessment methodology; certification-scheme alignment; accessibility; technical editing; and final publication approval.
This document is an informative sector implementation layer. It does not replace the authoritative GAISSF standard, applicable law, vehicle engineering, competent safety judgement, type approval, homologation, cybersecurity engineering, privacy review, or independent assessment. Publication status remains Publication Candidate - Open Review Gates.