ISA6_EN_redline

INTERNAL _x000D_ not public Maturity level 0 Maturity level 1 Maturity level 2 Name Incomplete Performed Managed Principle A process does not exist, is not followed or not suitable to achieve the objective. Definition Possible evidence (GWP) + Work products providing evidence of process outcomes. Information Security Assessment Maturity levels The answer to the control questions is a maturity level in a generic maturity model used to quantify the maturity of the corresponding processes. Determination of the maturity level requires that objective evidence of compliance with the requirements of the respective level is provided during the assessment. This is achieved, for example, by means of work products resulting from the processes of the control questions or by means of interview statements by persons carrying out the process. A process is followed which is not or insufficiently documented (“informal process”) and there is some evidence that it achieves its objective. A process achieving its objectives is followed. Process documentation and process implementation evidence are available. A process is not implemented or fails to achieve its process purpose. Little or no evidence exists of any systematic achievement of the process purpose. - The implemented process achieves its (process) purpose. - The intended base practices are verifiably performed. Control of process implementation (PA 2.1): - Objectives for the performance of the process are identified. - Implementation of the process is planned and monitored. - Implementation of the process is adjusted to meet plans. - Responsibilities and authorities for implementing the process are defined, assigned, and communicated. - Resources and information necessary for implementing the process are identified, made available, assigned, and used. - Interfaces between the involved parties are managed to ensure effective communication and clear assignment of responsibilities. Work Product Management (PA 2.2): - Requirements for the work products of the process are defined - Requirements for documentation and control of the work products are defined. - Work products are appropriately identified, documented, and controlled. - Work products are reviewed in accordance with planned measures and adjusted as necessary to meet requirements. + Process documentation + Process plan + Quality plan/records + Process implementation records

INTERNAL _x000D_ not public Examples KPI Examples and support License License conditions under which the ISA is published. Information Change history List of changes over the ISA lifetime. Information Key terms Term Explanation Examples The potential damage to the organization is limited and manageable. Confidentiality classification “internal” The potential damage to the organization may be substantial. Confidentiality classification “confidential” Confidentiality classification “strictly confidential” Requirements (must) The requirements indicated in this column are strict requirements without any exemptions. Requirements (should) Result (Maturity level) This tab shows examples of Key Performance Indicators (KPI) for measuring process results. The tab content provides support for identifying own suitable KPIs. It does not present mandatory requirements for achieving maturity level 4. Definition of KPIs is not mandatory, but may be helpful for a central management of information security at many locations. Protection class “normal”, normal protection needs Protection class “high”, high protection needs Protection class “very high”, very high protection needs The potential damage can reach a level of potentially threatening or disastrous impact on the organization’s existence. Principally, the requirements indicated in this column must be implemented by the organization. In certain circumstances, however, there may be a valid justification for non-compliance with these requirements. In case of any deviation, its effects must be understood by the organization and it must be plausibly justified. Additional requirements in case of high protection needs The requirements indicated in this column must additionally be met if the assessed subject has high protection needs. Additional requirements in case of very high protection needs The requirements indicated in this column must additionally be met if the assessed subject has very high protection needs. In the result tab ISA (spider web diagram), all results are presented as assessed. The line for the target maturity level does not consider controls marked “n.a”. When calculating the average, however, the maximum achievable target maturity level is taken into account.

INTERNAL _x000D_ not public Control question Objective 1 IS Policies and Organization This is intentional invisible text for technical reasons. Please do not remove this text This is intentional invisible text for technical reasons. Please do not remove this text This is intentional invisible text for technical reasons. Please do not remove this text This is intentional invisible text for technical reasons. Please do not remove this text. This is intentional invisible text for technical reasons. Please d 1.1 Information Security Policies 1.1.1 None None 1.2 Organization of Information Security 1.2.1 None None None 1.2.2 None 1.2.3 None None 1.2.4 None None 1.3 Asset Management 1.3.1 None None None 1.3.2 None None None Information Security Assessment Questionnaire Control number Maturity level Requirements (must) Requirements (should) Additional requirements for high protection needs Additional requirements for very high protection needs Additional requirements for Simplified Group Assessments (SGA) To what extent are information security policies available? The organization needs at least one information security policy. This reflects the importance and significance of information security and is adapted to the organization. Additional policies may be appropriate depending on the size and structure of the organization. + The requirements for information security have been determined and documented: - The requirements are adapted to the organization’s goals, - A policy is prepared and is released by the organization. + The policy includes objectives and the significance of information security within the organization. + The information security requirements based on the strategy of the organization, legislation and contracts are considered in the policy. + The policy indicates consequences in case of non-conformance. + Other relevant security policies are established. + Periodic review and, if required, revision of the policies are established. + The policies are made available to employees in a suitable form (e.g. intranet). + Employees and external business partners are informed of any changes relevant to them. + Policies are published and implemented in the entire assessment scope. To what extent is information security managed within the organization? Only if information security is part of the strategic goals of an organization, information security can be implemented in an organization in a sustainable manner. The information security management system (ISMS) is a control mechanism used by the organization’s management to ensure that information security is the result of sustainable management rather than that of mere coincidence and individual effort. + The scope of the ISMS (the organization managed by the ISMS) is defined. + The organization's requirements for the ISMS are determined. + The organizational management has commissioned and approved the ISMS. + The ISMS provides the organizational management with suitable monitoring and control means (e.g. management review). + Applicable controls have been determined (e.g. ISO 27001 Statement of Applicability, completed ISA catalogue). + The effectiveness of the ISMS is regularly reviewed by the management. + The management system is approved by an entity that has the necessary authority for the entire assessment scope (i.e., all locations within the scope). To what extent are information security responsibilities organized? A successful ISMS requires clear responsibilities within the organization. + Responsibilities for information security within the organization are defined, documented, and assigned. + The responsible employees are defined and qualified for their task. + The required resources are available. + The contact persons are known within the organization and to relevant business partners. + There is a definition and documentation of an adequate information security structure within the organization. - Other relevant security roles are considered. + An appropriate organizational separation of responsibilities should be established in order to avoid conflict of interests (separation of duties). (C, I, A) + A named person with overall responsibility for the management system exists and is available. To what extent are information security requirements considered in projects? For project implementation, it is important to consider the information security requirements. This applies to projects within the organization regardless of their type. By appropriately establishing the information security process in the project management procedures of the organization, any overlooking of requirements is prevented. + Projects are classified while taking into account the information security requirements. + The procedure and criteria for the classification of projects are documented. + During an early stage of the project, risk assessment is conducted based on the defined procedure and repeated in case of changes to the project. + For identified information security risks, measures are derived and considered in the project. + The measures thus derived are reviewed regularly during the project and reassessed in case of changes to the assessment criteria. (C, I, A) To what extent are the responsibilities between external IT service providers and the own organization defined? It is important, that a common understanding of the division of responsibilities exists and that the implementation of all security requirements is ensured. Therefore, when using external IT service providers and IT services, the responsibilities regarding the implementation of information security measures are to be defined and verifiably documented. + The concerned services and IT services used are identified. + The security requirements relevant to the IT service are determined: + The organization responsible for implementing the requirement is defined and aware of its responsibility. + Mechanisms for shared responsibilities are specified and implemented. + The responsible organization fulfils its respective responsibilities. + In case of IT services, configuration has been conceived, implemented, and documented based on the necessary security requirements. + The responsible staff is adequately trained. + A list exists indicating the concerned IT services and the respective responsible IT service providers. (C, I, A) + The applicability of the ISA controls has been verified and documented. (C, I, A) + The service configuration is included in the regular security assessments. (C, I, A) + Proof is provided that the IT service providers fulfil their responsibility. (C, I, A) + Integration into local protective measures (such as secure authentication mechanisms) is established and documented. (C, I, A) To what extent are information assets identified and recorded? It is important for each organization to know the information constituting its essential assets (e.g. business secrets, critical business processes, know-how, patents). They are referred to as information assets. An inventory ensures that the organization obtains an overview of its information assets. Moreover, it is important to know the supporting assets (e.g. IT systems, services/IT services, employees) processing these information assets. + Information assets and other assets where security is relevant to the organization are identified and recorded. - A person responsible for these information assets is assigned. + The supporting assets processing the information assets are identified and recorded: - A person responsible for these supporting assets is assigned. + A catalogue of the relevant information assets exists: - The corresponding supporting assets are assigned to each relevant information asset, - The catalogue is subject to regular review. To what extent are information assets classified and managed in terms of their protection needs? The objective of classifying information assets is the consistent determination of their protection needs. For this purpose, the value the information has for the organization is determined based on the protection goals of information security (confidentiality, integrity, and availability) and classified according to a classification scheme. This enables the organization to implement adequate protective measures. + A consistent scheme for the classification of information assets regarding the protection goal of confidentiality is available. + Evaluation of the identified information assets is carried out according to the defined criteria and assigned to the existing classification scheme. + Specifications for the handling of supporting assets (e.g. identification, correct handling, transport, storage, return, deletion/disposal) depending on the classification of information assets are in place and implemented. + The protection goals of integrity and availability are taken into consideration.

INTERNAL _x000D_ not public 3.1.3 None None None 3.1.4 None None 4 Identity and Access Management 4.1 Identity Management 4.1.1 + Identification means can be produced under controlled conditions only. None None 4.1.2 None 4.1.3 None None None 4.2 Access Management 4.2.1 None 5 5.1 Cryptography 5.1.1 None None 5.1.2 + Information is transported or transferred in content-encrypted form. (C) None 5.2 Operations Security 5.2.1 None None 5.2.2 None None None To what extent is the handling of supporting assets managed? During their lifecycle (e.g. usage, disposal), supporting assets are subject to risks such as loss, theft or unauthorized viewing. + The requirements for the handling of supporting assets (e.g. transport, storage, repair, loss, return, disposal) are determined and fulfilled. + Supporting assets are protected. Disposal of supporting assets is conducted in accordance with one of the relevant standards (e.g. ISO 21964, at least Security Level 4). (C) To what extent is the handling of mobile IT devices and mobile data storage devices managed? Mobile IT devices (e.g. notebooks, tablets, smartphones) and mobile data storage devices (e.g. SD cards, hard drives) are generally used not only on the premises of an organization, but also in mobile applications. This presents an increased risk with respect to e.g. loss or theft. + The requirements for mobile IT devices and mobile data storage devices are determined and fulfilled. The following aspects are considered: - Encryption, - Access protection (e.g. PIN, password), - Marking (also considering requirements for use in the presence of customers). + Registration of the IT devices. + Users are informed of missing data protection on mobile devices. + General encryption of mobile data storage devices or the information assets stored thereon: (C, I) - Where this is technically not feasible, information is protected by similarly effective measures. To what extent is the use of identification means managed? To check the authorization for both physical access and electronic access, means of identification such as keys, visual IDs, other physical access devices as well as cryptographic tokens are often used. The security features are only reliable if the use of such identification means is handled adequately. + The requirements for the handling of identification means over the entire lifecycle are determined and fulfilled. The following aspects are considered: - Creation, handover, return and destruction, - Validity periods, - Traceability, - Handling of loss. + The validity of identification means is limited to an appropriate period. (C, I, A) + A strategy of blocking or invalidation of identification means in case of loss is prepared and implemented as far as possible. (C, I, A) To what extent is the user access to IT services and IT systems secured? Only securely identified (authenticated) users are to gain access to IT systems. For this purpose, the identity of a user is securely determined by suitable procedures. + The procedures for user authentication have been selected based on a risk assessment. Possible attack scenarios have been considered (e.g. direct accessibility via the internet). + State of the art procedures for user authentication are applied. + The user authentication procedures are defined and implemented based on the business-related and security-relevant requirements: - Users are authenticated at least by means of strong passwords according to the state of the art. + Superior procedures are used for the authentication of privileged user accounts (e.g. Privileged Access Management, two-factor authentication). + Depending on the risk assessment, authentication procedure and access control have been enhanced by supplementary measures (e.g. continuous access monitoring with respect to irregularities or use of strong authentication, automatic logout, disabling in case of inactivity, or brute force prevention). (C, I, A) + Before gaining access to data of very high protection needs, users are authenticated by means of strong authentication (e.g. two-factor authentication) according to the state of the art. (C, I) To what extent are user accounts and login information securely managed and applied? Access to information and IT systems is provided via validated user accounts assigned to a person. It is important to protect login information and to ensure the traceability of transactions and accesses. + The creating, changing, and deleting of user accounts is conducted. + Unique and personalized user accounts are used. + The use of “collective accounts” is regulated (e.g. restricted to cases where traceability of actions is dispensable). + User accounts are disabled immediately after the user has resigned from or left the organization (e.g. upon termination of the employment contract). + User accounts are regularly reviewed. + The login information is provided to the user in a secure manner. + A policy for the handling of login information is defined and implemented. The following aspects are considered: - No disclosure of login information to third parties - not even to persons of authority - under observation of legal parameters - No writing down or unencrypted storing of login information - Immediate changing of login information whenever potential compromising is suspected - No use of identical login information for business and non-business purposes - Changing of temporary or initial login information following the 1st login - Requirements for the quality of authentication information (e.g. length of password, types of characters to be used). + The login information (e.g. passwords) of a personalized user account must be known to the assigned user only. + A basic user account with minimum access rights and functionalities is existent and used. + Default accounts and passwords pre-configured by manufacturers are disabled (e.g. by blocking or changing of password). + User accounts are created or authorized by the responsible body. + Creating user accounts is subject to an approval process (four-eyes principle). + User accounts of service providers are disabled upon completion of their task. + Deadlines for disabling and deleting user accounts are defined. + The use of default passwords is technically prevented. + Where strong authentication is applied, the use of the medium (e.g. ownership factor) is secure. + User accounts are reviewed at regular intervals. This also includes user accounts in customers' IT systems. + Interactive login for service accounts (technical accounts) is technically prevented. To what extent are access rights assigned and managed? The management of access rights ensures that only authorized users have access to information and IT services . For this purpose, access rights are assigned to user accounts. + The requirements for the management of access rights (authorization) are determined and fulfilled. The following aspects are considered: - Procedure for application, verification, and approval, - Applying the minimum (“need-to-know”/ "least privilege" ) principle. - Access rights are revoked when no longer needed + The access rights granted for normal and privileged user accounts and technical accounts are reviewed at regular intervals also within IT systems of customers. + Strategies for authorizing access to information are prepared. + Authorization roles are used. + Rights are allocated on a need-to-use basis and according to the role and/or area of responsibility. + Normal user accounts are not granted privileged access rights. + The access rights of a user account are adapted after the user has changed (e.g. to another field of responsibility). + The access rights are approved by the responsible internal Information Officer. (C, I, A) + Prevention of unauthorized persons gaining access and information (privileged users): (C) - Information is stored in encrypted form at content level (e.g. file level). - Where encryption is not feasible, information shall be protected by similarly effective measures. + Existing access rights are regularly reviewed at shorter intervals (e.g. quarterly) (C) IT Security / Cyber Security To what extent is the use of cryptographic procedures managed? When using cryptographic procedures, it is important to consider risks in the field of availability (lost key material) as well as risks due to incorrectly applied procedures in the fields of integrity and confidentiality (poor algorithms/protocols or insufficient key strengths). + All cryptographic procedures used (e.g. encryption, signature, and hash algorithms, protocols) provide the security required by the respective application field according to the recognized industry standard, - to the extent legally feasible. + Preparation of technical rules containing requirements for encryption in order to protect information according to its classification. + A concept for the application of cryptography is defined and implemented. The following aspects are considered: - Cryptographic procedures, - Key strengths, - Procedures for the complete lifecycle of cryptographic keys, including generation, storage, archiving, retrieval, distribution, deactivation, renewal, and deletion. + An emergency process for restoring key material is established. + Key sovereignty requirements (particularly in case of external processing) are determined and fulfilled. (C, I) To what extent is information protected during transfer? When being transferred via public or private networks, information can in some circumstances be read or manipulated by unauthorized third parties. Therefore, requirements regarding the protection needs of the information must be determined and implemented by taking suitable measures during such transfer. + The network services used to transfer information are identified and documented. + Policies and procedures in accordance with the classification requirements for the use of network services are defined and implemented. + Measures for the protection of transferred contents against unauthorized access are implemented. + Measures for ensuring correct addressing and correct transfer of information are implemented. + Electronic data exchange is conducted using content or transport encryption according to the respective classification. + Remote access connections are verified to possess adequate security features (e.g., encryption, granting and termination of access) and capabilities . + Information is transported or transferred in encrypted form: (C) - Where encryption is not feasible, information must be protected by similarly effective measures. To what extent are changes managed? The objective is to ensure that information security aspects are considered in case of any changes to the organization, business processes and IT systems (Change Management) in order to prevent these changes from causing an uncontrolled reduction in the information security level. + Information security requirements for changes to the organization, business processes, IT systems are determined and applied. + A formal approval procedure is established. + Changes are verified and assessed for their potential impact on the information security. + Changes affecting the information security are subjected to planning and testing. + Procedures for fallback in fault cases are considered. + Compliance with the information security requirements is verified during and after the changes are applied. (C, I, A) To what extent are development and testing environments separated from operational environments? The objective of separating the development, testing and operational environments is to ensure that the availability, confidentiality and integrity of productive data are maintained. + The IT systems have been subjected to risk assessment in order to determine the necessity of their separation into development, testing and operational systems. + A segmentation is implemented based on the results of risk analysis. + The requirements for development and testing environments are determined and implemented. The following aspects are considered: - Separation of development, testing and operational systems, - No development and system tools on operational systems (except those required for operation), - Use of different user profiles for development, testing, and operational systems.

