OEM Notification Requirements

OEM notification requirements (VDA ISA 9.1.2) mean you must notify affected OEM partners when an information security incident may impact their confidential data, and you must do it within the timeframe defined in your contract. To operationalize this quickly, map each OEM’s contractual notice clock, build an incident-to-OEM impact triage, and pre-approve notification templates, owners, and evidence retention. ¹

Key takeaways:

• Your “deadline” is contractual, so you need a contract-to-playbook mapping, not a generic SLA. ¹
• Notifications must cover incident details, impact assessment, and planned corrective actions, so collect those elements early in the incident workflow. ¹
• Auditors will test execution, not intent: decision logs, timestamps, and proof of delivery matter as much as the message. ¹

“OEM notification requirements requirement” questions usually boil down to one operational gap: teams have an incident response process, but they cannot prove they notified the right OEM, with the right content, within the contractually required timeframe. VDA ISA 9.1.2 is explicit that your notice obligation is triggered by an information security incident that may impact an OEM’s confidential data, and that the clock is defined by contract, not by your internal preference. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat OEM notification as a controlled workflow with three inputs: (1) which OEMs and contracts are in scope for the incident, (2) what confidential data could be impacted, and (3) what the contract requires you to say and when. Then you lock the workflow with governance: named owners, escalation rules, pre-approved templates, and evidence retention.

This page gives requirement-level implementation guidance you can put in place without rewriting your entire incident response program. It focuses on decision points, handoffs, and artifacts auditors will ask for under TISAX expectations aligned to VDA ISA. ¹

Regulatory text

VDA ISA 9.1.2 requirement (excerpt): “Notify affected OEM partners of information security incidents that may impact their confidential data within contractually defined timeframes.” ¹

Operator interpretation (what you must do):

1. Detect and triage incidents to determine whether an OEM’s confidential data may be impacted. This is a risk-based trigger; you do not need full certainty to start the notification decision. ¹
2. Notify the affected OEM partner(s) within the timeframe stated in the governing contract (including MSAs, data processing/security agreements, quality agreements, or OEM-specific security addenda). ¹
3. Include minimum content that allows the OEM to assess and respond: incident details, impact assessment, and planned corrective actions. ¹

Plain-English interpretation of the requirement

If something happens that could expose, alter, or disrupt an OEM’s confidential information you handle, you must tell that OEM quickly, using the timeframe you already agreed to in writing. The notification is not a marketing message or a legal essay; it’s a controlled security communication that enables the OEM to manage its own risk, regulatory duties, and operational continuity. ¹

Who it applies to

In-scope entities

• Automotive suppliers that store, process, transmit, or otherwise handle OEM confidential data. ¹
• OEMs where they are the notifying party to other OEM partners (less common operationally, but the control language includes OEMs). ¹

In-scope operational contexts (practical triggers)

• Supplier portals, EDI integrations, design collaboration platforms, PLM systems, file transfer services, ticketing tools, and email where OEM data exists.
• Engineering and manufacturing environments where OEM drawings, specifications, prototype info, test data, or security-relevant documentation is handled.
• Third-party hosted systems used by you (cloud services, MSSPs, tool vendors) that store OEM data; the obligation is still yours to the OEM.

What you actually need to do (step-by-step)

1) Build a contract notice matrix (the “clock”)

Goal: Know the notification deadline and delivery method for each OEM before an incident occurs.

• Inventory active OEM agreements and addenda that include security incident notification clauses.
• Extract into a matrix:
  • OEM legal entity and security contact points
  • Notice timeframe language (e.g., “without undue delay” or a fixed time window if specified in contract)
  • Required delivery method (email, portal, hotline, written notice)
  • Required content elements and any mandated format
  • Required follow-up cadence (initial + updates)
• Validate contacts quarterly with account management or the OEM’s supplier security team.

Control owner: Legal for interpretation; GRC for mapping and maintenance; Incident Response (IR) for execution.

2) Define “OEM confidential data” for triage

Goal: Make the trigger testable.

