A Structured NIS2–ISO/IEC 27001:2022 Alignment Framework for Higher Education Institutions

1. Introduction

Higher education institutions (HEIs) have become complex digital organizations. Their mission requires openness, collaboration, mobility, and rapid access to information systems, but the same characteristics increase their exposure to cyber incidents. Universities operate student-information systems, learning management platforms, identity infrastructures, research laboratories, cloud services, administrative systems, public websites, and, in many cases, high-performance or specialized research infrastructures. These environments are not always centrally managed and often involve different technical cultures across faculties, research groups, and administrative departments.

The NIS2 Directive [4,7] changes the institutional context in which cybersecurity must be governed. Cybersecurity can no longer be treated only as a technical matter delegated to central IT departments. It becomes a matter of institutional risk, management accountability, continuity of important services, supplier control, and demonstrable compliance. ISO/IEC 27001:2022 [5] provides a well-established Information Security Management System (ISMS) model, but its application in universities requires careful adaptation. A literal or purely checklist-based application is unlikely to match the operational reality of HEIs, where academic freedom, decentralized infrastructure, research autonomy, and student mobility are part of the institutional fabric.

The Romanian context is particularly relevant for the institutional instantiation considered in this paper. Romania transposed the NIS2 Directive through Government Emergency Ordinance No. 155/2024 on the establishment of a framework for the cybersecurity of networks and information systems in the national civilian cyberspace [8], subsequently approved with amendments by Law No. 124/2025 [9]. The ordinance designates the National Cyber Security Directorate (DNSC) as the competent authority and establishes cybersecurity risk-management and incident-reporting obligations for essential and important entities [10]. Sectoral applicability is determined by the sectors listed in Annexes 1 and 2 of the ordinance, which include public administration among the covered sectors, together with entity-size criteria and designation mechanisms; classification is confirmed through the DNSC notification and registration process operationalized by DNSC Orders No. 1/2025 and No. 2/2025. Consequently, a Romanian public university cannot be discussed only as a generic higher education institution: its NIS2 relevance must be assessed against the Romanian transposition, the DNSC registration and classification process, and the applicable implementing orders. The present paper does not provide a legal determination of the institution’s final status; rather, it uses the Romanian transposition as the jurisdictional anchor for the design-science instantiation.

This paper addresses the following research questions:

RQ1. 

How can NIS2 cybersecurity obligations be operationalized in higher education institutions?

RQ2. 

How can ISO/IEC 27001:2022 serve as an implementation backbone for NIS2 compliance?

RQ3. 

What higher-education-specific adaptations are required for governance, risk management, incident handling, supplier management, and evidence management?

The contribution of the paper is threefold. First, it proposes a structured mapping between NIS2 implementation areas and ISO/IEC 27001:2022 clauses and Annex A control domains. Second, it develops a higher-education-specific implementation framework covering governance, scope definition, risk management, incident response, supplier control, and evidence management. Third, it introduces a maturity and evidence model that can be used by universities to assess readiness, prepare for audit, and support continuous improvement.

The remainder of this paper is organized as follows. Section 2 presents the regulatory and standards background and reviews related work. Section 3 describes the design science research methodology. Section 4 derives the implementation requirements. Section 5 presents the proposed framework. Section 6 introduces the NIS2–ISO/IEC 27001:2022 mapping model. Section 7 presents the maturity model. Section 8 demonstrates the framework in the UPT scenario. Section 9 describes the evaluation approach. Section 10, Section 11 and Section 12 discuss the implications, limitations, and conclusions of the paper.

2. Background and Related Work

2.1. Cybersecurity Risks in Higher Education Institutions

The cybersecurity posture of HEIs is shaped by a combination of technical, organizational, and cultural factors. Unlike many industrial or financial organizations, universities are expected to maintain relatively open digital environments. Students, staff, visiting researchers, contractors, alumni, and external partners may all require access to institutional systems. Devices are heterogeneous, users are mobile, and the boundary between institutional and personal equipment is often blurred.

The most relevant HEI-specific risk factors include decentralized IT administration, federated identity, bring-your-own-device practices, cloud-based teaching platforms, legacy laboratory equipment, research data repositories, and procurement processes that may be distributed across faculties or projects. In addition, cybersecurity must coexist with institutional values such as openness, academic collaboration, and research autonomy. This creates a security-governance problem rather than a purely technical one.

2.2. NIS2 Directive and Cybersecurity Governance

NIS2 establishes a stronger European framework for cybersecurity governance, risk management, incident reporting, business continuity, and supply-chain security. Its implementation depends on national transposition, whose status varies across Member States [11], and therefore each university must determine its precise legal status under national law. Nevertheless, the directive introduces a general expectation that relevant entities maintain proportionate technical, operational, and organizational measures for managing cybersecurity risks.

For HEIs, the key consequence is that cybersecurity must be addressed at institutional level. It requires explicit responsibility, risk-based decision making, incident escalation, supplier oversight, and evidence that controls are not only declared but implemented and reviewed. The exact legal qualification of a university may differ across Member States, but the governance logic is broadly applicable.

2.3. ISO/IEC 27001:2022 as an ISMS Implementation Model

ISO/IEC 27001:2022 specifies requirements for establishing, implementing, maintaining, and continually improving an ISMS. The standard provides a management-system structure based on organizational context, leadership, planning, support, operation, performance evaluation, and improvement. Its Annex A controls provide a catalogue of organizational, people, physical, and technological controls.

In the context of NIS2, ISO/IEC 27001:2022 can serve as the operational backbone for compliance. It provides mechanisms for defining scope, assigning responsibilities, assessing risks, selecting controls, maintaining evidence, conducting internal audits, and performing management reviews. However, ISO/IEC 27001 certification should not be treated as an automatic substitute for NIS2 compliance. The standard provides a management system; NIS2 introduces regulatory obligations that must be interpreted in the relevant national legal context.