INTERNAL _x000D_ not public 7.1.1 None None None 7.1.2 None None None None To what extent is compliance with regulatory and contractual provisions ensured? Non-compliance with legal, regulatory, or contractual provisions can create risks to the information security of customers and the own organization. Therefore, it is essential to ensure that these provisions are known and observed. + Legal, regulatory, and contractual provisions of relevance to information security (see examples) are determined at regular intervals. + Policies regarding compliance with the provisions are defined, implemented, and communicated to the responsible persons. + The integrity of records in accordance with the legal, regulatory, or contractual provisions and business requirements is considered. To what extent is the protection of personally identifiable data considered when implementing information security? Privacy and protection of personally identifiable data are considered in the implementation of information security as required by relevant national legislation and regulations, where applicable. + Legal and contractual information security requirements regarding the procedures and processes in the processing of personally identifiable data are determined. + Regulations regarding the compliance with legal and contractual requirements for the protection of personally identifiable data are defined and known to the entrusted persons. + Processes and procedures for the protection of personally identifiable data are considered in the information security management system.

INTERNAL _x000D_ not public Contractual requirements include, for example, customer requirements ISO 27001:2013: A.17.1 ISO 27001:2022: A.5.29 NIST CSF 1.1: ID.BE-2, ID.SC-5, PR.IP-7, PR.IP-9, PR.IP-10, RS.RP-1, RS.CO-3, RS.CO-4, RS.AN-1, RS.AN- 2, RS.AN-3, RS.AN-4, RS.MI-1, RS.MI-2, RS.IM-1, RS.IM-2, RC.RP- 1, RC.IM-1, RC-IM-2 BSI IT-Grundschutz-Compendium: DER.4 NIST SP800-53r5: CP-2, CP-3, CP-4, CP-6, CP-7, CP-8, CP-9, CP-9(3), CP-10, CP-11, CP-12, CP-13, PE-8, PE-13(2), IR-4, IR-5, IR-7, IR-8, IR-9, PM-8, SI-17 ISO 27001:2013: A.7.1.1 ISO 27001:2022: A.6.1 ISA/IEC 62443: 1.1.2 NIST CSF 1.1: PR.IP-11 BSI IT-Grundschutz-Compendium: ORP.2 NIST SP800-53r5: PS-2, PS-3, PS-7, PS-9, SA-21 ISO 27001:2013: A.7.1.2, A.7.3.1 ISO 27001:2022: A.6.2, A.6.5 BSI IT-Grundschutz-Compendium: ORP.2 NIST SP800-53r5: PL-4, PS-4, PS-6, PS-8 ISO 27002: A.7.2.1, A.7.2.2 ISA/IEC 62443: 1.1.4 NIST CSF 1.1: PR.AT-1, PR.AT-2, PR.AT-3, PR.AT-4, PR.AT-5, PR.IP- 11, RS.CO-1 BSI IT-Grundschutz-Compendium: ORP.2 NIST SP800-53r5: IR-2, AT-2(2), AT-2(3), AT-3(5), AT-6, AC-21(1), AT-3, AT-4, IR-2, IR-3, PM-12, PM-13, SA-16 ISO 27001:2013: A.6.2 ISO 27001:2022: A.6.7, A.8.1 BSI IT-Grundschutz-Compendium: INF.8, INF.9, CON.7, NET.3.3 NIST SP800-53r5: PE-17 ISO 27001:2013: A.11.1 ISO 27001:2022: A.7.1 - A.7.6 ISA/IEC 62443: 1.3.1, 8.1.3 NIST CSF 1.1: ID.BE-4, PR.AC-2, DE.CM-2, DE.CM-3 BSI IT-Grundschutz-Compendium: ORP.1, INF.1, INF.2, INF.5, INF.6, INF.7, INF.8, INF.9, INF.10, OPS.2.1 NIST SP800-53r5: PE-3, MA-5, MP-3, MP-4, PE-2, PE- 6, PE-8, PE-9, PE-10, PE-11, PE-13, PE-14, PE-15, PE-18, PE-23 Introduction: The concept of security zones basically describes different physical areas with different protection requirements. How a corresponding zone is to be protected is derived from the protection requirements of the assets located there. The more important the assets located there, the higher the protection requirements of the security zone. For example, personnel data or prototype data and the areas in which they are processed are more sensitive than areas of the canteen where menus are displayed. In principle, each company can freely choose the number of existing zone types. One approach would be, for example, to link the classification levels "public" to, for example, "strictly confidential" and the analogous definition of 4 security zones. Basic information: An effective security zone concept separates different security zones from each other by means of suitable measures. These separations can be represented by the following measures, among others: - Technical measures such as detectors and alarm monitoring. - Physical measures such as the use of walls, doors, locking systems - Personnel measures such as security guards, doormen, receptionists - Organizational measures such as processes for granting and withdrawing access authorizations. Only if a zone is separated from the previous zones by one or more measures, it can be considered as an independent zone. If there is no protective measure between the respective security zones, the higher security zone falls back to the lower zone. Using the example of an open-plan office, it is not possible to define one part as a highly sensitive zone for handling strictly confidential data, for example, and the other part as an internal zone. Using the example of a server room, this falls back to the protection level of the existing area such as corridors if the doors to the server room are not locked and no monitoring takes place. Security zones should be built on the basis of an onion-shell model. A highly protected zone is usually not adjacent to a public area (e.g. The prototype warehouse is located directly next to the publicly accessible canteen). Ideally, between a public area and a highly sensitive area such as the prototype warehouse, there is an "internal" zone as a buffer, which only the company's own employees can enter. A direct derivation of protective measures from the security zones is the implementation of the need-to-know principle. The more security-relevant the security zone, the fewer people should be able to enter the area. For example, if the entire workforce can enter an open-plan office, only administrators usually need access authorizations for the server room. For the implementation of a security zone concept, the implementation of an access concept is therefore always necessary. However, it should be noted that locking concepts do not correspond 1-to-1 with the security zones, since, for example, a prototype responsible for the highly sensitive zone of the prototype protection may not enter the highly sensitive zone of the server room, or the administrator does not necessarily have to enter prototype areas. The definition of security zones can affect the following areas, among others: - Technical measures: use of alarm systems, motion detectors, video cameras + Physical measures: walls, barbed wire, fences, resistance classes of doors & windows - Personnel measures: use of doormen, security services with stripes, use of external service providers such as cleaning companies - Organizational measures: Allocation of access authorizations (need-to-know), frequency of rights review of access authorizations; the introduction of sound recording devices; masking of optics from smartphones of employees and employees; Clear Screen and Clean Desk requirements; visitor registration requirements; Conclusion of confidentiality agreements (GHV); Use or prohibition of smart devices (e.g. with microphones) #####Technik with organizational measures##### Design aids for defining security zones in the security zone concept: The use of a zone scheme based on the classification scheme with four zone types has established itself as good practice for security zones: public area, normal protection area, high protection area and very high protection area. It is easier to transfer the protection requirements of the assets into a zone scheme, especially when first sketching security zones. It has also proven to be useful to mark the security zones on premises and building floor plans in color in order to provide the company itself and possible auditors with a quick overview of the location of the security zones. One possibility is the use of clearly defined and intuitive colors for each security zone. For example, the following color scheme could be chosen:

INTERNAL _x000D_ not public ISO 27001:2013: A.14.1, A.14.2 ISO 27001:2022: A.5.8, A.8.25 NIST CSF 1.1: PR.IP-1, PR.IP-2 BSI IT-Grundschutz-Compendium: CON.8, CON.10, OPS.1.1.2, OPS.1.1.6 NIST SP800-53r5: SA-3, SA-4, SA-5, SA-8, SA-20, SI- 13, SR-5 ISO 27001:2013: A.13.1.2 ISO 27001:2022: A.8.21 ISA/IEC 62443: 3.1.8 NIST CSF 1.1: PR.DS-4 BSI IT-Grundschutz-Compendium: NET.1.1, NET.1.2 NIST SP800-53r5: SA-3, SA-4, SA-17 ISO 27001:2022: A.5.23 ISO 27017: CLD.8.1.5 ISA/IEC 62443: 5.1.6 NIST CSF 1.1: PR.DS-3, PR.IP-6, PR.IP-11 BSI IT-Grundschutz-Compendium: ORP.5, CON.2, CON.6, CON.9, ORP.2 NIST SP800-53r5: MP-6, MP-8, SR-12 ISO 27017: CLD.9.5.1, CLD.9.5.2 NIST CSF 1.1: DE.CM-7 BSI IT-Grundschutz-Compendium: OPS.2.1, OPS.2.2, OPS.3.1 NIST SP800-53r5: SA-9, SC-4, SC-46 ISO 27001:2013: A.15.1, A.15.2.1 ISO 27001:2022: A.5.19 - A.5.22 NIST CSF 1.1: ID.SC-2, ID.SC-3, ID.SC-4 BSI IT-Grundschutz-Compendium: OPS.2.1, OPS.2.2, OPS.3.1, ORP.2 NIST SP800-53r5: MA-4, CA-3, CA-6, PM-16, PM-30, SR-2, SR-3, SR-6, SR-7, SR-8 Within the context of ISA, the term contractor includes both classic suppliers and subcontractors but also classic service providers, freelancers or other partner companies. It also includes cooperation partners (e.g. academic institutions, institutes). The explanations below describe a possible procedure for fulfilling the requirements: Identification of contractors and specification of protection needs and security requirements: At first, all contractors must be identified (e.g. via the list of creditors of the accountants department) in order to gain an initial overview. For all contractors, the respective protection needs should be specified and the security requirements derived according to their tasks and the relevance to own and customer’s processes. Generally, a large number of contractors is found not to require the assignment of relevant protection needs and to be therefore not subject to security requirements (e.g. suppliers of office stationary). Ensuring implementation by the contractor: In the next step, the applicable requirements must be made known to all security-relevant contractors in a suitable manner and (contractually) fixed as being mandatory. Finally, a decision should be made as to how the implementation of the security requirements can be appropriately verified. For this purpose, adequate verification processes and procedures should be defined according to the respective risk (and the associated protection needs). Their purpose is to ensure that contractors implement the necessary requirements. Establishment in standard processes: The insights gained should be used to develop a comprehensible procedure and to integrate it into the existing processes of the B2B / supplier management. This starts with the selection of the contractor, where aspects of information security should already be considered alongside criteria such as quality, adherence to delivery dates, credit rating etc. The procurement process should be such that the relevance of information security has already been considered beforehand (with respect to the procurement decision; contract design; inspection requirements). Furthermore, it is recommended to incorporate information security aspects into existing processes for supplier evaluation which have already been established by e.g. an existing quality management system. Contractually specified deliverables (e.g. availability requirements) should be verified at regular intervals. This can be done by e.g. regular analysis of service reports and SLAs. ISO 27001:2013: A.13.2.2, A.13.2.4 ISO 27001:2022: A.5.14, A.6.6 BSI IT-Grundschutz-Compendium: OPS.2.1, OPS.2.2, OPS.3.1, ORP.5, CON.2