• Create a short, operational definition aligned to your contracts and data classification scheme.
• Map OEM data locations (systems, shares, SaaS workspaces) and common identifiers (project codes, part numbers, OEM program names).
• Add an IR playbook prompt: “Is OEM confidential data present in the affected system or potentially accessed via compromised credentials?”

This is where many teams fail: they can’t answer “which OEMs are impacted” within the notice window because they never mapped OEM data flows.

3) Embed an “OEM impact” decision point into incident response

Goal: Ensure notification decisions happen early and are logged.

Add a required IR step after initial containment:

• Identify the potentially affected data domains and counterparties (OEMs).
• Decide one of three statuses per OEM:
  • Notify now (credible possibility of impact)
  • Prepare to notify (uncertainty remains; gather facts quickly; draft message)
  • No notification (document why; preserve evidence)

Require approvals:

• IR lead (facts)
• GRC/Compliance (requirement check)
• Legal/Privacy (contract interpretation, wording guardrails)
• Account/OEM relationship owner (contact routing, coordination)

4) Pre-approve notification templates and minimum content

Goal: Reduce delay caused by drafting and internal debate.

Your template should force inclusion of the items explicitly expected:

• Incident details: what happened, when detected, affected systems, current status. ¹
• Impact assessment: what OEM data may be impacted, how you reached that conclusion, what is known vs unknown. ¹
• Planned corrective actions: containment, eradication, recovery steps, and longer-term corrective actions where known. ¹

Practical formatting tips:

• Put “known facts” and “open questions” in separate bullet lists.
• Include a dedicated section for “OEM actions recommended” if appropriate (credential resets, monitoring).
• Avoid absolute statements early (“no data accessed”) unless proven and you can evidence it.

5) Prove delivery within the contract window

Goal: Make this auditable.

• Use a controlled communication channel (case-managed email, ticketing portal, or secure supplier portal).
• Capture timestamps for:
  • Incident detection time (or internal declaration time, if that is your policy trigger)
  • Time notification decision was made
  • Time notice was sent
  • Proof of receipt/delivery where possible

If the contract specifies a method (for example, “written notice”), follow it even if you also call the OEM informally. Informal calls do not replace contractual notice.

6) Run post-notification follow-through

Goal: Close the loop with corrective actions and lessons learned.

• Provide updates if new facts materially change the impact assessment.
• Track corrective actions to completion and link them to the incident record.
• Feed systemic issues into your risk register and supplier/OEM relationship governance.

How Daydream fits (practical, non-disruptive)

If you manage many OEM-specific clauses, Daydream can act as the system of record for your OEM notice matrix, link each contract’s notification obligations to the incident workflow, and keep evidence (approvals, timestamps, delivery proofs) attached to a single case. The objective is simple: shorten the time from “incident declared” to “OEM notified” and make audits a document pull, not a forensic reconstruction.

Required evidence and artifacts to retain

Keep these artifacts in a retrievable case file per incident:

1. OEM notification matrix extract showing the contractual timeframe and required method for the affected OEM(s).
2. Incident record with key timestamps (detection, declaration, containment milestones).
3. OEM impact assessment (who, what data, which systems, basis for conclusion).
4. Approval log (names/roles, decision time, any legal review notes).
5. Notification content (initial notice + updates), preserved in final sent form.
6. Proof of delivery (email headers, portal submission receipt, ticket ID, or other evidence).
7. Corrective action plan and completion evidence mapped to the incident. ¹

Common exam/audit questions and hangups

Expect auditors to probe execution details tied to VDA ISA 9.1.2. ¹

• “Show me the contract clause and the timeframe you followed.” Hangup: contracts are decentralized, or the clause is ambiguous and you have no documented interpretation.
• “How do you decide whether an incident ‘may impact’ OEM confidential data?” Hangup: no defined decision criteria; the answer depends on a person’s memory.
• “Provide evidence of notification and timing.” Hangup: you have a draft email, but no proof it was sent or when.
• “What did you tell the OEM?” Hangup: notifications omit impact assessment or corrective actions, contrary to the expectation in the plain-language summary. ¹
• “How do you coordinate Legal, IR, and account teams?” Hangup: internal debate causes delay; no escalation path.

