Logging and Monitoring

To meet the TISAX (VDA ISA 6.6.1) logging and monitoring requirement, you must implement security logging across all systems that process confidential information, centralize or reliably collect those logs, and run a regular review process with alerting for security-relevant events ¹. Operationally, this means defined log sources, retention, access controls, review cadence, and documented response actions.

Key takeaways:

• Cover every system that processes confidential information, not just “core” servers ¹.
• Centralize collection (SIEM/log platform) and document regular review plus alert handling ¹.
• Evidence matters: log source inventory, configurations, review records, and incident tickets are what auditors ask for.

Logging and monitoring fails in practice for one reason: teams treat it as a tool deployment instead of an operational requirement. VDA ISA 6.6.1 expects that security-relevant events are captured across all systems processing confidential information, and that you review those logs regularly ¹. That “regular review” clause is where many programs fall down: you need people, a process, and evidence, not only telemetry.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate the requirement into a control statement you can assign and test: (1) define scope (systems processing confidential information), (2) ensure security logs are generated and collected, (3) protect and retain logs, (4) review and respond on a defined cadence, and (5) prove it with artifacts. This page gives you a requirement-level checklist you can hand to IT/SecOps, plus the exam-style questions you should pre-answer in your documentation.

If you need to scale quickly across many plants, programs, and third parties, treat logging as a coverage problem (what’s in scope, what’s actually onboarded, what’s excluded and why) and monitoring as a workflow problem (what alerts exist, who reviews them, and what “done” looks like).

Regulatory text

VDA ISA 6.6.1 excerpt: “Implement security logging and monitoring across all systems processing confidential information with regular log review.” ¹

Operator interpretation (what the requirement demands):

• “Across all systems processing confidential information” means you must identify in-scope systems and ensure they generate security-relevant logs and send them to a place you can review ¹.
• “Logging and monitoring” implies both collection and the ability to detect suspicious activity (centralized log management and alerting are explicitly expected) ¹.
• “Regular log review” requires a documented cadence, assigned roles, and evidence that reviews occur and lead to actions when needed ¹.

Plain-English requirement

If confidential information touches it, it must produce security logs, those logs must be collected in a manageable way, and someone must review them on a schedule and respond to meaningful findings ¹. Passing intent-based assessment depends less on having “all logs” and more on proving you know what you collect, why you collect it, how you detect problems, and how you show that reviews and responses happen.

Who it applies to (entity + operational context)

Entity types: automotive suppliers and OEMs ¹

Operational context (typical in-scope environments):

• Systems handling confidential customer/OEM data (engineering files, prototypes, CAD/CAE, test results).
• Identity platforms and access control components (directory services, SSO, MFA, privileged access tooling).
• Endpoints and servers used by engineering, manufacturing IT, and corporate functions if they process confidential information.
• Cloud workloads and SaaS where confidential information is stored, processed, or shared.
• Key third-party connections where your confidential information is processed on their systems; you still need logging visibility or contractual assurances and evidence.

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

1) Define scope using “confidential information processing” as the trigger

1. Write a scoping rule: “Any system that stores, transmits, or processes confidential information is in scope for security logging and monitoring.” ¹
2. Build a system inventory view for this requirement: list applications, infrastructure, endpoints, cloud services, identity, and network/security tooling that touch confidential information.
3. Document boundary decisions: if something is out of scope, record the reason (no confidential data; isolated lab; decommissioned).

Deliverable: “Logging and Monitoring Scope Register” tied to your confidential information map.

2) Define minimum log sources and event types per system class

Create a short “logging baseline” by system type. Keep it practical:

• Identity & access: authentication attempts, MFA events, privileged role changes, account lifecycle actions.
• Endpoints/servers: security agent events, OS security logs, local admin changes, malware detections.
• Applications: admin actions, data export/download, permission changes, authentication/authorization failures.
• Network/security controls: firewall denies/accepts (as feasible), VPN access, IDS/IPS alerts, secure web gateway events.
• Cloud/SaaS: admin activities, configuration changes, sharing events, access logs, key management events.

Your baseline should state: what to log, where it is collected, and what constitutes a security-relevant event that should alert ¹.

Deliverable: “Security Logging Standard” (one-pager + appendix for source specifics).

3) Centralize log collection (or prove reliable aggregation)

VDA ISA expects centralized log management as part of the requirement summary ¹. Implementation options:

• SIEM
• Managed detection and response (MDR) platform
• Central log platform with search + alerting

Operational requirements you must specify:

• Onboarding workflow: how new in-scope systems get connected.
• Time sync: consistent timestamps across sources (document NTP/time source expectation).
• Normalization and parsing: enough structure to support alert rules and investigations.
• Resilience: what happens if forwarding breaks (queueing, health checks, backlog handling).

Evidence tip: auditors often accept “centralized enough” if you can demonstrate end-to-end collection, queryability, and review records for the covered systems ¹.

4) Protect logs from tampering and restrict access

Implement and document:

• Role-based access to the logging platform.
• Admin privilege control and change tracking on the SIEM/log system.
• Separation of duties where feasible (operators vs. reviewers vs. admins).
• Integrity expectations (for example, restricted deletion, retention locks where supported).

Deliverable: “Log Access Matrix” + logging platform role list + admin change records.

5) Set retention and review expectations that you can execute

The requirement does not provide a numeric retention period; avoid inventing one. Instead:

• Define a retention period that matches your risk and operational needs.
• Document the rationale and make it consistent across similar log types.
• Ensure you can retrieve logs for investigations and assessment sampling ¹.

For review:

• Define what “regular” means in your environment (daily for high-signal alerts; scheduled review for lower-signal logs).
• Separate alert triage (reactive) from log review (proactive sampling/hunting, admin activity review, control health checks).
• Document escalation paths and what constitutes closure.