INTERNAL _x000D_ not public ISO 27001:2013: A.18.1.1, A.18.1.2, A.18.1.3, A.18.1.5 ISO 27001:2022: A.5.31, A.5.32, A.5.33 NIST CSF 1.1: ID.GV-3, PR.IP-5 BSI IT-Grundschutz-Compendium: ORP.5 Introduction: Durch laws, regulations such as standards, contracts or even specially imposed requirements result in different requirements for processes, infrastructure, projects and / or workflows. Some of these requirements relate specifically to information security. Control therefore helps to identify and understand the existing requirements and to regulate the handling to meet the requirements. Reason: Die risks arising from non-compliance with specifications can result in serious financial and material damage as well as reputation-damaging consequences in one's own company or with customers and business partners. If requirements and specifications are not complied with or are not determined, this may result in breaches of contract or laws with corresponding consequences or risks for the company and its business partners. Basic information: Im general, Control is concerned with determining and monitoring compliance with requirements arising from laws, regulations and contracts as well as self-imposed requirements. The focus is on the relevance to the ISMS. It can be helpful here to first identify all relevant requirements, check them regularly and collect them in a kind of legal cadastre. In addition, it is necessary to define, in accordance with the requirements, how the corresponding provisions are to be fulfilled and for which group of persons these provisions are relevant. This can be done, for example, in the context of guidelines, action plans or work instructions that have been made known to the corresponding responsible persons. If requirements arise with regard to the integrity of documents and records, such as protection against loss, retention periods or access authorizations, these must also be recorded and considered. ISO 27001:2013: A.18.1.4 ISO 27001:2022: A.5.34 BSI IT-Grundschutz-Compendium: CON.2

INTERNAL _x000D_ not public Possible questions (examples, not mandatory) Possible evidence (not mandatory) Support: Examples “Normal protection need” Support: Examples “High protection need” Support: Examples “Very high protection need” - What information security requirements have been identified? - What are the guidelines on information security? - Who released them? - Are the requirements aligned with the organization's goals? - What are the objectives of the organization with regard to the ISMS and how are they to be achieved? - Who is responsible for implementation? - What are the consequences of not following the guidelines? - Who regularly reviews the guidelines and when? - How are the guidelines communicated to employees? Projects can be classified as follows - CIAA (Confidentiality, Integrity, Availability, Authenticity) - CIA (Confidentiality, Integrity, Availability) - What projects related to information security have been carried out? - What risks have been identified in this context for the individual project? - What criteria are used to assess the risk of projects? - What measures have been derived? - Have the measures been documented? - Has the risk been checked for changes during the project? It is not necessary to list all information assets individually; instead, categories can be established (e.g. master data of employees – responsible body: Human Resources) - Which core processes are required to perform the company's task? - What sensitive information do you receive from your customers? - What information do you have in your company that is worth protecting? - How is the process of identifying, recording and maintaining information values carried out? - How are responsibilities for information assets determined? - How is the handling of information values described? - How are the responsibilities for determining company values documented in the organization? - Which information directories are used to document the information values? - How and who ensures that the directories are up-to-date? - How are the regulations checked for up-to-dateness? - What evidence (e.g. impact analyses, etc.) is available? - How are the primary and supporting information values used determined, classified and documented? - How and when are the directories checked for completeness, timeliness and traceability? - How are the least critical information values evaluated and documented? - What protection levels are defined in the company and what criteria are used to classify them? - What measures are defined for each protection level? - How can the classification of the information be recognized by employees? - How is information classified? - What regulations are derived for the protection of information (storage media/documents)? - How do employees know how to classify information? - What are the tools for classifying the classification? - How are information objects labelled? - Who is responsible for classifying the classification? - How are unmarked documents handled? - What measures must be taken for each protection requirement in different situations (e.g. travel, destruction, storage, transport, storage)? - What contact channels are available so that employees can receive support in classification?

INTERNAL _x000D_ not public The protection need of software can be derived from the intended use-case or from the design of the software. This means all software that do not have access to information with high or very confidentiality or integrity need and that does not run on systems that have high or very high availability requirements can be considered software with normal protection need. Additionally, software where the risk to information is limited by the fact that it is not designed to access relevant information and does not have elevated privilegies can be considered having a normal protection need. An organization might adopt the following policiy: For normal protection need software, a bulk- approval based on licensing terms and a well-known or otherwise sufficiently trusted distributor seems the appropriate solution. If the software in question is not available from trustworthy distributor, the organization will do a brief evaluation of the software functionality by testing the software for obvious undesired functionality such as adware or spyware by means of individual recherche and testing. Updated software will regularly inherit the approval of previous versions unless significant changes are detected. For this example, software that has only access to information with high protection need in terms of availability or integrity or are relevant for availability on systems with a respective need or software that faces specific security risks (software that is used to communicate with untrusted communication ends such as externally reachable server software, network clients such as web browsers), is considered software with high protection need. For such software and use-cases, the example organization may maintanin a list of repositories and vendors that are trusted for these cases (such as baseline software installation of the operating system and drivers and firmware for the used hardaware with well-known licensing terms). To get to this list, a vendor and repository can either be well-known and widely accepted (i.e. common operating systems and their base software, drivers for standard hardware) or individually known by the organization (such as a vendor for special hardware or machines that have been carefully selected. A software that is not on such a list can be individually evaluated by checking licensing conditions and then searching for bad reputation and finally by doing a test-installation to check for undesired available features or functionality such as adware or spyware. Updated software will regularly inherit the approval of previous versions unless significant changes are detected. For this example, software that has access to information with very high protecton need in terms of availability and integritcy or software that is relevant for the availability of Critical IT Systems. Even such software and use-cases , the example organization may maintanin a list of repositories and vendors that are trusted for these cases (such as baseline software installation of the operating systems designed for the purpose and drivers and firmware for the used hardaware with well-known licensing terms. However, to gain the trust the vendor and distributor must have an excellent reputation. All other software is individiually approved. Depending on the risk profile, this may include not only testing but also careful analysis of available documentation (or even a technical audit of the functionality of a specific software). Change logs for software wil Updated software will regularly inherit the approval of previous versions for minor software versions. However, the organization will actively monitor release notes and (if available) relevant other sources to detect changes that might require a re-evaluation. Major software versions always require re-evaluation before approval. + What is your strategy when it comes to software approval? + Do you differentiate approval on protection need or usage scenario? + What software is currently approved for working with a specific protection need? + How does your software approval process work? + For what use case is software A approved? + Where can i see what software is installed on a specific client or server? + How does the software repository work? How do users and/or administrators access it to install software? + Process documentation for approval process + Exports of lists of approved software from software repositories + Screenshots from software management software (such as MDM)

INTERNAL _x000D_ not public For example, security zones can be represented as follows: - Public (typical color coding in the security zone plan: grey): Public street, parking lot without fences, company premises if no fencing is present, stairwell in a house with several tenants. - Normal protection requirements (typical color coding in the security zone plan: green) (e.g. internal data): Company premises, if a complete fencing is given, reception areas, conference rooms, corridors, general areas where every employee can stay, but these cannot be entered from the public areas. - Special protection requirements (typical color coding in the security zone plan: purple): server room, infrastructure switch and distribution rooms, chemical warehouse Example of a zone with normal protection requirements: The following example contains selected measures for an open-plan office of the shipping department, in which only internal information such as shipping information, delivery notes and package labels are produced and processed. The classification of the assets located there has at most an "internal character". - Example of technical measures: The open-plan office has not implemented any separate technical protection measures. - Example of physical measures: The façade as well as doors and windows are built in solid construction and thus enable a resistance class against burglary according to RC 2 according to DIN EN 1627. Doors to the open-plan office are open during the day so that every employee of the company can enter the room at any time. In the evening the door is locked. - Example of personnel measures: At night, a security service sporadically carries out strip searches. An external cleaning company cleans the open-plan office unattended outside regular working hours and uses its own keys. - Example of organizational measures: Each employee of the open-plan office has his own key. A ban on the use of company and private smartphones is not pronounced. Employees can use these devices freely. A review of the assigned access authorizations takes place sporadically. Employees are allowed to leave documents such as delivery notes on the tables after work. Visitors (and suppliers) may enter the area alone after registration and if necessary and do not have to conclude an explicit confidentiality agreement in advance. For example, security zones can be represented as follows: - High protection requirements (typical color coding in the security zone plan: yellow/orange) (e.g. confidential data): HR department, design office, IT office, management offices Example of a zone with high protection needs: The following example contains selected measures for design offices in which tender documents, specifications and calculations are created, edited and stored. The classification of the assets located there has a "confidential character". - Example of technical measures: The design office is equipped with motion sensors. After the daily working hours, the alarm system for the entire building is activated at 22:00 and automatically deactivated at 6:00. - Example of physical measures: The façade as well as doors and windows are built in solid construction and thus enable a resistance class against burglary according to RC 2 according to DIN EN 1627. Doors to the design office are open during the day when construction employees are working within the zone. In the evening and in the absence of the employees, the door is locked. - Example of personnel measures: At night, a security service carries out sporadic strip searches. An external cleaning company cleans the design office during regular working hours only under the supervision of employees present. The cleaning company does not have its own keys to the design office. - Example of organizational measures: Only employees of the construction have their own key. A ban on the use of company and private smartphones is not pronounced. Employees can use these devices freely, but there is a ban on taking photographs in the room. A review of the assigned access authorizations takes place once a year. Employees of the construction are obliged to lock confidential documents in cabinets after work. Visitors (and suppliers) are not allowed to enter the area alone and are accompanied in this area at all times. For example, security zones can be represented as follows: - Very high protection requirements (typical color coding in the security zone plan: red) (e.g. strictly confidential data): prototype area, project offices for customers. Example of a zone with high protection needs: The following example contains selected measures for a project office with special customer projects. The classification of the assets located there is "strictly confidential". - Example of technical measures: The area is equipped with motion sensors. When leaving the area, it is alarmed. A loud siren sounds when a burglary attempt is made. In addition, the alarm system is connected to a security service. - Example of physical measures: The façade as well as doors and windows are built in solid construction and thus enable a resistance class against burglary according to RC 2 acc. DIN EN 1627. The area has an external knob so that it is not possible to forget to close the door. So a key must always be used to enter the room. In addition, door closers are fitted to ensure that the door does not remain open. - Example of personnel measures: External service providers may only enter the area in exceptional cases, after prior announcement and registration, accompanied by employees of the area. Employees are qualified and sensitized before obtaining project-related access permits. - Example of organizational measures: Only employees of the department have their own key. A review of the assigned access authorizations takes place once a year. - What are the different security zones you have? - How are your security zones designed? - Why did you choose your security zones? - Where are the areas with a very high need for protection? - What happens in the event of a break-in? - How many people have access to zone XYZ? - Who assigns the respective access authorizations for area XYZ? - When was the last check of the assigned access authorizations for selected areas carried out? - When was the last time you revoked an access authorization? - How do you document the request, approval and allocation of access authorizations? - How does the visitor registration process work? - Security zone concept and plan (site plan) - Key lists - Extracts of the assigned authorizations of an electronic access control system - Access logs of selected areas - Visitor Policy - Guideline for the handling of mobile IT devices - Protocols of reviews - Photos of the respective areas with recognizable security measures - Contracts with security companies

INTERNAL _x000D_ not public - Where have you defined which supporting assets exist and which information values may be stored on them? - How are supporting assets with high protection requirements protected? - Which encryption methods are used? - Where are the requirements for the life cycle of different suporting assets described? - What do employees have to do with documents when leaving the workplace? - How are hard drives, e.g. from purchased or leased devices, disposed of? - How do you dispose of paper documents? - Where are the shredders / data protection bins? - What user authentication methods are used in the organization? - What criteria were used to select the user authentication methods (risk assessment, state of the art, business and security requirements, etc.)? - What methods are used to authenticate privileged user accounts? - How is it ensured that the password standard used in the organization corresponds to the current state of the art? - Have sensitive resources been identified and which sensitive resources and systems are accessed with two-factor authentication? - How is it ensured that privileged access rights are restricted, controlled and secured by higher-level authentication procedures? - Is information with a very high need for protection identified and the associated access mistaken with a second factor? - How are user accounts created, changed, blocked and deleted? Does it use unique and personalized user accounts? - What security measures have been implemented when using "collective accounts"? - Are user accounts checked at regular intervals? Can you show the last review? - How are user credentials delivered? - Which regulations have been defined and implemented for the handling of login information? - What training have the employees received regarding credential handling? - What security considerations have you taken to ensure that credentials are not compromised? - Which shares are used for setting up user accounts? - e-mail encryption by means of TLS - access to websites via https:// - e-mail encryption by means of S/MIME, PGP - encrypted PDF files, encrypted ZIP files

INTERNAL _x000D_ not public Desktop firewall, Linking to loopback interfaces - What information about technical vulnerabilities can be determined? - What are your sources? - Where do you list hardware and software? - How do you reconcile this information with your IT systems? - Which vulnerabilities can be identified on the basis of risk assessments? - When do you respond to identified vulnerabilities? - How is the process from identification to elimination of the vulnerability defined? Possible measures: - Use of security technologies such as firewall systems, intrusion detection and prevention systems (IDS/IPS), network management tools, security software for networks for preventing unintended data exchange. - What requirements have you defined for managing and controlling your network? - How do you check that these requirements are complied with or fulfilled? - How did you evaluate the segmentation of your network? - How is the transition from one subnetwork to another prevented? - Which evaluation results have you documented? - Which requirements for your network have you determined and recorded? - Who manages, controls and maintains your network? - How do you identify new IT systems in the network that were not installed by IT? - What access rights do the administrators have with regard to all devices such as firewalls, switches and routers? - Which protocols do you use and which do you not use? - Who has access to network components and how? - Who has access to the services in the network and how? - Which protection mechanisms should be used in the network (e.g. firewall, IDS/IPS) - What are the availability requirements? - How is the network documented? - What are the requirements when using cloud services / externally hosted systems?

INTERNAL _x000D_ not public - How are the requirements for information security determined in the development of IT systems? - How are legal or regulatory requirements for IT system development considered? - Is a standard/guideline/framework used for IT system development? - How are the design changes of the IT system controlled? - How is the external development process of the IT system (third- party development) controlled? - How is the development environment managed? (commissioning, configuration, access, decommissioning) How are risks related to IT system development assessed and documented? - How is compliance with information security requirements verified during IT system development? - How are real test data sets, if any, controlled during IT system development? Identification of contractors and specification of protection needs and security requirements: It is crucial for this evaluation, whether the contractor’s work includes 1) gaining access to information or security zones of the company with normal protection needs regarding confidentiality; or 2) providing or being able to modify relevant information with normal protection needs regarding integrity; or 3) having relevant influence on processes or IT systems with normal protection needs regarding availability (comp. to internal or customer-related SLAs). Typical contractors with normal protection needs are e.g. cleaning services for general areas, classic logistics companies or maintenance staff. The minimum requirements for information security (in relation to the respective protection goal) should be defined in a policy (e.g. information security policy for service providers). These requirements can be based on the requirements of the ISA described herein in addition to the company-specific requirements. This policy can be supplemented according to the specific order. Ensuring implementation by the contractor: The security requirements should be made known to the contractor, e.g. at procurement, in briefings (project meetings) by corresponding documents (e.g. information security policy for service providers) or when entering the premises (in case of contractors providing their services on site). Compliance with the information security requirements should be contractually fixed. At this point already, potential further subcontractors of the contractor should also be considered, as relevant. This can be done by individual agreements such as general terms and conditions of purchase, for example. In many cases, suppliers (e.g. IT service providers) already assure compliance with security requirements in their standard contracts. In order to ensure compliance with the requirements in a suitable manner, simple mechanisms should be established. This may include, for example: - The submission of at least a self-disclosure confirmed by the management (e.g. ISA) or an adequate attestation/certificate - The right to and execution of irregular sampling and event-related inspections. Identification of contractors and specification of protection needs and security requirements: It is crucial for this evaluation, whether the contractor’s work includes 1) gaining access to information or security zones of the company with high protection needs regarding confidentiality; or 2) providing or being able to modify relevant information with high protection needs regarding integrity; or 3) having relevant influence on processes or IT systems with at least high protection needs regarding availability (comp. to internal or customer-related SLAs). Typical contractors with high protection needs are e.g. cleaning services autonomously cleaning relevant security zones, IT service providers (e.g. data base administrators), consultants, agencies and subcontractors (e.g. tool designers to whom project data need to be forwarded). Obviously, contractors with high protection needs are subject to the minimum information security requirements regarding the respective protection goal. These requirements should be supplemented particularly by necessary general (see e.g. ISA high protection needs) and order- specific requirements. Ensuring implementation by the contractor: Here, the procedure described for normal protection needs can be used for orientation. Besides the obligation regarding implementation of an adequate information security level and the non-disclosure obligation, a right to audit should be contractually fixed or appropriate controls (regular auditing of the contractor) should be ensured. This may also include an obligation to participate in TISAX. In order to ensure compliance with the requirements in a suitable manner, simple mechanisms should be established. This may include, for example: - contractor requires TISAX label for high protection needs or equivalent (e.g. ISO 27001, certificate of corresponding scope) - right to and execution of regular sampling and event-related inspections. Identification of contractors and specification of protection needs and security requirements: It is crucial for this evaluation, whether the contractor’s work includes 1) gaining access to information or security zones of the company with very high protection needs regarding confidentiality; or 2) providing or being able to modify relevant information with very high protection needs regarding integrity; or 3) having relevant influence on processes or IT systems with at least very high protection needs regarding availability (comp. to internal or customer-related SLAs). Typical contractors with very high protection needs are IT service providers (e.g. domain administrators), consultants, agencies, subcontractors (e.g. CAD designers to whom extensive project data of very high protection needs need to be forwarded) and prototype manufacturers. Obviously, contractors with very high protection needs are subject to the minimum information security requirements regarding the respective protection needs. These requirements should be supplemented particularly by necessary general (see e.g. ISA very high protection needs) and order-specific requirements. The difference to high protection needs is essentially the number and quality of the necessary additional requirements. Ensuring implementation by the contractor: Here, the procedure described for high protection needs can be used for initial orientation. Besides the obligation regarding implementation of an adequate information security level and the non-disclosure obligation, a right to audit should be contractually fixed or appropriate controls (regular auditing of the contractor) should be ensured. This should also include an obligation to participate in TISAX. In order to ensure compliance with the requirements in a suitable manner, simple mechanisms should be established. This may include, for example: - contractor requires TISAX label for very high protection needs - right to and execution of regular and event-related thorough inspections (if applicable, supplemented with supporting certificates). - Which contractors/service providers receive or process data in need of protection? - Which contractors/service providers are granted access to security zones? - Are any further contractual agreements regarding information security other than the non-disclosure agreement in effect? - How is the compliance with contractual agreements by the contractor/service provider verified? - At which points within the company are risk assessments regarding the employment of contractors/service providers conducted? - Is an information security policy for contractors/service providers in place? - How is the compliance with policies by the contractors/service providers verified? - Which contractors/service providers have been/are reviewed? - How is the review documented? - Which criteria trigger an assessment process? - How are the services rendered by contractors/service providers reviewed? - Are networks/IT systems maintained by contractors/service providers? - How do you prevent that contractors/service providers can gain unauthorized access to information of high/very high protection needs? - Template NDA with contractor - Example of undersigned NDA - Example of risk assessment (Focus point: Information security aspects) - Information security policy for service providers/contractual terms and conditions regarding information security - Process description B2B/supplier management (e.g. selection, evaluation, qualification of suppliers) - Viewing of self-disclosures - Viewing of attestations/certificates of selected suppliers (e.g. TISAX label; ISO 27001 certificate) - Example of conducted supplier evaluation (focus on information security aspects) - Viewing of audit reports - List of approved contractors - Viewing of SLA Reporting

