Prototype and physical security

The TISAX prototype and physical security requirement means you must prevent unauthorized access, viewing, handling, loss, or theft of prototypes and physical assets shared or processed in automotive collaborations. Operationalize it by defining prototype classification and handling rules, restricting physical access end-to-end (sites, labs, docks, vehicles), and keeping audit-ready evidence that controls work in daily operations.

Key takeaways:

• Treat prototypes as “high-risk physical assets” with explicit handling, storage, transport, and disposal rules tied to access control.
• Build controls around real workflows: receiving, staging, test drives, lab work, photography, shipping, and scrapping.
• Evidence wins assessments: logs, training, visitor records, chain-of-custody, exception approvals, and periodic checks.

“Prototype and physical security” is a practical requirement: can you reliably protect pre-series parts, mule vehicles, test units, drawings printed on paper, and any other physical items that could expose IP, safety designs, or customer confidentiality if seen or removed? TISAX assessments commonly focus on whether your controls match how engineering and operations teams actually work, not what your policy says.

For a CCO or GRC lead, the fastest path is to define a prototype security operating model, then force it into daily execution through access controls, handling procedures, and traceable records. You need consistency across internal sites and third parties such as test houses, logistics providers, and contract manufacturers. The operational reality is messy: prototypes move; people take photos; visitors show up; shipments get re-labeled; scrap bins get overlooked; security exceptions happen under schedule pressure. Your program has to manage these predictable failure points.

This page translates the prototype and physical security requirement into a requirement-level implementation plan you can assign, verify, and defend in a TISAX conversation, using the publicly available ENX TISAX overview as the cited source for the baseline intent. ¹

Regulatory text

Baseline excerpt (as provided): “Baseline implementation-intent summary derived from publicly available framework overviews; licensed standard text is not reproduced in this record.” ¹

Operator summary of the requirement (TISAX-03): Protect prototype and physical assets in automotive collaboration contexts. ¹

Plain-English interpretation

You must control who can access, see, handle, move, and dispose of prototypes and sensitive physical assets, and you must prove those controls operate in practice. “Prototype” should be interpreted broadly in automotive collaboration: pre-series components, test fixtures, prototype ECUs, mule vehicles, 3D prints, physical mockups, and paper outputs that reveal design details.

What assessors look for:

• Clear rules that define what counts as a prototype or sensitive physical asset.
• Physical security controls aligned to where prototypes exist (labs, warehouses, yards, test tracks, offices, vehicles).
• Prototype handling procedures that prevent casual exposure (photos, unattended items, untracked transfers).
• Evidence that the above happens consistently, including at third parties.

Who it applies to

Entity scope: Automotive suppliers and automotive service providers participating in automotive collaborations where prototypes or sensitive physical assets are created, stored, tested, transported, or disposed. ¹

Operational contexts that usually trigger scope:

• R&D labs and engineering centers working on pre-series designs.
• Warehousing and staging areas where prototype parts are received or shipped.
• Vehicle testing, track operations, and field testing that involves mule vehicles or prototype components.
• Third-party test houses, calibration facilities, logistics providers, and contract manufacturing locations that touch the items.

People in scope (typical):

• Engineering, test, quality, and program teams.
• Facilities, physical security, and EHS.
• Warehouse, shipping/receiving, and logistics.
• Security guards, reception, and visitor management staff.
• Third-party personnel with site access or custody of prototypes.

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

Below is a pragmatic build sequence you can run as a control implementation project. Assign an owner per step and require written completion evidence.

Step 1: Define “prototype” and classify physical assets

1. Create a prototype/sensitive physical asset definition for your organization (include examples relevant to your projects).
2. Add a classification rule that maps categories to minimum handling requirements (for example: “prototype vehicle,” “pre-series part,” “prototype electronics,” “confidential printed outputs”).
3. Document scope boundaries: which sites, labs, yards, and third parties are in scope for prototype handling.

Deliverable: Prototype and Physical Asset Classification Standard (policy/standard level), approved by Security + Engineering leadership.

Step 2: Map prototype life cycle and control points

1. Build a simple process map across: receive → store → issue to workbench → test/use → move/ship → return → rework → scrap.
2. Identify “loss/exposure points”: loading docks, temporary staging, overnight storage, meeting rooms, photography areas, test track parking, scrap bins.
3. For each point, choose a control type: access restriction, surveillance, locking storage, escorting, inventory/checkout, chain-of-custody.

