ISA VDA 6.0.3 – The Data Protection sheet explained

The Data Protection catalog is the shortest of the three in ISA 6.0.3 and the one most often underestimated.

Twelve control questions across eight subchapters, all numbered under chapter 9. Compared to the roughly sixty questions in Information Security, it looks like an afterthought.

It isn’t.

It is the part of the assessment where an auditor stops asking how your systems are built and starts asking who told you to process this data, what you agreed to, and what happens when someone asks you to delete it.

 

Three things about this catalog are worth knowing before reading a single control:

• First, it never stands alone. The sheet says so in its own header text: an isolated assessment of the data protection module cannot lead to TISAX certification. If your customer asks for the “Data” or “Special data” label, you are assessed against the Information Security catalog and the Data Protection catalog together. The Participant Handbook confirms the same mapping.
• Second, everything here is a must. The Information Security sheet has four requirement columns covering must, should, and additions for high and very high protection needs. The Data Protection sheet has one, and it is the must column. For both the “Data” and “Special data” labels, only that column applies. There is no should-level cushion and no tiering. The difference between the two labels sits entirely on the Information Security side, where “Special data” pulls in the very high protection need requirements marked with a C for confidentiality. The Data Protection questions themselves are identical either way.
• Third, the whole catalog is written from the position of a processor under Article 28 GDPR. Both labels are defined that way. The controller is your customer, usually an OEM or a tier-1, and a surprising number of the requirements are about the relationship rather than about your infrastructure. If your organisation is the controller for the data in scope, several of these questions will feel oddly angled, and you should raise that with your audit provider early rather than improvise answers.

The target maturity level is 3 for every question, same as the rest of ISA. Level 3 means the process is defined, documented, and actually followed, not that it is world class.

A last practical note: the support columns that make the Information Security sheet easier to interpret, the ones with example questions, example evidence, and references to other standards, are empty for the entire Data Protection sheet in 6.0.3. There is exactly one assistance note in the whole catalog, attached to the processing directory question. You are reading the raw requirement text without the usual scaffolding, which is part of why this sheet feels harder than its length suggests.

9.1.1 To what extent do data protection policies exist?

The stated objective is that the organisation needs at least one policy on privacy, that this policy reflects how seriously data protection is taken, and that it is adapted to the organisation. The sheet adds that further policies may make sense depending on your size and structure.

The requirement is one sentence. A policy is created, kept up to date through regular review, and approved by management.

For an engineering director this is the least interesting control in the catalog and the easiest one to fail on a technicality. What auditors find is usually not the absence of a policy but a policy that was written once, signed by someone who has since left, and never revisited. Management approval means the approval is traceable to a person with authority, and regular updating means there is a review interval you can name and evidence of the last review having happened. A document with a version history and a named approver clears this. A PDF on the intranet with no owner does not.

9.2.1 To what extent are the responsibilities for data protection organized?

The objective is short: successful data protection needs clear responsibilities.

The requirement list behind it is the longest in the catalog. A data protection officer is appointed where Article 37 GDPR requires one, and you have to have actually determined whether the appointment is mandatory or voluntary rather than assuming. If no DPO is required, you still name a data protection function or something comparable. Contact details are published, for example on your website. The role is integrated into the organisational structure. The monitoring obligations under Article 39 (1) (b) GDPR are carried out and documented. The data protection status is documented and reported to top management. The function has enough capacity and resources, which the sheet breaks down into whether the role is full time or part time, professional qualification, regular training, access to specialist literature, and support from data protection coordinators in individual units such as marketing, sales, HR, logistics and development, depending on company size.

The part product managers tend to miss is the reporting line. It is not enough that someone holds the title. There has to be evidence that this person periodically tells the leadership team where the organisation stands, and that they have the time and training to know. A DPO who is also the head of IT and spends four hours a year on the role will struggle here, and so will one who has never attended a training since being appointed.

9.3.1 To what extent are processing activities identified and recorded?

The objective is accountability and transparency, and having an overview of what data processing actually happens.

