TISAX Assessment Scope Definition

Define and document a TISAX assessment scope that includes every location, process, and system that creates, processes, stores, or transmits confidential automotive information, then align your Statement of Applicability and evidence set to that scope. Auditors will test scope completeness, boundary controls, and whether “out-of-scope” exclusions are justified and enforced (VDA ISA Catalog v6.0).

Key takeaways:

• Scope is an inventory problem first: information types, flows, locations, systems, and third parties that touch confidential automotive information (VDA ISA Catalog v6.0).
• Exclusions are allowed only if you can prove the information never touches the excluded boundary, including via remote access, shared services, or people/process overlap.
• Your scope document must be operational: named sites, named systems, defined interfaces, and clear ownership for keeping scope current.

“TISAX assessment scope definition” sounds administrative, but it is one of the fastest ways to fail an assessment if you treat it like a paragraph in a policy. The requirement in VDA ISA 5.1.1 expects you to draw a defensible boundary around the parts of your business that handle confidential automotive information, and then show that your security controls and evidence match that boundary (VDA ISA Catalog v6.0).

For a CCO, GRC lead, or security compliance owner, the practical goal is simple: create a scope statement that an assessor can test without guessing. That means you must map where confidential automotive information lives and moves (sites, processes, systems, people, and third parties), decide what is in scope, justify anything that is out of scope, and implement controls that prevent scope “leakage” (for example, staff accessing in-scope systems from out-of-scope networks).

This page gives requirement-level implementation guidance you can put into motion quickly: a step-by-step scoping method, the artifacts to retain, common audit questions, and a phased execution plan to get from “we think it’s these departments” to a scope definition that survives assessor scrutiny.

Regulatory text

Requirement (VDA ISA 5.1.1): “Define the scope of the TISAX assessment covering all locations, processes, and systems that handle confidential automotive information.” (VDA ISA Catalog v6.0)

What the operator must do:
You must produce a clear, accurate assessment scope that includes:

• Locations where confidential automotive information is handled (owned sites and relevant shared/hosted environments).
• Processes that create/use that information (engineering, program management, quoting, testing, incident handling, etc.).
• Systems that store/process/transmit it (applications, endpoints, servers, networks, cloud services).
  Then you must be able to demonstrate that the scope boundary is real in practice: information cannot “bleed” into excluded sites, systems, or teams without controls and governance that bring them into scope (VDA ISA Catalog v6.0).

Plain-English interpretation

Your TISAX scope is the list of “everything that touches confidential automotive information.” If a site, team, or system can access it, send it, store it, or process it, it belongs in scope. If you want to keep something out of scope, you need a factual basis: the data never goes there, the people there cannot access it, and the technical paths are blocked or controlled.

Treat scope as a living control boundary. Assessors will use it to decide:

• what they sample,
• what evidence they expect,
• what counts as a nonconformity.

Who it applies to (entity and operational context)

Applies to:

• Automotive suppliers and OEMs seeking or maintaining a TISAX label, where confidential automotive information is exchanged or handled (VDA ISA Catalog v6.0).

Operational contexts that almost always expand scope:

• Distributed engineering teams and shared service centers (IT, HR, finance) that administer accounts or infrastructure used by in-scope systems.
• Remote access (VPN, VDI, jump hosts) into engineering networks or PLM systems.
• Cloud-hosted collaboration and storage used for customer drawings, specifications, test results, or program documentation.
• Third parties (contractors, testing labs, managed service providers) who access or process confidential automotive information on your behalf.

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

1) Define “confidential automotive information” for scoping purposes

You need a working definition that matches your customer obligations and the reality of what you handle. For scope definition, you don’t need perfect classification taxonomy; you need a clear rule: which document types, systems, and workflows count as “confidential automotive information” in your environment (VDA ISA Catalog v6.0).

Practical output: a one-page data scoping note listing examples (CAD files, requirements specs, RFQs, test reports, program timelines, supplier pricing—whatever is relevant for your organization).

2) Build an information flow map (not just an asset list)

Start with 3 questions:

• Where does the information enter (customer portals, email, EDI, shared drives)?
• Where is it processed (PLM, ALM, ERP modules, engineering workstations)?
• Where does it leave (deliverables, uploads, third-party testing, manufacturing handoff)?

