Risk Management

To meet the VDA ISA 1.3.1 risk management requirement, you need a documented, repeatable process that identifies, assesses, treats, and monitors information security risks in line with your organization’s risk appetite. Operationally, that means maintaining a living risk register, defined scoring and treatment rules, accountable owners, and evidence that decisions are made and tracked. ¹

Key takeaways:

• You must run a closed-loop process: identify → assess → treat → monitor, with documented outputs each step. ¹
• “Aligned with risk appetite” requires explicit thresholds that drive treatment decisions and escalation, not informal judgment. ¹
• Auditors will look for traceability: risks tie to assets/processes, have owners, treatment plans, and status updates with management visibility. ¹

“Risk management” in VDA ISA is not a one-time risk assessment or a set of security controls. It is an operating rhythm: a defined method for discovering information security risks, scoring them consistently, deciding what to do about them, and tracking those decisions until risk is reduced, accepted, transferred, or avoided. The requirement becomes easy to defend when you can show a risk register that matches your environment, a scoring model people actually use, and governance that ties risk decisions to business ownership.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a process design and evidence problem. You are building: (1) clear decision rules (risk appetite + criteria), (2) a repeatable workflow (intake, assessment, approvals, remediation tracking), and (3) artifacts that prove the workflow is followed. If you also manage third-party risk, connect your third-party assessments to the same scoring and treatment logic so exceptions and compensating controls are visible in one place.

This page gives requirement-level implementation guidance you can put in motion quickly and defend in a TISAX assessment against VDA ISA 1.3.1. ¹

Regulatory text

Requirement (excerpt): “Implement a risk management process to identify, assess, and treat information security risks aligned with organizational risk appetite.” ¹

What the operator must do:

• Implement a process (not a one-off activity) that covers risk identification, assessment, treatment, and monitoring. ¹
• Align the process to risk appetite, meaning you define what levels/types of risk the organization will accept and when escalation or treatment is mandatory. ¹
• Produce evidence of execution: documented methodology, risk records, decisions, and follow-through on treatments. ¹

Plain-English interpretation

You need a practical way to answer four audit questions with proof:

1. What could go wrong? (identify risks)
2. How bad is it and how likely? (assess risks consistently)
3. What did you decide to do about it? (treat: mitigate/avoid/transfer/accept)
4. Did you actually do it and keep it current? (monitor, update, report) ¹

“Aligned with risk appetite” is where teams often fail. Auditors want to see that your scoring and treatment choices follow explicit thresholds (for example: what requires mitigation vs. can be accepted), and that acceptance is authorized at the right level.

Who it applies to

Entities: Automotive suppliers and OEMs assessed against VDA ISA/TISAX expectations. ¹

Operational context (where it must work in practice):

• Product development and engineering environments (including prototypes and test systems where applicable)
• Corporate IT and end-user computing
• Manufacturing/OT interfaces where information security risks exist
• Cloud/SaaS and shared infrastructure
• Third parties that access your data, networks, tooling, or facilities (treat third-party risk as a first-class input into the same risk process)

If your organization has multiple sites or business units, define whether the risk process is centralized, federated, or hybrid, and ensure local risks can be aggregated into a management view.

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

Step 1: Define scope and risk taxonomy

1. Define what “information security risk” includes in your environment (confidentiality, integrity, availability, plus relevant business impacts like customer commitments).
2. Set the unit of analysis for risks (asset-based, process-based, system-based, or a mix). Pick one as primary to avoid duplicate entries.
3. Create a consistent taxonomy for:
   • Asset/system/process name
   • Threat scenario (what happens)
   • Vulnerability/control gap (why it can happen)
   • Impact categories (what is harmed)
   • Ownership (who can fund/execute treatment)

Operator tip: A risk register built around named systems and business processes is easier to maintain than one built around generic “risks” that never map to owners.

Step 2: Document risk appetite and decision thresholds