INTERNAL _x000D_ not public Corresponding provisions can be included in the following, for example: - Author’s rights - Cryptography - Copyright - Intellectual property - Archiving - Information security legislation - Data protection - Trade Secrets Act - Contractually agreed provisions (GTC, terms and conditions of purchase, framework contracts, individual contracts) - What are the legal and regulatory requirements that are relevant to you and that you must take into account in your ISMS? - What are the contractual requirements relevant to you that you need to take into account in your ISMS? - Are these requirements maintained in a corresponding legal register? - Are the legal and regulatory requirements checked at regular intervals to ensure that they are up to date? - Which person(s) are responsible for the legal, regulatory and contractual requirements and their implementation and compliance (process owners)? - Is compliance documented in a report? - When and with what result was this process last audited? Raising awareness: - How often and at what interval are awareness-raising measures carried out? - What are the contents of awareness-raising activities? - How do you ensure that the awareness-raising measures reach all employees? Intellectual property: - What are the contractual provisions on "intellectual property" in the contracts with subcontractors? - What are the contractual provisions on "intellectual property" in the employee contracts? License: - How do you handle licenses for internal use (license management)? - What is your policy on the use of licenses? - What is your policy on downloading software from the Internet? Open source: - How is the use of "Open Source" products in software development regulated? - How are the license terms of "Open Source" products regularly reviewed and made transparent to customers? - What are the contractual regulations for the use of "open source" products by subcontractors? What are the contractual requirements relevant to you that you need to take into account in your ISMS?

INTERNAL _x000D_ not public Control question Measures/recommendations Further information 8 Prototype Protection 8.1 Physical and Environmental Security 8.1.1 . 8.1.2 8.1.3 8.1.4 8.1.5 8.1.6 8.1.7 8.1.8 Information Security Assessment Additional prototype protection requirements Control number Maturity level To what extent is a security concept available describing minimum requirements regarding the physical and environmental security for prototype protection? To what extent is perimeter security existent preventing unauthorized access to protected property objects? To what extent is the outer skin of the protected buildings constructed such as to prevent removal or opening of outer- skin components using standard tools? To what extent is view and sight protection ensured in defined security areas? To what extent is the protection against unauthorized entry regulated in the form of access control? To what extent are the premises to be secured monitored for intrusion? To what extent is a documented visitor management in place? To what extent is on-site client segregation existent?

INTERNAL _x000D_ not public 8.2 Organizational Requirements 8.2.1 8.2.2 8.2.3 8.2.4 8.2.5 8.2.6 8.2.7 8.3 To what extent are non-disclosure agreements/obligations existent according to the valid contractual law? To what extent are requirements for commissioning subcontractors known and fulfilled? To what extent do employees and project members evidently participate in training and awareness measures regarding the handling of prototypes? To what extent are security classifications of the project and the resulting security measures known? To what extent is a process defined for granting access to security areas? To what extent are regulations for image recording and handling of created image material existent? To what extent is a process for carrying along and using mobile video and photography devices in(to) defined security areas established? Handling of vehicles, components, and parts

INTERNAL _x000D_ not public 8.3.1 8.3.2 8.4 Requirements for trial vehicles 8.4.1 8.4.2 8.4.3 8.5 Requirements for events and shootings 8.5.1 To what extent are transports of vehicles, components or parts classified as requiring protection arranged according to the customer requirements? To what extent is it ensured that vehicles, components, and parts classified as requiring protection are parked/stored in accordance with customer requirements? To what extent are the predefined camouflage regulations implemented by the project members? To what extent are measures for protecting approved test and trial grounds observed/implemented? To what extent are protective measures for approved test and trial drives in public observed/implemented? To what extent are security requirements for presentations and events involving vehicles, components or parts classified as requiring protection known?

INTERNAL _x000D_ not public 8.5.2 To what extent are the protective measures for film and photo shootings involving vehicles, components or parts classified as requiring protection known?

INTERNAL _x000D_ not public Support: Examples “Normal protection need” Support: Examples “High protection need” Support: Examples “Very high protection need”

INTERNAL _x000D_ not public Possible questions (examples, not mandatory) Possible evidence (not mandatory) Column4

INTERNAL _x000D_ not public Assessment Control question Objective 9 Data Protection This is intentional invisible text for technical reasons. Please do not remove this text. This is intentional invisible text for 9.1 Data Protection Policies 9.1.1 To what extent do data protection policies exist? 9.2 Organization of Data Protection 9.2.2 Successful data protection requires clear responsibilities in the organization. 9.3 Processing directory 9.3.1 9.4 Data protection impact assessment 9.4.1 9.5 Data transfers 9.5.1 To what extent is the transfer of data managed? The company knows and secures data transmissions. 9.5.2 The company is aware of and secures data transfers to subcontractors. 9.5.3 The company is aware of and secures data transfers to third countries. 9.6 Handling requests and incidents 9.6.1 9.6.2 9.7 Human Resources 9.7.1 9.7.2 9.8 Instructions 9.8.1 Information Security Assessment Additional requirements for Data Protection/Privacy Control number Requirements (must) This tab supplements the Information Security tab on information security with data protection. In order to obtain an effective TISAX assessment of data protection, the information security questionnaire must be also assessed. Therefore, an isolated assessment of the data protection module cannot lead to a TISAX certification. The organization needs at least one policy on privacy. This reflects the importance and significance of data protection and is adapted to the organization. Other policies may be appropriate depending on the size and structure of your organization. + A policy is created, regularly updated, and approved by the organization's management. To what extent are the responsibilities for data protection organized? + A data protection officer is appointed, if required by Art. 37 GDPR - Determination of whether the appointment of a data protection officer is voluntary or mandatory - otherwise determination of a data protection function or comparable + Publication of contact details (e.g. on the Internet) + Integration into the organization's structure + Exercise of the control obligations as defined in Art. 39 (1) (b) GDPR and corresponding documentation + Documentation of the data protection status and report to organization's top management + Equipped with sufficient capacities and resources - Determination of whether the data protection function is full-time or part-time - adequate professional qualification - regular professional training - access to specialist literature - support of the data protection officer by data protection coordinators in the companies organizational units, depending on the company size (e.g. marketing, sales, personnel, logistics, development, etc.) To what extent are processing activities identified and recorded? The company fulfils its duty of accountability and transparency and thus creates an overview of the respective data processing. + If required by law, a register of processing activities as defined in Article 30 (1) and/or (2) GDPR (in the latter case only information relating to the order, expressly not other information/details on internal processing) exists and is up to date. - Technical and organizational measures required for processing as required by the information security questionnaire are adequatly implemented for the processing activities - There is a process description / sequence description with defined responsibilities. To what extent is adequate handling of high-risk processing activities ensured (data protection impact assessment)? The handling of high-risk processing is secured in cooperation with the service provider with appropriate measures to identify and, if necessary, reduce risks to the rights and freedoms of the data subjects. + Processing activities that require a data protection impact assessment are known. + Data protection impact assessments are carried out. - Responsibilities/tasks and support possibilities in the context of data protection impact assessments are defined and known. + Appropriate processes and workflows for the transmission of data are implemented (e.g. valid contracts within the meaning of Art. 28 GDPR, suitable transfer instruments like standard contractual clauses, transfer impact assessments, adequacy decisions) - Ensuring the consent or the right of objection of the person responsible for subcontracting To what extent are contractual obligations passed through to and enforced at subcontractors and cooperation partners? + Applicable contractual obligations to clients are passed on to subcontractors and cooperation partners (sub processors). + Compliance with contractual agreements is reviewed. - Contact details of the contact persons of the subcontractor are available and up to date. To what extent are data transfers to third countries managed? + Transfers to third countries are known and systematically recorded. - e.g. through corresponding documentation in the processing directory + Sufficient guarantees (Chapter V GDPR, consideration of decisions of the ECJ on international data transfer, Transfer Impact Assessment in case of relevance, especially in the role of data exporter) are available for data transfers. + In the case of data transfers to third countries, it is determined whether the consent of the person responsible is to be obtained for each transfer to third countries. To what extent are data subject requests processed? The objective is to ensure the timely processing and fulfilment of data subject requests in order to secures the rights of data subjects guaranteed by law. + Requests from data subjects are processed in a timely manner. - Procedures are in place to assist the controller in responding to data subject requests. - Employees are trained to the effect that they must immediately contact the respective person responsible in the event of an incoming request from a data subject and coordinate the further procedure with this person. To what extent are data protection incidents processed? The objective of processing data protection incidents is to ensure that possible damage to the data subjects is limited and that a recurrence is prevented. In addition, the legally required documentation and, if necessary, timely reporting to the supervisory authority must be ensured. + Data protection incidents (e.g. unauthorized access to personal data) are processed in a timely manner. + The requirements from 1.6 of the information security questionnaire also take into account data protection incidents or, alternatively, there is an emergency plan for dealing with data protection incidents. + In addition, procedures are established and documented to ensure the following aspects: - immediate notification to the respective responsible person, as far as his order is affected - Documentation of the incident handling activities - Training of employees on the defined measures/processes - Support of the respective controller in the processing of data protection incidents To what extent are employees obliged to maintain confidentiality? Organizations are subject to laws, regulations, and internal policies. For employment (hiring/implementation/termination), it is important that employees commit to compliance with the guidelines. + Employees whose tasks include the processing of personal data are obliged to maintain confidentiality (even beyond the duration of the employment relationship) and to comply with applicable data protection laws. - The obligation is documented To what extent are employees trained in data protection? If the requirements and risks of data protection are not known to employees, there is a risk that employees will behave incorrectly and thus damage the organization. It is therefore important that data protection is internalized and lived as a natural part of their work. + Employees are trained and sensitized. - Scope, frequency, and content of the training is determined according to the protection needs of the data - Employees in critical areas (e.g. IT administrators) are instructed and trained specifically for their work (e.g. specific training courses or instructions, short videos, etc.). To what extent are instructions of processing relationships handled? The orderly and defined handling of instructions with regard to the processing by the controller is intended to ensure that the tasks of the processor are fulfilled, and that the processor fulfils the planned and contractually agreed obligations (in particular also to determine a possible exceeding of the contractually agreed framework). + The instructions by the controller regarding the processing of personal data are handled. + Procedures and measures are in place to ensure that: - Received instructions are documented - Instructions can be implemented (e.g. procedures for correcting, deleting, ...) - Data is separated by client and specific order or project