Include:

• human steps (who approves, who reviews),
• technical steps (which system, storage, network zone),
• interfaces (APIs, SFTP, integrations).

Tip: if you only do an “inventory,” you will miss shadow pathways (personal email, unmanaged endpoints, ad-hoc file sharing) that later blow up your scope claims.

3) Enumerate in-scope locations

List all physical sites that participate in the information flow:

• engineering offices,
• labs/test facilities,
• data centers (if any),
• any site where staff access in-scope systems (even if they “only view”).

For each site, record:

• legal entity / site name,
• address,
• site owner,
• what in-scope work happens there,
• connectivity to in-scope systems.

4) Enumerate in-scope processes

Document the business processes that handle the information. Keep it operational:

• process name,
• owner,
• where it is performed,
• primary systems used,
• inputs/outputs.

Examples often missed: incident response involving customer data, backup/restore operations, identity lifecycle management for engineers, and supplier collaboration activities.

5) Enumerate in-scope systems and supporting infrastructure

For each system (application, service, platform), capture:

• system name and purpose,
• hosting model (on-prem / cloud / SaaS),
• data handled (types),
• integrations and dependencies,
• admin access paths,
• logging/monitoring coverage.

Scope trap: shared infrastructure (identity provider, MDM, endpoint management, email, network services) may become in scope if it administers or provides security control over in-scope systems. If admins can change access to in-scope data through a shared tool, assessors often expect that tool and its control environment to be addressed within the scope boundary or via a clearly documented boundary and control mapping.

6) Identify scope boundaries and “out-of-scope” justifications

Create an explicit boundary statement:

• what is in scope,
• what is out of scope,
• why.

Then validate the boundary with checks:

• Access: Can out-of-scope users authenticate to in-scope systems?
• Network: Is there routing/connectivity from out-of-scope segments?
• Data movement: Are there approved/unapproved paths for file transfer?
• Endpoints: Can unmanaged devices access in-scope data?
• People: Do staff rotate between in-scope and out-of-scope work?

If any answer is “yes,” you either expand scope or implement boundary controls and retain evidence that the boundary is enforced.

7) Align your evidence plan to the scope

Once scope is set, create an assessment evidence map: which policies, procedures, logs, tickets, and technical configurations demonstrate control operation for in-scope locations/processes/systems. Ensure sampling is possible per site and system.

8) Operationalize scope governance (make it stay true)

Define:

• scope owner (often GRC + IT + Engineering),
• change triggers (new site, new program, new SaaS, M&A, new third party),
• update cadence tied to architecture review, procurement, and project intake.

If you use a GRC platform like Daydream, treat “scope objects” (sites, systems, processes, third parties) as first-class records linked to evidence, risks, and control ownership so scope changes automatically drive updated evidence requests and assessment readiness.

Required evidence and artifacts to retain

Maintain a scope package that an assessor can read end-to-end:

• TISAX scope statement (in-scope and out-of-scope, with rationale) (VDA ISA Catalog v6.0)
• List of in-scope locations with site attributes and responsible owners
• Process inventory for in-scope processes, mapped to locations and systems
• System inventory of in-scope systems, including hosting, interfaces, and admins
• Information flow diagrams showing data entry, processing, storage, transmission, and exit points
• Boundary control evidence (examples: network segmentation proof, access control lists, conditional access rules, VDI controls, file transfer controls) where exclusions rely on boundaries
• Third-party access register for third parties that handle or access confidential automotive information, including access method and systems touched
• Scope governance procedure showing how scope is reviewed and updated

Common exam/audit questions and hangups

Assessors tend to probe these areas under VDA ISA 5.1.1 (VDA ISA Catalog v6.0):

• “Show me all sites where engineers work on customer programs. Are they all in scope?”
• “Which systems store customer drawings? How do you know you didn’t miss any?”
• “What prevents an out-of-scope team from accessing in-scope data through shared identity, shared file storage, or email?”
• “You say this subsidiary is out of scope. Do they share IT admin, network, or service desk?”
• “Where are logs generated and retained for in-scope systems, and who reviews them?”
• “Which third parties have access, and are they included in the information flow?”

