Business Continuity Management

The Business Continuity Management requirement in VDA ISA 10.5.1 expects you to implement a workable BCM program that keeps critical systems and information available during disruptions, backed by documented plans, recovery procedures, and regular testing. To operationalize it fast, define “critical,” set recovery targets, document BCP/DR runbooks, test them, and keep audit-ready evidence. (VDA ISA Catalog v6.0)

Key takeaways:

• Scope BCM to the systems, information, and services that would stop production, delivery, or secure data exchange if disrupted. (VDA ISA Catalog v6.0)
• Document recovery procedures and prove they work through structured tests and follow-up remediation. (VDA ISA Catalog v6.0)
• Treat third parties as part of the continuity boundary; their outages become your outages unless you contract and test around them.

VDA ISA 10.5.1 is a requirement-level control: you must have business continuity management that maintains availability of critical systems and information during disruptions. (VDA ISA Catalog v6.0) For a CCO or GRC lead, the fastest path is to translate “availability during disruptions” into three concrete deliverables: (1) a clear definition of critical processes, systems, and data; (2) recovery objectives and step-by-step recovery procedures; and (3) evidence that you tested those procedures and fixed what failed.

This page is written for operators supporting TISAX assessments in automotive supply chains (suppliers and OEM contexts), where availability impacts production schedules, engineering deliverables, and secure data exchange. (VDA ISA Catalog v6.0) You will see practical steps, evidence checklists, and exam-style questions that map to what assessors typically look for: documented continuity arrangements that match your real architecture and operational dependencies, including third parties such as hosting providers, logistics partners, managed service providers, and key sub-suppliers.

Regulatory text

VDA ISA 10.5.1 excerpt: “Implement business continuity management ensuring availability of critical systems and information during disruptions.” (VDA ISA Catalog v6.0)

Operator interpretation (what you must do):

• Stand up a BCM capability that can keep critical systems and information available, or restore them acceptably, during disruptive events. (VDA ISA Catalog v6.0)
• Maintain documented business continuity plans and recovery procedures that are specific to your environment, not generic templates. (VDA ISA Catalog v6.0)
• Test continuity arrangements regularly and keep evidence of results and remediation. (VDA ISA Catalog v6.0)

This is not satisfied by having a policy alone. Assessors expect proof that you know what is critical, you planned for disruption, and your plans work under test conditions. (VDA ISA Catalog v6.0)

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

Your organization can continue, or quickly resume, the business activities that matter most if you lose a site, a key application, a network segment, or a critical third party. “Availability of critical systems and information” means more than “IT is up.” It includes:

• Production and delivery commitments (where relevant to your role in the automotive supply chain).
• Engineering and customer data flows (drawings, requirements, quality records).
• Security-relevant services (identity, logging, backups) that protect confidentiality and integrity during recovery.

Who it applies to

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

Operational contexts where it matters most:

• Manufacturing and operational technology (OT) environments where downtime stops output.
• Engineering organizations exchanging sensitive customer information.
• Centralized IT (ERP, MES, PLM, email, identity) supporting multiple plants or programs.
• Heavy reliance on third parties: cloud hosting, managed security services, logistics, outsourced service desks, key component sub-suppliers.

If you depend on a third party for a critical process, that third party becomes part of your BCM scope in practice. Your BCM must address that dependency with contractual obligations, alternative processing paths, and testable recovery expectations.

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

1) Define BCM scope and governance

1. Assign an accountable owner for BCM (often InfoSec, IT, or Enterprise Risk) and named backups.
2. Define scope boundaries: sites, business units, products/programs, and in-scope systems and datasets.
3. Set minimum expectations: who declares an incident, who activates BCP, and who can authorize failover.

Deliverable: BCM charter or BCM policy plus a scope statement tied to your org and locations.

2) Identify “critical” processes, systems, and information

1. List top business services (order-to-cash, production scheduling, shipping, engineering change management, supplier onboarding).
2. Map supporting assets: applications, infrastructure, identity, connectivity, key data stores, and key people/roles.
3. Identify disruption scenarios that are realistic for your footprint: site loss, ransomware, cloud region outage, telecom outage, key supplier failure.

Deliverable: Business impact analysis (BIA) output or equivalent criticality register that names critical services, dependencies, and rationale.

3) Set recovery objectives and decision criteria

For each critical service/system/data set:

1. Define recovery time expectations (how quickly you need it back) and recovery point expectations (how much data loss is tolerable) in plain business terms.
2. Align objectives to technical design: backups, replication, high availability, manual workarounds.
3. Define “go/no-go” triggers for escalation: when to fail over, when to switch to manual processing, when to stop certain operations to protect integrity.

Deliverable: Recovery objectives matrix (service → dependency → target → owner).

4) Document BCP/DR procedures as runbooks people can execute

Write procedures at two levels:

• Business continuity procedures: manual workarounds, alternate sites, customer/supplier communications, prioritization rules (what gets restored first), and decision authorities.
• Disaster recovery procedures: technical runbooks for restore, failover, rebuild, privileged access, key management, and validation steps.

Keep runbooks operational:

• Include prerequisites (credentials, break-glass access, offline contact lists).
• Include validation criteria (how you confirm the service is correct, not just “up”).
• Include security controls during recovery (temporary access approvals, logging, malware checks) so recovery does not create a bigger incident.

Deliverable: BCP playbooks and DR runbooks mapped to the criticality register. (VDA ISA Catalog v6.0)

5) Build a testing program and capture results

Testing proves “availability during disruptions” is real. (VDA ISA Catalog v6.0)