INTERNAL _x000D_ not public Reference to other standards Measures/recommendations Further information r technical reasons. Please do not remove this text. This is intentional invisible text for technical reasons. Please do not remove this text. This is intentional invisible text for technical reasons. Please do not remove this text. This is intentional Usual person responsible for process implementation

INTERNAL _x000D_ not public Possible questions (examples, not binding) Possible evidence (not binding) l invisible text for technical reasons. Please do not remove this text. Assistance: Examples of "normal protection needs" Assistance: Examples of "High protection requirements" Assistance: Examples of "very high protection needs" It is not necessary to list all information values individually, but categories can also be formed (e.g. master data of the employees - responsible office: Human Resources Department).

INTERNAL _x000D_ not public Company: 0 Scope ID: 0 Date: 12/30/1899 Maximum score: 3.00 Result per chapter (without cutback): Result per subchapter (without cutback): Information Security Assessment Results Result with cutback to target maturity level: 1 IS Policies and Organization 2 Human Resources 3 Physical Security 4 Identity and Access Management 5 IT Security/Cyber Security 6 Supplier Relationships 7 Compliance 8 Prototypte Protection (na) 0 1 2 3 4 5 Target maturity level Result 1.1 Information Security Policies 1.2 Organization of Information Security 1.3. Asset Management 1.4. IS Risk Management 1.5 Assessments 1.6 Incident and Crisis Management 2.1 Human Resources 3.1 Physical Security and Business Continuity 4.1 Identity Management 4.2 Access Management 5.1 Cryptography 5.2 Operations Security 5.3 System acquisitions, requirement management and development 6.1 Supplier Relationships 7.1 Compliance 8.1 Prototypte Protection - Physical and Environmental Security (na) 8.2 Prototypte Protection - Organizational Requirements (na) 8.3 Prototypte Protection - Handling of vehicles, components and parts (na) 8.4 Prototypte Protection - Requirements for trial vehicles (na) 8.5 Prototypte Protection - Requirements for events and shootings (na) 0 1 2 3 4 5 Target maturity level Result

INTERNAL _x000D_ not public Maximum score: 3.00 Details: No. Subject Result 1.1.1 To what extent are information security policies available? 3 1.2.1 To what extent is information security managed within the organization? 3 1.2.2 To what extent are information security responsibilities organized? 3 1.2.3 To what extent are information security requirements considered in projects? 3 1.2.4 3 1.3.1 To what extent are information assets identified and recorded? 3 1.3.2 To what extent are information assets classified and managed in terms of their protection needs? 3 1.3.3 3 1.3.4 3 1.4.1 To what extent are information security risks managed? 3 1.5.1 To what extent is compliance with information security ensured in procedures and processes? 3 1.5.2 To what extent is the ISMS reviewed by an independent authority? 3 1.6.1 To what extent are information security relevant events or observations reported? 3 1.6.2 3 1.6.3 3 2.1.1 To what extent is the qualification of employees for sensitive work fields ensured? 3 2.1.2 To what extent is all staff contractually bound to comply with information security policies? 3 2.1.3 3 2.1.4 To what extent is mobile work regulated? 3 3.1.1 To what extent are security zones managed to protect information assets? 3 3.1.2 Superseded by 1.6.3, 5.2.8 and 5.2.9 na na 3.1.3 To what extent is the handling of supporting assets managed? 3 3.1.4 To what extent is the handling of mobile IT devices and mobile data storage devices managed? 3 4.1.1 To what extent is the use of identification means managed? 3 4.1.2 To what extent is the user access to IT services and IT systems secured? 3 4.1.3 To what extent are user accounts and login information securely managed and applied? 3 4.2.1 To what extent are access rights assigned and managed? 3 5.1.1 To what extent is the use of cryptographic procedures managed? 3 5.1.2 To what extent is information protected during transfer? 3 Information Security Assessment Results Result with cutback to target maturity level: Target maturity level To what extent are the responsibilities between external IT service providers and the own organization defined? To what extent is it ensured that only evaluated and approved external IT services are used for processing the organization’s information assets? To what extent is it ensured that only evaluated and approved software is used for processing the organization’s information assets? To what extent are reported security events managed? To what extent is the organization prepared to handle crisis situations? To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?

INTERNAL _x000D_ not public 5.2.1 To what extent are changes managed? 3 5.2.2 To what extent are development and testing environments separated from operational environments? 3 5.2.3 To what extent are IT systems protected against malware? 3 5.2.4 To what extent are event logs recorded and analysed? 3 5.2.5 To what extent are vulnerabilities identified and addressed? 3 5.2.6 To what extent are IT systems and services technically checked (system and service audit)? 3 5.2.7 3 5.2.8 To what extent is continuity planning for IT services in place? 3 5.2.9 To what extent is the backup and recovery of data and IT services guaranteed? 3 5.3.1 To what extent is information security considered in new or further developed IT systems? 3 5.3.2 To what extent are requirements for network services defined? 3 5.3.3 3 5.3.4 To what extent is information protected in shared external IT services? 3 6.1.1 3 6.1.2 To what extent is non-disclosure regarding the exchange of information contractually agreed? 3 7.1.1 To what extent is compliance with regulatory and contractual provisions ensured? 3 7.1.2 3 Method: - comparison of the top 41 security topics 3.00 To what extent is the network of the organization managed? To what extent is the return and secure removal of information assets from external IT services regulated? To what extent is information security ensured among contractors and cooperation partners? To what extent is the protection of personally identifiable data considered when implementing information security? - based on ISO 27001 controls - evaluated according to SPICE ISO 15504

INTERNAL _x000D_ not public Maximum score: 3.00 Details: No. Subject Result 8.1 Physical and Environmental Security 8.1.1 Security concept 3 8.1.2 Perimeter security 3 8.1.3 Stability of outer skin 3 8.1.4 View and sight protection 3 8.1.5 Protection against unauthorized entry and access control 3 8.1.6 Intrusion monitoring 3 8.1.7 Visitor management 3 8.1.8 Client segregation 3 8.2 Organizational Requirements 8.2.1 Non-disclosure obligations 3 8.2.2 Subcontractors 3 8.2.3 Awareness 3 8.2.4 Security classification 3 8.2.5 Access control 3 8.2.6 Film and photo regulations 3 8.2.7 Mobile video and photography devices 3 8.3 Handling of vehicles, components and parts 8.3.1 Transport 3 8.3.2 Parking and storage 3 8.4 Requirements for trial vehicles 8.4.1 Camouflage 3 8.4.2 Test and trial ground 3 8.4.3 Test and trial drives on public roads 3 8.5 Requirements for events and shootings 8.5.1 Presentations and events 3 8.5.2 Film and photo shootings 3 Information Security Assessment Results - Prototype Protection Result with cutback to target maturity level: Target maturity level

INTERNAL _x000D_ not public Control ISA 4.1.3 To what extent are user accounts and login information securely managed and applied? 5.2.1 To what extent are changes managed? 5.2.3 To what extent are IT systems protected against malware? Scope COVERAGE EFFECTIVENESS COVERAGE COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS ID “Collective accounts” Change - error rate Description Objective (Vision) Error-free performance of changes Recipients Information Security; supervisors Information Security Information Security Information Security Information Security Information Security Information Security Local IT, Information Security Local IT, Information Security Frequency (reporting) Threshold levels Number red: > 0, Green = 0 Measurement Frequency (measurement) Interfaces Incident Management User Management AV Management, IT Operations AV Management, IT Operations Components AV console, CMDB AV console, CMDB Information Security Assessment Examples of KPIs 2.1.3 To what extent is staff made aware of and trained with respect to the risks arising from the handling of information? Coverage degree of awareness measures Effectiveness of awareness measures Coverage degree review “User accounts” Coverage degree review “authorizations” Coverage degree Change Management Coverage degree Endpoint Security Effectiveness of updating Endpoint Security Employees with raised awareness represent an important pillar for the information security in a company. Awareness measures should reach all employees, as far as possible. The KPI measures the coverage degree of trainings such as e-learnings, classroom trainings. The contents of awareness measures should consider outcomes of information security incidents. The KPI measures the effectiveness of awareness measures by recording (based on number or cost) security incidents with human errors as a cause. Regular reviews of systems for unnecessary accounts are the prerequisite for a consistent and current user base according to the need-to-know principle. The KPI measures the coverage degree of the measure “Regular user review”. Regular reviews of user accounts for unnecessary authorizations are the prerequisite for a consistent and current authorization base according to the need-to-know principle. The KPI measures the coverage degree of the measure “regular authorization review”. Collective accounts should principally not be used or used only in exceptional cases since an explicit allocation of user activities is impeded. The KPI measures the number of used collective accounts in consideration of approved exceptions. A comprehensive and consistently observed change management process is the basis for secure operation. The KPI measures the coverage degree of changes complying with the policies. A high quality of the change management process leads to lower error rates among the performed changes and contributes to a secure operation. The KPI measures the error rate of changes. A comprehensive Endpoint Security provides a company with an essential protection against malware. The KPI measures the ratio of protected IT systems in consideration of approved exceptions. Current virus signatures are the prerequisite for an effective Endpoint Security. The KPI measures the target state and the actual state of virus definitions on reporting deadline. All employees are trained with respect to information security No information security incidents with human error as a cause All IT systems have valid user accounts only All authorizations comply with current needs All collective accounts are reviewed for their necessity All changes are made in conformance to policies Comprehensive protection of all IT systems threatened by malware All IT systems have up-to-date protection to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (0- 20 low, 20-50 medium, 50+ high) possible characteristic for comparability of business units: in relation to the number of employees, e.g. unit: incidents/100 employees to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%, special case of IT systems relevant to billing: target coverage = 100%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%, special case of IT systems relevant to billing: target coverage = 100%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%, special case of IT systems relevant to billing: target coverage = 100%) to be determined individually (e.g. Green: < 10%, Yellow: 10-30%, Red: > 30%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. target: 100% after max. 30 minutes, Green: > 90%, Yellow: 70-90%, Red: < 70%) Assessment of training management Quotient: number of participants/total number of employees Determining the number of security incidents with human error as a cause Quotient: number of performed reviews/total number of IT systems in scope Quotient: number of performed reviews/total number of users in scope determining the number of collective accounts (adjusted for authorized exceptions) Quotient: number of approved and requested changes (RFC)/total number of performed changes Quotient: number of reversed changes/total number of performed changes Quotient: number of protected IT systems/total number of IT systems (adjusted for authorized exceptions) time comparison average actual rollout state vs. target state to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. monthly) to be determined individually (e.g. annually) HR - Training Department - IKS - Internal Audit Department Data Owner, User Management, Supervisors Data Owner, User Management, Supervisors IT Operations, Change Management IT Operations, Change Management E-learnings, classroom training, training plan, training register Incident Mgt. Tool, Ticket System, ISMS Tool User registry, authorization management tool, IAM platform, CMDB User registry, authorization management tool, IAM platform User registry, authorization management tool, IAM platform Project Management, Change Management Project Management, Change Management

INTERNAL _x000D_ not public 5.2.9 To what extent is the backup and recovery of data and IT services guaranteed? 5.2.5 To what extent are vulnerabilities identified and addressed? 1.6.2 To what extent are reported security events managed? 1.1.1 To what extent are informa COVERAGE COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE Coverage degree of backup Backup effectiveness Effectiveness of patch installation Correct backups Local IT, Information Security Local IT, Information Security Initial version Number red: > 0, Green = 0 Number red: > 1, Green = 1 Backup process, IT Operations Backup process, IT Operations Backup process, IT Operations Backup software, CMDB Backup software, CMDB Backup software, CMDB 1.6.1 To what extent are information security relevant events or observations reported? Coverage degree of restoration tests Coverage degree Patch Management Detection rate of information security incidents Timely processing of information security incidents Creation degree of required policies/documentations A regular and complete backup provides protection against the loss of data, e.g. in case of a system failure or malware infection of IT systems. The KPI measures the degree of backup coverage. Regular restoration tests (e.g. by restoring data or systems) is essential to the availability of business information. The KPI measures the coverage degree of restoration tests. Backup quality must be ensured by correlating controls. Measures are e.g. data restore, system restorations. The KPI measures the number of incorrect data restores. A comprehensive patch management protects the company against malware and exploits. The KPI measures the inclusion of IT systems and applications in the patch management process. The timely installation of patches ensures the security of IT systems and applications and therefore reduces the exploit windows for the company. The KPI measures the recording of the target state and the actual state of patches. Information security incidents have to be detected and timely handled in order to protect the company from damages. The KPI measures the compliance of the incident reporting process between the involved interfaces. Information security incidents have to be adequately prioritized and handled according to their criticality. The KPI measures the appropriate timely handling of information security incidents. Under an ISMS, mandatory/voluntary policies/documentations must be prepared. All relevant data is adequately secured Regular restoration tests for all backed-up IT systems All IT systems are involved in the patch process All IT systems are at current patch level All information security incidents will be detected, reported and handled within the scope of the incident management process All information security incidents will be handled within an appropriate time frame All necessary policies/documentations are present Local IT, Information Security, service owner Local IT, Information Security, service owner Local IT, Information Security, service owner IT, Information Security, Compliance IT, Information Security, Compliance Information Security, Corporate Security, IT Security, HR, Business to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. Green: = 100% (of IT systems to be secured), Yellow: 70-99%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. target: 100% after max. 10 days, Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. according to the category maximum periods for solution: -PRIO 1: Days -PRIO 2: Weeks -PRIO 3: Months unsolved incidents within a period, e.g. Green: < 2%, Yellow: 2-5%, Red: > 5%) to be determined individually (target coverage = 100 %) Quotient: number of IT systems covered by backups/total number of IT systems (adjusted for authorized exceptions) Quotient: number of IT systems with tested restoration from backup/total number of all backed-up IT systems Quotient: number of restorations with errors/total number of all restoration tests Quotient: number of currently patched IT systems/total number of IT systems (adjusted for authorized exceptions) time comparison average actual rollout state vs. target state Quotient: number of information security incidents reported in the incident management/total number of incidents (known to the surveying unit) For each individual criticality level: All unsolved incidents within defined period/all incidents Quotient: number of existing policies/population of necessary policies to be determined individually (e.g. annually) to be determined individually (e.g. monthly) to be determined individually (e.g. annually) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) Patch/Change Management, IT Operations Patch/Change Management, IT Operations IT, CERT, Incident Management, Helpdesk, Service Management IT, CERT, Incident Management, Helpdesk, Service Management Information Security, Corporate Security, IT Security, HR, Business Change Management Console, Software Distribution Platform, CMDB, WSUS Change Management Console, Software Distribution Platform, CMDB, WSUS Incident Management System/Workflow Incident Management System/Workflow Contents derived from the Statement of Applicability (SoA) and documented in accordance with ISO 27001

