Tag Archive for: 6.0.3

You are here: / / 6.0.3

Posts

ISA VDA 6.0.3 – The Data Protection sheet explained

/in

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.

The post ISA VDA 6.0.3 – The Data Protection sheet explained first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

/in

This is the part 5 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

 

Chapter 6 — Supplier Relationships

This chapter addresses how the organization manages information security risks arising from third parties — contractors, cooperation partners, and the exchange of sensitive information with external organizations.

Note: Chapter 6 contains no separately titled subchapter. Controls run as 6.1.x.

6.1.1 — To what extent is information security ensured among contractors and cooperation partners?

All contractors and cooperation partners must be subjected to a risk assessment covering information security before engagement. Appropriate security levels must be ensured through contractual clauses. Where there are upstream contractual obligations from the organization’s own clients, those must be passed through to relevant partners. The should-level requires that contractors and cooperation partners are contractually obligated to pass information security requirements down to their own subcontractors, and that reports and documents from these partners are reviewed. For high protection needs, proof must be provided that the supplier’s information security level is adequate for the protection needs of the information being shared — for example, through a certificate, attestation, or internal audit.

Evidence includes supplier contracts containing security clauses, risk assessment records, and for high protection needs, supplier compliance evidence such as TISAX labels, ISO 27001 certificates, or audit reports.

6.1.2 — To what extent is non-disclosure regarding the exchange of information contractually agreed?

Non-disclosure requirements must be identified and fulfilled before sensitive information is passed to any external party. The people responsible for passing information must know when NDAs are required and how to apply them. NDAs must be signed before information is shared. The should-level requires NDA templates that are legally reviewed and kept current, and the NDA itself must cover the parties involved, the type and classification of information, the purpose, the validity period, and what happens upon termination or in case of unauthorized disclosure.

Evidence includes NDA templates, signed NDA records, and documentation showing awareness of NDA requirements among staff responsible for information exchange.

Chapter 7 — Compliance

This chapter addresses the organization’s obligations to comply with external legal, regulatory, and contractual requirements, and to handle personally identifiable data appropriately within its information security framework.

Note: Chapter 7 contains no separately titled subchapter. Controls run as 7.1.x.

7.1.1 — To what extent is compliance with regulatory and contractual provisions ensured?

Legal, regulatory, and contractual provisions relevant to information security must be identified at regular intervals. The landscape changes, and what was compliant last year may not be today. Policies and procedures for compliance with these provisions must be defined, implemented, and communicated to the responsible people. The should-level adds a specific focus on records integrity — the organization must ensure its records are maintained in a way that meets legal and regulatory requirements.

Evidence includes a legal and regulatory requirement register, compliance policies, communication records showing relevant staff awareness, and records management procedures.

7.1.2 — To what extent is the protection of personally identifiable data considered when implementing information security?

When personal data is processed, the legal and contractual information security requirements for that processing must be identified. Regulations for compliance with data protection requirements must be defined within the ISMS. This control is intentionally narrow in scope. It addresses data protection as an element of information security governance, not as a full replacement for GDPR compliance work (which is covered separately in the Data Protection sheet of the ISA).

Evidence includes a documented identification of applicable data protection requirements within the ISMS scope, internal policies referencing those requirements, and any relevant assessments or legal opinions obtained.

Document prepared based on ISA VDA 6.0.3, Information Security sheet. All control descriptions, requirements, and evidence expectations are derived directly from columns H (Control Question), I (Objective), J (Requirements must), K (Requirements should), L (Additional requirements for high protection needs), and M (Additional requirements for very high protection needs).

The post ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

/in

This is the part 4 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

Chapter 5 — IT Security / Cyber Security

This is the largest chapter in the Information Security sheet. It covers the technical and operational security measures applied to IT infrastructure, from encryption and network controls to development practices and cloud usage.

5.1 Cryptography

This subchapter addresses the use of cryptographic mechanisms to protect the confidentiality, integrity, and availability of information.

5.1.1 — To what extent is the use of cryptographic procedures managed?

All cryptographic algorithms, protocols, and key lengths used within the organization must meet recognized industry standards for their respective application. This applies across the board: encryption at rest, in transit, for signing, and for hashing. The should-level expects formal technical rules defining encryption requirements by information classification, and a cryptography concept covering algorithm choices, key strengths, key management, and the handling of lost or compromised keys. For high protection needs, key sovereignty requirements must be explicitly determined and fulfilled — particularly relevant when external services process encrypted data and the organization needs assurance that the provider cannot access keys.

