Incident Response Procedure

To meet the incident response procedure requirement in VDA ISA 9.1.1, you need a documented, practiced process that covers how you detect, report, escalate, contain, resolve, and document information security incidents across your organization and relevant third parties. Operationalize it by defining roles, severity criteria, communications paths, and evidence capture, then proving it works through testing and incident records. (VDA ISA Catalog v6.0)

Key takeaways:

• Your procedure must cover the full incident lifecycle: detection through resolution and documentation. (VDA ISA Catalog v6.0)
• Auditors will look for proof of execution: tickets, timelines, decisions, approvals, and lessons learned, not just a policy. (VDA ISA Catalog v6.0)
• “Escalation” is the common failure point; pre-define severity triggers, who gets paged, and when third parties and customers are informed. (VDA ISA Catalog v6.0)

An “incident response procedure” for TISAX purposes is not a slide deck or a generic policy statement. VDA ISA 9.1.1 expects a working operational procedure that tells your teams exactly what to do when an information security incident happens: how it is detected, how it is reported internally, how it is escalated to decision-makers, how containment and remediation are executed, and how closure is documented. (VDA ISA Catalog v6.0)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat incident response as a controlled business process with defined inputs (alerts, reports), decision points (severity, regulatory/customer impact, third-party involvement), outputs (containment actions, communications, corrective actions), and records (evidence). You will also need to connect the procedure to the reality of automotive supply chains: shared platforms, engineering access, plant systems, and third parties that may detect an issue before you do.

This page gives requirement-level implementation guidance you can put into motion immediately: what to write, what to implement, what evidence to retain, and what auditors tend to challenge under this requirement. (VDA ISA Catalog v6.0)

Regulatory text

Requirement (VDA ISA 9.1.1): “Establish incident response procedures for information security incidents including detection, reporting, escalation, and resolution.” (VDA ISA Catalog v6.0)

What the operator must do

You must establish documented incident response procedures that are actually usable by operations teams. At minimum, your procedures need to:

• Define how incidents are detected (monitoring, user reports, third-party notifications). (VDA ISA Catalog v6.0)
• Define how incidents are reported (channels, required information, who receives it). (VDA ISA Catalog v6.0)
• Define how incidents are escalated (severity classification, decision authority, criteria for involving leadership and specialists). (VDA ISA Catalog v6.0)
• Define how incidents are resolved (containment, eradication, recovery, closure, documentation). (VDA ISA Catalog v6.0)

Plain-English interpretation (what this requirement really means)

If an auditor picks any recent incident, you should be able to show a consistent story:

1. someone or something detected it,
2. it was reported through a defined route,
3. severity was assessed and escalation happened according to pre-set criteria,
4. containment and remediation actions were executed with approvals where needed, and
5. the incident was closed with documented outcomes and follow-up actions. (VDA ISA Catalog v6.0)

In practice, the procedure is your “playbook.” It reduces improvisation, speeds decision-making, and creates a clean evidence trail.

Who it applies to (entity + operational context)

Entities: Automotive suppliers and OEMs operating under the VDA ISA / TISAX assessment expectations. (VDA ISA Catalog v6.0)

Operational context where auditors focus:

• IT and security operations (alerting, triage, endpoint/network response).
• Engineering and product environments where sensitive data and access rights are concentrated (e.g., prototypes, drawings, test data).
• Manufacturing/plant operations where availability incidents can be security incidents (depending on cause and impact).
• Third-party connected services (managed IT, hosting, EDI providers, remote support) where detection or root cause may sit outside your perimeter.
  Even if parts of response are performed by a third party, you still need a procedure that governs your side of detection, escalation, decisions, and documentation. (VDA ISA Catalog v6.0)

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

1) Define scope and minimum incident categories

Write down what counts as an “information security incident” for your organization and examples people recognize (email compromise, malware, unauthorized access, data sent to wrong recipient, lost device, supplier portal compromise). Keep it practical so staff will report early. (VDA ISA Catalog v6.0)

Deliverable: Incident Response Procedure (IRP) section: scope + definitions. (VDA ISA Catalog v6.0)

2) Build a simple severity model with escalation triggers

Define severity levels and objective triggers that force escalation (e.g., suspected data exfiltration, privileged account compromise, impact to a customer-connected system, involvement of a critical third party). Avoid “escalate when major” language; auditors will press for clarity. (VDA ISA Catalog v6.0)