Deliverable: Prototype Life Cycle Flow + Control Matrix (one page is fine if it is specific).

Step 3: Implement physical access controls where prototypes exist

1. Define secure zones (prototype lab, prototype cage, prototype yard area).
2. Restrict access by role (badge access groups, keys, or lock codes controlled by documented authorization).
3. Require visitor controls for secure zones: sign-in, ID check, escort, and explicit photo restrictions.
4. Add environmental controls as needed: locked cabinets, cages, tamper-evident storage, or controlled parking.

Minimum expectation: you can demonstrate that only approved personnel can enter prototype areas, and that visitor access is controlled and recorded.

Step 4: Put prototype handling procedures into daily operations

Create procedures people can follow without asking permission every time:

1. Check-out / check-in rules for prototype parts (who can take items, where they can go, and how they are returned).
2. Transportation rules (internal moves, shipping to third parties, transport to test tracks). Include packaging requirements and custody handoffs.
3. Photography and recording controls for areas with prototypes (signage, training, and enforcement).
4. After-hours storage rules (no prototypes left on desks, in meeting rooms, or unsecured vehicles).
5. Exception handling (how to request, approve, time-bound, and document deviations).

This is where programs fail. If your procedures do not match the engineering workflow, people route around them and you lose evidence.

Step 5: Extend controls to third parties that touch prototypes

1. Identify third parties that store, test, transport, or dispose of prototypes.
2. Update contracts/SOWs with physical security and prototype-handling obligations: access control, visitor management, segregation, incident reporting, and audit rights.
3. Run targeted due diligence focused on prototype custody: site controls, chain-of-custody, and restricted zones.
4. Require proof: photos of storage controls, access lists, visitor log samples, shipment tracking, and training attestations.

Practical note: treat “prototype custody” as a distinct third-party risk scenario, not a generic vendor questionnaire line item.

Step 6: Train, test, and monitor control operation

1. Train in-scope staff (engineering, warehouse, reception, security) on the procedures they execute.
2. Run spot checks: storage inspections, visitor log reviews, and prototype check-out record validation.
3. Test incident response for a physical loss scenario: what happens if a prototype goes missing or is photographed.
4. Track and close corrective actions, then retain evidence.

Recommended control baseline: apply physical access and prototype handling procedures and prove they operate. ¹

Required evidence and artifacts to retain

Retain evidence that shows design + operation. Assessors often accept samples, but they want traceability.

Core documents

• Prototype/physical asset classification standard and scope statement.
• Physical security standard for prototype zones (access, visitors, surveillance expectations, keys/badges).
• Prototype handling procedures: storage, transport, photography restrictions, exceptions, disposal/scrap.
• Third-party requirements language (contract clauses, addenda, or security exhibits).

Operational records (samples are fine if representative)

• Access authorization list for prototype areas (with approvals).
• Badge access reports or key issuance logs (as available).
• Visitor logs for secure zones and escort records.
• Prototype check-out/check-in logs or inventory logs.
• Shipping and chain-of-custody records (handoff forms, tracking references).
• Incident tickets and investigations for prototype-related events (loss, unauthorized access, photo breach).
• Training completion records for in-scope roles.
• Inspection/spot check results and corrective action tracking.

Visual/physical evidence

• Photos of signage (“no photos,” “restricted area”), locked storage, cages, secure parking controls.
• Site maps marking prototype zones and access points.

Common exam/audit questions and hangups

Expect questions like:

• “Define ‘prototype’ here. Show me what items are covered and who decides.”
• “Which areas are designated for prototype work, and how is access controlled?”
• “Show evidence of visitor control for prototype areas, including escorts and photo restrictions.”
• “How do you track prototypes when they move between teams, buildings, or third parties?”
• “What happens when engineering needs an exception to handling rules?”
• “How do you validate third-party prototype custody controls?”

Hangups that slow assessments:

• Policies exist, but no operational logs exist.
• Controls apply at HQ but not at satellite labs, warehouses, or test locations.
• Third-party prototype handling is “assumed” rather than contractually required and verified.
• Incomplete scoping: prototype vehicles get managed, but prototype parts and printed materials do not.