Evidence includes a cryptography policy or technical standard, documentation of algorithms and key lengths used, key management procedures, and for high protection needs, documentation of key sovereignty arrangements.

5.1.2 — To what extent is information protected during transfer?

All network services used to transfer information must be identified and documented. Policies governing the use of these services must align with information classification requirements. Protection measures against unauthorized access and tampering during transfer must be implemented. The should-level adds requirements for correct addressing, content or transport encryption matched to classification, and verification that remote access connections meet adequate security standards. For high protection needs, information must be transferred in encrypted form — with documented compensating measures where encryption is not feasible. For very high protection needs, content-level encryption is required, not merely transport-level.

Evidence includes a data transfer policy, a list of approved network services, encryption configurations, and at higher protection levels, evidence of content encryption implementation.

5.2 Operations Security

This subchapter covers the day-to-day security of IT operations: managing changes, separating environments, protecting against malware, logging, handling vulnerabilities, auditing systems, managing networks, and maintaining continuity and backup capabilities.

5.2.1 — To what extent are changes managed?

Any change to the organization, business processes, or IT systems must consider information security requirements. The should-level requires a formal approval procedure for changes, impact assessments, planning and testing for changes affecting security, and documented fallback procedures. For high protection needs, compliance with security requirements must be verified both during and after change implementation.

Evidence includes a change management process, change request and approval records, testing documentation, and for high protection needs, post-implementation security verification records.

5.2.2 — To what extent are development and testing environments separated from operational environments?

Before deciding on separation, a risk assessment of IT systems must determine whether separation into development, test, and production environments is necessary. Where it is, separation must be implemented. The should-level adds more specific requirements: no development tools in production, no real production data in test environments unless appropriately protected, and documented requirements for each environment type.

Evidence includes the risk assessment that informed the separation decision, environment configuration documentation, and access control records showing restricted cross-environment access.

5.2.3 — To what extent are IT systems protected against malware?

Protection requirements against malware must be determined, and both technical and organizational measures must be defined and implemented. The should-level expects unnecessary network services to be disabled, access to remaining services to be restricted, malware protection software to be installed and automatically updated, and received files to be scanned before opening. No additional high or very high requirements apply.

Evidence includes the malware protection policy, configuration records for endpoint protection tools, and update verification records.

5.2.4 — To what extent are event logs recorded and analysed?

Information security requirements for logging must be determined and implemented. Activities of system administrators and privileged users must be logged. Systems must be assessed to determine appropriate log scope and retention. The should-level adds escalation procedures for relevant events, log integrity protection, and adequate retention periods. For high protection needs, contractual logging requirements must be met, and connections and disconnections of external networks — such as remote maintenance sessions — must be logged. For very high protection needs, any access to data of very high classification must be logged to the extent technically feasible and legally permissible.

Evidence includes a logging policy, log retention configuration, log integrity controls, and at higher protection levels, specific log samples or monitoring dashboards showing coverage of required event types.

5.2.5 — To what extent are vulnerabilities identified and addressed?

The organization must actively gather information about technical vulnerabilities affecting its IT systems — from manufacturer advisories, public CVE databases, and internal assessments — and evaluate them for relevance and severity using a structured method such as CVSS. Affected systems must be identified and remediated within an appropriate time. The should-level requires adequate patch management, including testing patches before deployment, implementing risk-minimizing measures while patches are pending, and verifying successful installation.

Evidence includes a vulnerability management procedure, subscription records for vulnerability feeds, patch management records, and evidence of CVSS-based prioritization.

5.2.6 — To what extent are IT systems and services technically checked (system and service audit)?

Technical audits of IT systems and services must be scoped, coordinated with system operators, and recorded in a traceable way. The should-level expects risk-aware planning of audits, regular execution by qualified personnel using appropriate tools, and documentation of findings and remediation. For high protection needs, critical IT systems must have additional audit requirements — such as human penetration testing or risk-driven intervals — defined and applied. For very high protection needs, IT systems and services must be regularly scanned for vulnerabilities, with documented compensating measures for systems that cannot be scanned.