INTERNAL _x000D_ not public ation security policies available? 3.1.1 To what extent are security zones managed to protect information assets? 5.2.4 To what extent are event COVERAGE COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE COVERAGE EFFECTIVENESS Functioning log activity IT Security, Information Security number of incorrectly written logs IT Operations, IT Security IT Operations, IT Security Logistics, Access Management Overview of projects per PMO Overview of projects per PMO Overview of mobile devices Overview of mobile devices CMDB, Logging server CMDB, Logging server 1.2.3 To what extent are information security requirements taken into account in projects? 3.1.4 To what extent is the handling of mobile IT devices and mobile data storage devices managed? Actuality of required policies/documentations Coverage degree of information security in projects Protective measures - implementation in projects Coverage degree of mobile device security Effectiveness of implementation of mobile device security measures Implementation degree of zone concept Implementation of protective measures for zone concept Coverage degree review “Access authorizations” Coverage degree of event logs on security-critical IT systems For the ISMS, the prepared policies/documentations must be reviewed for their actuality. Information security topics shall be addressed during projects. Projects subject to information security requirements A comprehensive and consistent protection of all relevant mobile devices is the basis for their secure operation. The KPI measures the coverage degree of the defined protective measures. A strong implementation of protective measures regarding relevant mobile devices reduces vulnerabilities. Properties must be adequately protected; this can be achieved by implementation of a zone concept. The zone concept should be implemented comprehensively. Zones must be adequately protected according to criticality. Regular verifications of access rights with respect to their necessity are an absolute prerequisite for a secure delivery and shipping zone. Event logging enables traceability of activities in a process or process step/on an IT system/in an application. This functionality helps to solve system failures/abnormalities. Logs should be activated in security- critical IT systems. Results of logging activities must allow analysis. Reliable end-to- end recording of the activities to be monitored is essential for traceability, if required. All necessary policies/documentations are reviewed for actuality/content Information security requirements are considered in all projects Information security requirements are implemented in all projects All relevant mobile devices are subject to protective measures All relevant mobile devices are subject to up-to-date protection Zones are defined for all properties Security zones are protected according to internal specifications (see e.g. References “Security zones”) All employees working in the delivery and shipping area are subject to regular review of access rights All relevant IT systems and applications are integrated into event logging Completeness and correctness of logs Information Security, Corporate Security, IT Security, HR, Business Information Security, Corporate Security, IT Security Information Security, Corporate Security, IT Security IT Security, Information Security, Corporate Security Information Security, Corporate Security Information Security, Corporate Security Corporate Security, Logistics, authorities Local IT, Information Security, Compliance Local IT, Information Security, Compliance to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (target coverage = 100 %) to be determined individually (target coverage = 100 %) to be determined individually (target coverage = 100 %) to be determined individually (target coverage = 100 %) to be determined individually (target coverage = 100 %) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (target coverage = 100 %) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%, special case of IT systems relevant to billing: target coverage = 100%) Number of incorrect logs Red: > 0, Green = 0 Quotient: number of policies reviewed according to cycle/population of policies to be reviewed Quotient: number of projects considering security/total number of relevant projects Quotient: number of projects considering security aspects/total number of relevant projects Quotient: number of protected mobile devices/total number of mobile devices Quotient: number of mobile devices protected in a timely manner/total number of mobile devices Quotient: number of properties with zone concept/population of properties Quotient: number of adequately secured zones/population of all zones Quotient: number of employees working in the delivery and shipping area who are subject to regular access rights reviews/population of employees working in the delivery and shipping area Quotient: number of logged security-critical IT systems/total number of security-critical IT systems to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. annually) to be determined individually (e.g. quarterly) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. quarterly) Information Security, Corporate Security, IT Security, HR, Business Project customer, Project Management Office (PMO) Project customer, Project Management Office (PMO) Plant security, local security functions, specialized departments Plant security, local security functions, specialized departments IT, IT System Owner, Data Owner, Risk Owner IT, System Owner, Data Owner, Risk Owner Contents derived from the Statement of Applicability (SoA) and documented in accordance with ISO 27001 Property plans, zone concept, information classification Property plans, zone concept, information classification Staff registry (internal/external), access control system

INTERNAL _x000D_ not public t logs recorded and analyzed? 5.3.2 To what extent are requirements for network services defined? 5.3.1 To what extent is information security considered in new or further developed IT systems? COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS COVERAGE EFFECTIVENESS Functioning log activity Coverage degree system audits Effectiveness of observing SLAs Local IT, Information Security Local IT, Information Security Local IT, Information Security Local IT, Information Security CMDB, Logging server, IAM CMDB, Logging server, IAM CMDB CMDB, Audit system CMDB CMDB Acquisition system 5.2.6 To what extent are IT systems and services technically checked (system and service audit)? 6.1.2 To what extent is non- disclosure regarding the exchange of information contractually agreed? Coverage degree of admin logs on security-critical IT systems Effectiveness of system audit implementation Coverage degree review service level agreements (SLA) Coverage degree non-disclosure agreements Effectiveness of risk handling in IT system acquisition processes Coverage degree of risk assessment in software development process Effectiveness of risk handling in development process Admin logging allows traceability of administrator activities in a process or process step/on an IT system/in an application. This functionality helps to solve abnormalities. Admin logs should be activated in security-critical IT systems and protected against (admin) manipulations. Results of admin logging activities must allow analysis. Reliable and manipulation-protected end-to- end recording of the admin activities to be monitored is essential for traceability, if required. IT systems processing or storing information of high or very high protection needs must be subjected to audits at regular intervals. Measures resulting from those audits must be implemented in time in order to eliminate any detected vulnerabilities. Regular verifications of the SLAs for network services ensure consideration of current security requirements at all times. The agreed measures resulting from the SLAs must be implemented. The protection of information confidentiality must be subject to contractual agreement where at least confidential information is exchanged with external partners. Risks identified during the acquisition process are treated in a timely and effective manner. Information security risks associated with the applications to be developed must be identified as early as possible in the process of software development. Risks identified in the process of software development are treated in a timely and effective manner. All relevant IT systems and applications are integrated into admin logging Completeness and integrity of admin logs All relevant IT systems are subjected to audits at regular intervals All measures are implemented in time All SLAs include the current security requirements All requirements resulting from the SLAs are implemented Non-disclosure agreements have been entered with all external partners Security risks identified in acquisition are handled in an effective manner Security risks are taken into account in the software development process Security risks are addressed in the development process in an effective manner Local IT, Information Security, Compliance Local IT, Information Security, Compliance Acquisition, Information Security, specialized department Information Security, Local IT, Procurement Information Security, Local IT, Risk Management Information Security, Local IT, Risk Management to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%, special case of IT systems relevant to billing: target coverage = 100%) Number of incorrect admin logs Red: > 0, Green = 0 to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) Quotient: number of logged security-critical IT systems/total number of security-critical IT systems number of incorrectly written admin logs Quotient: number of audited IT systems/total number of security- critical IT systems Quotient: number of measures implemented in time/number of measures still to be implemented Quotient: number of verified SLAs/total number of SLAs Quotient: number of measures implemented/number of measures agreed Quotient: number of orders with concluded non-disclosure agreement/total number of relevant orders Quotient: number of treated risks/population of risks identified in the acquisition process Quotient: number of software development projects that underwent risk assessment/population of relevant development projects Quotient: number of treated risks/population of risks identified in the development process to be determined individually (e.g. annually) to be determined individually (e.g. quarterly) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. monthly) to be determined individually (e.g. quarterly) to be determined individually (e.g. quarterly) to be determined individually (e.g. quarterly) IT, System Owner, Data Owner, Risk Owner, User Management IT, System Owner, Data Owner, User Management Audit Management, IT Operations, System Owner Audit Management, IT Operations, System Owner IT Operations, Information Security IT Operations, Information Security Acquisition, Information Security, specialized department Procurement, specialized departments (requisitioner), Local IT Procurement, specialized departments (requisitioner), Local IT Procurement, specialized departments (requisitioner), Local IT Acquisition register, ordering system Development system, development project data base Development system, development project data base

INTERNAL _x000D_ not public COVERAGE EFFECTIVENESS 1.5.1 To what extent is compliance with information security ensured in procedures and processes? Coverage degree of activities to eliminate vulnerabilities determined during audits Timely elimination of vulnerabilities determined during audits Vulnerabilities identified in the course of information security audits (internal and external) must be eliminated in a consequent and traceable manner. Findings must not remain unhandled. Vulnerabilities identified in the course of information security audits (internal and external) are eliminated within the deadlines agreed (with the audited departments). All vulnerabilities identified in the course of audits are traced and assigned to activities Vulnerabilities identified in the course of audits are eliminated within the defined time and in an effective manner Information Security, Corporate Security, Local IT, Internal Audit Information Security, Corporate Security, Local IT, Internal Audit to be determined individually (e.g. annually) to be determined individually (e.g. annually) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) to be determined individually (e.g. Green: > 90%, Yellow: 70-90%, Red: < 70%) Quotient: number of findings subject to subsequent activities/population of identified findings Quotient: number of activities for eliminating vulnerabilities within the defined period for implementation/population of all specified activities to be determined individually (e.g. quarterly) to be determined individually (e.g. quarterly) Internal Auditors, Information Security, Local IT, specialized departments (Auditees) Internal Auditors, Information Security, Local IT, specialized departments (Auditees) Audit data base, follow-up data base Audit data base, follow-up data base

INTERNAL # _x000D_ # not public

INTERNAL # _x000D_ # not public You are free to: Under the following terms: Creative Commons Attribution-NoDerivatives 4.0 International Public License Information Security Assessment License © 2023 ENX Association, an Association according to the French Law of 1901, registered under No. w923004198 at the Sous- préfecture of Boulogne-Billancourt, France. This work of ENX's Working Group ISA was provided to the VDA in the present version by the ENX Association for published by the VDA as the VDA ISA. It is made to all interested parties free of charge under the following licensing terms. The release in the VDA is done by the VDA's Working Group Information Security and Economic Protection. Publication takes place with the consent of the rights holder. The VDA is responsible for the publication of the VDA ISA. The Tab "Data Protection" is provided, owned and copyrighted by VERBAND DER AUTOMOBILINDUSTRIE e. V. (VDA, German Association of the Automotive Industry); Behrenstr. 35; 10117 Berlin This work has been licensed under Creative Commons Attribution - No Derivative Works 4.0 International Public License. In addition, You are granted the right to distribute derivatives under certain terms as detailed in section 9 which are not part of the Creative Commons license. The complete and valid text of the license is to be found in line 17ff. · Share — copy and redistribute the material in any medium or format · for any purpose, even commercially. · The licensor cannot revoke these freedoms as long as you follow the license terms. · Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. · Restricted derivatives — If you change or otherwise build directly upon the material, You may only distribute the modified material if it is clearly marked as a derivative not approved by the licensor and if all logos and/or trademarks of the licensor have been removed. · No additional restrictions — You may not apply any additional legal terms or technological measures that legally restrict others from doing anything the license permits. By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-NoDerivatives 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. Section 1 – Definitions.

INTERNAL # _x000D_ # not public a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. b. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labelled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. c. Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations within the meaning of Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. d. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. e. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. f. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. g. Licensor means the individual(s) or entity(ies) granting rights under this Public License. h. Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. i. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. j. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. Section 2 – Scope. a. License grant. 1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non- sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: A. reproduce and Share the Licensed Material, in whole or in part; and B. produce and reproduce, but not Share, Adapted Material. 2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 3. Term. The term of this Public License is specified in Section 6(a). 4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 5. Downstream recipients. A. Offer from the Licensor – Licensed Material. Each recipient of the Licensed Material will automatically receive an offer from the Licensor to exercise the Licensed Rights under the terms of this Public License. B. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). b. Other rights.

INTERNAL # _x000D_ # not public Your exercise of the Licensed Rights is expressly made subject to the following conditions. For the avoidance of doubt, You do not have permission under this Public License to Share Adapted Material. Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 2. Patent and trademark rights are not licensed under this Public License. 3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. Section 3 – License Conditions. a. Attribution. 1. If You Share the Licensed Material, You must: A. retain the following if it is supplied by the Licensor with the Licensed Material: i. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); ii. a copyright notice; iii. a notice that refers to this Public License; iv. a notice that refers to the disclaimer of warranties; v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable; B. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and C. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. Section 4 – Sui Generis Database Rights. a. for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database, provided You do not Share Adapted Material; b. if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and c. You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. Section 5 – Disclaimer of Warranties and Limitation of Liability. a. Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. b. To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. c. The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. Section 6 – Term and Termination.

INTERNAL # _x000D_ # not public 3. any logos and/or trademarks of the Licensor have been removed. a. This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. b. Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 2. upon express reinstatement by the Licensor. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. c. For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. d. Sections 1, 5, 6, 7, and 8 survive termination of this Public License. Section 7 – Other Terms and Conditions. a. The Licensor must not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. b. Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. Section 8 – Interpretation. a. For the avoidance of doubt, this Public License does not, and must not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. b. To the extent possible, if any provision of this Public License is deemed unenforceable, it must be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it must be severed from this Public License without affecting the enforceability of the remaining terms and conditions. c. No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. d. Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. Section 9 – Distribution of Derivatives (additional rights granted and not part of the Creative Commons license) a. In addition to those rights granted under Sections 2(a)(3), the Licensor grants You the right to distribute modified material provided: 1. this material is clearly marked as a modified version not approved by the Licensor; and 2. the license terms have not been modified, and

INTERNAL # _x000D_ # not public

INTERNAL # _x000D_ # not public 1.0 1.1 1.2 1.3 2.0 2.0.1 2.1.0 2.1.1 2.1.2 2.1.3 2.1.4 3.0.2

INTERNAL # _x000D_ # not public 4.0.0 4.0.1 4.0.2 4.0.3 4.1.0 5.0.0 5.0.2 5.0.3 5.0.4

INTERNAL # _x000D_ # not public 5.1 6.0.0