1. Define test types: tabletop exercises, technical recovery tests, communication drills, third-party outage simulations.
2. Set success criteria per test: what “pass” means (restored service, validated data, communications sent, tickets logged).
3. Track findings to closure with owners and deadlines; retest material fixes.

A common pattern that fails assessments: “We did a tabletop once.” Tabletop exercises are useful, but they do not prove restore steps, access paths, or data integrity. Pair them with technical recovery tests for your most critical systems.

Deliverable: Test schedule, test scripts, results reports, and remediation tracking. (VDA ISA Catalog v6.0)

6) Extend BCM to third parties that support critical services

1. Identify third parties that directly enable critical services (cloud, data centers, MSPs, EDI providers, logistics, key sub-suppliers).
2. Document continuity expectations: notification timelines, recovery capabilities, and support during your incident.
3. Ensure contracts/SOWs cover continuity commitments and access to evidence (attestations, test summaries).
4. Test the dependency: simulate provider outage and confirm your workaround (alternate provider, manual path, cached operations).

If you run third-party due diligence in Daydream, treat BCM as a required control domain: collect the provider’s continuity evidence, map it to your critical services, and track gaps to remediation with the business owner. Daydream can also centralize your internal BCM artifacts so assessors see one coherent evidence set instead of scattered documents.

Required evidence and artifacts to retain (audit-ready)

Keep evidence that ties planning to execution:

• BCM policy/charter and scope statement. (VDA ISA Catalog v6.0)
• Criticality register / BIA outputs with dependency mapping.
• Recovery objectives matrix for critical services/systems/data.
• BCP documents and DR runbooks (version controlled).
• Backup and restore procedures plus proof of restore validation for key systems.
• Test program artifacts: schedules, scenarios, participant lists, results, after-action reports, and remediation tickets. (VDA ISA Catalog v6.0)
• Incident communication templates and call trees (with update cadence).
• Third-party continuity evidence for in-scope critical dependencies (contracts clauses, attestations, test summaries where available).

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me what you consider ‘critical’ and why.” They will look for a defensible method, not intuition.
• “Walk me through how System X is restored.” They want the runbook and evidence of a test, not a promise.
• “How do you know backups are restorable?” Screenshots of successful restore validation or test reports settle this quickly.
• “What happens if your cloud provider/MSP is down?” If the answer is “they handle it,” you will get follow-ups on your dependency mapping and contractual controls.
• “What changed since the last test?” They will check whether runbooks match the current architecture.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Generic BCP templates with no system-specific steps. Fix: tie every critical system to an owner, a runbook, and a validation step.
• Mistake: No clear restore priority. Fix: define restoration tiers (production first, identity early, then supporting apps) and document the rationale.
• Mistake: BCM owned by one person with no alternates. Fix: name backups and run exercises that force alternates to execute.
• Mistake: Ignoring third-party dependencies. Fix: add critical third parties to the BIA and require continuity evidence during onboarding and renewals.
• Mistake: Tests produce findings that never close. Fix: treat findings like security issues: assign, track, escalate, retest.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. (VDA ISA Catalog v6.0) Operationally, the risk is straightforward: unplanned downtime, missed customer commitments, loss of access to sensitive information, and recovery actions that weaken security (for example, rushed access grants without logging). For TISAX purposes, weak BCM commonly results in assessment findings because it is easy for an assessor to ask for test evidence and compare it to your stated recovery capability. (VDA ISA Catalog v6.0)

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign BCM ownership, backups, and activation authority.
• Draft scope and inventory critical services and their dependencies.
• Identify top disruption scenarios relevant to your operations and third-party footprint.
• Create a “minimum viable” recovery objectives matrix for the highest-impact services.

By 60 days (document and align to architecture)

• Produce BCP playbooks for critical business services.
• Produce DR runbooks for the highest-impact systems and shared services (identity, core network, core data stores).
• Implement an evidence repository with version control and clear ownership (Daydream or equivalent), including third-party continuity evidence collection.

By 90 days (prove it works)

• Run at least one tabletop exercise covering a realistic disruption scenario and executive decision points.
• Run at least one technical recovery test for a critical system, including restore validation and documented results.
• Track findings to closure, update runbooks, and schedule the next test cycle.

Frequently Asked Questions

What counts as “critical systems and information” for VDA ISA 10.5.1?

“Critical” is whatever would materially disrupt your ability to deliver products/services or protect required information if unavailable. Define it through a BIA-style method and document dependencies so an assessor can see why those assets are critical. (VDA ISA Catalog v6.0)

Do we need both a BCP and a disaster recovery plan?

Practically, yes: BCP covers business workarounds and decisioning, while DR covers technical restoration steps. VDA ISA 10.5.1 expects documented recovery procedures and testing, which usually requires both layers. (VDA ISA Catalog v6.0)

How often do we need to test?

VDA ISA 10.5.1 requires regular testing but does not specify an interval in the provided text. Set a cadence based on criticality and change rate, then document and follow it consistently. (VDA ISA Catalog v6.0)

Can we rely on our cloud provider’s resilience instead of writing our own DR runbooks?

No. You can incorporate provider capabilities, but you still need documented procedures for your configuration, your restore/failover steps, and your validation checks. Include the provider dependency in your plans and tests.

What evidence is most persuasive to assessors?

Test results tied to specific runbooks and systems, plus proof that findings were fixed. Pair that with a clear criticality register and recovery objectives matrix so the evidence forms a coherent story. (VDA ISA Catalog v6.0)

How do we handle third-party continuity evidence when providers won’t share detailed test reports?

Request higher-level attestations or summaries, contract for notification and support obligations, and focus your own testing on your workaround paths (manual operations, alternate routing, alternate providers). Track gaps and acceptance decisions in your third-party risk process.