Access Control Policy

An Access Control Policy for TISAX (VDA ISA 6.2.1) must document how you grant, change, review, and remove access across all information systems using least privilege and need-to-know. To operationalize it fast, define role-based access rules, enforce a consistent access request/approval workflow, prove periodic access reviews, and retain evidence that access aligns to job duties. (VDA ISA Catalog v6.0)

Key takeaways:

• Your policy must translate “least privilege” into enforceable rules: roles, approvals, exceptions, and reviews. (VDA ISA Catalog v6.0)
• Auditors will test operation, not prose: joiner/mover/leaver records, access review results, and privileged access controls. (VDA ISA Catalog v6.0)
• The fastest path is standardization: one intake, one approval matrix, one access review cadence, and measurable exceptions. (VDA ISA Catalog v6.0)

VDA ISA 6.2.1 is simple on paper and painful in practice: implement access control policies based on least privilege and need-to-know for all information systems. (VDA ISA Catalog v6.0) The operational challenge is scope. “All information systems” includes corporate IT (email, endpoints, collaboration tools), identity systems (directory/IAM), infrastructure (cloud consoles, network devices), business apps (ERP, CRM), and environments that touch customer data or sensitive automotive information.

For a Compliance Officer, CCO, or GRC lead, the goal is not to write a generic policy. The goal is to create a policy that drives consistent execution across teams that actually provision access: IT, Security, application owners, and HR. That means you need clear decision points (who can approve what), consistent artifacts (tickets, approvals, review reports), and an exception process that you can defend during assessment.

This page gives requirement-level implementation guidance: who must follow the policy, what steps to implement, what evidence to keep, and where audits usually stall.

Regulatory text

Requirement (VDA ISA 6.2.1): “Implement access control policies based on least privilege and need-to-know principles for all information systems.” (VDA ISA Catalog v6.0)

What the operator must do

You need a documented Access Control Policy that:

• Defines least privilege and need-to-know as operational rules, not slogans. (VDA ISA Catalog v6.0)
• Covers the full access lifecycle: request, approval, provisioning, modification, review, and removal. (VDA ISA Catalog v6.0)
• Applies across all systems in scope, including systems operated by third parties where your users have access or where your data is processed. (VDA ISA Catalog v6.0)
• Governs authorization, meaning it must specify how access is granted based on job duties (roles), not ad hoc decisions. (VDA ISA Catalog v6.0)

Plain-English interpretation (what this means in real life)

Only the people who need access to do their jobs should have it, and they should have the minimum access required. “Need-to-know” is the data angle (who needs to see specific information). “Least privilege” is the permissions angle (what actions they can take in systems). Your policy must make both enforceable through documented roles, approvals, and reviews. (VDA ISA Catalog v6.0)

If you cannot answer “who approved this access, based on what role, and when it was last reviewed” for a sample of users, you should treat the control as not implemented.

Who it applies to

Entity scope

• Automotive suppliers and OEMs seeking to meet TISAX expectations aligned to VDA ISA. (VDA ISA Catalog v6.0)

Operational scope (who must follow it)

• IT operations and IAM/Directory administrators
• Information Security (policy owner or control owner)
• Application owners (ERP, PLM, CRM, ticketing, manufacturing systems if in scope)
• HR (trigger for joiner/mover/leaver events)
• Facilities/Physical Security if badge access and building entry are included as “information system” access paths in your environment
• Third parties: contractors, service providers, managed service providers, and any external users accessing your systems or data

System scope (what “all information systems” means)

Build and publish a list of in-scope systems, then map each to an access model:

• Central identity (SSO/IAM, directory)
• End-user computing (endpoints, MDM, local admin)
• Collaboration and email
• Cloud control planes
• Business applications
• Databases and file shares
• Network/security devices (VPN, firewalls, EDR consoles)
• Developer tools and repositories if they store or access sensitive information

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

1) Assign ownership and define policy boundaries

• Name a policy owner (often Security/GRC) and control operators (IAM/IT plus app owners).
• Define what the policy covers: user access, privileged access, service accounts, API tokens, third-party access, and remote access.

Deliverable: Access Control Policy with an appendix that lists in-scope systems and ownership.

2) Define your access model (RBAC is the default)

Write down how authorization works:

• Role-based access control (RBAC): roles aligned to job functions (e.g., “Accounts Payable Clerk,” “Plant Engineer,” “Sales Ops”).
• Attribute-based rules (optional): region, site, employment type, project assignment.
• Data need-to-know rules: which roles can access sensitive categories and what approvals are required.

Practical tip: start with your top business apps and IAM. If you try to model every system at once, you will end up with exceptions that become the real process.

Deliverable artifacts:

• Role catalog (role → permissions → systems)
• Role-to-approver matrix (who can approve each role)

3) Standardize the access request and approval workflow

Your policy should require:

• A single intake path (ticketing system, IAM workflow tool, or HR-driven onboarding).
• Required fields: requester, user, role requested, business justification, system, manager, data owner (where relevant), start/end date for time-bound access.
• Approval rules:
  • Manager approval for job alignment
  • System/app owner approval for system impact
  • Data owner or security approval for sensitive roles (especially admin or broad data access)

Deliverable artifacts:

• Workflow diagram
• Approval rules documented in the policy or standard

4) Implement joiner/mover/leaver controls that actually remove access

Audits frequently fail on “leaver” execution. Your policy should require:

• HR-triggered termination notifications routed to IT/IAM
• A defined removal process for:
  • SSO/directory account disabling
  • Application access removal
  • Privileged access revocation
  • Token/key invalidation where applicable
• Handling for contractors and third-party identities (often missed)

Evidence you need: termination samples showing same-day or prompt deprovisioning per your internal standard (state the standard in policy and meet it).

5) Control privileged access separately

Least privilege becomes concrete when you treat admin access as a controlled exception:

• Define privileged roles (domain admin, cloud admin, database admin, security console admin).
• Require stricter approvals and logging.
• Require administrative access to be time-bound or separate accounts where feasible.

If you can’t implement tooling immediately, start with process controls: named list of privileged users, documented approvals, and periodic review results.

6) Run periodic access reviews and track remediation to closure

Your policy needs a review mechanism that proves least privilege remains true over time:

• Identify “high-risk systems” (systems with sensitive data or powerful permissions) and review them first.
• Require reviewers to certify:
  • user still employed/engaged
  • role still correct
  • no toxic combinations (define these for your environment)
• Track findings and removals as tickets with closure evidence.

GRC execution pattern that works: access review produces a report, findings create tickets, tickets close with screenshots/export logs, and the report references ticket IDs.

7) Create an exception process you can defend

Least privilege has exceptions. The question is whether you control them. Policy requirements for exceptions:

• Written justification
• Time-bound duration or review date
• Compensating controls (monitoring, logging, secondary approval)
• Approval by a defined authority
• Recorded in an exception register

8) Extend the policy to third-party access

Where third parties access your systems or data:

• Require named accounts (avoid shared accounts where possible)
• Contractual requirement or procedure for access removal at end of engagement
• Sponsor/owner inside your organization responsible for review and removal

9) Make it auditable

Before you declare done, test it like an assessor:

• Pick a set of users across departments and verify:
  • ticket exists
  • approvals match matrix
  • access matches role definition
  • leaver access removed
• Pick privileged accounts and confirm approvals, logs, and review evidence.

Required evidence and artifacts to retain

Keep these in a single audit-ready folder or GRC system, indexed by system and period:

• Access Control Policy (approved, versioned, with effective date) (VDA ISA Catalog v6.0)
• System inventory or “in-scope systems” list with owners (VDA ISA Catalog v6.0)
• Role catalog and role-to-approver matrix (VDA ISA Catalog v6.0)
• Access request tickets (joiner/mover), with approvals and provisioning proof (VDA ISA Catalog v6.0)
• Deprovisioning evidence (leaver tickets, account disable logs, app removal confirmations) (VDA ISA Catalog v6.0)
• Privileged access list, approvals, and review results (VDA ISA Catalog v6.0)
• Periodic access review packages: reviewer attestations, results, remediation tickets, closure proof (VDA ISA Catalog v6.0)
• Exceptions register with approvals and expiration/review dates (VDA ISA Catalog v6.0)
• Training/communications that show operators know the process (recommended)

Tooling note: Daydream can help you centralize evidence, map it to VDA ISA 6.2.1, and keep review packages consistent across systems, which reduces the “spreadsheet archaeology” that slows assessments.

Common exam/audit questions and hangups