Deliverables:

• Severity matrix (impact × likelihood, or impact-only with clear examples).
• Escalation matrix: who is notified/approves actions per severity. (VDA ISA Catalog v6.0)

3) Establish detection and intake channels that work in real life

Create at least two intake paths:

• Operational path: SOC/ITSM ticket queue, security mailbox, hotline, or on-call paging.
• Business path: a way for non-IT staff to report quickly (service desk, dedicated form, clear internal page).

Also define how you handle third-party notifications (supplier says “we had a breach,” cloud provider reports suspicious activity) and how those are triaged. (VDA ISA Catalog v6.0)

Artifacts: documented reporting channels; on-call roster or role coverage model; intake form fields. (VDA ISA Catalog v6.0)

4) Create the response workflow: triage → contain → remediate → recover → close

Document the “happy path” and decision points:

• Triage: confirm incident vs. event; preserve evidence; initial severity.
• Containment: short-term actions (disable accounts, isolate host, block indicators) with change-control expectations for high-impact actions.
• Eradication/remediation: remove malware, patch, reset credentials, fix misconfigurations, rotate keys.
• Recovery: restore services, validate integrity, monitor for recurrence.
• Closure: root cause summary, impact statement, lessons learned, corrective actions with owners. (VDA ISA Catalog v6.0)

Keep the procedure readable. One common approach is a 1–2 page “operator runbook” plus deeper appendices (forensics, communications, third-party coordination). (VDA ISA Catalog v6.0)

5) Assign roles and decision authority (RACI)

Spell out who does what:

• Incident commander (or duty manager)
• Security lead / IR lead
• IT operations lead
• Legal/privacy (as applicable to your org)
• Communications/customer interface (account teams)
• Third-party manager (for supplier coordination)

Auditors frequently challenge “shared ownership” with no named function accountable for escalation decisions. Make decision authority explicit. (VDA ISA Catalog v6.0)

6) Pre-write communication templates and approval steps

Your procedure should include:

• Internal notification template (what happened, when, current impact, actions taken, next steps).
• External/third-party request template (logs, timelines, indicators).
• Customer-facing draft update format, if customer notification is part of your contractual obligations.

Even if you decide case-by-case, the procedure should show how that decision is made and recorded. (VDA ISA Catalog v6.0)

7) Define documentation and evidence capture requirements

Require responders to record:

• timestamps for detection, triage, escalation, containment, recovery, closure
• who approved major actions
• affected assets/accounts/data types (as known at the time)
• evidence locations (log sources, imaging, email headers)
• final root cause and corrective actions (or “pending” with an owner)

Make “if it isn’t documented, it didn’t happen” a procedural rule. (VDA ISA Catalog v6.0)

8) Test the procedure and prove improvements

Run a tabletop exercise and record outcomes. Update the procedure based on gaps found (unclear escalation, missing contacts, weak logging, slow containment approvals). A stale IR document is easy to spot during assessment because nothing in tickets matches the supposed workflow. (VDA ISA Catalog v6.0)

Where Daydream fits naturally: Many teams fail on evidence quality, not intent. Daydream can help you standardize incident evidence checklists, map incidents to required artifacts, and keep IR actions, approvals, and follow-ups in one audit-ready record without building a custom spreadsheet system.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository:

• Approved Incident Response Procedure with version history and owner. (VDA ISA Catalog v6.0)
• Severity and escalation matrices; contact lists and on-call coverage model. (VDA ISA Catalog v6.0)
• Incident records (tickets/cases) showing detection, reporting, escalation, and resolution steps. (VDA ISA Catalog v6.0)
• Evidence logs: screenshots, alert IDs, SIEM extracts, email headers, access logs, forensic notes (as appropriate). (VDA ISA Catalog v6.0)
• Post-incident reviews / lessons learned; corrective action plans with owners and status. (VDA ISA Catalog v6.0)
• Exercise records (agenda, participants, scenario, decisions, improvement actions). (VDA ISA Catalog v6.0)
• Third-party communications relevant to incidents (requests, confirmations, timelines). (VDA ISA Catalog v6.0)

Common exam/audit questions and hangups

Expect questions like:

• “Show me your incident response procedure and walk me through the escalation path.” (VDA ISA Catalog v6.0)
• “Pick one incident from the last period. Show detection, reporting, escalation decision, containment actions, and closure documentation.” (VDA ISA Catalog v6.0)
• “How do users report suspicious activity? How do third parties report incidents to you?” (VDA ISA Catalog v6.0)
• “Who can declare an incident ‘major’ and who approves disruptive containment actions?” (VDA ISA Catalog v6.0)
• “How do you ensure incidents become corrective actions that actually close?” (VDA ISA Catalog v6.0)

Hangup: teams present a policy, but cannot show operational records that match the described steps. Under VDA ISA 9.1.1, the requirement is “establish procedures,” and auditors commonly interpret that as procedure + execution evidence. (VDA ISA Catalog v6.0)

Frequent implementation mistakes (and how to avoid them)

1. No clear escalation criteria. Fix: write trigger-based criteria tied to business impact and data sensitivity; route to named roles. (VDA ISA Catalog v6.0)
2. IR depends on one person. Fix: define role coverage and backups; keep contacts current. (VDA ISA Catalog v6.0)
3. Third-party incidents handled ad hoc. Fix: add a third-party incident intake and coordination step, including what evidence you request. (VDA ISA Catalog v6.0)
4. Containment conflicts with change management. Fix: pre-authorize emergency changes for defined severities and record approvals. (VDA ISA Catalog v6.0)
5. Weak documentation. Fix: standardize required fields in your ticketing tool; add an “IR evidence checklist” to every case. (VDA ISA Catalog v6.0)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. From a risk perspective, weak incident response procedures typically translate into longer incident duration, inconsistent decision-making, and poor audit outcomes because you cannot prove you detected, escalated, and resolved incidents in a controlled way. (VDA ISA Catalog v6.0)

A practical 30/60/90-day execution plan

First 30 days (stabilize)

• Appoint an IR procedure owner and confirm cross-functional roles. (VDA ISA Catalog v6.0)
• Draft the IRP with: definitions, severity model, reporting channels, escalation matrix, response workflow, documentation requirements. (VDA ISA Catalog v6.0)
• Implement a single system of record (ITSM/SOC platform) for incident tickets and required fields. (VDA ISA Catalog v6.0)

By 60 days (operationalize)

• Train service desk, IT ops, security, and key business owners on reporting and escalation. (VDA ISA Catalog v6.0)
• Build templates: internal updates, third-party evidence requests, closure report. (VDA ISA Catalog v6.0)
• Run a tabletop exercise; record gaps and assign corrective actions. (VDA ISA Catalog v6.0)

By 90 days (prove and improve)

• Close the tabletop corrective actions that affect escalation, contacts, or evidence capture. (VDA ISA Catalog v6.0)
• Validate that real incidents (or drills) produce audit-ready records aligned to your IRP steps. (VDA ISA Catalog v6.0)
• Add a management review cadence for IR metrics and lessons learned outcomes (keep it lightweight, but consistent). (VDA ISA Catalog v6.0)

Frequently Asked Questions

Do we need a formal “SOC” to meet the incident response procedure requirement?

No. You need documented procedures and a working way to detect, report, escalate, and resolve incidents. A lean on-call model can meet the requirement if it is clear and produces evidence. (VDA ISA Catalog v6.0)

Can a third party handle incident response for us?

A third party can perform parts of IR, but you still need your own procedure that defines escalation, decision authority, communications, and documentation on your side. Auditors will ask how you control and evidence the process. (VDA ISA Catalog v6.0)

What’s the minimum evidence an auditor will accept for incident handling?

Expect to show an incident record with timestamps, actions taken, escalation/approvals, and closure notes, plus supporting evidence like alerts/log extracts or communications. A policy without records is usually not enough. (VDA ISA Catalog v6.0)

How do we handle “near misses” or security events that didn’t become incidents?

Define an event-to-incident triage step and require a short record for significant events, including why it was not classified as an incident. That makes your classification defensible during assessment. (VDA ISA Catalog v6.0)

Should the incident response procedure include customer notification steps?

Include the decision path and roles for customer communication, plus how you document the decision. Whether you notify depends on contracts and facts of the incident, but the procedure should show governance and escalation. (VDA ISA Catalog v6.0)

How do we keep the procedure from becoming shelfware?

Embed it into tooling (required ticket fields, templates, checklists) and test it through exercises. Update the document when incidents reveal gaps, and keep the version history. (VDA ISA Catalog v6.0)