Change Management

The change management requirement in VDA ISA 8.2.1 means you must run every change to IT systems and applications through a formal process that includes a documented security impact assessment, testing, and approval before production release. To operationalize it, define scope, standardize change records and risk ratings, require security sign-off for in-scope changes, and retain evidence end-to-end. (VDA ISA Catalog v6.0)

Key takeaways:

• Treat “security impact assessment” as a required gate on all in-scope changes, not an optional review. (VDA ISA Catalog v6.0)
• Your audit pass depends on evidence: tickets, approvals, test results, rollback plans, and post-implementation reviews tied to each change.
• Include third parties and SaaS changes in scope; many programs fail by covering only on-prem infrastructure.

Change management is where security, uptime, and accountability meet. Under VDA ISA 8.2.1, you are expected to prove that changes to IT systems and applications do not introduce unmanaged security risk, and that you can trace each change from request to production deployment with appropriate assessment and approval. The requirement is short, but the operational expectation is not: assess security impact for all changes, test before release, approve before production, and retain evidence. (VDA ISA Catalog v6.0)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to stop debating tooling and start defining “in-scope change,” “security impact,” “required approvals,” and “minimum change record.” Once those are set, you can implement a lightweight workflow in your ITSM tool (or even a controlled ticketing process), align engineering/IT/security roles, and create an evidence pack that auditors can sample without back-and-forth.

This page gives requirement-level implementation guidance: what the requirement means in plain English, who it applies to, the steps to implement, the artifacts to retain, common audit questions, and an execution plan you can hand to IT and security owners.

Regulatory text

VDA ISA 8.2.1 excerpt: “Implement change management processes for IT systems and applications with security impact assessment for all changes.” (VDA ISA Catalog v6.0)

Operator interpretation:
You need a documented, consistently followed change management process for all changes to IT systems and applications that could affect confidentiality, integrity, or availability. Each change must have a security impact assessment, be tested, and be approved before production deployment. Your proof is the change record and its attachments, not a policy on a shelf. (VDA ISA Catalog v6.0)

Plain-English interpretation (what the requirement is really asking)

A compliant program answers four questions for every in-scope change:

1. What changed and why? (traceability)
2. What security impact could the change create? (risk visibility)
3. Was it tested and approved before going live? (control gate)
4. Can you roll it back and verify outcome after release? (resilience and accountability)

“Security impact assessment for all changes” is the key phrase. That means you define a repeatable method to decide whether a change affects security, what controls must be applied (testing, approvals, segregation of duties), and what evidence is retained. (VDA ISA Catalog v6.0)

Who it applies to

Entities: Automotive suppliers and OEMs assessed against the VDA ISA catalog (including TISAX assessments). (VDA ISA Catalog v6.0)

Operational context (what systems are in scope):

• Production IT systems: servers, endpoints, network devices, identity platforms, security tooling
• Business applications: ERP, PLM, HRIS, CRM, engineering and manufacturing apps
• Cloud/SaaS configurations: IAM settings, tenant security controls, logging, integrations
• CI/CD and infrastructure-as-code pipelines where changes are deployed automatically
• Changes executed by third parties (managed service providers, hosting providers, integrators), if they change your environment or your application behavior

Common scoping decision:
Include changes that can affect security posture or system behavior. Exclude truly cosmetic items only if you document the boundary (for example, content-only website edits with no code or config change), and you can defend it consistently during sampling.

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

Use this as an implementation checklist you can assign to IT operations, engineering, and security.

1) Define and publish “change” and “in scope”

Create a short standard that states:

• What counts as a change (code, config, infrastructure, permissions, firewall rules, certificates, integrations, SaaS security settings)
• Which environments are covered (production first, then staging and shared services)
• Which changes require a security impact assessment (practically: all in-scope changes must be assessed, even if the assessment outcome is “no security impact”)

Deliverable: Change Management Standard (or procedure) that references security impact assessment as mandatory. (VDA ISA Catalog v6.0)

2) Establish change types and minimum control gates

Define categories so teams can move fast without skipping controls:

• Standard change: pre-approved, low-risk, repeatable, with a defined implementation plan
• Normal change: requires documented risk assessment, testing evidence, approvals
• Emergency change: expedited to restore service or address critical risk, but still documented with after-the-fact review and approval

