Security Awareness and Training

To meet the security awareness and training requirement in VDA ISA 1.5.1, you must provide information security awareness training to all employees and deliver additional role-specific security training aligned to each person’s function (for example, IT administration and software development). Operationalize it by defining training audiences, setting a cadence, tracking completion, and retaining evidence that the right people received the right content. (VDA ISA Catalog v6.0)

Key takeaways:

• You need two layers: baseline awareness for everyone, plus role-specific training for security-sensitive roles. (VDA ISA Catalog v6.0)
• Auditors look for coverage, relevance, and proof (rosters, content, completion, exceptions, and follow-up).
• Training must be tied to roles and actual risks in your environment, not a generic annual video.

“Security Awareness and Training” is easy to describe and easy to fail in practice. Most gaps come from treating training as a one-time HR checkbox rather than an operational control that changes behavior in engineering, IT operations, and customer-facing teams. VDA ISA 1.5.1 is explicit: everyone gets security awareness training, and people in security-sensitive functions get training tailored to their responsibilities. (VDA ISA Catalog v6.0)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to convert the requirement into a training matrix tied to your role catalog, then build a repeatable workflow: assign, deliver, track, remediate non-completion, and retain evidence. You also need a clean way to handle edge cases (contractors, temps, leaves of absence, shared accounts, and external developers).

This page gives requirement-level implementation guidance you can put into a control design doc and run as a program. It focuses on what assessors typically ask for: who was trained, on what, when, why that content fits the role, and what you did when someone didn’t complete it.

Regulatory text

Requirement (VDA ISA 1.5.1): “Ensure all employees receive information security awareness training and role-specific security training appropriate to their function.” (VDA ISA Catalog v6.0)

Operator interpretation (what you must do):

1. Cover every employee with baseline security awareness. “All employees” means you should not limit training to office staff or IT. Your scope must include production, engineering, sales, and shared services, as applicable. (VDA ISA Catalog v6.0)
2. Add role-specific security training for security-sensitive functions. The requirement expects additional depth where job duties create higher security impact, explicitly including IT administration and development as examples. (VDA ISA Catalog v6.0)
3. Make training appropriate to function. Appropriateness is demonstrated through role mapping and content relevance, not by asserting “everyone took the same module.” (VDA ISA Catalog v6.0)

Plain-English requirement: what “good” looks like

You can explain compliance in one sentence to an assessor:
“We train everyone on baseline security behaviors, we train high-impact roles on the security tasks they perform, we track completion, and we keep evidence that training aligns to each role.” (VDA ISA Catalog v6.0)

A working program has:

• A defined population (who must be trained, including joiners and movers).
• A training matrix mapping roles to required modules.
• A delivery mechanism (LMS, HR platform, or managed workflow).
• Completion tracking plus escalation for overdue training.
• Evidence that content is current enough to match your environment and responsibilities.

Who it applies to

Entity types: Automotive suppliers and OEMs using the VDA ISA catalog, including organizations pursuing or maintaining TISAX alignment/assessment expectations. (VDA ISA Catalog v6.0)

Operational context (who you should include):

• Employees: Full-time, part-time, interns, apprentices.
• Privileged internal users: IT admins, OT admins (if applicable), system owners, database admins.
• Engineering and development: Developers, QA, DevOps, build/release, architects.
• People who handle sensitive information: Customer program teams, purchasing, finance, HR, legal, and anyone accessing confidential project data.
• Third parties working “like staff”: Long-term contractors or outsourced functions with corporate accounts or access to systems/data. If they are not “employees” legally, treat them as in-scope operationally because the risk is the same, and assessors commonly ask how you handle them.

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

1) Define your training scope and ownership

• Name one accountable owner (often Security Governance, GRC, or HR + Security as co-owners).
• Write a short standard: “Security Awareness and Role-Based Training Standard” that states:
  • Who must complete baseline awareness.
  • Which roles require additional training.
  • How completion is tracked and enforced.
  • How exceptions work (if any).

Deliverable: a one-page standard plus a RACI for Security, HR/L&D, IT, and Engineering.