Where the law requires it, you keep a record of processing activities under Article 30 (1) or Article 30 (2) GDPR, and it is current. The sheet is specific about the processor case: for the Article 30 (2) record you document what relates to the customer’s mandate, expressly not other details of your internal processing. The technical and organisational measures needed for each processing activity, the ones the Information Security catalog asks about, are implemented adequately for those activities. There is a written process description with defined responsibilities, meaning a defined way that new processing gets added to the record and existing entries get reviewed.

This is the only control in the catalog with an assistance note. It says you do not need to list every information asset individually and that categories are acceptable, giving employee master data owned by HR as the example. That note saves a lot of wasted effort. Teams routinely try to build a record at field level and give up halfway. Category level is what is being asked for.

The link to information security matters here and is easy to overlook. The record is not just an inventory. Each entry carries a claim about the controls protecting that processing, and an auditor can walk from a line in your record into the Information Security catalog and ask you to demonstrate the control.

9.4.1 To what extent is adequate handling of high-risk processing activities ensured (data protection impact assessment)?

The objective describes securing high-risk processing in cooperation with the service provider, using measures that identify and where necessary reduce risks to the rights and freedoms of data subjects.

Three things are required. You know which of your processing activities need a data protection impact assessment. Those assessments are carried out. Responsibilities, tasks and the available support during a DPIA are defined and known inside the organisation.

The first point is the one that fails. Knowing which activities trigger a DPIA means there is a screening step somewhere, usually a threshold check when a new processing activity is registered or a new product feature touches personal data. If your answer is that nothing in your scope has ever required a DPIA, the auditor will want to see how you reached that conclusion rather than accept it. For product managers, the useful takeaway is that the DPIA question belongs early in a feature lifecycle, not at launch review.

9.5.1 To what extent is the transfer of data managed?

The objective is that the company knows and secures its data transmissions.

The requirement is that appropriate processes and workflows exist for transferring data, and the examples given are valid Article 28 contracts, suitable transfer instruments such as standard contractual clauses, transfer impact assessments, and adequacy decisions. A sub point covers making sure the consent or the right of objection of the responsible party is respected when work is subcontracted.

Read this as contract hygiene with a process attached. The auditor is not only checking that a data processing agreement exists for a given customer. They are checking that there is a repeatable way these agreements get created, checked and stored, and that engineering does not start moving data before that step is complete.

9.5.2 To what extent are contractual obligations passed through to and enforced at subcontractors and cooperation partners?

The objective is that the company is aware of and secures data transfers to its subcontractors.

What you agreed with your customer is passed on to your sub-processors and cooperation partners. Compliance with those agreements is reviewed rather than assumed. Contact details for the people at the subcontractor are on hand and current.

This is where cloud services, analytics tools and offshore development partners surface. The obligations flow down the chain unchanged, so a commitment you made to an OEM about deletion timelines or breach notification has to appear in the contract with the vendor you rely on to meet it. The review element is what most organisations lack. Signing the contract is evidence of the first requirement. Something like a periodic vendor check or a documented review of a supplier’s certifications is evidence of the second.

9.5.3 To what extent are data transfers to third countries managed?

The objective is that the company is aware of and secures transfers to third countries.

Transfers outside the EU or EEA are known and systematically recorded, for example through the processing directory. Sufficient guarantees under Chapter V GDPR are in place, taking into account the decisions of the European Court of Justice on international transfers, and a transfer impact assessment where relevant, particularly when you act as data exporter. For each third country transfer, it is determined whether the responsible party’s consent has to be obtained.

The word systematically is doing real work. A list assembled once for the audit is not a system. The expectation is that a new third country transfer cannot appear without the record being updated, which in practice means the question is asked when a vendor is onboarded or a region is added to a deployment.

9.6.1 To what extent are data subject requests processed?

The objective is timely handling and fulfilment of data subject requests so that the rights guaranteed by law are protected.

Requests are handled in a timely manner. Procedures exist that let you assist the controller in responding. Employees are trained to immediately pass an incoming request to the responsible person and agree the next steps with them.

The employee training piece is the practical core. As a processor you are not usually the one answering the data subject, but a request can arrive at any inbox in the company. Someone in support or sales needs to recognise it and route it within hours, not discover it in a backlog three weeks later. If your customer has a thirty day clock, your internal handoff has to be measured in days.