INTERNAL # _x000D_ # not public First release (Initial version) Changing open questions to solved questions More precise level descriptions Incorporating examples from practice Spelling errors corrected 8.2 and 10.1 reference adjustment 10.2 change from production environment to productive environment 10.5 change from IDS/IPS to HIDS/HIPS 11.2 changes to the translation 11.3 and 11.4 restructuring of controls 11.4 add “IT” to systems 9.4 revision Maturity Level 2 Revision due to the new edition of ISO 27002:2013 Adjustment of the maturity levels Fix for error in calculation and spider web diagram Revision of the maturity levels, corrections of some controls Release version 2.1 Print area adjusted Spider web diagram shows results without cutback Control 13.5 revised Control 7.1 Maturity Level 1 revised Controls 9.4 and 9.5 reference revised Maturity Control changed from 12.4 to 4 Maturity Control changed from 16.3 to 3 Addition of KPIs Spell checking in Maturity Level 3 Revision for TISAX Module Connection of third parties included Module Prototype Protection (25) included, derived from the Whitepaper of 06/10/2016 “Questions” renamed “ISMS” Including KPIs in controls with Maturity Levels “4” Removal of KPI from Control 18.2 Information Security Assessment Change history Module Data Protection (24) included, reference to 18.2 deleted, maturity levels removed from the module, references from generated instead, reference included (ISMS, 18.2) showing that the data protection module will be used only in commissio processing according to §11 BDSG, introduction of questions “fulfilled [yes/no]” Upon agreement with the data protection working group, Maturity Level “4” has been removed from Control 18.2 and set to Control 10.21 Cryptography has been raised from “2” to “3”. Introduction of the protection needs “normal”, “high” and “very high” to represent the protection goals “integrity”, “availability “confidentiality”; mapping from “internal” to “normal”, from “confidential” to “high” and from “secret/strictly confidential” to “ve Assignment of requirements within Maturity Level “1” in the different controls.

INTERNAL # _x000D_ # not public Introduction of references to several information security topics Readability enhancement for information security controls Categorizing the requirements of the individual controls into ‘must’, ‘should’ and ‘may’ in order to clarify the degree of obliga Introduction of tab “Explanations” Introduction of tab “Maturity levels” Extension of tab “KPIs” Extension of tab “Information Security” with additional controls to clarify requirements for usage of cloud services KPI link at Control 12.2 has been deleted Correction of the link of Control 14.4 on the results page, Level 3 adaptation: Established in tab “Maturity levels” Tab Results: The results will only be indicated for controls that have been subject to processing. 8.4, 13.3 correction in description of objective 9.1 addition of control and objective description 10.1, 11.1, 12.5, 12.6, 12.9 adaptation of requirements 18.2 and Data Protection (24) adaptation to DSGVO References: 'secret' changed to 'strictly confidential' and classification levels supplemented to protection classes Prototype Protection (25) revised Topical restructuring of VDA ISA in the module Information Security New table format in all modules for improved overview and easier export options Deletion of the module Connection to third parties and transfer of its requirements to the module Information Security Integration of Notes and Explanations into the module Information Security, consequently deletion of the tabs Notes and Ex Revision of ally questions, objectives and requirements Harmonization of the target maturity level across all controls to a target value of 3 Integration of Control 1.2 into the new Control 1.4.1 Integration of Control 1.3 into the new Control 1.2.1 Integration of Control 9.4 into the new Control 4.1.3 Integration of Control 12.4 into the new Controls 3.1.2 and 3.1.4 New Control “Teleworking” (2.1.4) New Control “Qualification of employees” (2.1.1) New Control “Handling of identification means” (4.1.1) Change of the License to Creative Commons BY ND 4.0 + special terms and conditions for the distribution of derivatives Correction of overall maturity level calculation Input check of “Maturity level” column Correction of change history Renumbering in “Data Protection” module Correction of diagram designations in “Results” module Supplementation of print areas Correction of orthography and expression Adaptation of Chapter 24 to DSGVO and minor modifications to those controls designated with 4.1.0 Integration of Controls 1.2 into the new Control 1.2.4 Integration of Controls 1.2 into the new Control 1.2.1 Integration of Controls 1.2 into the new Control 1.2.2 Integration of Controls 1.2 into the new Control 1.2.1 Integration of Controls 1.2 into the new Control 1.2.4 Integration of Controls 1.2 into the new Control 1.2.7 Integration of Controls 14.2 and 14.3 into the new Control 5.3.1 Integration of Controls 1.2 into the new Control 1.2.1 Integration of Controls 1.2 into the new Control 1.2.1 Deletion of Control 12.9

INTERNAL # _x000D_ # not public Correction of orthography and expression, linguistic clarification, elimination of ambiguities Restructuring of "Welcome” tab, Definitions of tabs moved to “Definitions” Supplementation of protection goals with respect to requirements for high and very high protection needs in the “Information Deletion of column “Addressed protection goals” in “Information Security” and “Prototype Protection” tabs Content deleted from column “Usual person responsible for process implementation” in the “Information Security” and “Prot Additional requirements to improve availabability New Control 1.3.4 ("Software approval") Renamed control section 1.6 ("Incident and Crisis Management") Revised Control 1.6.1 ("Reporting of security events") New Control 1.6.2 ("Managing of security events") New Control 1.6.3 ("Handling crisis situations") (supersedes 3.1.2) Supersesed Control 3.1.2 New Control 5.2.8 ("IT-service continuity planning") New Control 5.2.9 ("Backup and recovery") Removal of ISA 4 compatibility Update module “Data Protection” (revised requirements provided by VDA Working Group "Datenschutz") References to ISA/IEC 62443-2, ISO 27001:2022 and NIST CSF References to implementation guide (BSI IT-Grundschutz, NIST SP800-53) Additional scope of IT-systems on Operational Technology (OT) Added further information, examples, typical auditor questions, and typical evidence to help and support auditees for many Correction of references ISO 27001