2.4. Existing Approaches and Research Gap

Existing work provides important foundations for understanding NIS2, ISO/IEC 27001, and cybersecurity governance, including governance frameworks [15] and ISMS adoption studies in resource-constrained organizations [13], but it does not yet provide a higher-education-specific alignment artefact that links NIS2 obligations, ISO/IEC 27001:2022 controls, and institutional evidence in a single operational structure. Ruohonen’s systematic review [16] clarifies the emerging NIS2 research landscape and identifies the breadth of sectors and legal-technical themes addressed in the literature, but its contribution is primarily review-oriented rather than an implementation framework for universities. Mentzelou et al. [12] examine barriers to NIS2 compliance and are useful for understanding organisational, financial, technical, and regulatory obstacles; however, their model does not translate those barriers into a control-level HEI maturity structure. Vestad and Yang [14] focus on sustainable cybersecurity capabilities in resource-constrained municipal organisations, offering a valuable socio-technical perspective, but their context is local government rather than higher education and their contribution is not a NIS2–ISO/IEC 27001 traceability model. Castiglione et al. [17] propose an ontological approach to compliance verification for NIS2, contributing a formal representation of legal obligations; by contrast, the present paper focuses on institutional governance, evidence production, and staged implementation in a university setting.

The gap addressed here is therefore narrower and more operational than a general claim that NIS2 has not been studied. The paper contributes a design-science artefact for higher education institutions that: (i) structures the cybersecurity governance problem into HEI-specific capability domains; (ii) maps those domains to explicit NIS2 Articles 20, 21, and 23 and ISO/IEC 27001:2022 clauses and Annex A controls; and (iii) shows how institutional evidence can be organized for readiness assessment without claiming that the illustrative case values are audit results.

3. Research Methodology

The methodological approach adopted in this paper follows established design science research (DSR) practice [1,2,3]. This choice is appropriate because the aim of the work is not only to describe the regulatory and standardization landscape, but to construct and evaluate an artefact that can be used by higher education institutions in the implementation of cybersecurity governance. The proposed artefact is an integrated NIS2–ISO/IEC 27001:2022 implementation framework adapted to the institutional, operational, and technical characteristics of universities. The research process instantiates the six activities of the design science research methodology of Peffers et al. [2]: problem identification, definition of solution objectives, design and development, demonstration, evaluation, and communication. In the knowledge-contribution framing of Gregor and Hevner [3], the contribution is positioned as an improvement-type artefact: a new structured solution (the alignment framework, mapping method, and maturity instrument) for a known organizational problem (regulatory compliance in complex institutions).

The process starts from the practical problem faced by higher education institutions: the need to translate regulatory cybersecurity obligations into operational governance, risk-management, control, and traceability-management practices. Implementation requirements are then derived from three sources: the NIS2 Directive, ISO/IEC 27001:2022, and the specific organizational properties of higher education institutions, including academic openness, decentralized IT governance, heterogeneous research infrastructures, cloud-based teaching services, student-facing platforms, and a broad supplier ecosystem. The framework is designed as a layered model combining institutional governance, service and asset classification, risk assessment, control implementation, incident handling, supplier-risk management, and compliance evidence management. The artefact is demonstrated on representative university service domains and evaluated through coverage analysis, ISO/IEC 27001 alignment, and expert-oriented validation criteria, consistent with the artefact-evaluation guidance of Hevner et al. [1].

Figure 1. Design science research process used for developing the proposed NIS2–ISO/IEC 27001:2022 implementation framework for higher education institutions.

Figure 1. Design science research process used for developing the proposed NIS2–ISO/IEC 27001:2022 implementation framework for higher education institutions.

The methodology therefore combines normative analysis and artifact construction. The normative component is used to identify the obligations and control expectations that must be addressed. The design component translates these expectations into an implementation structure suitable for universities. The evaluation component verifies whether the resulting framework is complete, traceable, and applicable to the higher education context.

The research design is summarized in Table 1. Each phase produces an intermediate result that supports the construction of the final framework.

4. Requirements Analysis

The framework requirements are derived from three sources: the regulatory orientation of NIS2, the management-system structure of ISO/IEC 27001:2022, and the organizational characteristics of HEIs. These sources lead to a set of implementation requirements summarized in Table 2. The first seven requirements are reflected as functional layers of the proposed framework. The eighth requirement, academic compatibility, is treated as a cross-cutting design constraint rather than as a separate layer, since it affects the implementation of governance, risk management, access control, supplier management, and evidence collection across the whole institution.

5. Proposed Framework

Although the framework is organized into seven operational layers, it is derived from eight implementation requirements. Requirements R1–R7 correspond to the main functional layers, while R8 is intentionally treated as a cross-cutting constraint. This reflects the fact that academic compatibility is not a standalone process, but a condition that must be preserved when defining governance rules, risk treatments, access-control mechanisms, incident procedures, supplier controls, and compliance evidence.

As shown in Figure 2, the framework contains seven operational layers. The dashed boundary indicates that academic compatibility acts as a cross-cutting constraint rather than a separate implementation layer.

The framework is structured as follows.

5.1. Governance Layer

The governance layer defines institutional responsibility for cybersecurity. It includes the university executive leadership, the CISO or equivalent information-security role, the Data Protection Officer, the central IT directorate, faculty-level IT coordinators, research-infrastructure owners, procurement and legal offices, and internal audit or compliance functions. The objective is to make cybersecurity risk visible at institutional level and to avoid a situation in which central IT is formally responsible for risks it cannot govern.

5.2. Scope and Service-Classification Layer

The second layer defines the scope of the ISMS and classifies university services. The starting point should not be a list of servers, but a service view of the institution: identity and access management, learning platforms, student records, admissions, finance, HR, research systems, laboratory networks, email, public websites, and cloud services. Each service can then be mapped to assets, data categories, owners, suppliers, dependencies, and required security properties.