9.6.2 To what extent are data protection incidents processed?

The objective is limiting damage to data subjects, preventing recurrence, and making sure the legally required documentation and, where necessary, timely notification to the supervisory authority happen.

Data protection incidents, with unauthorised access to personal data given as the example, are handled in a timely manner. The requirements in chapter 1.6 of the Information Security catalog, the incident and crisis management chapter, also cover data protection incidents, or you have a separate emergency plan for them. Beyond that, documented procedures cover immediate notification of the responsible party where their mandate is affected, documentation of what was done during the handling, employee training on those procedures, and support to the controller while they process the incident.

This is the control most worth building around your existing incident process rather than alongside it. ISA explicitly allows the 1.6 process to carry data protection incidents, which is the cheaper path and the one that actually works during an incident. What you have to add is the privacy dimension: a trigger that recognises when an incident involves personal data, a notification path to the customer fast enough for them to meet their own reporting deadline, and a record of what was decided and when.

9.7.1 To what extent are employees obliged to maintain confidentiality?

The objective notes that organisations are bound by laws, regulations and internal policies, and that at hiring, during employment and at termination it matters that employees commit to following them.

Employees whose work includes processing personal data are placed under an obligation of confidentiality that survives the end of the employment relationship, and are obliged to comply with applicable data protection law. The obligation is documented.

The documentation requirement is the whole control. A clause in an employment contract works. A signed separate undertaking works. An onboarding slide deck does not.

The scope is anyone whose tasks involve personal data, which in most companies is broader than the engineering team.

9.7.2 To what extent are employees trained in data protection?

The objective is direct about the risk. If employees do not know the requirements and the risks, they will behave incorrectly and harm the organisation. The sheet asks for data protection to become a natural part of how people work.

Employees are trained and made aware. Scope, frequency and content follow the protection needs of the data involved. People in critical areas, with IT administrators named as the example, get instruction and training specific to their work, which can take the form of dedicated courses, instructions or short videos.

Two levels of training, in other words. General awareness for everyone, and something targeted for the roles with elevated access. An annual click-through course delivered identically to the entire company satisfies the first half and not the second. The formats named in the requirement are deliberately modest, so a fifteen minute recorded session for the admin team, with attendance recorded, is enough.

9.8.1 To what extent are instructions of processing relationships handled?

The objective is that instructions from the controller are handled in an orderly and defined way, so that the processor’s tasks are fulfilled and the contractually agreed obligations are met. The sheet adds a specific purpose: to identify when something goes beyond what was contractually agreed.

Instructions from the controller about processing personal data are handled. Procedures and measures make sure that received instructions are documented, that they can actually be carried out, with correction and deletion given as examples, and that data is separated by client and by specific order or project.

This is the control that most directly touches system design, and it is the one where an architectural decision made years ago can be expensive. Separation by client and project has to be real. If customer data from three OEMs sits in one table distinguished only by a tenant column that nobody enforces, this requirement is where that shows up. The ability to implement an instruction is equally concrete. If a controller instructs you to delete a specific data set, you need a way to do it and evidence that the deletion happened, including in backups and in downstream systems.

The documentation of instructions is the part teams skip. An instruction arriving as a message in a shared channel and acted on by whoever saw it first is not a documented instruction. The auditor is looking for a channel, a record, and a way to tell later that an instruction was received, who acted on it, and what was done.

Where the effort actually goes

Reading the twelve questions in order gives a misleading impression of the work. Roughly half of them, the policy, the responsibilities, the confidentiality obligation and the training, are documentation and organisation, and a company that has already done ISO 27001 work will move through them quickly.

The other half, the processing record, the DPIA screening, the third country transfers, the incident path and the handling of instructions, need something to exist in the way the company operates, and that is where the months go.

If you are preparing for a “Data” or “Special data” label and want a single place to start, start with 9.3.1. The record of processing activities is what the auditor will use to navigate everything else, and building it honestly tends to reveal which of the other eleven controls you have and which you only think you have.

© Copyright 2026 Sorin Mustaca, All rights Reserved. Written For: Sorin Mustaca - Security & Technology

---

Want to work with me on this topic?
Check Endpoint Cybersecurity to see the consulting services we offer.