1. Write a risk appetite statement that is operational, not aspirational.
2. Translate appetite into thresholds that drive action:
   • What risk levels require treatment
   • What can be accepted with conditions
   • Who can approve acceptance (by threshold)
3. Define “exception” handling (temporary acceptance with expiry, compensating controls, and documented approvals).

What auditors hang up on: “We accept this risk” without documented approver, rationale, and review date is treated as unmanaged risk.

Step 3: Build the assessment method (consistent scoring)

1. Pick scoring inputs (commonly likelihood and impact) and define scales in plain language.
2. Define impact criteria tied to your environment (examples: sensitive data exposure, production downtime, customer delivery disruption).
3. Define likelihood criteria (examples: exposure to internet, known exploitability, control maturity).
4. Require inherent risk + residual risk if you want to show control effectiveness and treatment results.

Keep the method simple enough that system owners can use it without “GRC translation.”

Step 4: Stand up a risk intake and identification workflow

Create multiple intake channels, then normalize them into a single register:

• Security findings (pen tests, vulnerability scans, SOC trends)
• Audit findings and nonconformities
• Change events (new systems, major releases, network redesign)
• Third-party onboarding and renewals
• Incident postmortems

Minimum expectation: each intake becomes either (a) a risk record, (b) a tracked issue with rationale why it is not a risk, or (c) a duplicate mapped to an existing record.

Step 5: Treat risks with a standard playbook

For each risk above your appetite threshold, enforce one of these dispositions:

• Mitigate: implement controls, reduce likelihood/impact
• Avoid: stop the activity or remove exposure
• Transfer: shift impact contractually/through insurance (still track residual exposure)
• Accept: explicit approval per thresholds, with rationale and review cadence ¹

Operationalize treatment with:

• A risk treatment plan (tasks, owners, dates, dependencies)
• Links to change tickets and control implementations
• Defined “done” criteria (what proves the risk reduced)

Step 6: Monitor, report, and re-assess

1. Set review triggers: material system changes, new threats, incidents, major third-party changes, periodic review.
2. Run a recurring risk review forum with decision-makers (security, IT, engineering, procurement, legal as relevant).
3. Report risk posture to management in a way that shows:
   • Top risks by residual score
   • Overdue treatments
   • Accepted risks and expiries
   • Emerging risks from changes and incidents ¹

Step 7: Make it auditable (traceability)

Auditors test traceability. Ensure you can trace:

• Risk → affected asset/process → owner
• Risk → assessment criteria used → resulting score
• Risk → disposition decision → approver
• Risk → treatment tasks → evidence of completion
• Risk → re-assessment showing residual change ¹

Where Daydream fits naturally: If you struggle with scattered evidence (tickets in one tool, policies in another, third-party assessments in spreadsheets), Daydream can act as the system of record for risk items, link treatment tasks to artifacts, and keep an audit-ready trail without manual cross-referencing.

Required evidence and artifacts to retain

Keep these artifacts in a form you can export for an assessment:

• Risk Management Policy/Standard describing the process lifecycle and governance. ¹
• Risk appetite statement and documented approval.
• Risk assessment methodology (scales, definitions, residual vs inherent guidance).
• Risk register with required fields: scenario, asset/process, owner, score, disposition, treatment status, approvals.
• Risk treatment plans (or linked remediation tickets) with completion evidence.
• Risk acceptance records (rationale, approver, expiry/review date).
• Meeting minutes / governance outputs showing risk review decisions and escalations.
• Reporting snapshots showing risk posture over time (even simple exports are fine).

Common exam/audit questions and hangups

Expect questions like:

• “Show me your risk appetite. Where is it documented, and who approved it?” ¹
• “Pick a top risk. Walk me from identification to treatment completion, with evidence.” ¹
• “How do you ensure consistent scoring across teams/sites?”
• “How do third-party risks enter the same register and follow the same thresholds?”
• “How do you track accepted risks and ensure re-review?”