5.3. Risk-Management Layer

The risk-management layer translates service classification into risk scenarios and treatment decisions. The HEI context requires risk criteria that account for teaching continuity, research continuity, personal-data exposure, reputational impact, financial loss, legal exposure, and disruption of external partnerships. Typical scenarios include ransomware affecting administrative systems, compromise of federated identity, exfiltration of research data, supplier-originated disruption of an LMS, or misuse of privileged accounts in a laboratory network.

5.4. Control-Implementation Layer

The control-implementation layer groups organizational, people, physical, and technological measures. The relevant domains include access control, multi-factor authentication, privileged-access management, network segmentation, endpoint protection, vulnerability management, logging and monitoring, backup and recovery, user awareness, physical security, secure configuration, and change management. Controls should be selected through the ISO/IEC 27001 risk-treatment process rather than copied mechanically from a checklist.

5.5. Incident-Response and Reporting Layer

The incident layer defines detection, triage, containment, escalation, communication, reporting, and post-incident improvement. It should distinguish between operational incident handling and regulatory reporting. A university needs a procedure that allows technical staff, legal advisers, the DPO, executive leadership, and communications personnel to make timely decisions. Incident categories should include account compromise, ransomware, data breach, denial of service, compromise of teaching platforms, compromise of research infrastructure, and supplier-originated incidents.

5.6. Supplier and Cloud-Risk Layer

The supplier layer is critical because many university services are outsourced or cloud-hosted. Learning-management systems, productivity suites, research SaaS platforms, library platforms, payment systems, cybersecurity providers, and laboratory vendors can become part of the institution’s risk surface. Supplier management should include security requirements in contracts, incident notification clauses, data-processing agreements, assurance reports, service continuity commitments, and exit or migration plans.

5.7. Evidence and Audit Layer

The evidence layer connects regulatory requirements, ISO/IEC 27001 mechanisms, controls, owners, and proof of implementation. Typical evidence includes the ISMS scope, security policies, risk methodology, risk register, Statement of Applicability, access reviews, incident logs, supplier assessments, backup test reports, vulnerability reports, awareness-training records, internal-audit reports, management-review minutes, and corrective-action logs. Without this layer, compliance remains declarative and difficult to defend.

6. NIS2–ISO/IEC 27001:2022 Mapping Model

The mapping model is the central bridge between regulatory implementation areas and ISMS operation. Table 3 gives the structure of the mapping. The mapping was constructed using a fixed protocol. The unit of analysis on the regulatory side is the individual obligation: the governance duties of Article 20, each risk-management measure enumerated in Article 21(2)(a)–(j), and the reporting obligations of Article 23. Each obligation was mapped to the ISO/IEC 27001:2022 clause or Annex A control whose stated purpose operationally implements it, preferring the most specific applicable control; where an obligation is implemented by several mechanisms, a one-to-many mapping was recorded rather than forcing a single correspondence. Ambiguous cases were resolved by cross-checking against ENISA implementation guidance [6] and documenting the rationale in the evidence column. The mapping remains interpretative rather than legally authoritative, but the protocol makes it transparent, criticizable, and replicable by other institutions.

7. Cybersecurity Maturity Model

A maturity model is useful because many universities will not be able to implement a complete ISMS across the entire institution at once. Table 4 defines a generic scale. The scale can be applied to governance, asset and service inventory, risk management, incident handling, supplier security, technical controls, business continuity, evidence management, awareness, and continuous improvement.

7.1. Maturity Scale, Scoring Rules, and Application

The maturity model is not intended to produce a single undifferentiated institutional score. Instead, it should be applied per domain, allowing the university to identify uneven development across functional areas. In practical use, a higher education institution may, for example, achieve Level 4 in backup and recovery practices while remaining at Level 2 in supplier security or evidence management. This domain-oriented interpretation is more informative than a global score and is more consistent with the heterogeneous operational reality of universities.

To make the assessment reproducible, the model is applied with four explicit scoring rules. First, levels are cumulative: a domain is rated at level N only if the criteria of all levels up to N are satisfied. Second, each level assignment must be anchored in named evidence: Level 2 requires approved documentation, Level 3 requires records demonstrating operation across the defined scope, Level 4 requires measurement records (indicators, audit reports, review minutes), and Level 5 requires documented improvement cycles; a claim without the corresponding evidence type defaults to the highest level for which evidence exists. Third, where evidence is partial, a range (e.g., 2–3) is recorded together with the missing evidence, rather than an averaged score. Fourth, the assessment is performed by at least two assessors who rate independently and then resolve differences in a documented consensus step; systematic inter-rater reliability analysis is identified as future validation work in Section 11.

8. Demonstration Scenario: Application to Politehnica University Timisoara

This section demonstrates the applicability of the proposed framework using Politehnica University Timisoara (UPT) as an illustrative higher education institution. The demonstration is not presented as a formal audit, certification exercise, or institutional security assessment. Its purpose is to show how the proposed NIS2–ISO/IEC 27001:2022 framework can be instantiated in a real university context, using publicly available institutional information and a limited set of representative service domains.

UPT is a public technical university with a complex educational, research, administrative, and student-support mission. Public institutional information describes UPT as having ten faculties and a large academic community, with more than 12,800 students enrolled across bachelor, master, doctoral, and postdoctoral cycles, supported by more than 600 teaching staff and more than 700 administrative staff [18]. The university also operates a significant physical and educational infrastructure, including teaching and research spaces, student residences, and support services [18]. This scale and diversity make UPT a representative case for demonstrating the applicability of a cybersecurity governance framework adapted to higher education institutions.

The choice of UPT is also justified by the institution’s explicit strategic orientation toward digitalization: its strategic plan emphasizes decentralized decision-making and software-supported information transfer [21], and its digital transformation strategy targets increased digitalization of the entire university [22]. This creates a relevant environment in which digital transformation, institutional autonomy, decentralized operation, and compliance requirements must be considered together.

