Information Security Policy

To meet the VDA ISA 1.1.1 information security policy requirement, you must have a written information security policy that is approved by top management, communicated to employees and relevant external parties, and kept current as the organization’s direction-setting document for information security (VDA ISA Catalog v6.0). Operationalize it by assigning ownership, defining mandatory topics, implementing distribution and acknowledgment, and retaining evidence.

Key takeaways:

• Top management approval must be explicit, provable, and current (VDA ISA Catalog v6.0).
• “Communicate” means controlled distribution plus tracked awareness/acknowledgment for staff and relevant third parties (VDA ISA Catalog v6.0).
• “Maintain” requires change control, periodic review, versioning, and linkage to supporting standards and procedures.

An information security policy is the document auditors reach for first because it shows intent, governance, and direction. Under VDA ISA 1.1.1, you are expected to establish, communicate, and maintain a policy approved by top management that sets the direction for information security (VDA ISA Catalog v6.0). That sounds straightforward, but teams fail assessments on the details: missing evidence of top management approval, policies written as aspirational statements with no enforceable “shall” requirements, unclear applicability to sites and subsidiaries, and weak communication records.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat the information security policy as a controlled governance artifact: define scope, state mandatory rules, map ownership and exceptions, publish it through a controlled channel, and create an audit-ready evidence pack. Then tie it to the procedures people actually follow (access control, incident response, third-party security, asset management) so the policy is not a standalone PDF.

This page translates VDA ISA 1.1.1 into requirement-level steps you can assign, track, and evidence.

Regulatory text

VDA ISA 1.1.1 requires you to: “Establish, communicate, and maintain an information security policy approved by top management that sets the direction for information security.” (VDA ISA Catalog v6.0)

What the operator must do:

1. Establish: Create a formal, documented policy (not a slide deck, not an email thread) that states the organization’s information security direction and core rules (VDA ISA Catalog v6.0).
2. Approved by top management: Obtain documented approval from top management and be able to show it to an assessor (VDA ISA Catalog v6.0).
3. Communicate: Ensure employees and relevant external parties receive the policy in a controlled way, aligned to their role and relationship to your information (VDA ISA Catalog v6.0).
4. Maintain: Keep the policy current through review, version control, and controlled updates (VDA ISA Catalog v6.0).

Plain-English interpretation (what “good” looks like)

A passing implementation looks like this: you have one primary information security policy (or a clear policy set with a top-level “umbrella” policy) that states your security objectives, assigns governance and accountability, defines mandatory behaviors, and points to supporting standards/procedures. Top management has approved the current version. People can find it, and you can prove it was communicated. Updates are controlled, traceable, and reflect how the business and risks change.

Who it applies to

Entity types: Automotive suppliers and OEMs operating under the VDA ISA/TISAX assessment scope (VDA ISA Catalog v6.0).

Operational context (where assessors focus):

• In-scope locations and functions: Sites, business units, and processes that handle customer data, prototype information, production data, or other sensitive information relevant to the assessment scope.
• IT and OT where relevant: Corporate IT and any production/engineering environments where information security requirements must be enforced.
• Third parties: External parties who access, process, host, or otherwise interact with your information (including service providers, contractors, and partners), to the extent they are “relevant external parties” for policy communication (VDA ISA Catalog v6.0).

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

1) Define scope and policy architecture

• Set scope language: Identify what the policy covers (business units, sites, systems, data types) and what is out of scope (if anything) with a clear rationale.
• Choose structure:
  • Option A: One umbrella information security policy + supporting standards (acceptable if it truly sets direction).
  • Option B: A policy suite with a top-level “Information Security Policy” that governs the suite.
• Decide the “shall” level: Write enforceable requirements using “must/shall,” not vague aspirations.

Practical example (policy scope statement): “This policy applies to all employees and contractors with access to company information or systems, and to third parties where contract terms require adherence.”

2) Draft content that sets direction (minimum topics checklist)

VDA ISA 1.1.1 is short, but assessors expect the policy to set real direction. Include at least:

• Purpose and objectives (what security outcomes you prioritize).
• Governance and accountability: Security roles, decision rights, escalation paths.
• Risk management stance: Commitment to assess and treat information security risk at an organizational level.
• Core control expectations: High-level requirements for access control, asset handling, incident reporting, secure use of systems, and third-party access.
• Compliance statement: Expectations for adherence to internal standards and contractual/customer requirements.
• Exception management: How deviations are requested, approved, time-bounded, and tracked.
• Enforcement language: Consequences for noncompliance (HR/process-based, not punitive theater).
• References: Link to supporting procedures (incident response, joiner-mover-leaver, change management, supplier security requirements).

3) Obtain top management approval (make it auditable)

You need explicit evidence that top management approved the policy (VDA ISA Catalog v6.0). Build a simple approval package:

• Final policy document (versioned).
• Approval record (signature page, approved meeting minutes, or controlled document workflow output).
• “Effective date” and “next review” fields.
• Named policy owner (often CISO/Head of IT Security) and a GRC custodian for document control.

Common hangup: A policy “reviewed by IT leadership” is not the same as “approved by top management.” Route it through the recognized top management body in your org.

4) Communicate it to employees and relevant external parties

“Communicate” is not satisfied by storing a PDF in a folder no one visits (VDA ISA Catalog v6.0). Implement a communication method you can prove:

• Employees: publish in your controlled policy repository + announce via HR or internal comms + require acknowledgment (LMS, HRIS, or attestation workflow).
• New joiners: include policy acknowledgment in onboarding.
• Relevant external parties: decide who is “relevant” based on access and data sensitivity (e.g., contractors with network access, managed service providers, engineering partners). Communicate via:
  • Contract terms referencing the policy or a third-party code of conduct,
  • Portal access with click-through acknowledgment,
  • Statement of work attachments or onboarding packs for onsite contractors.

Operator tip: Keep third-party communication targeted. You do not need to email every supplier; focus on those who touch systems/data.

5) Maintain it through controlled review and change management

“Maintain” means you manage policy lifecycle (VDA ISA Catalog v6.0):

• Assign a policy owner responsible for review and updates.
• Put it under document control: version history, change log, controlled approvals.
• Trigger updates from real events: incidents, audit findings, major IT changes, M&A, customer contractual changes.
• Ensure supporting standards/procedures stay aligned. A policy that says “MFA is required” while procedures allow exceptions without tracking will create assessment friction.

6) Build an evidence pack (so audits don’t become archaeology)

Create one folder (or GRC system record) called “Information Security Policy – Evidence” containing the artifacts listed below. This reduces scramble and prevents inconsistent versions.

Required evidence and artifacts to retain

Keep these as controlled records:

• Current information security policy (final, versioned, effective date).
• Prior versions and change log (to prove “maintain”).
• Top management approval evidence (signed approval page or governed workflow output) (VDA ISA Catalog v6.0).
• Policy distribution proof:
  • Employee acknowledgment report or training completion export,
  • Communication email/post screenshots with timestamps,
  • Intranet/policy portal publication record.
• Third-party communication evidence where relevant:
  • Contract clauses referencing policy or security requirements,
  • Contractor onboarding acknowledgment,
  • Third-party portal access logs or attestations.
• Exception register entries (if any) showing approval and expiration.
• Policy review record (meeting notes, review workflow, or periodic review signoff).

Common exam/audit questions and hangups

Expect questions like:

• “Show me top management approval for the current policy.” (VDA ISA Catalog v6.0)
  Hangup: Approval exists but is for an older version; align version numbers.
• “How do you ensure employees know the policy?” (VDA ISA Catalog v6.0)
  Hangup: You sent an email once; no acknowledgment or onboarding integration.
• “Which external parties receive the policy, and why?” (VDA ISA Catalog v6.0)
  Hangup: No definition of “relevant external parties,” so the scope looks arbitrary.
• “How do you keep this current?” (VDA ISA Catalog v6.0)
  Hangup: No review cadence, no owner, no change triggers.