INTERNAL # _x000D_ # not public n” tabs mns W to AB)

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public 2a 2b 2c 4 5 Control Column Previous wording Information Security 1.1.1 Should Information Security 1.2.2 should (expand the requirement) Tab (e.g. information security) Change suggestion / new wording + Further relevant information security policies are prepared. + Other relevant security policies are prepared - Other relevant security roles are considered

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.3.4 all New control: To what extent is software used for processing the organization’s assets managed? Objective: Information processing is mostly done through the use of specific software. Security issues in software will easily become a risk for the information processed. Accordingly, software must be appropriatly managed. Must: + Software is approved before installation or use. The following aspects are considered: - Limited approval for specific use-cases or roles - Conformance to the information security requirements - Software use rights and licensing - Source / reputation of the software + Software approval also applies to special purpose software such as maintenance tools Should: + The types of software such as firmware, operating systems, applications, libraries, device drivers to be managed are determined. + Repositories of managed software exist + The software repositories are protected against unauthorized manipulation + Approval of software is regularly reviewed + Software versions and patch levels are known High: Very High: + Additional requirements for software use

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.4.1 should Information Security 2.1.3 Should Information Security 2.1.4 Must none + A procedure is in place defining how to identify, assess and address information security risks within the organization. + Criteria for the assessment and handling of information security risks exist. + Measures for handling information security risks and the persons responsible for these are specified and documented: - A plan of measures or an overview of their state of implementation exists. + In case of changes to the environment (e.g. organizational structure, location, changes to regulations), reassessment is carried out in a timely manner. + A procedure is in place defining how to identify, assess and address security risks within the organization. + Criteria for the assessment and handling of security risks exist. + Measures for handling security risks and the persons responsible for these are specified and documented: - A plan of measures or an overview of their state of implementation is followed . + In case of changes to the environment (e.g. organizational structure, location, changes to regulations), reassessment is carried out in a timely manner. + Target groups for training and awareness measures (e.g. new employees, administrators, employees having access to customer networks) are identified and taken into account in a training concept. + Target groups for training and awareness measures ( i.e., people working in specific risk environments such as administrators, employees having access to customer networks, personnel in areas of manufacturing ) are identified and taken into account in a training concept. '+ Remote access connections are verified to possess adequate security features (encryption, granting and termination of access) and capabilities

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 4.1.1 Objective Information Security 4.1.2 Information Security 4.2.1 Must none Information Security 4.2.1 Must Information Security 5.2.6 Should To check the authorization for both physical access and electronic access, means of identification such as keys, visual IDs or cryptographic tokens are often used. The security features are only reliable if the use of such identification means is handled adequately. To check the authorization for both physical access and electronic access, means of identification such as keys, visual IDs, other physical access devices as well as cryptographic tokens are often used. The security features are only reliable if the use of such identification means is handled adequately. additional req for high protection needed + Depending on the risk assessment, authentication procedure and access control have been enhanced by supplementary measures (e.g. permanent access monitoring with respect to irregularities or use of strong authentication, automatic logout or disabling in case of inactivity) '+ Depending on the risk assessment, authentication procedure and access control have been enhanced by supplementary measures (e.g. continuous access monitoring with respect to irregularities or use of strong authentication, automatic logout, disabling in case of inactivity, or brute force prevention ) - Access rights are revoked once no longer needed (as additional 3rd point under the first +) - Procedure for application, verification and - Procedure for application, verification, approval + System audits are planned taking into account any security risks they might cause (e.g. disturbances). + System audits are carried out by trained experts. + Suitable tools (e.g. vulnerability scanners) are available for system audits. + Within a reasonable period following completion of the audit, a report is prepared. + System audits are planned taking into account any security risks they might cause (e.g. disturbances). + Regular system or service audits are performed - carried out by qualified personnel - suitable tools (e.g. vulnerability scanners) are used for system and service audits (if applicable) - performed from the internet and the internal network

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 5.2.6 High none Information Security 5.2.6 very high none + Critical IT services and systems relevant to them are regularly scanned for vulnerabilities. (A ) For critical IT systems or services, additional system audit requirements have been identified and are fulfilled (e.g., service specific tests and tools and/or human penetration tests, risk-based time intervals) (A) + IT systems and services are regularly scanned for vulnerabilities. (A) - Suitable protective measures must be implemented for systems and services that may not be scanned.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 5.2.7 should Information Security 5.2.7 High + Procedures for the management and control of networks are defined. + For network segmentation, the following aspects are considered: - Limitations for connecting IT systems to the network, - Use of security technologies, - The increased risk due to network services accessible via the internet, - Technology-specific separation options when using external IT services, - Adequate separation between own networks and customer networks while considering customer requirements. + Procedures for the management and control of networks are defined. + For a risk-based network segmentation, the following aspects are considered: - Limitations for connecting IT systems to the network, - Use of security technologies, - performance, trust, availability, and safety considerations - Limitation of impact in case of compromised IT systems - Detection of potential attacks and lateral movement of attackers - Separation of networks with different operational purpose (e.g. test and development networks, office network, manufacturing networks) - The increased risk due to network services accessible via the internet, - Technology-specific separation options when using external IT services, - Adequate separation between own networks and customer networks while considering customer requirements - Detection and prevention of data loss/leakage + Extended requirements for the management and control of networks are determined and implemented. The following aspects are considered: (C, I, A) - Authentication of IT systems on the network, - Access to the management interfaces of IT systems is restricted. + Extended requirements for the management and control of networks are determined and implemented. The following aspects are considered: (C, I, A) - Authentication of IT systems on the network, - Access to the management interfaces of IT systems is restricted. - specific risks (e.g. wireless and remote access)

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security New: 5.2.8 all none New control: 5.2.8: To what extent is continuity planning for IT- Services in place? Objective: Continuity (including contingency) planning for IT- Services is part of an overall program for achieving continuity of operations for organizational mission and business critical functions. Actions addressed in continuity plans include orderly system degradation, system shutdown, fallback to a manual mode, alternate information flows, and operating in modes reserved for when a security incident occurs. Must: + Critical IT-services are identified, and business impact is considered. + Requirements and responsibilities for continuity and recovery of those IT-Services are known to relevant stakeholders and fulfilled. Should: + Critical IT-Systems are identified - the relevant systems are classified to have the appropriate protection need - adequate security measures are implemented + Continuity planning includes at least the following scenarios affecting critical IT-systems: - (Distributed) Denial of Service attacks - Successful ransomware attacks and other sabotage activities - System failure - Natural disaster + Continuity planning considers the following cases - Alternative communication strategies, in case primary communication means are not available - Alternative storage strategies, in case primary storage means are not available - Alternative power and network + Continuity planning is regularly reviewed and updated

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security New: 5.2.9 all none New control: 5.2.9: To what extent is the backup and recovery of data and IT services guaranteed? Data and IT services can become unavailable through events such as hardware failures, software defects, operator errors or attacks. Backup and recovery enables organizations to recover from relevant situations and limit potential harm to the organization to a reasonable amount. Must + Backup concepts exist for relevant IT systems. The following aspects are considered: - Appropriate protective measures to ensure confidentiality, integrity and availability for data backups. + Recovery concepts exist for relevant IT services. Should + A backup and recovery concept exists for each relevant IT service. - Dependencies between IT services and the sequence for recovery are taken into account High + Backup and recovery concepts are methodically reviewed at regular intervals. (A) + General restore capability is considered and tested (e.g., sample testing, test systems) (A) (I) + Backup and recovery concepts consider the following aspects: (A) - Recovery Point Objective (RPO). - Recovery Time Objective (RTO). - Required resources for recovery (considering capacity and performance incl. personnel and hardware). - Avoidance of overload scenarios during recovery. - Appropriate spatial redundancy (e.g., separate room, separate fire section, separate datacenter, separate site)

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 5.3.1 should Information Security 5.3.1 very high none Information Security 6.1.1 should '+ Requirement specifications are prepared under consideration of the information security requirements. + Requirement specifications are prepared. The following aspects are considered: - The information security requirements. - Vendor recommendations and best practices for secure configuration and implementation - Best practices and security guidelines - Fail safe (designed to return to a safe condition in the event of a failure or malfunction) + The security of non-standard software applications or significantly adapted software is tested (e.g. penetration testing) - during commissioning - in case of significant changes - or at regular intervals + Contractors and cooperation partners are contractually obliged to also pass on any requirements regarding an appropriate level of information security also to their subcontractors. + Contractors and cooperation partners are contractually obliged to pass on any requirements regarding an appropriate level of information security to their subcontractors.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security definitions all none Information Security definitions all none Information Security definitions all none Definitions Glossary -na- New definition for "Critical IT-Service": Critical IT-Services are essential to the business or organization. When such a service fails or is interrupted, business operations are severely impacted. New definition for "Critical IT-Systems": Critical IT-Systems are essential to operate Critical IT-Services. New definition for "IAM Technology": Identity and access management (IAM or IdAM) Technology, is a framework of technologies to ensure that the right users (that are part of the ecosystem connected to or within an enterprise) have the appropriate access to technology resources. Identity and access management systems not only identify, authenticate, and control access for individuals who will be utilizing IT resources but also the hardware and applications employees need to access. Glossary: IT Systems - Examples (Computer, server, cloud, communication systems, video conference systems, smartphones, tablets) Glossary: IT Systems - Examples (Computer, server, cloud, communication systems, video conference systems, smartphones, tablets, Industrial automation and control system )

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security -na- Discussion 4.2.1 - Application the minimum (“need-to-know”) principle. - Application the minimum (“need-to-know” /"least privilege-only") principle.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security Information Security all none Discussion SW Services interactive login rights 4.1.2 high protection needs + A basic user account with minimum access rights and functionalities is existent and used. + Default accounts and passwords pre-configured by manufacturers are disabled (e.g. by blocking or changing of password). + User accounts are created or authorized by the responsible body. + Creating user accounts is subject to an approval process (four-eyes principle). + User accounts of service providers are disabled upon completion of their task. + Deadlines for disabling and deleting user accounts are defined. + The use of default passwords is technically prevented. + Where strong authentication is applied, the use of the medium (e.g. ownership factor) is secure. + User accounts are reviewed at regular intervals. This also includes user accounts in customers' IT systems. + A basic user account with minimum access rights and functionalities is existent and used. + Default accounts and passwords pre-configured by manufacturers are disabled (e.g. by blocking or changing of password). + User accounts are created or authorized by the responsible body. + Creating user accounts is subject to an approval process (four-eyes principle). + User accounts of service providers are disabled upon completion of their task. + Deadlines for disabling and deleting user accounts are defined. + The use of default passwords is technically prevented. + Where strong authentication is applied, the use of the medium (e.g. ownership factor) is secure. + User accounts are reviewed at regular intervals. This also includes user accounts in customers' IT systems. + interactive login for service accounts (technical accounts) is technically prevented. New column "Reference to implementation guidance" Content from separate change list as proposed by the German Federal Bureau for Information Security (BSI) + NIST SP800-53 revision 5 mapping

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 3.1.2 all Information Security 3 Section Headline Physical Security Information Security 1.6 Section Headline Incident Management Remove entire control (replaced by 1.6.3 and 5.2.8 and 5.2.9) Physical Security and Business Continuity Incident and Crisis Management

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.6.1 entire control Control: To what extent are information security events processed? Objective: Organized processing of information security events aims at limiting potential damage and preventing recurrence. Must: '+ A definition of information security events/vulnerabilities exists. + A procedure for reporting and recording information security events/vulnerabilities is defined and implemented. + The following aspects are considered: - Reaction to information security events/vulnerabilities - Report form and channel - Processing body - Feedback procedure - Indications regarding technical and organizational measures (e.g. disciplinary action). + Procedures for ensuring traceability in case of information security events/vulnerabilities are established and documented. + Information security events/vulnerabilities are assessed and documented in order to ensure traceability. + An adequate reaction to information security events/vulnerabilities is given. + A strategy for an adequate reaction to events of information security violations: - This includes escalation procedures, remedial actions and communication to relevant internal and external bodies as well as a procedure for deciding whether a cybercriminal attack will be prosecuted. Should: '+ Information security events/vulnerabilities (problem management) are analyzed. + Measures to prevent further occurrence of similar Control: To what extent are information security relevant events reported? Objective : Potential security events or observations are detected by anyone. It is vital that anyone can and knows when and how to report anything that one has observed and that has potential security implications (observations) or events so that the experts can decide if and how it needs to be handled. Must: + A definition for a reportable security event or observation exists and is known by employees and relevant stakeholders. The following aspects are considered: - Events and observations related to personnel (e.g., misconduct / misbehavior) - Events and observations related to physical security (e.g., intrusion, theft, unauthorized access to security zones, vulnerabilities in the security zones) - Events and observations related to IT and cyber security (e.g., vulnerable it-systems, detected successful or unsuccessful attacks) - Events and observations related to suppliers and other business partners (e.g., any incidents that can have negative effect on the security of the own organization) + Adequate mechanisms based on perceived risks to report security events is defined, implemented, and known to all relevant potential reporters + Adequate channels for communication with event reporters exist. Should + A single point of contact (SPOC) for event reporting exists. + Different reporting channels according to perceived severity exist (i.e., real time communication for significant events / emergencies in addition to asynchronous mechanisms such as tickets or email) are available.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.6.2 all new control Control: To what extents are reported security events managed? Objective Once security events are reported, it is vital that the handling of the events is managed. This means to ensure that the type and criticality of the reported event as well as the persons responsible are quickly identified to ensure that time-critical aspects can be handled in time. Once identification is done, ensuring that the responsible persons become aware and deal with the event within a reasonable time frame is necessary. Furthermore, if the event affects multiple different persons, or management also include coordinating communication is a important part of event management. Finally, if there are external (contractual or regulatory) reporting requirements, its important to ensure that these are also fulfilled in a professional way. Must: + Reported events are processed without undue delay. + An adequate reaction to reported security events is ensured. + Lessons learned are incorporated into continuous improvement. Should: + During processing, reported events are categorized (e.g. by responsibility into personnel, physical and cyber), qualified (e.g. not security relevant, observation, suggested security improvement, security vulnerability, security incident) and prioritized (e.g. low, moderate, severe, critical). + Responsibilities for handling of events based on their category are defined and assigned. The following aspects are considered: - Coordination of incidents and vulnerabilities across multiple categories - Qualification and resources - Contact mechanisms based on type and priority (e.g., non-time-critical communication, time-critical

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.6.3 all new control Control: To what extents is the organization prepared to handle crisis situations? Objective A crisis situation occurs If exceptional situations (e.g. natural disasters, physical attacks, pandemics, exceptional social situations, cyber-attacks causing major infrastructure failures) are severly disrupting key business operations. In such cases, the main priority of the organization is to handle the situation as gracefully as possible and recover as quickly as possible. To achieve that and since time is of the essence, switching to a crisis management mode executing pre-planned procedures having specific distribution of responsibilities and structures enables an organization to deal with such a situation is the usual approach. Must: + An appropriate planning to react to and recover from crisis situations exists. - The required resources are available. + Responsibilities and authority for crisis management within the organization are defined, documented and assigned. + The responsible employees are defined and qualified for their task. Should: + Methods to detect crisis situations are established. - General indications for the existence or imminence of a crisis situation and specific predictable crisis situations are identified + A procedure to invoke and/or escalate crisis management is in place. + Strategic goals and their priority in crisis situations are defined and known to relevant personnel. The following aspects are considered: - Ethical priorities (e.g., protection of life and health) - Core business processes (e.g., processes that ensure the survival of the organization) - Appropriate information security

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Definitions - all Information Security all ISO 27001 27001 + ISA/IEC 62443 Controls Information Security all ISO 27001:2013 ISO 27001:2022 Information Security 1.1.1 - Information Security 1.2.1 - Information Security 1.2.2 - Original Equipment Manufacturer (OEM): Within the context of VDA ISA, this refers to an automobile manufacturer. Original Equipment Manufacturer (OEM): The owner of the IP controlling the exact design and specification of the product in question. Reference to other standard P Reference to other standard P New column "Additional Requirements for Simplified Group Assessments + Policies are published and implemented in the entire scope. New column "Additional Requirements for Simplified Group Assessments + The management system is approved by an entity that has the necessary authority for the entire scope (i.e., all locations within the scope). New column "Additional Requirements for Simplified Group Assessments + A named person with overall responsibility for the management system exists and is available.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 1.5.1 - Information Security 1.6.2 - Definitions Information Asset all Information Security 4.1.2 Control Question Information Security 4.2.1 Objective Information Security 5.3.4 Should New column "Additional Requirements for Simplified Group Assessments + Internal controls are implemented for all entities within the assessment scope. - The implementation of all applicable security requirements and control objectives are included. + Suitably qualified and appropriate information security audit responsibilities and resources are defined. + A detailed internal audit plan and schedule is defined and followed. The following aspects are considered: - The entire scope of the assessment is covered - Internal audits are conducted regularly - Results of internal audits are tracked within the ISMS structures New column "Additional Requirements for Simplified Group Assessments + Standard mechanisms to report and track relevant security events are established. Information of essential value to the organization. Information of relevant value to the organization. To what extent is the user access to network services, IT systems and IT applications secured? To what extent is the user access to IT services and IT systems secured? The management of access rights ensures that only authorized users have access to information and IT applications. For this purpose, access rights are assigned to user accounts. The management of access rights ensures that only authorized users have access to information and IT services . For this purpose, access rights are assigned to user accounts. + The provider’s segregation concept is documented and adapted to any changes. The following aspects are considered: - Separation of data, functions, applications, operating system, storage system and network, - Risk assessment for the operation of external software within the shared environment. + The provider’s segregation concept is documented and adapted to any changes. The following aspects are considered: - Separation of data, functions, customer-specific software , operating system, storage system and network, - Risk assessment for the operation of external software within the shared environment.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 5.1.1 Must Information Security 5.2.3 ü + All cryptographic procedures used (e.g. encryption, signature, and hash algorithms, protocols, applications ) provide the security required by the respective application field according to the state of the art. + The legal parameters for the use of cryptography are taken into account. + All cryptographic procedures used (e.g. encryption, signature, and hash algorithms, protocols) provide the security required by the respective application field according to the state of the art. + The legal parameters for the use of cryptography are taken into account. + Unnecessary network services are disabled. + Access to network services is restricted to necessary access by means of suitable protective measures (see examples). + Malware protection software is installed and updated automatically at regular intervals (e.g. virus scanner). + Received files and programs are automatically inspected for malware prior to their execution (on- access scan). + The entire data contents of all systems is regularly inspected for malware. + Data transferred by central gateways (e.g. e-mail, internet, third-party networks) is automatically inspected by means of protection software: - Encrypted connections are taken into account. + Measures to prevent protection software from being deactivated or altered by users are defined and implemented. + Case-related staff awareness measures. + For IT systems operated without the use of malware protection software, alternative measures (e.g. special resilience measures, few services, no active users, network isolation) are implemented. + Unnecessary network services are disabled. + Access to network services is restricted to necessary access by means of suitable protective measures (see examples). + Malware protection software is installed and updated automatically at regular intervals (e.g. virus scanner). + Received files and software are automatically inspected for malware prior to their execution (on- access scan). + The entire data contents of all systems is regularly inspected for malware. + Data transferred by central gateways (e.g. e-mail, internet, third-party networks) is automatically inspected by means of protection software: - Encrypted connections are taken into account. + Measures to prevent protection software from being deactivated or altered by users are defined and implemented. + Case-related staff awareness measures. + For IT systems operated without the use of malware protection software, alternative measures (e.g. special resilience measures, few services, no active users, network isolation) are implemented.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Definitions IT service Definition Definitions Critical IT service Examples Definitions IT system Examples Definitions Software Data Protection All All <old data protection tab> Information Security Multple Multiple different use of words "application", "software", "p Conistent use of "Software" Information Security 4.1.2 Must IT Service refers to a specified set of software running on one or more IT systems that satisfies a business need. Examples: Active Directory, Corporate Network, ERP, Corporate phone system Computer, server, cloud, communication systems, video conference systems, smartphones, tablets Computer, server, cloud, communication systems, video conference systems, smartphones, tablets, industrial automation and control system, OT devices, IoT Definition + Examples Software is a generic term used to refer to applications, scripts and programs that run on a IT system. Examples: Operating systems, applications, libraries, device drivers, apps <new data protection tab as provided by VDA AK Datenschutz> been selected based on a risk assessment. Possible attack scenarios have been considered (e.g. direct accessibility via the internet). + The procedures applied for user authentication comply with the current state of the art. selected based on a risk assessment. Possible attack scenarios have been considered (e.g. direct accessibility via the internet). + State of the art procedures for user authentication are applied.

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Information Security 5.1.3 Should Information Security Integration Examples Results Spider diagram Welcome n/a n/a © 2023 Verband der Automobilindustrie e.V. © 2023 ENX Association, an Association according to Welcome n/a n/a License n/a n/a Wrong CC logo, unclarity about what is covered by CRephrasing Data Protection 9 Control Question Data Protection + Requirement specifications are prepared. The following aspects are considered: - The determined information security requirements. - Vendor recommendations and best practices for secure configuration and implementation - Publically available best practice guidelines - fail safe (graceful handling of failure) + Requirement specifications are reviewed against the information security requirements. + The IT system is reviewed for compliance with specifications prior to productive use. + The use of productive data for testing purposes is avoided as far as possible (if applicable, anonymization or pseudonymization): - Where productive data are used for testing purposes, it shall be ensured that the test system is provided with protective measures comparable to those on the operational system, - Requirements for the lifecycle of test data (e.g. deletion, maximum lifetime on the IT system), - case-related specifications for the generation of test data are defined. + Requirement specifications are prepared. The following aspects are considered: - The determined information security requirements. - Vendor recommendations and best practices for secure configuration and implementation - Publically available best practice guidelines - Commonly known risks such as OWASP Top 10 - fail safe (graceful handling of failure) + Requirement specifications are reviewed against the information security requirements. + The IT system is reviewed G73for compliance with specifications prior to productive use. + The use of productive data for testing purposes is avoided as far as possible (if applicable, anonymization or pseudonymization): - Where productive data are used for testing purposes, it shall be ensured that the test system is provided with protective measures comparable to those on the operational system, - Requirements for the lifecycle of test data (e.g. deletion, maximum lifetime on the IT system), - case-related specifications for the generation of test data are defined. ENX WG ISA and VDA Working Group Information Securtiy of this document wish you every success. The authors of this document wish you every success. Data Protection Policies and Organization

INTERNAL # DD.MM.YYYY | Responsible Department for filing: xxxx-xx | CSD-class: xx.x – xx years | Author _x000D_ # not public Data Protection 9 Objective This questionnaire supplements the ISA information s Information Security all ISA4 ISA4 Remove ISA4 columns Information Security 1.3.4 W to AB as baseline software installation of the operating systems designed for the purpose and drivers and firmware for the used hardaware with well-known licensing terms. However, to gain the trust the vendor and distributor must have an excellent reputation. All other software is individiually approved. Depending on the risk profile, this may include not only testing but also careful analysis of available documentation (or even a technical audit of the functionality of a specific software). Change logs for software wil Updated software will regularly inherit the approval of previous versions for minor software versions. However, the organization will actively monitor release notes and (if available) relevant other sources to detect changes that might require a re- evaluation. Major software versions always require re-evaluation before approval. Typical Questions What is your strategy when it comes to software approval? Do you differentiate approval on protection need or usage scenario? What software is currently approved for working with a specific protection need? How does your software approval process work? For what use case is software A approved? Where can i see what software is installed on a specific client or server? How does the software repository work? How do users and/or administrators access it to install software? Typical Evidence: Process documentation for approval process Exports of lists of approved software from software repositories Screenshots from software management software (such as MDM)