8.1. Institutional Context

The institutional context of UPT reflects characteristics typical for technical universities: a multi-faculty structure with distributed educational and research activities, a combination of central administrative services and specialized teaching or research infrastructures, and a heterogeneous user population of students, staff, researchers, external collaborators, and international partners.

This organizational structure is relevant for NIS2 and ISO/IEC 27001:2022 implementation because cybersecurity responsibility cannot be reduced to a single technical unit. The Senate of UPT is described in the institutional regulation as the highest forum for regulation, decision, and debate, functioning under the principles of university autonomy, academic freedom, and transparency [24]. These principles are important when adapting cybersecurity controls to a university environment. A security measure that may be straightforward in a centralized enterprise can be difficult to apply in a university if it conflicts with academic mobility, research autonomy, open collaboration, or decentralized decision-making.

The demonstration therefore treats UPT as a distributed socio-technical system, applying the framework through representative service domains that each illustrate a different aspect of institutional cybersecurity governance.

8.2. Identity and Access Management Baseline

A cross-cutting service domain for the UPT scenario is identity and access management. In the demonstration scenario, identity services are treated as a foundational cybersecurity capability, since they support access to teaching platforms, student services, administrative systems, communication services, and collaborative environments. UPT uses a Microsoft 365 and Active Directory-based identity infrastructure for institutional authentication and user management. In practical terms, this creates a central identity layer that can support account lifecycle management, institutional email, cloud collaboration, group-based authorization, and integration with university digital services.

The identity layer is complemented by a publicly accessible password self-service endpoint based on the open-source PWM application [25,26]. In the proposed model, this component is interpreted as a password self-service layer connected to the institutional directory, not as the identity provider itself.

From the perspective of the proposed framework, this identity layer should be considered part of the initial ISMS scope. Its relevance is structural: most other service domains depend on it. A compromise of institutional credentials may propagate toward student services, digital education platforms, administrative workflows, research collaboration environments, and external cloud services. Consequently, identity and access management should be treated as one of the main control domains for both NIS2 risk management and ISO/IEC 27001:2022 implementation.

The technical control baseline for this domain should include centralized account lifecycle management, role-based access control, privileged-account separation, multi-factor authentication for administrative and high-risk accounts, periodic privileged-user review, authentication logging, and secured self-service password reset, with lifecycle rules aligned to institutional status (admission, employment, enrolment, graduation, suspension, project participation, termination).

The evidence package should include identity-architecture documentation, lifecycle procedures, privileged-access review records, MFA coverage reports, administrator-role assignments, and incident records related to account compromise. Because identity is a dependency for several other domains, it should also be linked in the evidence repository to digital education, administrative systems, and research infrastructures.

8.3. Digital Education and Student-Facing Services

A first representative service domain is digital education and student-facing services. UPT publicly describes the development of a digital education ecosystem over more than two decades, organized around a progression from digitization toward digital transformation [19]. A central component of this ecosystem is Campus Virtual UPT, publicly accessible through cv.upt.ro, developed by the ID/IFR and e-Learning Center. The platform is described as an online academic-support environment for all UPT faculties and distance-learning activities, supporting online learning, mobile learning, academic and administrative support, communication, and blended-learning activities for master and doctoral students [20]. Public information also describes the platform as Moodle-based and continuously developed from earlier institutional e-learning initiatives [20].

The student-facing digital ecosystem also includes public services such as student.upt.ro and catalog.upt.ro. These platforms are relevant because they support administrative and academic interaction with students, including student information, educational records, academic status, and access to institutional processes. In the proposed framework, such services should be classified as critical or important university services, depending on the precise service dependency, data processed, and continuity requirements.

Within the proposed framework, cv.upt.ro should be classified primarily as a critical teaching and communication service. Its cybersecurity relevance derives from the number of users, the dependency of teaching activities on platform availability, the processing of student-related data, the need for authenticated access, and the reputational impact of service disruption or compromise. In ISO/IEC 27001:2022 terms, this domain requires clear asset ownership, access control, supplier and software-management procedures, logging, backup, incident handling, and continuity planning. In NIS2 terms, the same domain is relevant to risk-management measures, incident detection and reporting workflows, continuity of essential digital services, and supply-chain or platform-dependency analysis.

For demonstration purposes, Campus Virtual is first included in the ISMS scope, its assets are classified (application components, authentication mechanisms, course content, accounts, logs, backups, administrative interfaces), and risks are assessed for scenarios such as account compromise, unauthorized access, unavailability during examination periods, ransomware, and role misconfiguration. The corresponding treatment plan can include MFA for privileged accounts, role-based access control, administrator-account review, backup and restore testing, vulnerability management, logging and alerting, and incident playbooks.

8.4. Institutional Administrative and Student Services

A second service domain concerns institutional administrative and student-facing services, including student.upt.ro and catalog.upt.ro. UPT’s digital transformation strategy mentions concrete institutional digitalization initiatives such as electronic registry, the student.upt.ro application, and the virtual catalogue, as part of the effort to increase institutional digitalization and improve information exchange through modern software applications and data structures [22]. In this paper, these services are treated as representative examples of administrative and academic-support platforms that require formal cybersecurity governance.

Compared to the digital education domain, administrative and catalogue-related systems tend to present higher integrity and confidentiality requirements. They may support official student records, administrative workflows, formal requests, grades, academic status information, and institutional reporting. The risk model should therefore include not only availability scenarios, but also unauthorized modification, incorrect data synchronization, privilege misuse, insufficient segregation of duties, and inadequate traceability of administrative actions.

For ISO/IEC 27001:2022 implementation, this domain requires clear definition of process owners, information owners, access roles, retention rules, backup procedures, audit logs, and change-management procedures. From a NIS2 perspective, the domain illustrates the importance of governance and management accountability: the protection of administrative systems is not only a technical matter, but a requirement for maintaining institutional function and trust. Evidence for this domain may include access-review records, change approvals, incident logs, backup-test reports, user-management procedures, and documented responsibilities between central IT services and administrative departments.

