News
University of Tübingen cyberattack: Check access rights after software changes
The University of Tübingen reported that around 3,900 staff records were accessed. Check that internal functions and personal data remain protected after a change.
Archive photograph of the Neue Aula, 5 February 2025. Giftzwerg 88 / Wikimedia Commons, CC BY-SA 4.0. Resized and converted to WebP for publication.
A software update can change who can access staff data even when the role model stays the same. After the update, check whether the system allows the intended access and reliably blocks everyone else. The University of Tübingen says several recommended settings interacted in a way that opened access to internal functions.
What the University of Tübingen reported
The university announced on 10 November 2026 that unidentified attackers had obtained around 3,900 staff records. These included names, dates of birth, work email addresses, usernames and department details. The university says students were unaffected and no passwords were taken.
The university attributed the access to a combination of settings that a software vendor had recommended. It blocked further access through the gap, reviewed access logs and notified the state data protection authority. Its statement says it is contacting affected people directly. The investigation is ongoing. The statement gives no date for the attack. University statement in German
Which access rights should apply after a change?
When a change affects roles, sign-in or interfaces, agree before release which functions and data must remain protected. Start with the existing role model or change ticket. If necessary, add three details: the function in scope, the role allowed to use it and the data that role may access. The business owner confirms who needs the data to do their job.
Take a fictional HR portal. HR staff can edit employee records. Employees can view their own details. External support can view service issues and has no access to personnel files in normal operations. These three decisions give the team concrete expectations to check after an update.
You can define what to check even when the vendor applies the update. Agree in advance which settings will change, who can verify the result and how to report a discrepancy.
Check what the system actually allows
Use authorised test accounts and test data in an environment designated for the check. Confirm that someone in the HR role can still edit the intended test record. Add a negative test: the system must deny the same action to the support role. For employees, check both sides of the boundary. They can view their own test profile and are denied access to another test user's profile.
If the change affects several access paths, check the relevant interfaces. Hiding a menu item tells you little about whether the system enforces the restriction. OWASP recommends validating permissions on every request and testing authorisation logic. OWASP Authorization Cheat Sheet
If a security setting differs between the test and target environments, account for that difference in the release decision. After rollout, repeat the relevant check with a designated account. If protected data becomes accessible unexpectedly, have the person responsible review the release decision and arrange a correction.
Record the decision alongside the change
For a small change, a few lines in the existing ticket can provide useful evidence. Record the version, function and roles checked, the expected result and what happened. If the results differ, record the correction, its owner and the outcome of the retest. Use test data or anonymised examples in the record.
Teams running an ISO 27001 ISMS can connect the existing change record to the configuration and access review. Configuration management is covered by Annex A control A.8.9. Kopexa lets teams connect the affected systems, evidence of the review and outstanding corrections.
Start with one application
Pick an upcoming change to an application that holds personal data. Confirm with the business owner which roles should see which data. After the change, check at least the intended access and the affected boundary for a role without permission. The Review and correct access rights measure walks you through checking existing access and verifying corrections. If you need a role model, request the template.
Use this template in these measures
Implementation measure
Agree safe technical system testing
Mapped requirements (1)
- A.8.34 · Schutz von Informationssystemen während der Auditprüfung (DE)
Supporting contribution
The workflow connects agreed planning, limited access, operational and information safeguards, controlled testing and closure. Actual configuration, execution and evidence remain necessary.
Further framework mappings of this measure
TISAX · 5.2.6
VDA ISA 6.0.3 · Partial contribution
The specific test assignment supports timely scope definition, coordination with operations and users, risk-aware execution, reported results and follow-up work. Regular testing, appropriate competence, methods and applicable additional requirements must still be implemented separately.
Read the source ↗
Implementation measure
Approve remote work securely
Mapped requirements (1)
- A.6.7 · Telearbeit (DE)
Supporting contribution
The steps determine safe conditions outside sites, provide suitable resources and maintain approvals through changes and termination. The organisation selects suitable safeguards and actually implements them.
Further framework mappings of this measure
TISAX · 2.1.4
VDA ISA 6.0.3 · Partial contribution
Task-based and environment-based approval, information handling, suitable access and communication support remote work. Additional protection, contractual and travel requirements depend on the actual case.
Read the source ↗
Implementation measure
Assign security roles and duties
Mapped requirements (3)
- A.5.2 · Informationssicherheitsrollen und -verantwortlichkeiten (DE)
Supporting contribution
The workflow assigns security duties, authority, competence and known owners within the existing organisational model and keeps delegation and maintenance traceable.
- A.5.3 · Aufgabentrennung (DE)
Supporting contribution
Actual conflicting duties are separated in the process and effective rights. Practical limitations are addressed through suitable effective additional controls.
- A.5.4 · Managementverantwortlichkeiten (DE)
Supporting contribution
Managers explain duties and rules before relevant access, require their application and provide necessary competence, resources and planning time. Actual application is checked through a case.
Further framework mappings of this measure
TISAX · 1.2.2
VDA ISA 6.0.3 · Partial contribution
Assigned competent roles, resources, known contacts and appropriate segregation support this ISA question. The actual organisation and applicable protection-need additions still require checking.
Read the source ↗ISO/IEC 27001 · 5.1
ISO/IEC 27001:2022 + Amd 1:2024 · Supporting contribution
Leadership work connects a strategically aligned policy and objectives, integration into business processes, necessary resources, communication, support for people, intended outcomes and continual improvement. Top management must actually exercise this responsibility; delegated tasks do not replace its leadership.
Read the source ↗ISO/IEC 27001 · 5.3
ISO/IEC 27001:2022 + Amd 1:2024 · Supporting contribution
The allocation identifies roles and authorities, including ensuring ISMS conformity and reporting its performance to top management. Responsibilities are communicated and maintained when changes occur; actual application remains necessary.
Read the source ↗
Implementation measure
Manage identities and authentication information
Mapped requirements (4)
- A.5.16 · Identitätsmanagement (DE)
Supporting contribution
The workflow connects confirmed identity and need with personal or technical assignment, limited shared identities and approved creation, maintenance and effective retirement. The organisation manages real identities and appropriate independent oversight in its systems.
- A.5.17 · Authentifizierungsinformationen (DE)
Supporting contribution
The workflow and integrated concept structure authorised secure issue, recovery, user guidance and invalidation of authentication information. Actual technical procedures, quality requirements and protected storage and transmission remain to be implemented in the authentication system used.
- A.8.5 · Sichere Authentifizierung (DE)
Supporting contribution
Selecting and actually configuring suitable login procedures, with failed-login, session and recovery tests, connects access rules to technical authentication. Actual parameters and their continuing effectiveness are maintained in the authentication system.
- A.5.15 · Zugangssteuerung (DE)
Supporting contribution
Controlled logical access connects confirmed need, approval and technical authentication. Existing site procedures provide the physical entry rules.
Further framework mappings of this measure
TISAX · 4.1.3
VDA ISA 6.0.3 · Partial contribution
Personal and limited shared accounts, approved creation and changes, secure issue and handling of authentication information support this ISA requirement. Technical enforcement, actual account coverage including customer systems and applicable additional requirements are checked separately.
Read the source ↗
Implementation measure
Restrict and check sensitive data flows
Mapped requirements (3)
- A.8.3 · Einschränkung des Informationszugangs (DE)
Supporting contribution
Permitted content and actions derive from the leading role model, are technically restricted and are checked through authorised and unauthorised access. The workflow does not replace the full access rights lifecycle.
- A.8.11 · Datenmaskierung (DE)
Supporting contribution
Purpose-based reduction and masking consider access rules, protected originals and mappings, and checked identifiability. The actual method is implemented and legally assessed for the organisation’s data flow.
- A.8.12 · Verhinderung von Datenlecks (DE)
Supporting contribution
The workflow considers sensitive data and actual leakage paths, configures suitable restriction and detection, and checks alerts, exceptions and response. Technical measures and legal boundaries must be applied to the specific situation.
Implementation measure
Review and correct access rights
Mapped requirements (5)
- A.5.18 · Zugangsrechte (DE)
Supporting contribution
The workflow supports reviewing and correcting logical access rights. The other provisioning processes and physical access rights require the appropriate operational workflow.
- A.8.2 · Privilegierte Zugangsrechte (DE)
Supporting contribution
The review includes justified privileges, separate administrative use, suitable authentication, usage logs and effective removal. Allocation and operational use remain governed by the leading concept and actual systems.
- A.8.3 · Einschränkung des Informationszugangs (DE)
Supporting contribution
The comparison includes actual enforcement of permitted actions through authorised and unauthorised access. The leading role model and additional technical protections are applied in the affected system.
- A.8.18 · Nutzung privilegierter Hilfsprogramme (DE)
Supporting contribution
The workflow checks necessary and authorised use of privileged utilities, personal attribution, separation of duties, restricted availability and logging of every use. Technical disabling, separation and ongoing control must be implemented on the actual systems.
- A.5.15 · Zugangssteuerung (DE)
Supporting contribution
The review compares permitted logical access against duties and authoritative rules and implements changes effectively. Physical entry remains part of site procedures.
Further framework mappings of this measure
TISAX · 4.2.1
VDA ISA 6.0.3 · Partial contribution
The review and correction support regular checks of effective access rights. The complete provisioning process, technical enforcement and further requirements for the relevant protection needs still require separate work.
Read the source ↗
Implementation measure
Review and safely implement a system change
Mapped requirements (11)
- A.8.4 · Zugang zu Quellcode (DE)
Supporting contribution
Step 2 separates read and write access to code, tools and libraries, including technical identities. Approval, enforcement and logged verification remain actual work in the target system.
- A.8.19 · Installation von Software auf Betriebssystemen (DE)
Supporting contribution
Steps 5 and 6 connect authorised competent installation, a trusted tested release, configuration, update logging, rollback, necessary old versions and controlled external access. The installation procedure must actually be established and carried out.
- A.8.25 · Sicherer Entwicklungslebenszyklus (DE)
Supporting contribution
The steps connect requirements, design, secure development, protected environments, testing, implementation and maintenance in the existing process. Appropriate technical rules and their application remain necessary.
- A.8.26 · Anforderungen an die Anwendungssicherheit (DE)
Supporting contribution
Step 1 leads to described, confirmed security requirements and testable criteria before development or acquisition. Selection and acceptance must relate to the actual use.
- A.8.27 · Sichere Systemarchitektur und technische Grundsätze (DE)
Supporting contribution
Step 1 checks safeguards at data flows and interfaces and how the principles work together. The suitable actual system design and decided exceptions remain necessary.
- A.8.28 · Sicheres Coding (DE)
Supporting contribution
Step 2 connects applicable coding practices, specific error checks and component maintenance with the version. Technical practices and effective code reviews must be applied in the development tools.
- A.8.29 · Sicherheitstests in Entwicklung und Abnahme (DE)
Supporting contribution
Step 4 connects requirements-based tests, results, retests and independent acceptance for in-house development. Actual test cases and results must be carried out and retained.
- A.8.30 · Ausgelagerte Entwicklung (DE)
Supporting contribution
Steps 1 and 4 connect outsourced development with agreed requirements, deliverables, usage rights and review of the actual delivery. Ongoing supplier management is reused.
- A.8.31 · Trennung von Entwicklungs-, Test- und Produktionsumgebungen (DE)
Supporting contribution
Step 3 and controlled implementation in step 5 connect risk-based environment boundaries, access and actual checks for unauthorised transitions. They do not automatically establish technical separation.
- A.8.32 · Änderungsmanagement (DE)
Supporting contribution
The workflow connects impacts, requirements, testing, decisions, controlled implementation, rollback and result checks in the existing change record. Actual execution and follow-up remain necessary.
- A.8.33 · Testinformationen (DE)
Supporting contribution
Step 3 and completion in step 6 connect suitable test information, separate authorisation for operational copies, protection, traceable use and secure removal. They do not automatically meet legal requirements.
Further framework mappings of this measure
TISAX · 5.2.1
VDA ISA 6.0.3 · Partial contribution
The specific change record supports security requirements, impact assessment, approval, testing, rollback and result checks. Actual execution and applicable additional requirements remain necessary.
Read the source ↗TISAX · 5.2.2
VDA ISA 6.0.3 · Partial contribution
Step 3 connects risk-based separation and protection of development, test and production environments. The actual risk assessment, segmentation and technical implementation still need to be evidenced.
Read the source ↗