Frequent implementation mistakes (and how to avoid them)

1. Relying on a single global notice SLA. Fix: build the OEM-by-OEM matrix because the requirement is “within contractually defined timeframes.” ¹
2. Waiting for certainty before notifying. Fix: treat “may impact” as a trigger for a decision and a documented rationale; notify based on credible risk, then update as facts mature. ¹
3. No proof of delivery. Fix: enforce a single controlled channel and require a receipt artifact in the incident checklist.
4. Content mismatch. Fix: templates that force incident details, impact assessment, and corrective actions. ¹
5. Contact rot. Fix: periodic validation with OEMs; don’t assume last year’s email works during a crisis.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat “enforcement” here as contractual and assurance-driven: failure to notify within the agreed timeframe can escalate into loss of trust, commercial disputes, OEM scorecard impacts, and TISAX assessment findings tied to VDA ISA expectations. The operational risk is compounded by delays caused by unclear ownership, missing contract mapping, and weak evidence preservation. ¹

Practical 30/60/90-day execution plan

Use this phased plan to operationalize OEM notification requirements without re-architecting your entire IR program.

First 30 days (foundation and fast risk reduction)

• Assign owners: IR (process), Legal (contract interpretation), GRC (control oversight), Account/Customer Success (contact routing).
• Build the first version of the OEM notification matrix for your highest-risk or highest-volume OEM relationships.
• Create a standard OEM notification template with required fields: incident details, impact assessment, corrective actions. ¹
• Add an “OEM impact assessment” task to your incident workflow with mandatory decision logging.

Days 31–60 (operationalize and test)

• Expand the matrix to all active OEM contracts and security addenda.
• Run a tabletop exercise focused on timing: from incident declaration to OEM notice, including approvals and proof of delivery.
• Define evidence retention rules and a single repository location per incident.

Days 61–90 (scale and make it auditable)

• Automate prompts and checklists in your ticketing/IR tool so OEM impact triage cannot be skipped.
• Implement periodic contact validation and contract refresh processes.
• Establish metrics you can defend qualitatively in audits (for example: “we track decision time, send time, and proof of delivery per OEM notice”), without inventing benchmarks.

Frequently Asked Questions

What counts as an incident that “may impact” OEM confidential data?

Treat it as a reasonable possibility based on the affected systems, compromised identities, and known data presence. Document your rationale either way and update the OEM if later facts change the impact assessment. ¹

Which timeframe do we follow if the contract language is vague?

Follow the contract language as written and document Legal’s interpretation in your OEM notice matrix. If the clause is ambiguous, standardize internal escalation so you can still send an initial notice quickly and refine details later. ¹

Do we notify the OEM if only availability is impacted (no confirmed data exposure)?

If the incident could impact OEM confidential data or the OEM’s ability to access it, treat it as potentially in scope and run the documented decision process. The requirement trigger is “may impact,” not “confirmed exfiltration.” ¹

Can our third-party provider notify the OEM on our behalf?

A provider can supply facts and draft language, but you should assume the contractual obligation remains with your organization unless the contract explicitly allows delegated notice. Keep proof that the OEM was notified via the required method within the contractual timeframe. ¹

What should we do if we don’t know which OEM’s data was involved yet?

Start with system-to-OEM mapping and use “prepare to notify” status while you investigate, but set a short internal decision deadline so you do not miss contractual timeframes. If credible exposure exists, send an initial notice with clearly labeled unknowns and planned next update. ¹

What evidence is most likely to fail an audit if it’s missing?

Proof of delivery and the decision log are the usual gaps. Auditors want to see the contract-based timeframe you followed, the time you sent the notice, and what you told the OEM about impact and corrective actions. ¹

Footnotes

1. VDA ISA Catalog v6.0