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

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

Chapter 5 — IT Security / Cyber Security

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

5.1 Cryptography

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

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

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

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

5.1.2 — To what extent is information protected during transfer?

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

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

5.2 Operations Security

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

5.2.1 — To what extent are changes managed?

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

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

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

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

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

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

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

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

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

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

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

5.2.5 — To what extent are vulnerabilities identified and addressed?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3 System Acquisitions, Requirement Management and Development

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

---

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