Frequent implementation mistakes and how to avoid them

Mistake 1: Scoping by org chart instead of data flow

Avoidance: scope by where the information goes. Start with customer artifacts and trace storage and access.

Mistake 2: Declaring shared services “out of scope” while they control access

Avoidance: if shared IAM, endpoint management, or service desk can grant access or change configurations affecting in-scope systems, include them or document compensating boundary and governance with evidence.

Mistake 3: Forgetting remote work and contractor access paths

Avoidance: document every access method (VPN, VDI, SSO, privileged access tooling) and treat it as part of the scope boundary.

Mistake 4: Vague system lists (“engineering tools”)

Avoidance: name systems, owners, and environments. “PLM” is not a scope object; “PLM instance X in tenant Y with integration Z” is.

Mistake 5: No mechanism to keep scope current

Avoidance: tie scope updates to procurement intake, architecture review, and program kickoff. Make “new system that handles confidential automotive information” a mandatory compliance gate.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk is assessment-driven: an incomplete or inaccurate scope can cause major nonconformities, rework, and customer trust issues because assessors may conclude controls are not applied where confidential automotive information is actually handled (VDA ISA Catalog v6.0). Scope errors also create blind spots: unmanaged repositories, unlogged access paths, and third-party handling that falls outside your intended control environment.

A practical 30/60/90-day execution plan

First 30 days (establish the boundary)

• Assign a single scope owner and a small working group (GRC, IT, engineering/program).
• Draft a working definition of confidential automotive information for scoping.
• Build an initial inventory of sites, key processes, and primary systems.
• Produce a first-pass information flow diagram for the top customer programs.
• Identify obvious exclusions and list the assumptions behind them.

Days 31–60 (validate completeness and enforce boundaries)

• Validate inventories against reality: access reviews, system admin interviews, and storage discovery in collaboration platforms.
• Document third-party access paths tied to in-scope systems and processes.
• Test boundary assumptions (remote access, shared identity, shared IT operations).
• Update scope statement with explicit inclusions/exclusions and owner sign-off.
• Build the evidence map: what artifacts prove controls for each in-scope site/system.

Days 61–90 (lock governance and audit-readiness)

• Formalize scope governance: intake triggers, review workflow, approval authority.
• Implement required boundary controls for any justified exclusions.
• Run an internal “scope challenge” session: have IT/security argue against your exclusions and document resolutions.
• Package the scope artifacts into an assessor-ready folder/workspace with version control.
• If using Daydream, connect scope objects to control ownership and evidence tasks so scope changes automatically generate the right readiness work.

Frequently Asked Questions

Can we exclude a location if it doesn’t store confidential automotive information but staff there access in-scope systems?

Usually no. If people at that site can access, view, or transmit confidential automotive information, the location is part of the handling chain and should be included or tightly bounded with enforceable controls (VDA ISA Catalog v6.0).

Are shared corporate services (IdP, service desk, endpoint management) automatically in scope?

They become scope-relevant if they administer, secure, or can materially change access to in-scope systems. If you keep them out of scope, document the boundary and show how you prevent them from affecting in-scope access and configurations (VDA ISA Catalog v6.0).

How detailed does the system list need to be?

Detailed enough that an assessor can sample evidence without guessing. Name the system, owner, hosting model, environments, and key integrations where confidential automotive information is processed or stored (VDA ISA Catalog v6.0).

Can we define scope by customer program instead of the whole company?

You can define a scope that covers the parts of the organization handling confidential automotive information, but you must include all locations, processes, and systems that handle it within that defined boundary. Program scoping fails when shared platforms or teams supporting multiple programs get omitted (VDA ISA Catalog v6.0).

How do third parties affect scope?

If a third party accesses or processes confidential automotive information for you, they must appear in your information flow and access register, and your scope must reflect the systems and processes where that access occurs (VDA ISA Catalog v6.0).

What’s the simplest way to defend an “out-of-scope” exclusion?

Show a combination of (1) documented data flow that never enters the excluded area, (2) technical controls that block access or transfer, and (3) governance that prevents future drift without review (VDA ISA Catalog v6.0).