Deliverable: “Log Review Procedure” with roles, cadence, and sample review checklists.

6) Build alerting for security-relevant events and tie it to response

The requirement summary explicitly calls for alerting for security-relevant events ¹. Make this concrete:

• Maintain an “alert catalog” of enabled detections (name, description, severity, data sources, owner).
• Ensure every alert has an expected response: investigate steps, containment options, and ticketing workflow.
• Track alert disposition: true positive, benign positive, false positive, tuning change.

Deliverable: Alert catalog + sample tickets showing triage and closure.

7) Prove “regular review” with durable evidence

Assessment teams typically sample evidence. Make it easy:

• Store review checklists and outcomes in a ticketing system or GRC tool.
• Keep meeting notes or daily/weekly triage summaries.
• Link notable findings to incident records, problem management, or corrective actions.

If you’re coordinating across plants or subsidiaries, Daydream can help you standardize evidence collection by mapping each in-scope system to required artifacts (log forwarding proof, review records, access lists) and tracking exceptions so you can walk into an assessment with a complete package instead of screenshots scattered across teams.

Required evidence and artifacts to retain

Use this as your audit binder checklist:

• Scope register of systems processing confidential information and their logging status ¹.
• Security Logging Standard (baseline requirements by system type).
• Architecture diagram showing log flow from sources to centralized log management.
• Configuration evidence (screenshots/exports) showing log forwarding enabled for representative in-scope systems.
• Access control evidence: SIEM/log platform user/role listing; admin roles; access approval records.
• Review records: dated log review tickets/checklists; alert triage queue exports; analyst notes.
• Incident/response linkage: tickets showing investigation, containment, and closure for security-relevant events.
• Exception register: systems not onboarded, compensating controls, and remediation plan.

Common exam/audit questions and hangups

1. “Show me all systems processing confidential information and how each is logged.” Hangup: no single inventory view.
2. “Who reviews logs, how often, and what do they do when they find something?” Hangup: review is informal with no records ¹.
3. “Is your log management centralized? Can you query across environments?” Hangup: split tools with no unified review process ¹.
4. “How do you know log collection is working?” Hangup: no health checks; broken forwarding discovered late.
5. “Can administrators delete or alter logs?” Hangup: excessive admin access; no separation of duties.

Frequent implementation mistakes and how to avoid them

• Mistake: logging only perimeter devices. Fix: start scope from confidential information flows, then cover endpoints, identity, apps, cloud ¹.
• Mistake: “we have a SIEM” as the control. Fix: document review cadence, roles, and show tickets or checklists proving regular review ¹.
• Mistake: collecting everything, reviewing nothing. Fix: define a minimum viable alert set and a routine review playbook; add sources iteratively.
• Mistake: no ownership for onboarding. Fix: create a joiner process: any new in-scope system must include log forwarding as a go-live gate.
• Mistake: weak evidence hygiene. Fix: standardize artifact capture (exports, screenshots, tickets) and store them in a controlled repository.

Enforcement context and risk implications

Public enforcement cases were not provided in the source catalog for this requirement, so this page does not cite specific cases. Practically, weak logging and monitoring increases the chance that security incidents go undetected, prevents reliable root cause analysis, and makes it difficult to demonstrate control effectiveness during a TISAX assessment ¹.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and prove “regular review”)

• Produce the scoped system list tied to confidential information processing.
• Publish a logging baseline (what to log by system class).
• Stand up a repeatable review workflow: alert triage + scheduled log review with ticket evidence ¹.
• Identify quick-win high value sources: identity logs, endpoints, key applications, remote access.

By 60 days (centralize and harden)

• Expand log onboarding to remaining high-risk in-scope systems.
• Implement or tighten centralized log management coverage ¹.
• Lock down log access roles; document admin controls.
• Create an alert catalog with owners and response steps.

By 90 days (operational maturity and assessment readiness)

• Add monitoring health checks and reporting (collection gaps, noisy alerts, coverage by system).
• Run a tabletop on a detection scenario using your logs (prove you can investigate).
• Finalize your evidence pack: scope register, configurations, reviews, tickets, and exceptions ready for sampling.

Frequently Asked Questions

What counts as “regular log review” for VDA ISA 6.6.1?

The requirement expects a defined cadence and documented activity, not ad hoc spot checks ¹. Set a schedule you can execute, assign owners, and keep review records (tickets or checklists) that show what was reviewed and what actions were taken.

Do we need a SIEM to meet the logging and monitoring requirement?

VDA ISA’s summary calls for centralized log management and alerting ¹. A SIEM is a common way to do that, but the key is proving centralized collection, query capability, controlled access, and evidence of review.

How do we handle logging for SaaS platforms that process confidential information?

Turn on available audit and security logs, route them to your centralized logging platform where feasible, and document limitations with compensating monitoring ¹. Keep admin activity and sharing events in your baseline because those are frequent investigation needs.

What evidence is most convincing to an assessor?

A scoped inventory mapped to log sources, plus dated review tickets and alert investigations that show follow-through ¹. Configuration exports or screenshots that demonstrate log forwarding for sampled systems typically close the loop.

Can we exclude lab or plant systems if they’re hard to integrate?

Only if you can show they do not process confidential information, or you document an exception with rationale, compensating controls, and a plan ¹. Undocumented exclusions are a common assessment failure mode.

How should third parties fit into logging and monitoring?

If a third party processes your confidential information, you need contractual and operational assurance that security-relevant events are logged and reviewed, plus a way to obtain relevant records during incidents. Track those expectations in your third-party due diligence and your exception register ¹.

Footnotes

1. VDA ISA Catalog v6.0