Frequent implementation mistakes (and how to avoid them)

1. Policy is a copy-paste template with no decisions.
   Fix: add org-specific direction (scope, roles, minimum requirements, exception process).
2. Approval is informal or untraceable.
   Fix: use controlled approvals tied to the exact document version (VDA ISA Catalog v6.0).
3. Communication is assumed, not evidenced.
   Fix: require acknowledgment and retain reports (VDA ISA Catalog v6.0).
4. Policy conflicts with reality.
   Fix: validate key statements (MFA, encryption, incident reporting) against actual controls before publishing.
5. No linkage to procedures and standards.
   Fix: add a “Related documents” section and ensure those documents exist and are controlled.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is assessment failure or reduced confidence in your governance maturity: without a top-management-approved, communicated, maintained policy, assessors will question whether security controls are consistently directed and enforceable across sites and functions (VDA ISA Catalog v6.0). Operationally, this increases the chance of inconsistent behavior (shadow IT, unmanaged third-party access, uneven incident reporting) because teams lack a shared set of mandatory rules.

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

Use this as an operator’s runbook. Adjust scope based on organizational complexity.

First 30 days (stabilize and draft)

• Identify policy owner, document controller, and approver path to top management (VDA ISA Catalog v6.0).
• Define scope: sites, entities, key information types, and relevant external parties.
• Inventory existing policies and decide umbrella vs suite.
• Draft the policy with enforceable statements, exception process, and references to required procedures.
• Pre-review with IT, HR, Legal/Procurement (for third-party communication feasibility).

Days 31–60 (approve and publish)

• Route policy for top management approval with traceable evidence (VDA ISA Catalog v6.0).
• Publish in a controlled repository with access controls and versioning.
• Launch employee communication and acknowledgment workflow; embed in onboarding.
• Create third-party communication approach: contract language + contractor onboarding pack + targeted distribution list.
• Build the evidence pack folder and populate it as you go.

Days 61–90 (operationalize and close gaps)

• Reconcile policy statements with procedures and technical controls; open remediation tickets where mismatches exist.
• Stand up an exceptions register and approval workflow.
• Test audit readiness: run a tabletop “show me the evidence” drill with your internal audit or security team.
• Add policy review triggers to your GRC calendar and change management process (VDA ISA Catalog v6.0).

Where Daydream fits (practical, non-disruptive)

If you manage many sites, third parties, and policy acknowledgments, Daydream can act as the system of record for policy versions, approvals, distributions, and evidence packaging. The operational win is consistent artifact retention: one place to show assessors the current policy, top management approval, acknowledgment reports, and third-party attestations without stitching together emails and shared drives.

Frequently Asked Questions

What counts as “top management” approval for VDA ISA 1.1.1?

You need approval from the body recognized as top management in your organization (for example, executive management), and the approval must be traceable to the exact policy version (VDA ISA Catalog v6.0).

Do I need one policy document or multiple?

Either works if the “Information Security Policy” clearly sets direction and governs the rest. Assessors will look for clarity, enforceable requirements, and controlled maintenance (VDA ISA Catalog v6.0).

How do I prove the policy was communicated to employees?

Use a controlled distribution channel plus an acknowledgment mechanism (training/LMS attestation, HR workflow, or documented signoff) and retain the reports as evidence (VDA ISA Catalog v6.0).

Who are “relevant external parties” for communication?

External parties who access your information or systems, handle sensitive data, or operate in your in-scope environment. Define categories (contractors, managed service providers, engineering partners) and document your rationale (VDA ISA Catalog v6.0).

What if we have multiple sites with different practices?

Keep one corporate policy for direction, then allow site standards/procedures to vary where necessary through documented exceptions or site appendices under document control.

How often must the policy be reviewed?

VDA ISA 1.1.1 requires that you “maintain” the policy but does not provide a fixed interval in the provided text (VDA ISA Catalog v6.0). Set a review trigger model (periodic review plus event-based updates) and document it.