Evidence includes audit planning records, audit reports, remediation tracking, and at higher protection levels, penetration test reports and scheduled scanning records.

5.2.7 — To what extent is the network of the organization managed?

Requirements for network management and segmentation must be determined and implemented. The should-level defines the basis for risk-based segmentation: limiting which IT systems can connect to the network, using appropriate security technologies, and considering performance, trust, and safety criteria. For high protection needs, additional requirements apply: IT systems must be authenticated on the network, management interfaces must be access-restricted, and specific risks — such as wireless access, remote maintenance, and IoT — must be addressed.

Evidence includes a network architecture diagram, segmentation documentation, firewall and access control configurations, and for high protection needs, network authentication records and management interface access controls.

5.2.8 — To what extent is continuity planning for IT services in place?

Critical IT services must be identified and their business impact documented. Requirements and responsibilities for continuity and recovery of those services must be known and fulfilled. The should-level expects identification of critical IT systems, appropriate classification and security measures for those systems, and planning that covers scenarios including DDoS attacks, ransomware, and power failures. For high protection needs, RTO targets must be defined in continuity plans and reflected in SLAs with external service providers. For very high protection needs, continuity plans must be coordinated with external service providers and must support continuance of essential functions with minimal or no operational interruption, including hot standby or rapid failover capabilities.

Evidence includes a business continuity and IT recovery plan, risk impact analysis, RTO and RPO documentation, SLAs with external providers, and for very high protection needs, failover test records and coordinated plans with key providers.

5.2.9 — To what extent is the backup and recovery of data and IT services ensured?

Backup concepts must exist for relevant IT systems, addressing confidentiality, integrity, and availability of backup data. Recovery concepts must also exist for relevant IT services. The should-level requires a comprehensive backup and recovery concept per IT service that accounts for inter-service dependencies and recovery sequencing. For high protection needs, backup and recovery concepts must be methodically reviewed at regular intervals, restore capability must be tested, and RPO and RTO targets must be defined. For very high protection needs, backups must be supplemented with offline procedures, immutable backups, or isolated IAM technology to protect against ransomware scenarios. Restore procedures must be technically tested at regular intervals. Geographical redundancy must be considered.

Evidence includes backup configuration documentation, recovery plans, test records proving restore capability, and for very high protection needs, immutable backup configuration records and geographically redundant storage records.

5.3 System Acquisitions, Requirement Management and Development

This subchapter covers how security is built into IT systems from the start — whether acquired from vendors or built in-house — and how the organization manages its relationships with cloud and external service providers at the technical level.

5.3.1 — To what extent is information security considered in new or further developed IT systems?

Security requirements must be embedded into both development and acquisition processes. This includes security requirements in specification documents, vendor recommendations and best practices, and fail-safe design principles. Security requirements must also be considered throughout the development lifecycle, including testing and deployment. The should-level adds formal requirement specifications referencing security standards. For very high protection needs, purpose-built or significantly customized software must undergo security testing — such as penetration testing — at commissioning, at major changes, and at regular intervals thereafter.

Evidence includes requirement specifications containing security criteria, development lifecycle documentation, and for very high protection needs, penetration test reports.

5.3.2 — To what extent are requirements for network services defined?

Information security requirements for network services must be determined and fulfilled. The should-level expects formal SLAs to document agreed requirements and adequate redundancy to be implemented. For high protection needs, traffic monitoring procedures — such as flow analyses and availability measurements — must be defined and carried out to detect anomalies and verify quality.

Evidence includes a network service requirements document, SLA agreements, and for high protection needs, traffic monitoring reports or dashboards.

5.3.3 — To what extent is the return and secure removal of information assets from external IT services regulated?

When terminating an external IT service, the organization must have a defined and implemented procedure for securely removing or retrieving its information assets. The should-level requires this procedure to be documented, kept current, and contractually embedded with the service provider.

Evidence includes a termination and data retrieval procedure, contracts containing data return and deletion clauses, and records of executed terminations.

5.3.4 — To what extent is information protected in shared external IT services?

In multi-tenant cloud or shared hosting environments, effective logical segregation must prevent other organizations’ users from accessing the organization’s information. The should-level expects the provider’s segregation concept to be documented and regularly reviewed, covering data, functions, software, operating systems, storage, and networking, as well as risk assessments for third-party software running in shared environments.