Common hangups:

• No evidence of monitoring (register exists but is stale).
• Acceptance done informally in email/Slack with no expiry.
• Risk scoring changes without documentation of why.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Building a risk register with vague entries (“Malware”, “Data breach”).
   Fix: Force scenario format: “If X happens to Y via Z, then business impact is A.” Assign an owner who can actually act.

2. Mistake: Treating vulnerability management as the entire risk program.
   Fix: Ingest vuln findings as inputs. Convert the material ones into risk records with business impact and disposition decisions.

3. Mistake: “Risk appetite” exists as a slogan, not a threshold.
   Fix: Define acceptance thresholds and approval authority. Tie them to the scoring model.

4. Mistake: No link between treatment and delivery work.
   Fix: Require every mitigation plan to map to a tracked work item and attach evidence on completion.

5. Mistake: Third-party risk runs separately.
   Fix: Put third-party risks in the same register, scored the same way, with procurement and business owners as accountable stakeholders.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement. Treat this as an assessment-driven expectation: failure typically shows up as inability to demonstrate control over security risk decisions and follow-through, which can impact customer trust and assessment outcomes under VDA ISA 1.3.1. ¹

Practical 30/60/90-day execution plan

First 30 days (establish the minimum auditable process)

• Publish a short risk management procedure: lifecycle steps, roles, governance, and required fields. ¹
• Define risk appetite thresholds and approval authority; get management sign-off.
• Stand up a central risk register (tool-based or controlled spreadsheet) and seed it with known sources: open audit issues, top security findings, key third-party exposures.
• Run one risk review meeting and record decisions.

By 60 days (make it operational across teams)

• Roll out scoring criteria and train system/process owners on how to write a risk scenario and score it.
• Implement treatment workflow: every “mitigate” disposition ties to a tracked remediation item with an owner.
• Add an acceptance workflow with expiries and periodic re-review.
• Produce a management-level risk report (top risks, overdue treatment, accepted risks).

By 90 days (mature, normalize, and prove monitoring)

• Integrate additional inputs: change management triggers, incident postmortems, third-party onboarding/renewal outputs.
• Start trend evidence: periodic exports/snapshots of the register and reporting pack.
• Perform a quality review: remove duplicates, fix vague scenarios, verify ownership and approvals.
• Run a tabletop audit: pick several risks and test traceability end-to-end against the requirement language. ¹

Frequently Asked Questions

Do we need a specific risk framework (ISO 27005, NIST, etc.) to pass VDA ISA 1.3.1?

VDA ISA 1.3.1 requires a structured process aligned to risk appetite, but it does not mandate a named framework in the provided text. Use a framework if it helps consistency, but focus on evidence that your process runs and produces decisions and follow-through. ¹

What proves “aligned with organizational risk appetite” during an assessment?

A documented appetite plus thresholds that map to your scoring and drive treatment decisions is the clearest proof. Auditors also expect to see acceptance decisions approved at the right level and revisited. ¹

Can we accept risks, or do we have to mitigate everything?

You can accept risks if your process defines acceptance criteria and approval authority, and you document rationale and review/expiry. Acceptance without governance usually fails because it cannot be shown to align with risk appetite. ¹

How detailed does the risk register need to be?

Detailed enough to show scenario, impacted asset/process, owner, score, disposition, and treatment status with evidence. If a risk cannot be assigned to an owner or linked to a treatment decision, it will be hard to defend. ¹

How do we handle third-party risks in this requirement?

Treat third-party risks as inputs to the same identification and assessment process, scored with the same criteria and governed by the same thresholds. Keep contracts, security questionnaires, and exception decisions linked to the risk record.

What if we have multiple sites and different maturity levels?

Define a common methodology and minimum required fields, then allow local teams to identify and treat site-specific risks. Centralize reporting so management can see aggregated top risks and overdue treatments. ¹

Footnotes

1. VDA ISA Catalog v6.0