8.5. Research and Laboratory Infrastructure

A third service domain concerns research and laboratory infrastructure. As a technical university, UPT operates educational and research infrastructures across engineering, computer science, electronics, energy, architecture, civil engineering, mechanical engineering, and related fields [18]. Such environments are particularly relevant for cybersecurity governance because they often combine teaching laboratories, research prototypes, specialized equipment, locally managed systems, externally funded projects, and collaboration with industrial or international partners.

For the UPT demonstration, particular attention should be given to engineering and computer-related academic units, including the Faculty of Automation and Computers and the Faculty of Electronics, Telecommunications and Information Technologies. These units are representative of the challenges encountered in technical universities: laboratory networks, student development environments, experimental platforms, embedded and industrial systems, research prototypes, specialized software, externally funded research projects, and collaboration with industrial partners. Such environments cannot be treated in exactly the same way as administrative information systems, because they often require experimentation, reconfiguration, controlled exposure, or temporary exceptions.

Such environments may include experimental systems, non-standard configurations, legacy devices, instrumentation networks, and externally provided software, and they require openness and flexibility to support experimentation, so strict uniform controls may be impractical or counterproductive. The framework addresses this through the cross-cutting constraint of academic compatibility: environments are classified according to risk, connectivity, data sensitivity, and institutional dependency rather than forced into a single control profile.

For demonstration purposes, research and laboratory infrastructure can be divided into at least three categories. The first category includes isolated or low-risk teaching laboratories, where the primary concern is availability and recovery. The second category includes connected laboratories that interact with institutional identity, file storage, cloud services, or externally accessible systems. The third category includes higher-risk research infrastructures that process sensitive data, support externally funded projects, connect to industrial partners, or expose services to the Internet. Each category requires a different control baseline. For example, isolated teaching laboratories may emphasize imaging, recovery, account hygiene, and network separation, while higher-risk research infrastructures may require stronger access control, logging, vulnerability management, segmentation, supplier assessment, and documented risk acceptance.

This domain also demonstrates why an HEI-specific approach is necessary. A generic ISO/IEC 27001 implementation may identify laboratory systems as assets, but it may not sufficiently account for the academic need to experiment, reconfigure, and collaborate. Conversely, treating all research autonomy as an exception would weaken institutional cybersecurity governance. The proposed framework addresses this tension by requiring explicit risk ownership, documented exceptions, compensating controls, and periodic review.

Figure 3 summarizes the high-level IT context used in the UPT demonstration scenario. The figure is intentionally abstract and avoids implementation details such as internal network topology, tenant configuration, privileged role names, policy identifiers, server locations, or integration secrets.

The diagram should not be interpreted as a complete technical architecture of UPT. Rather, it identifies the minimum set of public and high-level institutional elements needed to demonstrate how the proposed framework connects identity management, digital education, student services, administrative systems, research infrastructure, control implementation, and compliance evidence.

8.6. Application of the Framework to UPT

Table 5 is not presented as an exhaustive legal equivalence table. Its purpose is to make the framework’s traceability explicit by linking each framework component to concrete NIS2 article anchors and to ISO/IEC 27001:2022 clauses or Annex A controls that can produce auditable institutional evidence.

The demonstration shows that the same framework can be applied to domains with different cybersecurity profiles. In the identity domain, the main emphasis is on account lifecycle, authentication, privilege control, and monitoring. In the digital education domain, the main emphasis is on availability, access control, and continuity of teaching. In the administrative domain, the emphasis shifts toward integrity, confidentiality, traceability, and governance. In the research and laboratory domain, the dominant issue is the balance between cybersecurity control and academic flexibility. This confirms the relevance of treating academic compatibility as a cross-cutting constraint rather than as a separate framework layer.

8.7. Indicative Maturity Assessment

Table 6 presents an indicative maturity assessment for the selected UPT service domains, applying the scoring rules of Section 7.1 to publicly available information. The values are not audit results: they demonstrate how the maturity model can structure institutional discussion, identify uneven development, and prioritize implementation steps, and they should be validated through internal interviews, evidence review, and technical assessment.

The indicative maturity assessment highlights a typical pattern for higher education institutions. Centralized and widely used services, such as identity management and digital education platforms, tend to have more mature operational practices. By contrast, research and laboratory environments are more heterogeneous and require a gradual, risk-based implementation approach. The purpose of the maturity assessment is therefore not to produce a single institutional score, but to identify the uneven distribution of cybersecurity capability across institutional domains.

8.8. Evidence Repository for the UPT Scenario

The proposed framework also requires that cybersecurity governance be supported by evidence. Public information indicates that UPT already maintains public sections for institutional strategies, reports, audit-related documents, and other information of public interest [23]. While these documents are not cybersecurity evidence in themselves, they indicate the existence of institutional reporting and transparency mechanisms that can be extended or complemented by an internal cybersecurity evidence repository.

For the UPT scenario, the evidence repository should be organized by framework layer and by service domain, following the evidence categories of the traceability matrix in Table 5: identity-lifecycle and privileged-access records for the identity domain; ownership, backup-testing, and continuity records for digital education; access, change-management, and audit-log records for administrative services; and asset classification, documented exceptions, and compensating controls for research infrastructure.

The repository should not be designed as a static document archive. It should be treated as an operational compliance layer that supports management review, internal audit, NIS2-oriented supervision, and, if pursued, ISO/IEC 27001 certification. Each evidence item should have an owner, review frequency, retention period, and relationship to both NIS2 obligations and ISO/IEC 27001:2022 controls.

8.9. Lessons from the Demonstration