Evidence includes the cloud or hosting provider’s segregation documentation, contractual guarantees of tenant isolation, and internal review records.

 

The post ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

/in

This is the part 3 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

Chapter 2 — Human Resources

This chapter addresses the people dimension of information security: how the organization selects staff for sensitive roles, contractually binds them to security obligations, trains and raises awareness among them, and manages the risks associated with working outside the office.

Note: Chapter 2 in ISA 6.0.3 contains only one structural level beneath the chapter header. Controls are numbered in the format 2.1.x but there is no separately titled subchapter 2.1 header. The implicit grouping covers general HR security measures.

2.1.1 — To what extent is the qualification of employees for sensitive work fields ensured?

The organization must identify which roles are sensitive from an information security perspective, define the qualification requirements for those roles, and verify the identity of candidates before hiring. The should-level extends this to personal suitability checks — interviews, reference checks, or more rigorous methods depending on the role’s sensitivity. There are no additional requirements at high or very high protection need levels.

Evidence includes a list or classification of sensitive roles, defined job profiles with security-relevant criteria, and records of identity verification performed during hiring.

2.1.2 — To what extent is all staff contractually bound to comply with information security policies?

Every employee must be under a non-disclosure obligation and must be formally committed to complying with information security policies. The should-level adds an expectation that the NDA extends beyond the employment period, that security aspects are embedded in employment contracts, and that there is a procedure for handling violations.

Evidence includes employment contract templates containing NDA clauses and information security obligations, and any documented procedures for managing breaches of these obligations.

2.1.3 — To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?

All employees must receive training and awareness activities related to information security. The should-level defines a minimum scope for that training: the organization’s information security policy, how to report security events, how to respond to malware, how to handle user accounts and passwords, and physical security measures. Training must be refreshed at regular intervals.

Evidence includes a training concept or awareness program, training records showing which employees completed which modules, and records of the training schedule and frequency.

2.1.4 — To what extent is mobile work regulated?

Working outside defined security zones — home offices, client sites, travel — introduces risks that must be addressed by specific requirements. The must-level requires that the organization has determined and implemented requirements covering secure access to and handling of information in both electronic and physical form during remote work. The should-level adds considerations for travel-specific risks, including measures for travel to security-sensitive countries. For high protection needs, protective measures against overhearing and visual exposure — such as privacy screens and secure communication practices — must be implemented.

Evidence includes a teleworking or remote work security policy, records showing the policy has been communicated to staff, and for high protection needs, documented technical and organizational measures against visual and acoustic compromise.

Chapter 3 — Physical Security

This chapter addresses the physical layer of information security: the security zones where information is processed, the hardware and media that carries it, and the mobile devices used to access it outside secure perimeters.

Note: Like chapter 2, chapter 3 contains no separately titled subchapter. Controls run directly as 3.1.x.

3.1.1 — To what extent are security zones managed to protect information assets?

A security zone concept must exist that maps protection requirements to physical areas — offices, server rooms, delivery zones, reception areas. The concept must define what protective measures apply in each zone, and zones must be demarcated with visible or enforced perimeters. The should-level adds expectations for access rights management procedures, visitor management policies, and rules for using mobile IT devices inside secure zones. For high protection needs, measures against overhearing and visual exposure inside or near sensitive zones must be implemented.

Evidence includes the security zone documentation, access control records, visitor logs, and for high protection needs, records of anti-eavesdropping or visual screening measures.

3.1.2 — Superseded by 1.6.3, 5.2.8, and 5.2.9

This control is no longer active in ISA 6.0.3. Its content has been redistributed into crisis management (1.6.3), IT continuity planning (5.2.8), and backup and recovery (5.2.9). No assessment is performed against 3.1.2 as a standalone control.

3.1.3 — To what extent is the handling of supporting assets managed?

Physical assets that support information processing — servers, workstations, storage media, paper — must have defined requirements covering their entire lifecycle: transport, storage, repair, loss reporting, return, and secure disposal. The should-level is not populated for this control. For high protection needs, supporting assets must be disposed of in accordance with recognized standards — for example, ISO 21964 at Security Level 4 or equivalent — to prevent data recovery from discarded equipment.

Evidence includes a hardware and media lifecycle policy, disposal records, and for high protection needs, certificates of secure destruction.

3.1.4 — To what extent is the handling of mobile IT devices and mobile data storage devices managed?