2) Build a role-to-training matrix (the core artifact)

Create a table mapping job functions to modules. Keep it tight and defensible.

Example training matrix (adapt to your environment):

Audience	Baseline awareness	Role-specific modules (examples)	Evidence to show assessor
All employees	Acceptable use, phishing/social engineering, password hygiene, reporting incidents	N/A	LMS roster, completion logs, content outline
IT admins	Baseline + privileged access behaviors	Privileged access, secure configuration, log review responsibilities, incident response tasks	Admin role roster + module assignments
Developers/DevOps	Baseline	Secure coding practices, secrets handling, dependency hygiene, change control expectations	SDLC role roster + module completion
Managers	Baseline	Data handling expectations, access approvals, onboarding/offboarding responsibilities	Manager training completion + SOP references

The requirement does not prescribe topics beyond “awareness” and “appropriate to function,” so your job is to show a rational mapping that fits your risk areas and responsibilities. (VDA ISA Catalog v6.0)

3) Set training events: onboarding + recurring + change-driven

Operationalize training as three triggers:

• Onboarding training: Assign baseline (and role-based if applicable) when the person starts.
• Recurring refresh: Set a recurring cadence that your organization can meet consistently.
• Change-driven training: Assign role-based training when someone changes roles (for example, promoted to admin) or when you introduce a material process/tool change (new ticketing workflow for access, new code scanning standard).

Avoid over-engineering. Consistency and evidence matter more than novelty.

4) Implement tracking, escalation, and remediation

You need a workflow that answers: “What happens if someone doesn’t complete training?”

• Automated reminders (LMS or HR workflow).
• Manager escalation for overdue training.
• Access gating for high-risk roles where feasible (for example, admin access conditional on completion). If you cannot gate, document the alternative control (manager escalation + exception record).

Keep an exceptions register. Make it boring and auditable: person, role, reason, compensating controls, approval, and expiry.

5) Validate role-based coverage for security-sensitive functions

Assessors often test whether your “role-based” training is real or just a label. Do a quarterly spot-check:

• Pull list of privileged accounts and admins.
• Pull list of developers with repo access or CI/CD permissions.
• Confirm those users are assigned the correct modules and completed them.

If you find drift, fix the role mapping and the joiner/mover workflow. That’s usually the root cause.

6) Retain evidence in an audit-ready package

Create a single folder (or GRC control record) that contains:

• The standard/policy.
• The role-training matrix.
• Training content outlines (and version history if you have it).
• Completion reports (by population and by role-based audiences).
• Exception records and closure evidence.
• A short annual review note: what changed in content, what changed in audiences, and what issues were found and corrected.

If you run the program in Daydream, store this as the control “system of record,” attach the matrix, and map evidence requests to recurring exports (completion logs, audience rosters) so audits don’t become spreadsheet archaeology.

Required evidence and artifacts to retain

Minimum evidence that typically satisfies VDA ISA 1.5.1 expectations:

• Security Awareness and Training Standard referencing baseline + role-based requirements. (VDA ISA Catalog v6.0)
• Role-based training matrix showing “appropriate to function.” (VDA ISA Catalog v6.0)
• Training content/materials (outlines, slides, or vendor module descriptions).
• Training assignment and completion records:
  • By employee population (baseline).
  • By role-based population (IT admins, developers, etc.). (VDA ISA Catalog v6.0)
• Attendance/completion attestations for instructor-led sessions (if used).
• Exception log (with expiry) and evidence of follow-up.
• Onboarding and role-change workflow evidence (ticket, HR workflow, or procedure excerpt) showing how training gets assigned.

Common exam/audit questions and hangups

Expect these, and pre-answer them in your evidence pack:

1. “How do you define ‘all employees’?” Show your population source (HRIS export) and how you reconcile it to LMS rosters.
2. “Which roles get role-based training, and why?” Produce your matrix and a short rationale (privilege, data sensitivity, customer requirements, system access).
3. “How do you know developers/admins really completed their modules?” Provide role rosters and completion reports.
4. “What happens when training is overdue?” Show escalation steps and examples of closures.
5. “How do contractors fit?” Show how you include them (or document limits and compensating controls).