The UPT scenario illustrates five main lessons. First, the implementation of NIS2 in a university cannot be reduced to central IT controls. It requires institutional governance, ownership of risk, and coordination between central services, faculties, administrative departments, and research units. Second, ISO/IEC 27001:2022 provides a suitable implementation backbone, but its scope and controls must be adapted to the university’s service domains and risk profile. Third, identity and access management should be treated as a foundational dependency because it conditions the security of teaching platforms, student services, administrative systems, and research collaboration. Fourth, student-facing and teaching platforms should be considered critical institutional services because their compromise or unavailability can directly affect educational continuity. Fifth, research and laboratory environments require explicit treatment of academic compatibility, including risk-based exceptions and compensating controls.

The demonstration also confirms the importance of starting with a limited and defensible ISMS scope (central identity, the main digital education platform, selected administrative systems) and extending it in later stages toward research infrastructures and laboratory environments; this phased approach is more realistic than whole-institution implementation and more compatible with ISO/IEC 27001:2022 certification practice.

9. Internal Traceability and Artefact Assessment

The assessment in this section is internal to the proposed artefact. It examines whether the framework components are traceable to NIS2 obligations, ISO/IEC 27001:2022 clauses and Annex A controls, and plausible HEI evidence artefacts. Because the requirements were derived by the same authors who designed the framework, coverage analysis of this kind is partly circular: it verifies internal consistency and completeness relative to the stated requirements, not the independent utility of the artefact. Two mitigations are applied: the mapping protocol and scoring rules are published in full so that the derivation can be replicated and challenged, and every coverage claim is anchored to an externally fixed reference point (a NIS2 Article, an ISO/IEC 27001:2022 clause or control, or a named evidence artefact) rather than to author judgement alone. The assessment does not constitute external validation, an audit, or empirical measurement of cybersecurity maturity; external validation through expert review, cross-institutional piloting, or audit comparison remains future work.

The evaluation combines four complementary perspectives: requirements coverage, standards alignment, demonstration-based applicability, and maturity/evidence assessment. Together, these perspectives assess whether the framework can translate regulatory and standards-based expectations into a structured implementation model for higher education institutions.

9.1. Requirements Coverage

The first evaluation perspective concerns coverage of the implementation requirements derived in Section 4. The framework was designed to address eight requirements: governance, scope definition, risk management, incident reporting, supplier security, evidence management, continuous improvement, and academic compatibility. Requirements R1–R7 are reflected as functional layers or operational mechanisms of the framework, while R8 is intentionally treated as a cross-cutting design constraint.

Table 7 summarizes the coverage logic. The table shows that each requirement is explicitly represented in the proposed framework and is also observable in the UPT demonstration scenario.

The coverage analysis indicates that the requirements are translated into operational structures instantiable across university domains, with academic compatibility as a cross-cutting constraint preventing a single uniform control profile from being imposed on teaching, administrative, and research environments.

9.2. ISO/IEC 27001:2022 Alignment

The second evaluation perspective concerns alignment with ISO/IEC 27001:2022. The framework does not attempt to reproduce the standard, but to use the ISMS logic of the standard as an implementation backbone for NIS2-oriented cybersecurity governance. The main alignment points are context and scope definition, leadership and responsibilities, planning and risk treatment, operational control, performance evaluation, and improvement.

Table 8 summarizes the alignment between the main framework elements and the ISO/IEC 27001:2022 implementation logic.

This alignment supports the claim that ISO/IEC 27001:2022 can serve as the operational backbone of NIS2 implementation in HEIs, while also showing that certification-oriented thinking alone is insufficient: practical value depends on adapting scope, control selection, risk treatment, and evidence to the institutional structure.

9.3. Demonstration-Based Applicability

The third evaluation perspective concerns applicability in the UPT demonstration scenario. The demonstration uses public or high-level institutional elements: the Microsoft 365/Active Directory-based identity layer, PWM-based password self-service at password.upt.ro, the digital education platform cv.upt.ro, student and academic-record services such as student.upt.ro and catalog.upt.ro, administrative services, and research and laboratory infrastructure associated with technical academic units such as the Faculty of Automation and Computers and the Faculty of Electronics, Telecommunications and Information Technologies.

The evaluation does not require detailed internal network diagrams, tenant configuration, privileged role names, policy identifiers, server locations, or security-sensitive integration details. Instead, it verifies whether the proposed framework can organize known public service domains into a coherent cybersecurity-governance model. Figure 3 supports this evaluation by showing the high-level relationship between institutional users, identity and access management, representative service domains, evidence collection, and control concerns.

The demonstration indicates that the framework is applicable to at least four different classes of university services with distinct control profiles: identity and access management (a structural dependency for most services), digital education platforms (availability, authenticated access, backup, incident response), student and administrative services (integrity, confidentiality, traceability), and research and laboratory infrastructures (risk-based flexibility with preserved security boundaries). This confirms the need for a domain-sensitive layered framework: a single generic baseline would be too weak for administrative records or too restrictive for experimental laboratories.

9.4. Indicative Maturity Evaluation

The fourth perspective on evaluation concerns the assessment of maturity. The maturity model introduced in Section 7.1 is used to assess implementation domains separately, rather than to produce a single global score for the institution. This is necessary because higher education institutions are heterogeneous. Mature controls may exist for central identity and digital education, while laboratory environments, supplier governance, or evidence management may be less formalized.

The indicative maturity values assigned within the UPT demonstration scenario are presented in Table 6 in Section 8 and are not repeated here.

The indicative maturity evaluation supports phased ISMS scoping: a realistic first scope may include identity and access management, digital education, and selected student or administrative services, while research and laboratory infrastructures can be integrated through later, risk-based phases.

9.5. Traceability-Based Evaluation

The final evaluation perspective concerns evidence. For NIS2 and ISO/IEC 27001:2022 implementation, the ability to produce evidence is as important as the existence of written policies. In the proposed framework, evidence is treated as an operational layer that connects governance, risk management, control implementation, incident handling, supplier management, and continuous improvement.