Mobile devices and removable storage must meet defined security requirements covering encryption, access protection such as PIN or password, and appropriate marking. The should-level adds device registration and user communication about risks. For high protection needs, general encryption of mobile storage devices or the information stored on them is required. Where encryption is not technically feasible, equally effective compensating measures must be implemented.

Evidence includes a mobile device management policy, encryption configuration records, device inventory, and for high protection needs, evidence of encryption enforcement or compensating controls.

Chapter 4 — Identity and Access Management

This chapter covers the mechanisms by which the organization controls who can access what — from physical identification tokens to digital user accounts and the logic for granting or revoking rights.

4.1 Identity Management

This subchapter addresses physical and digital means of identification and the authentication procedures that verify a user’s identity before granting system access.

4.1.1 — To what extent is the use of identification means managed?

Physical and digital identification tokens — keys, access cards, cryptographic tokens, certificates — must be managed across their full lifecycle: creation, issuance, return, revocation, and destruction. Validity periods must be defined and traceability maintained, along with a process for handling lost means. The should-level expects these tokens to be produced only under controlled conditions. For high protection needs, validity periods must be actively limited to an appropriate duration, and a blocking strategy for lost tokens must be both defined and implemented as far as technically possible.

Evidence includes an identification means register, lifecycle management procedures, records of issued and returned tokens, and for high protection needs, proof of validity enforcement and loss response procedures.

4.1.2 — To what extent is the user access to IT services and IT systems secured?

Authentication procedures must be chosen based on a risk assessment that considers the attack surface of each system, including whether systems are directly internet-accessible. State-of-the-art authentication must be applied. The should-level requires strong passwords at minimum and stronger mechanisms for privileged users. For high protection needs, enhanced measures such as continuous session monitoring, automatic logout, and brute force prevention must be implemented based on the risk profile. For very high protection needs, access to data of very high classification must require strong two-factor authentication.

Evidence includes a risk assessment underpinning authentication choices, authentication configuration documentation, and at higher protection levels, records of enhanced access controls and monitoring.

4.1.3 — To what extent are user accounts and login information securely managed and applied?

User accounts must follow a clear lifecycle: creation, modification, and deletion all managed with oversight. Accounts must be unique and personal. Generic or shared accounts must be restricted to cases where traceability is genuinely not needed. Accounts must be disabled immediately when a user leaves or changes role. The should-level adds expectations around minimal default-privilege accounts, disabling of default manufacturer credentials, formal authorization procedures for creating accounts, and regular account reviews.

Evidence includes a user account management procedure, records of account creation and deactivation, and periodic access reviews.

4.2 Access Management

This subchapter addresses how access rights are granted, reviewed, and revoked — and how the organization ensures that rights remain aligned with actual need.

4.2.1 — To what extent are access rights assigned and managed?

Access rights must be managed based on the need-to-know and least privilege principles. The process for requesting, approving, and revoking rights must be defined. Rights must be revoked when no longer needed. The should-level expects role-based access control, with rights assigned to roles rather than individuals where possible, and regular reviews to identify stale or excessive rights. For high protection needs, access rights must be approved by a designated internal information officer. For very high protection needs, data of very high classification must be stored in encrypted form so that even privileged users cannot access it without appropriate authorization, and access rights must be reviewed more frequently.

Evidence includes an access rights management procedure, role definitions, access review records, approval records, and at higher protection levels, encryption configuration and formal information officer sign-off records.

 

The post ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

/in

This is the part 2 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

 

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

 

Chapter 1 — IS Policies and Organization

This chapter establishes the governance foundation of the entire ISMS. It covers formal structures, policies, and management decisions that make information security a deliberate, managed discipline rather than an informal practice. Without a solid chapter 1, everything downstream has no authoritative basis.

1.1 Information Security Policies

This subchapter asks whether the organization has committed its approach to information security in writing and whether that commitment comes from the right level of authority.

1.1.1 — To what extent are information security policies available?

The organization must have at least one formally approved information security policy. This is not a technical document. It is a management-level statement that defines what information security means for the organization, why it matters, what the objectives are, and what roles and responsibilities exist. The policy must be adapted to the organization’s specific context, not copied wholesale from a template.