Assessors commonly push on:

• “Show me that least privilege exists in practice for a sensitive system.” Expect sampling of users and permissions. (VDA ISA Catalog v6.0)
• “How do you ensure access is removed when people leave?” They will ask for leaver samples and timestamps. (VDA ISA Catalog v6.0)
• “Who approves access and how do you prevent self-approval?” Approval matrix gaps are a common hangup.
• “How do you handle third-party access?” Shared accounts and unclear sponsorship fail quickly.
• “Where is your access review evidence and remediation trail?” Reviews without ticketed remediation look ceremonial.

Frequent implementation mistakes (and how to avoid them)

1. Policy exists, process doesn’t. Fix: require ticket-based provisioning and make “no ticket, no access” enforceable for admins.
2. RBAC defined only for one system. Fix: start with IAM + top apps, publish a roadmap for remaining systems, and track exceptions until onboarded.
3. Access reviews happen, removals don’t. Fix: tie review findings to tickets and report closure rates to management.
4. Privileged access treated like normal access. Fix: separate privileged roles, approvals, and review packaging.
5. Contractors fall through the cracks. Fix: require an internal sponsor, end-date access, and a monthly check of active third-party accounts.
6. “Need-to-know” not mapped to data. Fix: define sensitive data categories in a short appendix and map them to roles/systems.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat “enforcement” here as assessment risk. Access control failures create direct risk: unauthorized access to sensitive automotive information, data leakage via over-permissioned accounts, and uncontrolled administrator actions. In TISAX terms, weak evidence for access provisioning and review often becomes a high-friction assessment area because it touches multiple systems and teams. (VDA ISA Catalog v6.0)

Practical execution plan (30/60/90)

First 30 days: establish control design and stop the bleeding

• Publish a minimum Access Control Policy with: least privilege definition, required approvals, joiner/mover/leaver process, privileged access rules, access review requirement, exception handling. (VDA ISA Catalog v6.0)
• Inventory in-scope systems and name owners.
• Implement “single intake” for new access (ticket/workflow) for your top systems.
• Freeze informal admin grants; require documented approval for privileged access.

Days 31–60: operationalize across priority systems

• Build the role catalog for top systems (IAM, email/collab, ERP/PLM or other crown jewels).
• Implement the approver matrix and remove self-approval paths.
• Run your first access review on one high-risk system; remediate findings with tickets.
• Establish third-party access sponsorship and end-date controls.

Days 61–90: prove repeatability and expand coverage

• Extend RBAC and access reviews to additional systems based on risk.
• Formalize privileged access reviews and tighten evidence (lists, approvals, logs).
• Mature exception handling: central register, expirations, compensating controls.
• Package evidence for assessment: policy + samples for joiner/mover/leaver + access reviews + privileged access controls.

Frequently Asked Questions

Do we need one Access Control Policy for every system?

No. You need one policy that sets organization-wide rules, plus system-specific standards or procedures where complexity demands it. The assessor will still expect you to show the policy applies across all information systems. (VDA ISA Catalog v6.0)

What counts as “need-to-know” in practice?

Treat it as a rule that limits data visibility to roles with a documented business purpose. Document which roles can access which sensitive data categories and require data owner approval for exceptions. (VDA ISA Catalog v6.0)

How do we handle access if an application can’t do RBAC cleanly?

Document the limitations, then implement compensating controls: stricter approvals, smaller admin group, monitoring/log review, and more frequent access reviews for that system. Track it as an exception until you can improve the authorization model. (VDA ISA Catalog v6.0)

Are quarterly access reviews required?

VDA ISA 6.2.1 requires access control based on least privilege and need-to-know, but the provided text does not specify a review frequency. Set a frequency based on system risk and be consistent, then retain evidence that reviews occur and removals happen. (VDA ISA Catalog v6.0)

How should we control third-party access for contractors?

Require a named internal sponsor, role-based access, and an end date at provisioning. On disengagement, remove access through the same leaver process and retain the deprovisioning evidence. (VDA ISA Catalog v6.0)

What evidence is “good enough” for provisioning and removal?

A ticket or workflow record with approvals, plus a system log/export or admin screenshot showing the account/role was added or removed. For reviews, keep the reviewer sign-off and the remediation trail to closure. (VDA ISA Catalog v6.0)