For the UPT demonstration scenario, the evidence layer includes several categories: identity and access evidence, digital education evidence, administrative-service evidence, research-infrastructure evidence, supplier evidence, incident evidence, and management-review evidence. The evidence column of the traceability matrix in Table 5 provides the corresponding illustrative evidence structure for each framework component.

The indicative maturity profile in Table 6 complements this evidence structure: the values are interpreted as a worked example showing how the framework can expose relative strengths and weaknesses across governance, risk management, incident handling, continuity, supplier management, monitoring, and improvement, once institution-specific data become available.

This traceability-oriented evaluation strengthens the practical contribution of the framework. It shows how the proposed model can move from abstract compliance to auditable implementation. It also makes explicit that NIS2-oriented readiness cannot be assessed only through policy existence. Readiness requires traceable records showing that controls are assigned, implemented, reviewed, and improved.

9.6. Evaluation Summary

The evaluation supports four conclusions. First, the framework covers the implementation requirements derived from NIS2, ISO/IEC 27001:2022, and the higher education context. Second, the framework aligns with the ISMS logic of ISO/IEC 27001:2022 while preserving the sector-specific adaptations required by universities. Third, the UPT demonstration scenario shows that the framework can structure a real institutional context without exposing confidential operational details. Fourth, the maturity and evidence models provide practical mechanisms for phased implementation, internal assessment, audit preparation, and continuous improvement.

The evaluation also clarifies the limits of the present work: the UPT scenario is illustrative, and a formal institutional assessment would require internal policies, risk registers, incident records, and audit evidence (see Section 11). The demonstration is nevertheless sufficient for evaluating the framework as a design science artefact instantiable in a realistic higher education setting.

10. Discussion

The proposed framework and the UPT demonstration scenario support the central argument of the paper: NIS2 implementation in higher education institutions should not be approached as a narrow technical checklist or as a purely legal compliance exercise. Universities are distributed socio-technical systems in which identity management, digital education, student services, administrative workflows, research infrastructure, external platforms, and academic autonomy interact continuously. In such a context, cybersecurity governance requires a structured implementation model that can connect regulation, standards, institutional roles, technical controls, and auditable evidence.

A first discussion point concerns the role of ISO/IEC 27001:2022 as an implementation backbone. The analysis shows that the ISMS logic of ISO/IEC 27001:2022 is well suited to the operationalization of NIS2 because it provides mechanisms for scope definition, leadership, risk assessment, control selection, documented information, performance evaluation, and improvement. However, ISO/IEC 27001:2022 should not be interpreted as a direct substitute for legal analysis under NIS2 and national transposition laws. Rather, it provides the management-system structure through which NIS2-related cybersecurity obligations can be implemented, documented, reviewed, and improved.

A second discussion point concerns scoping. For a higher education institution, whole-institution implementation may be conceptually attractive but operationally difficult. The UPT scenario illustrates why a phased ISMS scope is more realistic. Central identity and access management, digital education platforms, and selected student or administrative services form a natural initial scope because they are institutionally visible, shared across user groups, and directly connected to teaching and administrative continuity. Research and laboratory environments should be included progressively, using risk-based categorization, documented exceptions, compensating controls, and periodic review. This avoids both extremes: excluding laboratories from governance altogether, or applying enterprise-style controls in a way that would obstruct teaching and research.

A third discussion point concerns identity and access management. The UPT scenario illustrates a typical university dependency pattern: identity services are a control dependency for most digital services, so account compromise or weak privileged access can propagate to digital education, student services, administrative systems, and research collaboration. Identity should therefore be treated as a priority domain in both NIS2 readiness and ISO/IEC 27001:2022 implementation.

A fourth discussion point concerns the evidence layer, the mechanism through which governance becomes auditable: policies have limited value if the institution cannot show that controls are assigned, implemented, reviewed, and improved. Organizing evidence by service domain is particularly relevant for universities because documentation is often distributed across central administration, IT departments, faculties, research groups, and external providers.

A fifth discussion point concerns academic compatibility, deliberately treated as a cross-cutting design constraint rather than a separate layer. Universities must preserve teaching flexibility, research autonomy, collaboration, and experimentation, but these values cannot justify uncontrolled exposure or unclear risk ownership. The proposed approach makes academic compatibility explicit: exceptions documented, risk owners identified, compensating controls defined, and high-risk environments differentiated from low-risk teaching environments.

The UPT demonstration also highlights the importance of domain-oriented maturity assessment. A single institutional maturity score would be misleading. A university may have relatively mature identity services and digital education platforms, while supplier governance, laboratory segmentation, or evidence management remain less formalized. The maturity model is therefore most useful when applied per domain. This allows management to prioritize investment and governance effort without implying that all parts of the university must progress at the same pace.

From a practical implementation perspective, the framework suggests a staged roadmap: (1) governance, scope, and initial risk assessment; (2) identity, incident response, backup, and digital education continuity; (3) supplier and cloud-risk management; (4) research and laboratory infrastructure through risk-based profiles; and (5) institutionalized evidence collection, audit, and continuous improvement. This sequence is compatible with ISO/IEC 27001:2022 implementation and supports NIS2-oriented readiness.

Finally, the paper connects strands often treated separately: NIS2 compliance, ISO/IEC 27001:2022 implementation, higher education cybersecurity, and traceability-based auditability. The framework does not replace legal interpretation or institutional risk assessment; it provides a structured artefact that universities can adapt when moving from fragmented practices toward a defensible, auditable governance model.

11. Limitations

The study has several limitations. The first limitation concerns the legal scope of NIS2. Since NIS2 is a directive, its practical applicability depends on national transposition laws and national authority guidance. The framework proposed in this paper is designed to be compatible with the general NIS2 logic, but it should not be interpreted as a legal determination that a specific university, faculty, service, or infrastructure falls within a particular national NIS2 category. Each higher education institution must verify its status, obligations, and reporting channels under the applicable national legal framework.