Frequent implementation mistakes and how to avoid them

1. Mistake: treating prototypes as only vehicles.
   Fix: include components, tooling, electronics, and printed outputs in the definition and training.

2. Mistake: relying on “restricted area” signs without access enforcement.
   Fix: implement actual access control (badge groups/keys) and keep approval records.

3. Mistake: no chain-of-custody for internal transfers.
   Fix: require check-out/check-in or transfer records for movement between teams/locations.

4. Mistake: exceptions handled verbally.
   Fix: require written, time-bounded exceptions with an approver, a reason, and compensating controls.

5. Mistake: third parties treated as out of scope.
   Fix: explicitly include third parties with prototype custody in scope, add contract requirements, and request evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should frame risk in operational and contractual terms rather than citing regulators.

Primary risk outcomes if you fail this requirement:

• IP loss and loss of customer trust due to leakage of pre-series designs.
• Contractual breach with OEMs or partners (prototype confidentiality is often a core obligation).
• Safety and quality exposure if prototype parts are substituted, tampered with, or untraceably modified.
• Assessment failure risk due to “insufficient implementation evidence for prototype and physical security.” ¹

Practical 30/60/90-day execution plan

This plan assumes you need measurable progress quickly and evidence you can show to an assessor.

First 30 days: define scope, rules, and owners

• Appoint owners: Physical Security (controls), Engineering (prototype definition), Warehouse/Logistics (custody), Legal/Procurement (third parties).
• Publish prototype definition + classification and list in-scope sites/areas.
• Build the prototype life cycle control matrix for each in-scope site.
• Implement quick wins: signage, visitor photo restrictions, locked storage for obvious gaps.
• Start an evidence folder structure aligned to the artifacts list above.

Days 31–60: implement controls and start collecting logs

• Configure access control groups for prototype zones; document approvals.
• Roll out prototype handling SOPs to engineering and logistics teams.
• Stand up check-out/check-in and chain-of-custody templates (even a controlled spreadsheet works if access is restricted and changes are tracked).
• Update third-party contracts/SOW templates with prototype custody clauses; prioritize third parties currently handling prototypes.
• Begin spot checks and document findings and fixes.

Days 61–90: validate operating effectiveness and close gaps

• Run a tabletop exercise for “prototype missing / unauthorized photo” and capture after-action items.
• Perform a mini internal audit: sample visitor logs, access lists, prototype transfer records, and shipping records.
• Validate third-party evidence for at least your highest-risk prototype custody relationships.
• Finalize a management review memo: scope, controls implemented, open risks, and remediation timeline.
• If you use Daydream, centralize third-party prototype custody evidence requests, exception approvals, and recurring checks so you can produce a clean assessment package without chasing emails.

Frequently Asked Questions

What counts as a “prototype” for this prototype and physical security requirement?

Define it broadly based on exposure risk: pre-series parts, prototype electronics, mule vehicles, mockups, and even printed outputs that reveal sensitive designs. Write the definition down and train to it so teams classify items consistently.

Do we need inventory tracking for every prototype part?

Track custody to the level that prevents loss and supports investigation. Many teams track high-risk items individually and use batch tracking for lower-risk prototype materials, as long as the rule is documented and consistently applied.

How do we handle photography rules in labs where phones are needed for work?

Set a clear policy for when photos are allowed, where they are allowed, and how they are stored and shared. Put signage at entrances, require explicit approvals for sensitive captures, and enforce violations through incident handling.

What evidence is most persuasive in a TISAX assessment?

Access approvals for prototype areas, visitor/escort logs, chain-of-custody or check-out records, training completion, and spot check results. Assessors want proof controls operate, not only that policies exist. ¹

How do we extend prototype controls to third-party test houses and logistics providers?

Add prototype custody obligations to contracts and verify operational controls with targeted evidence requests: restricted areas, access lists, visitor logs, and shipping handoffs. Re-check when scope changes or new prototype programs start.

We have multiple sites. Do we need identical controls everywhere?

Controls can vary by site, but outcomes must be consistent: restricted access, controlled handling, and evidence. Standardize the minimum baseline and allow site add-ons for higher-risk environments.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. ENX TISAX overview