The must-level requirements demand that the policy exists, that it has been formally released by management, and that it articulates the objectives and significance of information security. The should-level requirements raise the bar: the policy should also reflect the organization’s strategic direction, applicable legal obligations, and contractual requirements. It should state what consequences follow from non-compliance, reference other relevant security policies, and be subject to periodic review. There are no additional requirements at the high or very high protection need levels for this control.

Evidence an auditor will look for: the policy document itself, a visible approval signature or release notation, version history showing periodic reviews, and communication records proving staff awareness.

1.2 Organization of Information Security

This subchapter addresses how information security is structured within the organization — who owns it, who is responsible for what, how it connects to projects, and how external IT service providers fit into the accountability picture.

1.2.1 — To what extent is information security managed within the organization?

The organization must have a functioning ISMS with a defined scope, management endorsement, and monitoring mechanisms that give leadership visibility into the state of information security. Management must have actively commissioned and approved the ISMS. Passive acceptance is not enough.

Evidence includes the ISMS scope statement, documented management approval, and any governance reporting tools or dashboards used by leadership to track security performance.

1.2.2 — To what extent are information security responsibilities organized?

Roles and responsibilities for information security must be defined, documented, and assigned to real, qualified people. Those people must be known within the organization and to relevant external parties. The should-level pushes toward a documented organizational structure covering all relevant security roles. For high protection needs, the control adds a requirement for appropriate separation of duties to prevent conflicts of interest — for example, ensuring the person who configures systems is not the same person auditing them.

Evidence includes role descriptions, organizational charts, and records of qualifications for people in security roles.

1.2.3 — To what extent are information security requirements considered in projects?

All projects, regardless of their nature, must be classified from an information security perspective so that relevant security requirements are identified early. The should-level expects a documented procedure for this classification, risk assessments at project initiation and when changes occur, and documented measures for any identified risks. For high protection needs, those measures must be reviewed regularly throughout the project lifecycle and reassessed whenever the risk picture changes.

Evidence includes a project classification procedure, risk assessment records for projects, and documented security measures tied to specific projects.

1.2.4 — To what extent are the responsibilities between external IT service providers and the own organization defined?

When the organization uses external IT services, it must be clear who is responsible for which security requirements. A shared model — where both parties have responsibilities — must be explicitly defined, not assumed. The should-level requires that configurations are implemented and documented based on security requirements and that responsible staff are adequately trained. For high protection needs, a formal list of all affected external IT services and their responsible providers must exist, the applicability of ISA controls must be verified and documented, service configurations must be included in regular security assessments, and proof must be available that the provider actually implements the agreed security requirements.

Evidence includes contracts or service agreements with security clauses, RACI matrices or responsibility assignment records, and provider compliance documentation.

1.3 Asset Management

This subchapter addresses whether the organization knows what information assets it holds, how they are classified, and whether the tools and external services used to process them are managed with appropriate controls.

1.3.1 — To what extent are information assets identified and recorded?

Information assets — the core data and knowledge that matter to the organization — must be identified and recorded, with a responsible owner assigned. The supporting technical assets that process those information assets must also be inventoried and assigned an owner. The should-level expects a formal catalogue that maps supporting assets to information assets and is reviewed regularly.

Evidence includes an asset inventory or register, assigned ownership records, and review logs for the catalogue.

1.3.2 — To what extent are information assets classified and managed in terms of their protection needs?

The organization must have a consistent classification scheme focused at minimum on confidentiality, and must have applied that scheme to its information assets. Handling requirements must follow from the classification. The should-level encourages the organization to also consider integrity and availability when classifying assets.

Evidence includes the classification scheme documentation, records of classification applied to specific information assets, and handling guidelines tied to each classification level.

1.3.3 — To what extent is it ensured that only evaluated and approved external IT services are used for processing the organization’s information assets?

Before using any external IT service to process organizational information, a risk assessment must be completed and legal, regulatory, and contractual requirements must be considered. The service must be harmonized with the organization’s information security requirements. The should-level expects a formal approval and procurement procedure, a release process tied to protection need, and a documented inventory of approved services. No additional high or very high requirements apply beyond regular checking of approved status.

Evidence includes risk assessment records for external services, approval documentation, a register of approved external IT services, and contract clauses.

1.3.4 — To what extent is it ensured that only evaluated and approved software is used for processing the organization’s information assets?