The second limitation concerns the use of UPT as a demonstration scenario. The UPT case is used as an illustrative instantiation of the framework, not as a formal cybersecurity assessment, audit, or certification exercise. The demonstration relies on public or high-level information and on generic institutional knowledge provided by the authors. It intentionally avoids sensitive details such as internal network topology, tenant configuration, privileged role names, policy identifiers, server locations, vulnerability information, incident history, and security-control configuration. Consequently, the maturity values presented in the paper are indicative and should be validated through internal evidence review, interviews, technical assessment, and management approval before being used for institutional decision-making.

The third limitation concerns generalizability. UPT is a technical university with a specific institutional profile, digitalization history, faculty structure, and technical orientation. Other universities may differ significantly in size, legal status, governance model, IT centralization, outsourcing level, research intensity, cloud adoption, and available cybersecurity resources. The proposed framework is intended to be adaptable, but its implementation sequence, ISMS scope, maturity interpretation, and evidence repository structure should be tailored to the institutional context.

The fourth limitation concerns the mapping between NIS2 and ISO/IEC 27001:2022. The mapping proposed in the paper is interpretative and implementation-oriented. It identifies practical alignment between regulatory expectations and ISMS mechanisms, but it does not claim that ISO/IEC 27001:2022 certification automatically proves NIS2 compliance. NIS2 and ISO/IEC 27001:2022 operate at different levels: the former is a legal and regulatory instrument, while the latter is a management-system standard. Their relationship must therefore be mediated through scope definition, risk assessment, control selection, evidence, and national legal interpretation.

The fifth limitation concerns maturity assessment. The maturity model is designed as a practical assessment instrument, not as a statistically validated measurement scale. Its purpose is to support structured institutional discussion, prioritization, and phased implementation. Future work should validate the maturity model through expert panels, multi-institution case studies, inter-rater comparison, and empirical analysis of cybersecurity governance practices in universities.

The sixth limitation concerns evidence availability. A complete evaluation of the proposed framework would require access to internal artefacts such as risk registers, incident logs, access-review records, supplier contracts, backup-test results, internal audit reports, security policies, and management-review minutes. Since the present paper avoids confidential operational data, it evaluates the framework as a design science artefact rather than as a completed institutional implementation. This is appropriate for the current stage of research, but future work should include controlled institutional pilots.

A final limitation concerns the evolving regulatory and technical environment. NIS2 implementation guidance, national authority expectations, sector-specific cybersecurity practices, cloud-security architectures, and university digital infrastructures are all likely to evolve. The proposed framework should therefore be treated as a maintainable model. Its mappings, control expectations, evidence categories, and maturity criteria should be reviewed periodically.

12. Conclusions

This paper proposed a higher-education-specific framework for operationalizing NIS2 through ISO/IEC 27001:2022. The starting point was the observation that universities face a particular cybersecurity governance problem. They operate open academic networks, decentralized structures, student-facing digital services, research and laboratory infrastructures, cloud platforms, and heterogeneous user populations. At the same time, they must respond to increasingly formal cybersecurity governance, risk-management, incident-reporting, supplier-security, and evidence requirements.

The main contribution of the paper is a layered implementation framework that connects NIS2-oriented cybersecurity expectations with the ISMS logic of ISO/IEC 27001:2022. The framework includes governance, scope and service classification, risk management, control implementation, incident response and reporting, supplier and cloud-risk management, and evidence and audit. Academic compatibility is treated as a cross-cutting design constraint, because teaching, research autonomy, collaboration, and experimentation must be preserved while maintaining institutional cybersecurity accountability.

The paper also proposed a NIS2–ISO/IEC 27001:2022 mapping logic, a cybersecurity maturity model, and an evidence repository structure. These elements are intended to support practical implementation rather than only conceptual analysis. The maturity model allows universities to assess different domains separately, avoiding misleading global scores. The evidence model supports auditability by linking services, risks, controls, owners, review cycles, and documented proof of implementation.

The demonstration scenario applied the framework to Politehnica University Timisoara using public and high-level institutional elements, showing that the framework can organize a real university context without exposing confidential technical details, and that different university domains require different control profiles: identity services require strong lifecycle and privilege management; digital education requires availability and continuity; student and administrative services require integrity and traceability; research and laboratory infrastructure requires risk-based flexibility and documented exceptions.

The evaluation supported the usefulness of the framework from four perspectives: requirements coverage, ISO/IEC 27001:2022 alignment, demonstration-based applicability, and maturity/evidence assessment. The results suggest that ISO/IEC 27001:2022 can serve as a practical implementation backbone for NIS2 readiness in universities, provided that the ISMS scope, risk model, control selection, and evidence repository are adapted to the specific structure of higher education institutions.

For practitioners, the paper suggests a phased implementation path: begin with governance, service classification, identity, digital education, incident response, backup, and evidence collection; formalize supplier and cloud-risk management early; and incorporate research and laboratory environments progressively through risk-based profiles and documented exceptions.

For researchers, the paper opens several directions for future work. The proposed framework should be validated through expert review, multi-university case studies, and longitudinal implementation pilots. The maturity model should be refined through empirical assessment. The evidence repository could be developed into a structured tool or knowledge base that maps NIS2 obligations, ISO/IEC 27001:2022 controls, university service domains, risk scenarios, and audit artefacts. Comparative studies could also examine how universities in different EU Member States adapt their cybersecurity governance to national NIS2 transposition laws.

In conclusion, NIS2 implementation in higher education institutions requires more than technical hardening or policy writing. It requires institutional cybersecurity governance that is risk-based, traceability-driven, compatible with academic work, and continuously improved. ISO/IEC 27001:2022 provides a suitable management-system backbone for this task, but it must be adapted to the specific organizational and operational reality of universities. The framework proposed in this paper provides one such adaptation.