Access Control Systems
To meet the TISAX / VDA ISA 3.2.2 access control systems requirement, you must deploy electronic access control for all defined secure areas using badge readers, PINs, or biometrics, then operate it as a controlled process: approve access based on role/need, log access events, and trigger alerts on unauthorized attempts. Document the scope, rules, and evidence for assessments.
Key takeaways:
- Electronic access control must cover every “secure area,” not just the main entrance 1.
- Auditors will look for end-to-end operation: provisioning, deprovisioning, logging, and alert handling 1.
- Your fastest path is a clean area inventory, a mapped authorization model, and retained logs plus access reviews.
Footnotes
“Access control systems” under VDA ISA 3.2.2 is a physical security control with a strong information security purpose: stop unauthorized people from reaching spaces where sensitive assets exist (confidential documents, prototypes, test benches, servers, labs, production controls, or restricted engineering areas). The requirement is not satisfied by a policy statement, a receptionist, or a mechanical key cabinet alone. It expects electronic access control for secure areas, using badge readers, PIN codes, or biometric authentication, plus operational behaviors that make the system reliable during audits and real incidents 1.
For a Compliance Officer, CCO, or GRC lead, the practical challenge is scoping and proving completeness. “Secure areas” must be explicitly defined, mapped to real doors and entry points, and tied to who can enter and why. Evidence must show that access is granted based on authorization, removed promptly when no longer needed, and monitored through logs and alerts for unauthorized attempts 1.
This page gives you requirement-level guidance you can hand to facilities, security, and IT, with clear artifacts to retain for TISAX assessments.
Regulatory text
Requirement excerpt: “Deploy electronic access control systems for secure areas with badge readers, PIN codes, or biometric authentication.” 1
Operator interpretation (what the assessor expects):
- Electronic controls on secure-area boundaries. Each secure area needs an electronic mechanism that enforces entry rules (badge, PIN, or biometrics), not a manual sign-in sheet alone 1.
- Access logging. The operating expectation includes logging of access events so you can reconstruct who entered and when 1.
- Automated alerting on unauthorized attempts. You need a way to detect and respond when someone tries to access a secure area without authorization 1.
Plain-English requirement (what it means day to day)
- Decide which spaces are “secure areas.” If an unauthorized person in that space could expose customer confidential information, prototypes, regulated data, or critical systems, treat it as secure.
- Put electronic access control at every way in. Doors, gates, turnstiles, internal cages, lab entries, and server room doors count.
- Only approved people get access. Access must be tied to a role, job need, and manager/asset owner approval.
- Keep proof. Logs, access lists, and review records must be easy to produce for assessment and incident response.
Who it applies to (entity and operational context)
Entities: Automotive suppliers and OEMs operating under TISAX expectations aligned to VDA ISA 1.
Operational contexts where this control becomes “high scrutiny”:
- Engineering, R&D, prototype build areas, test tracks, calibration labs
- Data centers, server rooms, network closets, OT/ICS cabinets
- Secure printing, mailrooms for confidential deliveries, records storage
- Any area where customer-owned assets or confidential program materials are stored or processed
Third parties: This control also affects contractors (maintenance, cleaning, security guards) and visitors. Your process must cover how you issue, scope, time-limit, and revoke their access.
What you actually need to do (step-by-step)
Step 1: Define and approve “secure areas”
- Build a secure area register: area name, site, owner, assets inside, sensitivity, and all entry points (doors, gates, shared corridors).
- Set minimum criteria for secure classification (examples: customer confidential materials present; prototypes stored; privileged systems accessible).
- Get sign-off from the area owner (engineering, IT, lab manager) and security/facilities.
Exam priority: Assessors often test whether your scope matches reality. If a server room exists but is missing from the register, they will treat the control as incomplete.
Step 2: Standardize the access model (who should be allowed in)
Create an authorization matrix:
- Roles/groups (e.g., Facilities Tech, Lab Engineer, Network Admin, Cleaner, Visitor)
- Secure areas each role can access
- Approval authority (manager vs. area owner vs. security)
- Access constraints (business hours only; escort required; no after-hours)
Decision point: Prefer least privilege by area, not “whole building access.” If you must allow broad access (for example, emergency response), document the rationale and compensating monitoring.
Step 3: Implement electronic access control per entry point
For each secure-area entry:
- Select method: badge, PIN, or biometrics 1.
- Ensure the control is enforcing, not “alarm-only.” The door should remain locked until authenticated.
- Configure anti-passback / tailgating mitigations where feasible (turnstiles, mantraps, door alarms, CCTV coverage, or guard checks). If you cannot deploy these, document the limitation and how you detect tailgating through monitoring and spot checks.
Step 4: Provisioning workflow (grant access)
Implement a request/approval process that produces an audit trail:
- Requester identity and role
- Secure area(s) requested
- Business justification
- Start date and end date (especially for contractors)
- Approvals (manager + area owner or security, based on your matrix)
- Confirmation that access was applied in the access control system
Practical tip: Tie provisioning triggers to HR/identity events so you do not rely on email threads. If you use Daydream to manage third-party onboarding and access requirements, store approvals and expiry dates in one place and push tasks to facilities/security for badge activation.
Step 5: Deprovisioning workflow (remove access)
Define clear removal triggers:
- Employment termination or transfer
- Contract end
- Role change removing need
- Badge loss (temporary block, reissue process)
What auditors look for is consistency: deprovisioning must happen reliably, and you must be able to prove it via tickets, HR events, or access system records.
Step 6: Logging and retention (access event evidence)
Turn on and validate:
- Successful access events (door/reader, user/badge ID, timestamp)
- Failed attempts (invalid badge, wrong PIN, denied access)
- Administrative changes (who granted/removed access, when)
Retain logs in a way that you can retrieve them for a given user/door/time window. The requirement summary expects access logging 1. If logs are stored by a third party (managed security provider or building management), obtain contractual confirmation and a retrieval procedure.
Step 7: Automated alerting and response for unauthorized attempts
The requirement summary includes automated alerting for unauthorized access attempts 1. Operationalize it:
- Define alert conditions (repeated denied attempts, forced door open, access outside allowed hours)
- Define who receives alerts (SOC, security desk, on-call facilities)
- Define response steps (dispatch guard, call area owner, review CCTV, disable badge if needed)
- Record incidents and outcomes
Step 8: Access reviews (keep entitlements clean)
Run periodic reviews of who has access to each secure area:
- Area owner validates current access list
- Remove stale access
- Record exceptions with justification and time limits
Even when not explicitly timed in the text, assessors commonly ask how you confirm access remains appropriate over time because it is central to controlling secure areas 1.
Required evidence and artifacts to retain
Keep these artifacts ready for an assessment sampling request:
| Artifact | What it proves | Owner |
|---|---|---|
| Secure Area Register (with entry points) | Scope completeness and ownership | Security / Facilities + Area owners |
| Access authorization matrix | Least privilege rules and approvals | GRC + Security |
| Access control system configuration screenshots/exports | Electronic enforcement exists for secure areas | Facilities / Physical security |
| Access request and approval records (tickets/workflows) | Controlled provisioning with audit trail | HR/ITSM/Security |
| Termination/role change deprovision evidence | Timely removal | HR + Security |
| Access logs (successful/failed) | Logging is active and retrievable | Security / SOC |
| Alert rules + incident runbook | Automated detection and response | Security operations |
| Access review records and remediation actions | Ongoing governance | Area owners + GRC |
Common exam/audit questions and hangups
- “Show me your secure areas.” Expect a walkthrough request. If your register does not match the floor plan, you lose credibility fast.
- “How do visitors and contractors get access?” Auditors probe third-party access because it is a common gap.
- “Prove logging and alerting.” They may ask for a denied-entry example, the alert, and the follow-up record 1.
- “Who can grant access?” If too many admins can add access without approval, your process control looks weak.
- “What happens when a badge is lost?” They want to see rapid disablement and reissue controls.
Frequent implementation mistakes (and how to avoid them)
- Secure areas defined vaguely. Fix: maintain a register tied to real doors and a named owner per area.
- Electronic control at the building perimeter only. Fix: apply controls to internal secure zones, not just the lobby 1.
- Shared badges or “loaner” badges without traceability. Fix: issue individually assigned credentials; if you must have temporary badges, treat them as controlled assets with checkout logs and auto-expiry.
- No proof of alert handling. Fix: connect alerts to a ticketing or incident record so you can show response.
- Access drift over time. Fix: run access reviews driven by the area owner’s accountability.
Enforcement context and risk implications
No public enforcement cases were provided in the source catalog. Practically, failures here create direct pathways to data loss and customer trust issues: prototypes photographed, confidential documents removed, unauthorized access to network closets, or sabotage of production/testing environments. For TISAX assessments, weak physical access controls often cascade into findings across asset protection and confidentiality requirements because the physical boundary is a foundational assumption.
Practical 30/60/90-day execution plan
First 30 days (stabilize scope and governance)
- Name owners: physical security lead, facilities lead, and an accountable owner per secure area.
- Build the secure area register and validate it via site walkthroughs.
- Draft the authorization matrix and approval workflow.
- Confirm which doors already have electronic readers and where gaps exist.
By 60 days (implement and produce evidence)
- Install or configure electronic access control for missing entry points (badge/PIN/biometric) 1.
- Turn on access logging and confirm retrieval for sampling.
- Configure unauthorized-attempt alerts and route to a monitored queue 1.
- Start using a standard access request ticket with approvals and expirations.
By 90 days (operationalize and test)
- Run an access review with area owners; remove stale access; document exceptions.
- Tabletop test: simulate denied entry and prove alert-to-response workflow end-to-end.
- Package the assessment-ready evidence set (register, logs sample, approvals, alert runbook).
- If you use Daydream for third-party due diligence and onboarding, align contractor/visitor access steps with your third-party records so you can show one control story across security and compliance.
Frequently Asked Questions
Do we have to use biometrics to meet the access control systems requirement?
No. The requirement allows badge readers, PIN codes, or biometric authentication for secure areas 1. Choose based on risk and feasibility, then document the decision and how you log and monitor access.
What counts as a “secure area” under VDA ISA 3.2.2?
Treat any space with sensitive assets as a secure area, then list it explicitly in a register tied to physical entry points. Auditors expect your definition to match what exists onsite 1.
Are mechanical keys acceptable for secure areas?
The control expects electronic access control for secure areas 1. If you still have mechanical keys for some locations, document them as gaps with a remediation plan or add compensating controls while you transition.
How should we handle visitors and cleaning staff access?
Issue time-bound credentials with the minimum area access needed, and require approval per your authorization matrix. Keep logs of access events and disable access automatically at the end of the visit or contract period 1.
What evidence is most likely to be sampled in a TISAX assessment?
Expect a request for the secure area list, door/reader configuration evidence, a set of access grant approvals, and access log samples including denied attempts and alert handling 1.
Our access logs are managed by a building management third party. Is that a problem?
It is workable if you can retrieve logs on demand and can show that logging and alerting exist for secure areas 1. Document the retrieval procedure and confirm responsibilities with the third party.
Footnotes
Frequently Asked Questions
Do we have to use biometrics to meet the access control systems requirement?
No. The requirement allows badge readers, PIN codes, or biometric authentication for secure areas (Source: VDA ISA Catalog v6.0). Choose based on risk and feasibility, then document the decision and how you log and monitor access.
What counts as a “secure area” under VDA ISA 3.2.2?
Treat any space with sensitive assets as a secure area, then list it explicitly in a register tied to physical entry points. Auditors expect your definition to match what exists onsite (Source: VDA ISA Catalog v6.0).
Are mechanical keys acceptable for secure areas?
The control expects electronic access control for secure areas (Source: VDA ISA Catalog v6.0). If you still have mechanical keys for some locations, document them as gaps with a remediation plan or add compensating controls while you transition.
How should we handle visitors and cleaning staff access?
Issue time-bound credentials with the minimum area access needed, and require approval per your authorization matrix. Keep logs of access events and disable access automatically at the end of the visit or contract period (Source: VDA ISA Catalog v6.0).
What evidence is most likely to be sampled in a TISAX assessment?
Expect a request for the secure area list, door/reader configuration evidence, a set of access grant approvals, and access log samples including denied attempts and alert handling (Source: VDA ISA Catalog v6.0).
Our access logs are managed by a building management third party. Is that a problem?
It is workable if you can retrieve logs on demand and can show that logging and alerting exist for secure areas (Source: VDA ISA Catalog v6.0). Document the retrieval procedure and confirm responsibilities with the third party.
Authoritative Sources
Operationalize this requirement
Map requirement text to controls, owners, evidence, and review workflows inside Daydream.
See Daydream