Deliverable: Change classification matrix with required steps per type.

3) Build a security impact assessment template (short, mandatory fields)

Make the assessment part of the change record. Minimum fields:

• Data impact: does it touch sensitive data, authentication, authorization, encryption, logging?
• Access impact: does it change roles, permissions, service accounts, keys, certificates?
• Exposure impact: does it change network paths, firewall rules, public endpoints, APIs?
• Availability impact: does it change redundancy, failover, backups, monitoring?
• Threat/risk notes: what could go wrong, and what mitigations are applied?

Practical rule: if the change affects IAM, network exposure, cryptography, logging, or endpoints, require security reviewer sign-off (not just the change implementer).

Deliverable: Security impact assessment section embedded in your ITSM ticket form or change request template. (VDA ISA Catalog v6.0)

4) Require testing evidence before production

Set “minimum acceptable testing” by change type and system criticality:

• Functional testing (does it work)
• Security-relevant testing (auth flows, access checks, logging, error handling)
• Regression testing where applicable
• Deployment validation steps (smoke tests, monitoring checks)

Keep it pragmatic: auditors look for evidence that testing happened and was reviewed. Screenshots, pipeline logs, test reports, or signed checklists work if they are tied to the specific change.

Deliverable: Test plan / test results attachment requirement in the change ticket. (VDA ISA Catalog v6.0)

5) Implement approval workflow and segregation of duties

At minimum:

• The implementer cannot be the sole approver for production changes when security impact exists.
• Approvals are recorded (who, when, what they approved).
• CAB-style meetings are optional; approval gates are not.

Approver set typically includes:

• Service owner (business/technical)
• Security (for security-impacting changes)
• Operations/platform owner (for production stability)

Deliverable: Documented approval workflow plus a report/export showing approvals per change. (VDA ISA Catalog v6.0)

6) Control the release: scheduling, comms, and rollback

Require each production change to include:

• Planned window (or deployment timing)
• Backout/rollback plan
• Communication plan for impacted stakeholders
• Monitoring plan for post-deploy validation

Deliverable: Implementation plan + rollback plan in the change record.

7) Do post-implementation review (PIR) for high-impact and emergencies

Define triggers for PIR:

• Emergency changes
• Changes causing incidents or near-misses
• High-risk security-impacting changes

PIR should capture: what happened, what controls failed, what to improve (including updating standard change templates).

Deliverable: PIR notes attached to the change record.

8) Extend control to third parties

If a third party makes changes in your environment:

• Require them to open your change ticket (or provide equivalent change record mapped to your fields)
• Require security impact assessment evidence
• Require notice and approval before production changes, except defined emergencies
• Contractually reserve audit/evidence rights for change records that affect your environment

Deliverable: Third-party change procedure and contract addendum language in your third-party risk management process.

9) Build an auditor-ready evidence pack (sampling-ready)

Maintain a simple “change evidence index” so you can respond fast when an assessor asks for samples.

If you use Daydream to manage third-party risk and compliance evidence, treat change management artifacts as first-class evidence objects: map each change control to required artifacts, assign owners, and keep sample-ready exports for assessments without rebuilding packets manually.

Required evidence and artifacts to retain

Retain artifacts in a way that a reviewer can trace from policy to execution:

Governance

• Change Management Policy/Standard and supporting procedures (VDA ISA Catalog v6.0)
• Change classification matrix and required gates
• Defined roles and approval authority (RACI)

Per-change evidence (for sampled changes)

• Change request/ticket with unique ID
• Security impact assessment completed (including “no impact” rationale where applicable) (VDA ISA Catalog v6.0)
• Testing evidence (test plan/results, pipeline logs, screenshots, sign-off)
• Approvals (names/roles/timestamps) prior to production deployment
• Implementation plan and rollback plan
• Post-deployment validation notes and monitoring checks
• PIR for emergencies/high-impact changes

Operational reporting

• Change calendar or release log
• Emergency change log with after-the-fact approvals and PIR references
• Exceptions register (when steps are skipped, with documented compensating controls)

Common exam/audit questions and hangups

Expect these prompts during assessment:

• “Show me a sample of recent production changes and the security impact assessment for each.” (VDA ISA Catalog v6.0)
• “How do you determine whether a change is security impacting?”
• “Who can approve changes? Can the implementer approve their own change?”
• “How are emergency changes handled, and how do you prevent ‘emergency’ from becoming the default?”
• “Do third parties follow the same process? Show evidence.”
• “Where is testing documented, and how do you know it happened before deployment?”

Hangups that slow teams down:

• No consistent definition of “security impact”
• Security reviews happening in chat/email with no ticket linkage
• CI/CD automations deploying without a recorded approval gate
• Incomplete rollback plans or no post-deploy validation evidence

Frequent implementation mistakes (and how to avoid them)

1. Policy-only compliance.
   Fix: run an internal sample test. Pull several recent changes and check if each has assessment, testing, and approvals in one place.

2. Scoping only infrastructure, ignoring SaaS and IAM.
   Fix: explicitly include identity, permissions, and SaaS tenant security settings as “changes.”

3. Emergency change abuse.
   Fix: require after-the-fact approval plus PIR, and track patterns. If the same system has frequent “emergencies,” treat it as a process failure.

4. Approvals without accountability.
   Fix: approvals must be role-based and recorded in the system of record, not a meeting note.

5. Third party blind spot.
   Fix: require change evidence from third parties and map it to your required fields before you accept the change as “closed.”

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement. (VDA ISA Catalog v6.0)

Operationally, weak change control creates two outcomes assessors care about: security regressions (access control, logging, exposure) and instability (outages, data loss). If you cannot produce evidence for a sample of changes, the assessor can reasonably conclude the process is not implemented consistently, even if it exists on paper. (VDA ISA Catalog v6.0)

Practical 30/60/90-day execution plan

Use phases to move quickly without betting the program on a long tooling project.

First 30 days (stabilize and standardize)

• Publish a one-page Change Management Standard with in-scope systems and required gates. (VDA ISA Catalog v6.0)
• Add mandatory fields to change tickets: security impact assessment, test evidence, approvals, rollback plan.
• Define approvers and enforce “no self-approval” for security-impacting production changes.
• Run a sampling dry-run: pull recent changes and document gaps as a remediation backlog.

Days 31–60 (make it consistent across teams and third parties)

• Create standard change templates for repeatable low-risk work (patching patterns, certificate rotations).
• Formalize emergency change workflow with after-the-fact approvals and PIR triggers.
• Extend requirements to third parties: evidence mapping, notice/approval expectations, and record retention.
• Build a simple change evidence index for audit response.

Days 61–90 (harden and prove)

• Add reporting: emergency change trends, overdue PIRs, changes missing security assessment.
• Align CI/CD with governance: ensure production deployments link to a change record and approval.
• Perform a second sampling dry-run and package an assessor-ready evidence set.
• Operationalize continuous improvement: update templates based on incidents and PIR findings.

Frequently Asked Questions

Does “all changes” mean even minor configuration tweaks?

If the tweak is in-scope (IT systems/applications) and could affect security posture, it needs a recorded change and a security impact assessment outcome, even if the outcome is “no security impact.” The key is consistent treatment and evidence. (VDA ISA Catalog v6.0)

What qualifies as a “security impact assessment” in practice?

A security impact assessment is a documented review of how the change affects access, data handling, exposure, logging/monitoring, cryptography, and availability. It must be tied to the specific change record and completed before production approval. (VDA ISA Catalog v6.0)

Can our CAB meeting notes count as approval evidence?

Only if you can tie the CAB decision to each specific change record and show who approved what, when, prior to deployment. Meeting notes alone often fail sampling because they are hard to map cleanly.

How do we handle emergency changes without failing the requirement?

Allow expedited implementation to restore service or address urgent risk, but still require a change record, a security impact assessment, and an after-the-fact approval with a PIR. Track emergencies to prevent the category from becoming a bypass.

Do changes made by a managed service provider need to follow our process?

Yes, if they change your IT systems or applications. If they cannot use your ticketing system, require equivalent records and map them to your required fields, then retain that evidence for sampling. (VDA ISA Catalog v6.0)

What’s the minimum evidence an assessor will expect for a sampled change?

A traceable record showing the request, security impact assessment, testing evidence, approval before production, and implementation/rollback details. If any element is missing, you should document an exception and the compensating control. (VDA ISA Catalog v6.0)