Frequent implementation mistakes (and how to avoid them)

• Mistake: One generic module for everyone.
  Fix: Keep baseline universal, then add role-based modules for IT administration and development at minimum, plus other sensitive roles you identify. (VDA ISA Catalog v6.0)

• Mistake: No reliable population source.
  Fix: Use HRIS as the source of truth, reconcile against LMS monthly, and document the reconciliation.

• Mistake: Role-based training defined but not assigned automatically on role change.
  Fix: Implement a joiner/mover workflow trigger (HR change event or access request ticket) that assigns training.

• Mistake: “Training completed” but no proof of content relevance.
  Fix: Retain module outlines and version dates, and tie each module to job responsibilities in the matrix.

• Mistake: Exceptions that never expire.
  Fix: Add an expiry date and require re-approval, or remove exceptions entirely for high-risk roles.

Enforcement context and risk implications

No public enforcement cases were provided in the source materials for this requirement. Practically, the risk is straightforward: poor awareness increases the likelihood of user-driven incidents (phishing, misdelivery, weak password practices), while weak role-based training increases the likelihood of technical control failures (misconfiguration, insecure code, mishandled privileges). VDA ISA 1.5.1 focuses your program on the people most likely to create or prevent those failures: everyone, plus high-impact roles. (VDA ISA Catalog v6.0)

Practical execution plan (30/60/90-day)

Use this as an execution checklist. Adjust sequencing based on your audit calendar and tooling.

First 30 days (stand up the control)

• Assign control owner and define scope populations (employees + in-scope third parties with access).
• Draft and publish the Security Awareness and Training Standard.
• Build the first version of the role-to-training matrix, explicitly covering IT admins and developers. (VDA ISA Catalog v6.0)
• Select delivery mechanism (LMS or equivalent) and confirm you can export completion evidence.

Next 60 days (operate and prove)

• Launch baseline awareness training to the full population.
• Launch role-based modules to targeted groups (admins, developers, other sensitive functions).
• Implement reminders and manager escalation for overdue items.
• Create the evidence pack structure and start storing monthly exports.

By 90 days (stabilize and audit-proof)

• Run a reconciliation: HR roster vs LMS completion; remediate gaps.
• Run a role-based coverage check: privileged users and developers vs training assignments and completions.
• Close out exceptions or document compensating controls with expiry.
• Write a short program review note and capture improvements (role mapping fixes, content updates).

Frequently Asked Questions

Do contractors and consultants need security awareness training?

If they have accounts, system access, or handle your sensitive information, treat them as in-scope operationally and train them to the level appropriate to their function. Keep their completion evidence alongside employee evidence so you can answer coverage questions quickly. (VDA ISA Catalog v6.0)

What counts as “role-specific” security training for developers?

Training should reflect what developers do in your environment, such as secure coding expectations, secrets handling, and approved change pathways. The key is a documented mapping between the development role and the modules you assigned. (VDA ISA Catalog v6.0)

Can we meet the requirement with instructor-led training instead of an LMS?

Yes, if you can prove attendance, content, and who was required to attend. Keep sign-in sheets (or meeting attendance exports), the deck/outline, and the role roster that shows why those attendees were targeted. (VDA ISA Catalog v6.0)

How do we show the training is “appropriate to their function” without over-documenting?

A simple role-training matrix plus module outlines usually does the job. Add a short rationale column for the most sensitive roles (admins, developers) and keep the rest lightweight. (VDA ISA Catalog v6.0)

What do auditors usually flag first?

Coverage gaps and weak evidence packaging. If you cannot reconcile “all employees” to a completion report, or you cannot list which roles require extra training, the program looks informal even if training happened. (VDA ISA Catalog v6.0)

How can Daydream help without turning this into a tool-driven project?

Use Daydream as the control record and evidence hub: store the matrix, attach recurring completion exports, and track exceptions with expiry so you can answer assessor requests from one place. That keeps the program operational without adding documentation overhead.