Software must be approved before installation or use, taking into account licensing, use-case restrictions, conformance to security requirements, and the reputation of the source. Approval must also address the removal of software that is no longer needed or no longer compliant. The should-level adds expectations around managed repositories, protection of those repositories against tampering, and regular review of approvals. For very high protection needs, additional requirements — such as control or monitoring of software usage — must be determined and documented.

Evidence includes a software approval process, a software inventory or repository, records of approvals and periodic reviews, and for very high protection needs, usage monitoring records.

1.4 IS Risk Management

This subchapter addresses the central mechanism that connects threats and vulnerabilities to the organization’s information assets and produces actionable decisions.

1.4.1 — To what extent are information security risks managed?

Risk assessments must happen regularly and in response to events, not only on a fixed annual schedule. Identified risks must be assessed for probability and potential damage, documented, and assigned to a responsible risk owner. The should-level requires a formal risk management procedure, defined criteria for assessing and handling risks, and documented plans with responsible persons. Accepted risks must be explicitly approved by management. No additional high or very high protection need requirements apply.

Evidence includes risk assessment records, a risk register, documented risk treatment decisions, and management approval records for accepted risks.

1.5 Assessments

This subchapter addresses the organization’s obligation to verify that its information security policies and ISMS are actually working, through both internal reviews and independent external assessments.

1.5.1 — To what extent is compliance with information security ensured in procedures and processes?

Policies must be checked for compliance throughout the organization on a regular basis. Deviations must trigger corrective measures, and those measures must be tracked to closure. Compliance with legal and contractual information security requirements must also be verified. The should-level expects a documented plan that defines the scope, schedule, and controls covered by compliance reviews.

Evidence includes compliance review reports, records of corrective actions, and a compliance review schedule or plan.

1.5.2 — To what extent is the ISMS reviewed by an independent authority?

The ISMS must be assessed from outside the team responsible for running it — by an internal audit function, an external auditor, or another body that can provide an objective view. This must happen regularly and whenever fundamental changes occur. Corrective measures arising from such reviews must be tracked. The should-level expects results to be formally reported to management.

Evidence includes internal audit reports or third-party review reports, management reporting records, and corrective action logs.

1.6 Incident and Crisis Management

This subchapter covers the organization’s capacity to detect, respond to, and recover from security incidents and, at a higher scale, from crisis situations that threaten continuity.

1.6.1 — To what extent are information security relevant events or observations reported?

There must be a clear definition of what constitutes a reportable security event, and this definition must be known to employees and relevant stakeholders. The definition must cover personnel-related events, physical security observations, and technical/cyber events. The should-level requires a single point of contact for reporting, multiple reporting channels matched to severity, and formal obligations for employees to report. For very high protection needs, tests and exercises of the reporting process must be conducted regularly.

Evidence includes the event reporting definition and procedure, communication records or training materials proving staff awareness, and for very high protection needs, exercise records.

1.6.2 — To what extent are reported security events managed?

Once an event is reported, it must be processed without undue delay, receive an adequate response, and feed into continuous improvement through lessons learned. The should-level expects events to be categorized by type, qualified by severity, and prioritized. For high protection needs, maximum response times must be defined for each class and priority, and escalation mechanisms must be in place for events not processed within those times. For very high protection needs, event handling across different categories and priorities must be tested regularly, including simulation of rare scenarios and escalation exercises.

Evidence includes a ticketing or event management system showing processing records, defined response time SLAs, escalation procedures, and exercise or simulation records at the appropriate protection level.

1.6.3 — To what extent is the organization prepared to handle crisis situations?

A crisis is a situation where normal incident response is insufficient — for example, a major cyberattack causing infrastructure failure, a pandemic, or a natural disaster. The organization must have a crisis response and recovery plan, defined responsibilities, and appropriately qualified personnel. The should-level adds requirements for methods to detect emerging crises, a procedure to invoke crisis management, and documented strategic priorities for crisis situations. For high protection needs, a set of relevant crisis scenarios must have been identified, covering key personnel unavailability, facility unavailability, and major cyberattacks, with corresponding response plans. For very high protection needs, full crisis exercises and simulations involving all relevant decision-makers must be conducted regularly.

Evidence includes a crisis management plan, documented responsibilities, evidence of tested scenarios, and exercise reports.

 

The post ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization first appeared on Sorin Mustaca – Security & Technology.