Security Compliance as a Catalyst for Sustainable Partnerships: A Design Science Approach for SMEs

Abstract

Small-and-medium-sized enterprises (SMEs) increasingly depend on business partnerships to access markets and scale operations, yet they often face trust barriers during contract formation due to the complexity of the verification of their cybersecurity posture and compliance status by their partners. This problem is intensified by rising regulatory expectations, notably the EU Cyber Resilience Act (CRA), which many SMEs struggle to interpret and operationalize under constraints of budget, skills, and fragmented responsibilities. This study adopts a Design Science Research approach to blueprint and evaluate a lightweight mapping framework that links commonly implemented security controls to CRA requirements and to widely recognized benchmarks (ISO/IEC 27001 and CIS). Grounded in Institutional Theory and Socio-Technical Systems Theory, the artefact translates regulatory obligations into actionable, evidence-backed controls and produces partner-facing outputs that support transparency in negotiations and service level agreements. The framework is iteratively co-created with a multidisciplinary expert community. Expected contributions include a practical mechanism for making cybersecurity maturity visible, accelerating partnership formation, and enabling sustainable interorganizational relationships while remaining feasible for resource-constrained SMEs.

1. Introduction

SMEs are cornerstones of local economic development as they play a central role in empowering regional economies and fostering social stability. SMEs contribute significantly to the reduction in the regional unemployment rate and collectively have an impact on the growth of the economy [1,2]. Amidst the past and current galloping cyber developments, the economic and security landscape is rapidly changing in the world and is especially felt in the SMEs bracket [2,3].

The increasing regulatory and compliance pressures (for example, CRA), expose, in a more overt way, their resource limitations (budget and skilled workforce), which greatly contribute to a weak security posture and maturity, ultimately creating barriers of trust and consequently leading to fewer contracts with possible partners [4,5].

Recent research by Hoong, Davis, and Windekilde [6] and Wilson [7] has established a solid foundation on the challenges faced by SMEs in everything regarding cybersecurity. Studies highlight that managers often perceive security as a burden due to cost, lack of skills, and uncertainty about value creation. Others explore how regulatory requirements, particularly the CRA, introduce new obligations that SMEs struggle to interpret and operationalize, amplifying the mismatch between limited resources and increasing compliance demands [4,5]. Proudfoot [8] observes, this misalignment frequently results in weak security postures and inconsistent maturity, which erodes trust and complicates the negotiation of contracts and service level agreements (SLAs).

In parallel, the literature shows that transparency in cybersecurity practices and disclosure can improve firm reputation, performance, and stakeholder trust [9]. Research on supply chain and interorganizational governance also demonstrates that trust, fairness, and transparency are critical enablers of collaboration and long-term partnerships [10,11]. However, these works remain largely conceptual or sector-specific, with limited direct focus on how SMEs can practically and credibly demonstrate their cybersecurity maturity in partnership negotiations.

The gap, therefore, lies in the absence of a lightweight, actionable framework that explicitly links SME security controls to regulatory requirements in a way that builds trust, reduces negotiation frictions, and supports the formation of sustainable partnerships. While prior studies recognize the importance of compliance, transparency, and trust, none directly test whether making security maturity visible can accelerate business agreements and strengthen SME competitiveness in partnership ecosystems. Although compliance mapping approaches and “control crosswalks” exist (e.g., mappings between ISO 27001 [12], NIST, CIS Controls, or regulatory requirements), these typically function as technical reference documents intended for auditors or compliance specialists. They focus primarily on equivalence between standards and do not incorporate a socio-technical layer that translates compliance maturity into partner-facing signals. In contrast, the novelty of the proposed framework lies in four elements: (i) the integration of regulatory control mapping with a simplified, SME-adapted structure; (ii) the inclusion of a socio-technical layer that connects security controls to trust-building mechanisms; (iii) the generation of partner-facing outputs designed to support negotiation and due-diligence conversations; and (iv) an incremental scoring logic that allows SMEs to communicate progressive maturity rather than binary compliance. Additionally, the framework explicitly incorporates CRA-aligned requirements, positioning it within emerging EU regulatory dynamics while maintaining cross-standard compatibility.

The purpose of this study is to design and evaluate a lightweight mapping framework that connects commonly implemented security controls with regulatory requirements such as the CRA, ISO 27001, and CIS. Significantly, this study treats the CRA not merely as a generic compliance reference, but as a regulatory anchor specifically relevant to SMEs that develop, integrate, distribute, or significantly modify products with digital elements (PDEs)—including software vendors, SaaS providers, IoT device manufacturers, embedded system developers, and technology integrators operating within EU markets. These SMEs are directly exposed to CRA obligations related to secure development practices, vulnerability handling, documentation, conformity assessment, and supply-chain transparency.

While the CRA is product-focused, its requirements have strong organizational implications. To comply, SMEs must implement structured internal processes—such as risk management, incident reporting, secure development lifecycle controls, and third-party component governance. These internal capabilities inherently signal cybersecurity maturity. Therefore, even though the CRA regulates products, compliance necessarily reflects the maturity of the producing organization.

The framework proposed in this study leverages this intersection: it translates CRA-aligned controls into an interpretable maturity map that also aligns with ISO 27001 and CIS Controls. By doing so, it enables SMEs to make their security posture visible in a structured and credible manner during partnership negotiations. In supply-chain ecosystems, prime contractors and enterprise clients increasingly require evidence of regulatory alignment and secure-by-design practices. For technology-producing SMEs, demonstrating mapped compliance reduces information asymmetry and strengthens trust formation.

Although general service SMEs may not fall directly under CRA product obligations, the framework remains adaptable to digitally intensive service providers that embed third-party software, manage connected platforms, or operate within regulated supply chains. In these contexts, CRA-aligned practices function as a transparency mechanism, even when not legally mandatory. Thus, this study explicitly targets technology-oriented SMEs subject to or indirectly influenced by CRA requirements and positions regulatory alignment as a strategic instrument for partnership transparency.

2. Literature Review

2.1. Review Scope and Conceptual Foundation

2.1.1. Resource-Based View (RBV)

An organization’s competitiveness hinges on how effectively it configures, integrates, and deploys its internal resources across technological, human, and governance domains. When these resources and capabilities are valuable, well-organized, and mobilized coherently, they can be converted into sustained competitive advantage over market rivals, consistent with the Resource-Based View [13].

In the context of SMEs, cybersecurity capability, encompassing technical infrastructure, human expertise, and governance routines, constitutes a strategic resource that directly shapes competitiveness, trust, and partnership potential. According to the Resource-Based View (RBV), organizations gain a sustainable advantage when their internal resources are valuable, rare, inimitable, and non-substitutable (VRIN), and when they are effectively organized and deployed [13,14]. Within the information systems domain, scholars have consistently shown that IT-related resources, such as security processes and knowledge, become sources of advantage when they are properly aligned with organizational goals and integrated into management practices [15,16].

Building on this theoretical foundation, cybersecurity capabilities in SMEs can be viewed as organizational assets that not only protect operations but also act as enablers of external legitimacy and trust [17]. However, due to limited financial and human resources, these capabilities often remain under-leveraged, unstructured, undocumented, and invisible to potential partners [18]. The RBV suggests that unless SMEs can organize and communicate their cybersecurity maturity, the strategic potential of these resources remains unrealized. Consequently, the mapping framework developed in this study serves as a resource-leveraging mechanism, transforming latent internal capabilities into visible, auditable signals that reinforce credibility, facilitate negotiation, and strengthen partnership formation [19].

RBV explains why cybersecurity compliance can create competitive advantage. It shifts from protection logic to value-creation logic. Compliance is no longer treated as cost-centered, but it becomes a strategic asset that enhances negotiation power and partnership eligibility.

2.1.2. Dynamic Capabilities Theory (DCT)

An organization’s long-term competitiveness depends on its ability to adapt, integrate, and reconfigure internal and external resources in response to continuous environmental and technological changes. The Dynamic Capabilities Theory (DCT) posits that, beyond simply possessing valuable resources, firms must develop adaptive and transformative capacities that allow them to sense opportunities and threats, seize them effectively, and reconfigure their resources to maintain strategic alignment and competitiveness [20].

In the context of SMEs, cybersecurity maturity can be conceptualized as a dynamic capability that evolves over time as organizations improve their ability to detect risks, respond to incidents, and comply with regulatory requirements, such as the CRA. Dynamic capabilities emerge from the interaction between technological tools, managerial processes, and learning mechanisms that enable firms to respond to changing security landscapes [21]. However, SMEs typically operate under significant resource constraints, with limited budgets and technical expertise, which inhibits their capacity to continuously adapt and mature their cybersecurity posture [18].

Building on this theoretical perspective, dynamic capabilities in SMEs are not limited to reactive threat mitigation but extend to organizational learning and strategic adaptation, developing routines and mechanisms to align internal practices with evolving compliance obligations and partner expectations. The artefact proposed in this study, the mapping framework, acts as an enabler of dynamic capability, supporting SMEs in identifying compliance gaps, translating regulatory requirements into actionable security controls, and systematically improving over time. By formalizing adaptive learning and knowledge reuse, the framework helps SMEs institutionalize change, transforming compliance activities into sustainable capabilities that foster trust, resilience, and partnership readiness [20,21].

DCT explains how SMEs sustain compliance over time in evolving regulatory and threat environments. Compliance is framed as a dynamic capability, not a static checklist. Accordingly, compliance is reconceptualized as an ongoing adaptive learning process, rather than episodic regulatory alignment.

2.1.3. Institutional Theory

Organizational practices are shaped not only by efficiency-driven motivations but also by the need to gain legitimacy, stability, and acceptance within broader institutional environments. According to Institutional Theory, organizations conform to prevailing rules, norms, and expectations to appear credible and trustworthy to key stakeholders such as regulators, clients, and partners [22,23]. These pressures can be coercive, arising from legal and regulatory obligations, normative, stemming from professional standards and best practices, or mimetic, emerging when organizations imitate the actions of perceived leaders to reduce uncertainty. Compliance, therefore, becomes not merely a technical process but a social and legitimacy-seeking behavior that reinforces an organization’s standing in its institutional field.

In the case of SMEs, the CRA operates as a coercive institutional force, compelling organizations to adopt standardized cybersecurity controls and reporting structures to align with European regulatory expectations. Simultaneously, normative pressures from industry associations, clients, and auditors encourage SMEs to demonstrate compliance readiness and proactive risk management as part of responsible business conduct [24]. However, SMEs often face significant challenges in operationalizing such institutional requirements due to limited expertise, fragmented governance structures, and resource scarcity [18]. As a result, compliance efforts may remain largely symbolic, driven by the need to appear legitimate rather than by genuine security integration [22].

The mapping framework developed in this study directly addresses this institutional challenge by providing a practical translation mechanism that connects CRA requirements with concrete, auditable security controls. Through structured mappings and partner-facing outputs, SMEs can demonstrate conformity to institutional expectations while making their compliance efforts transparent and verifiable. In this sense, the artefact functions as a legitimacy mechanism, enabling SMEs to move from symbolic compliance to substantive alignment, not only satisfying regulatory demands but also strengthening their perceived reliability and trustworthiness in partnership networks [23].

Institutional Theory explains why SMEs adopt compliance practices beyond efficiency concerns. The framework acts as a translation mechanism converting institutional pressure into actionable control structures. It moves the discussion from “compliance as legitimacy theatre” to substantive compliance operationalization.

2.1.4. Signaling Theory

Signaling Theory [25] addresses how parties in environments characterized by information asymmetry communicate credible information to reduce uncertainty and build trust. When one party (the signaler) possesses private information about its quality or capability that the other (the receiver) cannot directly observe, the signaler can convey such information through observable and costly signals. These signals must be credible, that is, difficult or costly to imitate by those lacking the claimed quality, so that they meaningfully differentiate between both high and low-quality actors [26].

In interorganizational and B2B contexts, information asymmetry is a central barrier to trust formation, particularly in cybersecurity. Potential partners often lack direct visibility into one another’s internal security controls, risk management practices, and regulatory compliance. This opacity generates uncertainty and perceived risk, especially when dealing with SMEs, which are frequently assumed to have weaker cybersecurity postures due to limited resources and maturity.

Within this environment, security compliance and maturity evidence can function as credible signals. By systematically linking their implemented controls to recognized regulatory frameworks, such as the CRA, ISO 27001, or CIS benchmarks, SMEs can demonstrate competence and reliability in a verifiable and standardized manner. These disclosures act as signals of trustworthiness and resilience, enabling potential partners to assess risk more accurately and engage in partnerships with greater confidence.

The proposed mapping framework in this study thus operates as a signaling mechanism: it translates complex internal security practices into externally understandable and credible indicators of cybersecurity capability. By reducing uncertainty and perceived risk, these signals facilitate smoother contract negotiations, enhance reputational legitimacy, and promote sustainable interorganizational partnerships. Moreover, the framework’s “lightweight” nature ensures that signaling remains feasible for SMEs despite their resource constraints, an essential factor for practical adoption and long-term relevance.

Signaling Theory explains how compliance reduces information asymmetry in B2B contexts. Furthermore, compliance artefacts are reframed as market signals, not internal administrative records.

2.1.5. Trust and Relational Governance Theory

Trust and Relational Governance Theory explains how trust-based relationships function as alternative or complementary governance mechanisms to formal contracts in interorganizational exchanges. In environments characterized by uncertainty or information asymmetry, trust reduces transaction costs, encourages cooperation, and promotes stability in long-term partnerships [27,28]. Relational governance relies on shared norms, mutual expectations, and goodwill rather than strict contractual enforcement, fostering adaptability and collaboration across organizational boundaries [29,30].

SMEs often rely on relational rather than contractual governance due to their limited resources, lower bargaining power, and the frequently informal nature of their business networks. In such contexts, trust becomes a central mechanism for managing partnerships and mitigating risk. However, trust in digital collaboration, particularly where sensitive data or shared infrastructure is involved, depends increasingly on visible demonstrations of cybersecurity maturity.

By systematically linking implemented security controls to recognized standards and regulatory frameworks, SMEs can provide tangible evidence of their reliability and integrity. This demonstration of cybersecurity capability strengthens both cognitive trust (belief in the partner’s competence) and calculative trust (confidence based on predictability and reduced risk).

Within this framework, the proposed mapping artefact operates as a trust-enabling mechanism. It helps SMEs communicate their compliance posture in transparent, verifiable terms, reducing negotiation friction and reinforcing long-term collaboration. In doing so, it supports relational governance dynamics, where transparency, shared understanding, and confidence replace excessive contractual complexity. Ultimately, such trust-centered governance contributes to sustainable partnerships, improving resilience, cooperation, and mutual value creation within SME ecosystems.

This theory explains how visible compliance strengthens interorganizational cooperation. Compliance becomes a trust infrastructure, reducing negotiation friction and contractual complexity.

2.1.6. Socio-Technical Systems Theory

The Socio-Technical Systems (STS) Theory emphasizes that organizational performance and resilience depend on the effective integration of social and technical subsystems [31,32]. It posits that technology and human behavior are interdependent: technical measures can only succeed when aligned with the organizational culture, values, and practices that shape user behavior. Therefore, sustainable cybersecurity outcomes arise not solely from technological enforcement but from the joint optimization of people, processes, and technology.

In the context of SMEs, cybersecurity challenges often stem as much from human and organizational factors as from technical deficiencies. Even when employees are aware of good practices, such as using strong passwords or avoiding phishing emails, noncompliance persists without appropriate technical and organizational reinforcements. This is comparable to the logic of traffic systems, although drivers understand they should stop at crosswalks or remain in their lane, the presence of traffic lights and road markings provides the structural and visual cues that ensure predictable, collective compliance.

Similarly, in cybersecurity, technical controls such as mandatory training, spam filters, password complexity requirements, session timeouts, and port restrictions act as “digital traffic rules”; they embed secure behavior into everyday operations. These measures do not replace awareness but complement it, reinforcing a culture of compliance and minimizing reliance on individual discretion.

Within this study, the proposed mapping framework operationalizes this socio-technical balance by connecting technical controls (e.g., CIS benchmarks, ISO 27001 measures) with organizational compliance processes and the broader regulatory context of the CRA. By doing so, it helps SMEs develop both the technological foundations and the organizational culture necessary to sustain security maturity. This dual focus ensures that compliance is not perceived merely as a checklist obligation but as an embedded, systemic practice that aligns technical enforcement with human accountability.

The STS Theory explains why compliance fails when treated as purely technical. Compliance is reframed as a systemic socio-technical alignment challenge, not just control implementation.

2.2. Cybersecurity Challenges in SMEs: Constraints and Regulatory Pressures

When it comes to cybersecurity-related requirements, it is widely documented that SMEs struggle to meet those standards for several but commonly shared reasons.

When analyzing a company’s resources (either workforce related or its financial capabilities), SMEs usually lack adequate means to invest in their security posture, leading to practical constraints, limited knowledge for managing their complex cyber and physical environments, lack of awareness, and inadequate translation of directives [33,34]. Even if these institutions are well-intended and make efforts to comply with security requirements because they are obliged to follow directives of economic groups, such as the CRA within Europe, it is evident that they cannot reach the expected quality status and maturity, being the end result not aligned or satisfactory when compared with “what it should have” [35]. Shaffique [24] critically examines the CRA’s impact on IoT cybersecurity and concludes that CRA imposes complex and ambiguous requirements due to increasing compliance needs and imposing the need for clear mapping mechanisms between technical controls and legal obligations.

2.3. Transparency, Trust, and Partnership Formation

When a new service contract or economic relationship is established between two entities, it is assumed that both parties have previously reached an agreement on several fundamental aspects, including, but not limited to, security requirements, business continuity provisions, and technological maturity expectations. These elements are formally embedded within the contract and are therefore legally binding. Each party is obliged to adhere to the agreed obligations to maintain contractual validity and avoid potential legal consequences, including penalties and financial sanctions.

Elsayed, Ismail, and Ahmed [36] demonstrate that when banks make efforts to reinforce the transparency of their security structure, those efforts revert to an improvement on the conveying of results and legitimacy towards stakeholders. Nugraha and Martin [37] also demonstrate that explicit requirements and clauses in the state-of-the-art sections of security SLAs make expectations verifiable and negotiable, contributing to the reduction in uncertainty and contractual friction. Aligned with the topic previously mentioned, Wallis and Dorey [38] suggest that those practical principles of partnership and co-responsibility in the cybersecurity blockchain improve the sustainability of shared patterns and the transparency obtained by them promotes cooperation.

Narrowing the scope by focusing on the reality of SMEs, it is shown in the literature that these institutions are visibly hindered by awareness, budget, and size. These are core determinants of low security maturity in high-demand regulatory contexts, interfering with interfering in the commercial relations of these institutions [39]. SMEs managers also play a role in the instability lived in these environments, due to extrapolating fear when it comes to their grip of the security domains, allied with associated costs and barriers, allowing these internal factors to negatively affect the company’s security postures and promoting information concealing in negotiations [40]. Bai et al. [10] also argue that relational governance mechanisms (trust, contracts, social norms, etc.) interfere in the collaborative innovation performance between partners and affect the collaborative innovation process performance between partner companies.

2.4. Identified Gap and Design Principles

The reviewed literature highlights that SMEs consistently face structural constraints in developing and maintaining cybersecurity maturity, largely due to limited financial and human resources, fragmented expertise, and difficulties in interpreting and operationalizing regulatory instruments such as the CRA [24,33,35]. These constraints frequently result in inconsistent or underdeveloped security postures, which in turn create uncertainty and mistrust in partnership negotiations, particularly when sensitive systems or data sharing are involved [34,41]. At the same time, research demonstrates that transparency, structured disclosure, and clearly articulated security expectations contribute to stronger trust formation and more sustainable collaboration, especially where relationships depend on shared technological infrastructures and contractual SLAs [36,37,38].

Despite these converging findings, existing studies remain limited in providing SMEs with practical mechanisms to demonstrate cybersecurity maturity in clear, credible, and partner-facing ways. Prior work often focuses either on the internal improvement of cybersecurity capabilities or on theoretical governance models, without addressing the practical challenge of how SMEs can externally communicate their compliance posture to reduce uncertainty and negotiation friction. Hence, the literature reveals a clear gap: the absence of a lightweight, actionable framework that maps SME security controls to CRA compliance requirements in a format that is understandable, verifiable, and usable during partnership negotiation processes.

To address this gap, the present study derives the Design Principles presented in

Table 1. Design principles for the proposed mapping framework.

DP1—Legitimacy Alignment	The artefact must explicitly translate CRA regulatory expectations into concrete, auditable security controls to support institutional legitimacy
DP2—Socio-Technical Integration	The artefact must balance technical measures with organizational processes and responsibilities, ensuring that cybersecurity is institutionalized across people, processes, and technology
DP3—Lightweight and Resource-Conscious	The artefact must be feasible for SMEs to adopt and maintain, requiring minimal overhead and avoiding dependence on high-cost expertise
DP4—Partner-Facing Transparency	The artefact must produce outputs that can be used in contract negotiation contexts, enabling SMEs to credibly signal their cybersecurity maturity to external stakeholders
DP5—Gradual Maturity Development	The artefact must allow incremental development rather than imposing rigid maturity thresholds, thereby supporting sustainable security growth

, grounded in Institutional Theory and Socio-Technical Systems Theory:

These principles guide the design, implementation, and evaluation of the mapping framework that will be developed in the following methodology and artefact sections.

3. Methodology

To initiate the creation of the design community, specific attention was given to ensuring diversity of educational backgrounds and professional experience, as recommended in the Design Science Research (DSR) methodology. The community was designed to combine technical, analytical, and organizational perspectives relevant to the artefact’s goal, a lightweight framework connecting the CRA requirements to security controls applicable to SMEs. The sampling strategy followed a purposeful and competence-based selection logic, consistent with DSR principles. Rather than aiming for statistical representativeness, participants were selected to ensure functional diversity aligned with the artefact’s objectives. The goal was to assemble a small but complementary design community capable of critically evaluating regulatory interpretation, technical feasibility, operational implementation, and measurable compliance structuring.

The design community consists of five participants selected for complementary technical and compliance expertise, as shown in

Table 2. Summary of participant characteristics and expertise.

Participant	Academic Background	Professional Experience	Area of Expertise	Contribution to the Artifact
A	Bachelor’s in Artificial Intelligence and Data Science	3 years in data analysis and management	Data analytics, metrics, performance indicators	Definition of measurable indicators and quantification of compliance and maturity metrics
B	Bachelor’s in Computer Engineering	5 years in software development and systems integration	Software engineering, systems architecture	Ensuring technical feasibility and applicability in software-based implementation contexts
C	Bachelor’s in Computer Engineering; Postgraduate Diploma in Cybersecurity	2 years in compliance and cyber risk management in international enterprises	Regulatory compliance, security auditing, cyber risk management	Interpretation of CRA requirements and consistency of mappings with compliance frameworks
D	Bachelor’s in Computer Engineering; two Postgraduate Diplomas in Cybersecurity	1 year in networking, IoT, and electronic security systems (CCTV, access control)	Network security, IoT security, physical security systems	Integration of physical and logical security controls within the socio-technical design
E	Professional High School Diploma in Informatics and Programing	Experience in SME-focused system administration, vulnerability management, IAM, infrastructure hardening, and incident response	Operational cybersecurity, asset management, cyber risk management	Validation of technical realism, asset visibility, and feasibility of CRA-aligned controls in resource-constrained environments

. Participant A contributes data analytics capabilities, supporting measurable indicators, and the quantification of compliance metrics. Participant B brings software development and systems integration experience, ensuring technical feasibility in implementation environments. Participant C provides regulatory and auditing insight, strengthening the accurate interpretation and structured mapping of CRA requirements to recognized compliance frameworks. Participant D adds networking, IoT, and electronic security knowledge, reinforcing the integration of physical and logical security within the socio-technical model. Participant E contributes hands-on operational cybersecurity experience, including system administration, vulnerability management, infrastructure hardening, and identity and access control in SME contexts. Collectively, the group ensures that the artefact is analytically grounded, technically realistic, regulatory-consistent, and practically implementable within resource-constrained SME environments.

3.1. Research Design

This study adopts DSR as its formal methodological approach, as shown in Figure 1. The primary objective is not only to analyze a phenomenon but to design, construct, and rigorously evaluate a purposeful artefact that addresses a clearly identified real-world problem. DSR is particularly suitable in this context because it provides a structured, iterative process for artefact development, combining theoretical grounding with practical relevance. The methodology includes distinct phases of problem identification, artefact design, demonstration, and evaluation, ensuring both conceptual robustness and operational applicability.

Specifically, this research seeks to develop a lightweight mapping framework that enables SMEs to translate regulatory cybersecurity requirements (most notably those arising from the CRA) into more concrete, operational, and communicable security practices. The design phase involved a systematic derivation of framework components from regulatory standards, expert knowledge, and SME operational realities. Artefact construction followed a modular approach to allow flexibility, traceability, and incremental maturity scoring. Furthermore, the evaluation phase was structured as a formative, expert-based assessment, incorporating structured interview prompts, scenario-based walkthroughs, and predefined evaluation criteria such as utility, usability, completeness, and internal consistency. Feedback was analyzed using a thematic coding approach to identify strengths, limitations, and areas for refinement.

DSR is also particularly suitable in this context because SMEs face a practice-oriented problem, because although regulatory expectations are increasingly explicit, there is a persistent gap between legal requirements and their practical implementation and communication [42,43]. Traditional empirical or purely explanatory research methods would be insufficient to bridge this gap, as they do not directly support the creation of actionable solutions. In contrast, DSR provides a rigorous structure for iteratively designing an artefact, grounding it in theory, and evaluating its utility and relevance in realistic settings.

In this study, the evaluation reflects an early-stage DSR approach. The expert community consisted of five participants with relevant expertise in cybersecurity compliance and SME contexts. While limited in size, this configuration is consistent with formative evaluation phases aimed at assessing conceptual soundness and practical relevance rather than producing statistically generalizable results. Furthermore, the evaluation relied on a structured discussion of hypothetical and anonymized scenarios to simulate realistic SME compliance situations. Accordingly, the claims of this paper are limited to demonstrating preliminary utility, clarity, and conceptual robustness of the proposed framework.

To enhance evaluation transparency, the study documents the interview prompts and workshop protocol used to guide expert interaction with the artefact. Participants engaged in scenario-based walkthroughs, followed by guided reflection questions focused on applicability, interpretability, and completeness. Expert feedback was systematically analyzed using a structured qualitative approach, grouping observations into thematic categories aligned with predefined evaluation criteria. These criteria included perceived utility (relevance for SME compliance practice), usability (clarity and ease of application), completeness (coverage of regulatory and control mappings), and internal consistency (logical coherence of the framework structure). The explicit articulation of these criteria provides a transparent basis for interpreting the results and delimiting the scope of contribution.

The research design is explicitly anchored in an integrated theoretical approach combining Institutional Theory and socio-technical compliance perspectives, with Institutional Theory serving as the primary lens guiding the rationale for the artefact. Institutional Theory explains why the artefact is needed: SMEs are subject to coercive institutional pressures imposed by regulations such as the CRA and must demonstrate compliance and legitimacy to regulators, clients, and partners. The socio-technical perspective complements this by informing the internal structure of the artefact, highlighting how technical controls, organizational responsibilities, and evidentiary mechanisms interact to operationalize compliance in practice. SMEs’ cybersecurity maturity often remains opaque to external stakeholders, limiting trust and hindering partnership formation. By integrating these perspectives, the artefact functions as a legitimacy-enabling mechanism that translates institutional demands into visible and verifiable signals while ensuring that practical technical and organizational considerations are embedded in its design.

At the same time, STS Theory explains how the artefact must function to be effective. Cybersecurity compliance is not achieved solely through technical controls, but through the alignment of technologies, organizational processes, and human responsibilities. The research design requires that the artefact jointly address technical controls (e.g., CIS benchmarks, ISO/IEC 27001 measures) and organizational dimensions (e.g., roles, responsibilities, procedures, and evidence practices), ensuring that compliance is both operationally feasible and socially embedded within SMEs.

Although additional theories were discussed in the broader research background, they are not adopted as primary design lenses for specific reasons. The RBV and DCT focus primarily on competitive advantage and adaptive capability development. While these perspectives are valuable for interpreting potential performance implications of cybersecurity maturity, they do not directly explain the legitimacy-driven pressures that motivate compliance artefact development in regulated environments. The central problem addressed in this study is not how SMEs create sustained competitive advantage, but how they respond to institutionalized regulatory demands in a credible and structured manner. Therefore, RBV and DCT are conceptually informative but not foundational to the artefact’s design rationale. Similarly, Signalling Theory and Trust or Relational Governance Theory concentrate on interorganizational information asymmetry and trust formation. These perspectives help explain how visible compliance outputs may reduce uncertainty and facilitate partnerships. However, they primarily address the relational consequences of compliance rather than the institutional drivers that necessitate its formalization. The present research problem originates in regulatory coercion and institutional legitimacy requirements, not solely in bilateral trust deficits. For this reason, Signaling and Trust theories are positioned as interpretative extensions rather than core design foundations.

Following the DSR paradigm, this study proceeds through iterative cycles of problem diagnosis, artefact design, demonstration, and evaluation. The artefact is co-developed with a multidisciplinary expert community to ensure relevance, feasibility, and theoretical consistency. This research design thus provides a systematic and theory-informed pathway to bridge regulatory legitimacy requirements with socio-technical implementation realities, fulfilling both academic rigor and practical impact.

3.2. Problem Diagnosis and Objectives of a Solution

The problem addressed in this study emerges from the intersection of increasing regulatory pressure and persistent structural limitations within SMEs. From an Institutional Theory perspective, SMEs are subject to growing coercive pressures imposed by regulatory instruments such as the CRA, which require organizations to demonstrate adequate cybersecurity governance, risk management, and technical safeguards. Compliance with these requirements is no longer optional, as failure to do so may result in legal sanctions, reputational damage, and exclusion from business partnerships. However, while the regulatory expectations are increasingly explicit, SMEs often lack effective mechanisms to translate these institutional demands into demonstrable and credible compliance evidence.

In practice, this institutional pressure is compounded by socio-technical misalignment. From an STS Theory standpoint, SMEs typically exhibit fragmented cybersecurity practices, where technical controls, organizational processes, and human responsibilities are weakly integrated. Security measures may exist in isolation, such as firewall configurations, access control rules, or ad hoc policies, but are rarely structured into coherent governance routines that align with regulatory requirements. As a result, cybersecurity maturity remains inconsistent, poorly documented, and difficult to communicate externally. This misalignment undermines both internal control effectiveness and external trust, particularly during contract negotiations, audits, or partnership assessments.

The diagnosis identifies a dual problem. First, SMEs struggle to operationalize CRA requirements internally due to limited resources, lack of regulatory interpretation capability, and insufficient alignment between technical and organizational elements. Second, even when security measures are partially implemented, SMEs lack legitimate, auditable, and partner-facing mechanisms to signal their cybersecurity maturity and compliance posture. This creates uncertainty for external stakeholders and acts as a barrier to sustainable business relationships.

In response to this problem, the primary objective of the proposed solution is to design a lightweight mapping framework that systematically connects CRA regulatory requirements with commonly implemented security controls relevant to SMEs. The framework aims to translate abstract legal obligations into concrete, actionable, and verifiable practices that reflect both technical enforcement and organizational responsibility. A further objective is to ensure that this mapping supports socio-technical integration by explicitly linking controls to roles, processes, systems, and evidence artefacts.

Finally, the solution seeks to produce structured outputs that function as legitimacy and trust signals. These outputs are intended to be usable in external contexts, such as partnership negotiations, SLA discussions, and due-diligence processes, thereby reducing uncertainty, lowering negotiation friction, and supporting sustainable collaboration. Collectively, these objectives guide the subsequent design principles and artefact development stages of the DSR process.

3.3. Design Principles

The design principles guiding the development of the proposed artefact are derived directly from the problem diagnosis and are theoretically grounded in Institutional Theory and Socio-Technical Systems Theory. Within the DSR paradigm, design principles serve as normative guidelines that translate abstract theoretical insights into concrete requirements for artefact construction. In this study, the principles ensure that the resulting framework is not only theoretically sound but also practically applicable within the constrained environments typical of SMEs.

3.3.1. DP1—Institutional Alignment and Regulatory Traceability

Grounded in Institutional Theory, the first principle requires that the artefact explicitly translates CRA regulatory requirements into actionable and auditable security controls. SMEs face coercive institutional pressure to comply, yet regulatory texts are often abstract and difficult to operationalize. The framework must therefore maintain clear traceability between CRA articles, derived control objectives, and concrete security practices. This traceability supports institutional legitimacy by enabling SMEs to demonstrate conformity with regulatory expectations in a transparent and verifiable manner.

3.3.2. DP2—Socio-Technical Integration

Drawing on STS Theory, the artefact must integrate technical controls with organizational processes and human responsibilities. Cybersecurity maturity cannot be achieved through technology alone; it depends on the alignment of people, processes, and systems. Accordingly, each mapped control must reflect not only its technical implementation but also the associated organizational roles, procedures, and accountability structures. This principle ensures that compliance is embedded into daily operations rather than remaining a purely symbolic or documentation-driven exercise.

3.3.3. DP3—Lightweight and Resource-Conscious Design

Given the financial and human resource constraints faced by SMEs, the artefact must be lightweight, accessible, and feasible to adopt without specialized expertise or significant overhead. This principle emphasizes simplicity in structure, limited data requirements, and reuse of existing controls and documentation wherever possible. By minimizing complexity, the framework increases adoption likelihood and reduces the risk of compliance fatigue.

3.3.4. DP4—Partner-Facing Transparency and Evidence Generation

To address trust deficits in interorganizational contexts, the artefact must generate outputs that are suitable for external communication. These outputs should clearly summarize cybersecurity maturity, implemented controls, and supporting evidence in a format understandable to partners, auditors, and clients. This principle operationalizes legitimacy signaling by transforming internal security practices into credible, partner-facing artefacts that reduce information asymmetry during negotiations and contractual assessments.

3.3.5. DP5—Incremental Maturity and Continuous Improvement

Finally, the framework must support gradual improvement rather than imposing rigid maturity thresholds. SMEs vary significantly in size, sector, and risk exposure. Therefore, compliance and maturity should be achievable incrementally. This principle aligns with STS learning mechanisms by enabling organizations to progressively refine controls, update evidence, and internalize compliant behavior over time, fostering sustainable cybersecurity development.

Together, these design principles provide a coherent blueprint for the artefact’s architecture and functionality. They ensure an alignment with institutional expectations, reinforce socio-technical balance, and directly address the operational realities of SMEs, guiding the subsequent stages of artefact instantiation, demonstration, and evaluation.

3.4. Artefact: Architecture and Instantiation

The artefact developed in this study consists of a lightweight mapping framework designed to translate regulatory requirements from the CRA into concrete, socio-technical security controls that are feasible for SMEs to implement and communicate. In line with DSR principles, this section describes both the conceptual architecture of the artefact and its conceptual instantiation, demonstrating how theoretical foundations are operationalized into a structured solution.

3.4.1. Artefact Architecture

The architecture of the artefact is structured into two tightly integrated layers, directly reflecting the theoretical foundations of the study.

The Institutional Layer captures external compliance and legitimacy requirements. At this level, CRA articles and obligations are decomposed into regulatory objectives that define what must be achieved for compliance. These objectives are subsequently mapped to internationally recognized security standards, namely ISO/IEC 27001 and the CIS Critical Security Controls. This layered mapping ensures regulatory traceability and institutional legitimacy, allowing SMEs to demonstrate an alignment between regulatory demands and accepted security practices.

The Socio-Technical Layer operationalizes these regulatory objectives within the organizational reality of SMEs. For each mapped control, the framework specifies the dimensions presented in

Table 3. Socio-technical dimensions of cybersecurity control implementation and accountability.

Dimension	Description	Examples
Technical Mechanisms	System configurations, tools, and enforcement measures required to implement and operate the control	Firewall rules, MFA configuration, log management systems, vulnerability scanners
Organizational Processes	Policies, procedures, and workflows that support, regulate, and sustain the control over time	Incident response procedures, access management policies, change management workflows
Accountable Roles and Functions	Individuals or organizational units responsible for execution, monitoring, and oversight of the control	IT administrators, security officers, senior management, external service providers

.

This dual-layer structure ensures that compliance is not reduced to a purely technical exercise but is embedded into organizational routines and governance practices, consistent with Socio-Technical Systems Theory.

3.4.2. Core Components of the Artefact

The artefact comprises six interrelated components as presented in

Table 4. Structural components of the proposed lightweight cybersecurity mapping framework.

Framework Component	Description
Mapping Matrix	Links CRA requirements to ISO/IEC 27001 and CIS controls and further to SME-relevant implementation examples
Organizational Responsibility Layer	Assigns accountability for each control and clarifies governance structures and responsible roles
System and Asset Visibility Component	Identifies the systems, assets, and dependencies affected by each regulatory requirement
Dual-Control Representation	Pairs technical enforcement mechanisms with corresponding procedural or policy-based measures.
Lightweight Maturity Scoring Model	Enables incremental assessment and communication of cybersecurity maturity levels
Evidence Catalogue Layer	Specifies verifiable artefacts (e.g., logs, configurations, reports, policies) that substantiate control implementation.

, each derived from the design principles established in Section 2.4.

Together, these components provide a structured yet flexible representation of how regulatory compliance can be operationalized and communicated within SME environments.

3.4.3. Instantiation

At this stage, the artefact is instantiated as a conceptual model rather than a fully implemented technical system. The model is expressed through structured representations, such as matrices, layered diagrams, and control mappings, which define the relationships between regulatory requirements, security controls, organizational responsibilities, and evidentiary outputs.

This conceptual instantiation allows the artefact to remain technology-agnostic and adaptable to different SME contexts, tools, and levels of maturity. It also aligns with the exploratory and explanatory objectives of the study, enabling rigorous evaluation of the framework’s utility, coherence, and relevance before committing to specific software implementation.

By adopting a conceptual model, the study prioritizes clarity, transferability, and analytical rigor, ensuring that the artefact can be critically assessed, refined, and extended in future research or practical deployments.

4. Design Collaboration Workshops

The artefact was developed through four iterative DSR cycles, each combining problem diagnosis, artefact structuring, and a preliminary evaluation. In the first cycle, the team identified SME barriers and operational challenges, defining the core components: the Mapping Matrix, Organizational Responsibility Layer, Lightweight Maturity Scoring Model, Dual-Control Representation, and Evidence Catalogue. Evaluation at this stage was conceptual, focusing on an alignment with Institutional Theory and socio-technical logic.

In the second cycle, workshops refined the mapping logic and structural interactions, explicitly addressing partial implementations, shared responsibilities, and the establishment of an incremental maturity scoring. Evaluation criteria included clarity, internal consistency, and operational feasibility under typical SME constraints.

The third cycle applied scenario-based validation using hypothetical SMEs with fragmented IT and outsourced controls. The team assessed usability, understandability, and socio-technical coherence, refining the Dual-Control Representation and Evidence Catalogue to support incomplete or externally managed controls.

The fourth cycle prepared the artefact for demonstration, standardizing outputs such as CRA alignment summaries, responsibility overviews, and evidence indexes. Evaluation criteria focused on partner-facing transparency, interpretability, and legitimacy signaling rather than absolute compliance levels.

Across all cycles, design activities (workshops and iterative refinements) were clearly separated from evaluation activities (scenario testing, usability assessment, and judgement of clarity and legitimacy). This structure ensured that each build–evaluate iteration produced measurable improvements in both internal usability and external communication, demonstrating the artefact’s capacity to operationalize compliance while supporting trust and visibility in SME partnership contexts.

4.1. First Design Meeting—Problem Diagnosis and Conceptualization of the Artefact

4.1.1. Opening and Alignment with Research Purpose

Participant C initiated the discussion by revisiting the theoretical motivation behind the study, highlighting the coercive nature of the CRA and the consequent need for SMEs to demonstrate legitimacy. They stated: “Institutional pressure from CRA is coercive, and SMEs need legitimacy. But legitimacy is blocked by the fact that partners cannot see or verify what SMEs are actually doing. Our artefact must serve as a legitimacy-translation mechanism.” This mechanism would present itself as the applicable means to a more trustworthy communication and presentation of the works in question.

Design implication: the framework must generate partner-facing outputs that clearly map controls to regulatory obligations, strengthening the Institutional Theory dimension of the artefact.

4.1.2. Identification of SME Barriers and Initial Structuring

Participant E highlighted the operational challenges SMEs face due to the lack of structured visibility over their systems and security responsibilities. Based on their experience conducting vulnerability assessments and coordinating supplier-related security activities, they noted: “Most SMEs do not have a clear and consolidated view of their infrastructure or who is accountable for each part of it. CRA compliance depends on knowing which systems exist, their risks, and who maintains them. Without this visibility, alignment with regulatory requirements becomes impossible”.

Design implication: incorporation of a System and Asset Visibility Component within the framework, ensuring that each mapped control is linked to the relevant systems and responsible parties. This reinforces socio-technical integration by grounding compliance requirements in real operational environments and clarifying accountability across internal staff and external service providers.

Participant A highlighted the importance of measurement and traceability within the artefact: “The framework needs measurable indicators. Even if they are simple maturity steps 0, 1, 2, SMEs need to quantify how far they are from CRA alignment”.

Design implication: integration of a lightweight maturity scoring model to help SMEs understand compliance progress and communicate maturity levels to partners.

4.1.3. Technical Foundations and Mapping Logic

Participant B stressed the need for structural simplicity to ensure SME adoption: “If we overload the artefact with complexity, SMEs will not use it. Start with a matrix: CRA requirement → ISO → CIS → Example Control Implementation”.

Design implication: establishment of the core mapping matrix that will serve as the backbone of the lightweight framework, to create a usable and applicable artifact.

Participant D highlighted the necessity of embedding enforced behavioral mechanisms: “SMEs cannot rely on human decisions alone; controls must enforce behaviour. If CRA asks for secure authentication, the mapping should include both the policy and the technical enforcer, like MFA configuration”.

Design implication: creation of a dual-control representation combining technical and procedural measures, aligning with the socio-technical logic of STS Theory.

4.1.4. Synthesized Problem Statement and Framework Concept

Participant C consolidated the meeting outcomes: “So the core issue is twofold: SMEs cannot operationalise CRA internally, and they cannot communicate maturity externally. Our framework must solve both”.

This synthesis served as the foundational conceptualization of the artefact’s purpose and scope.

4.1.5. Resulting Upgrade of the Lightweight Mapping Framework

As a result of the first design meeting, the lightweight mapping framework underwent a substantive refinement, moving from an abstract idea to a clearly structured artefact concept. The collective discussion enabled the team to converge on a shared understanding of what the framework must contain in order to be both theoretically grounded and practically usable by SMEs. In particular, the meeting clarified that the artefact must simultaneously support internal operationalization of CRA requirements and external communication of cybersecurity maturity.

Five core structural components were consolidated at this stage. First, the Mapping Matrix was defined as the central backbone of the artefact, establishing explicit traceability between CRA requirements, ISO/IEC 27001 controls, CIS benchmarks, and concrete implementation examples suitable for SME environments. Second, an Organizational Responsibility Layer was introduced to associate each control with accountable roles and governance responsibilities, addressing the organizational dimension of compliance. Third, a Lightweight Maturity Scoring Model was incorporated to allow SMEs to assess and communicate their level of alignment in incremental and understandable terms. Fourth, the Dual-Control Representation was formalized to ensure that each requirement is supported by both technical enforcement mechanisms and corresponding procedural or policy-based measures. Finally, an Evidence Catalogue Layer was defined to structure the collection and presentation of verifiable artefacts, such as configurations, logs, or documented procedures, which substantiate control implementation.

Together, these components transformed the framework into a coherent socio-technical artefact capable of translating regulatory expectations into actionable practices while producing outputs that are meaningful in partner-facing and contractual contexts.

4.1.6. Closure and Next Steps

The meeting concluded with agreement on the immediate next steps for the design process. The team decided that the subsequent workshop would focus on systematically clustering CRA articles into thematic control areas and selecting the most relevant ISO/IEC 27001 and CIS controls for each cluster. This would be followed by the development of a preliminary visual representation of the framework, illustrating the relationships between regulatory requirements, controls, organizational responsibilities, and evidentiary outputs.

Additionally, the team agreed to test the initial framework logic using hypothetical SME scenarios to validate feasibility, identify ambiguities, and assess whether the proposed mappings remain understandable and realistic under typical resource constraints. These activities were defined as essential inputs for refining the artefact before proceeding to the demonstration and evaluation stages within the DSR cycle.

4.2. Second Design Meeting—Artefact Structuring and Control Mapping Refinement

4.2.1. Opening and Alignment with Research Purpose

Participant C opened the second design meeting by framing it as a transition point in the DSR cycle, moving from a conceptual agreement to structural consolidation. They reminded the team that the objective was no longer to justify why the artifact was needed, but to define how it should be structured and used. They stated: “At this stage, the artefact must stop being an idea and start becoming something that an SME could realistically follow. If we cannot explain its structure clearly, it will fail both scientifically and practically”.

Design implication: the meeting focus shifted from problem framing to artefact structuring, reinforcing the DSR transition from problem diagnosis to artefact design and instantiation, based on the understanding that an overly complex artefact will not be applied.

4.2.2. Identification of SME Barriers and Initial Structuring

Participant E returned to the issue of operational feasibility, stressing that control mappings must reflect how SMEs actually manage their environments. Drawing from their experience, they noted: “Even when controls exist, they are scattered. Assets, access rules, and responsibilities are rarely documented in one place. If the framework assumes a clean starting point, it will not work in real SMEs”.

Design implication: the framework structure was refined to assume partial, fragmented implementations as a starting point, allowing SMEs to progressively document and align existing controls rather than starting from scratch.

Participant A reinforced this concern from a measurement perspective, arguing that progress visibility is essential for engagement: “If SMEs can’t see improvement over time, they won’t maintain the effort. The structure must make partial compliance visible and meaningful”.

Design implication: the maturity scoring logic was clarified to support incremental alignment, enabling SMEs to reflect partial fulfilment of CRA-related controls without requiring full compliance upfront.

4.2.3. Technical Foundations and Mapping Logic

Participant B guided the discussion towards formalizing the mapping logic itself. They argued that the framework must follow a predictable and repeatable structure: “Each CRA requirement should always lead the user through the same path. If the logic changes, the framework becomes confusing.” They proposed a consistent sequence from regulatory requirement to recognized standards and finally to concrete control examples.

Design implication: the mapping logic was standardized as a fixed progression from CRA requirements to ISO/IEC 27001 control objectives, then to CIS controls, and finally to SME-oriented implementation examples.

Participant D complemented this by emphasizing enforceability: “It’s not enough to say that a policy exists. The mapping must show how behaviour is enforced technically, otherwise it remains theoretical”.

Design implication: technical enforcement mechanisms were explicitly positioned alongside procedural controls within the mapping logic, strengthening socio-technical consistency and repeatability.

4.2.4. Synthesized Problem Statement and Framework Concept

Participant C synthesized the discussion by clarifying the refined problem statement emerging from the meeting: “Not only are we mapping regulations to controls, but we are also designing a way for SMEs to understand what they already do, what is missing, and how to explain that to others”.

This synthesis refined the framework concept as both an internal structuring tool and an external communication mechanism, reinforcing its dual purpose within the DSR artefact.

4.2.5. Resulting Upgrade of the Lightweight Mapping Framework

As a result of the second design meeting, the lightweight mapping framework evolved from a set of components into a more coherent and structured conceptual model. The discussion clarified how the previously identified elements interact and in which sequence they should be applied. The Mapping Matrix was refined to operate through clustered CRA domains rather than isolated articles, improving usability and alignment with SME mental models. The Organizational Responsibility Layer was adapted to support flexible, role-based accountability instead of rigid job titles, reflecting common SME practices. In addition, the refinement process explicitly addressed shared responsibility models, which are common in SME environments that rely on outsourced IT providers, managed service providers, or cloud platforms. Rather than assuming full internal control over all security functions, the Organizational Responsibility Layer distinguishes between internally owned controls, externally delegated controls, and jointly managed controls. For outsourced arrangements, the framework requires explicit documentation of responsibility allocation, including contractual clauses, SLAs, and evidence of third-party assurance (e.g., certifications, audit reports, or compliance attestations). This shared-responsibility mapping ensures that regulatory accountability remains visible even when technical implementation is externalized. It prevents ambiguity regarding “who is responsible for what” and supports traceability across organizational boundaries.

The Lightweight Maturity Scoring Model was adjusted to explicitly support partial and evolving compliance states, enabling SMEs to document progress incrementally. The Dual-Control Representation was strengthened by requiring each mapped requirement to reference both a procedural element and a technical enforcement mechanism. Finally, the Evidence Catalogue Layer was structured to categorize acceptable proof types per control, ensuring consistency and relevance for partner-facing use.

Together, these refinements position the framework as a structured socio-technical model capable of guiding SMEs through compliance alignment while simultaneously producing credible, externally understandable representations of cybersecurity maturity.

4.2.6. Closure and Next Steps

The meeting concluded with agreement on the next steps in the design process. The team decided that the following workshop would focus on applying the refined framework structure to concrete hypothetical SME scenarios, covering different levels of technical maturity and organizational complexity. The objective would be to validate whether the mapping logic, responsibility assignments, and maturity scoring remain understandable and realistic under typical SME constraints.

These scenario-based applications were identified as a necessary step before proceeding to a formal demonstration and evaluation, ensuring that the artefact is sufficiently robust, comprehensible, and aligned with real-world SME conditions before entering the later stages of the DSR cycle.

4.3. Third Design Meeting—Scenario-Based Validation and Refinement of the Artefact

4.3.1. Opening and Alignment with Research Purpose

Participant C opened the third meeting by clarifying that its primary objective was validation rather than expansion. They stressed that the framework should now be tested against realistic SME situations to verify whether the design choices made so far were understandable, coherent, and usable. They stated: “At this point, the question is not whether the framework is theoretically sound, but whether it still makes sense when applied to real SME conditions with limited time, skills, and documentation”.

Design implication: the meeting was positioned as a validation checkpoint in the DSR cycle, focusing on assessing artefact clarity, internal consistency, and practical applicability before further refinement.

4.3.2. Identification of SME Barriers and Initial Structuring

Participant E presented a hypothetical SME scenario based on a small service-oriented company with outsourced IT infrastructure and minimal internal security documentation. They highlighted a recurring issue: “In many SMEs, controls exist because a supplier configured them, not because the company understands or governs them. The framework must allow SMEs to document controls even when knowledge is partial”.

Design implication: the framework was adjusted to explicitly accommodate externally managed controls, allowing SMEs to reference supplier-managed implementations while still linking them to CRA requirements and internal accountability.

Participant A examined the same scenario from a measurement perspective and noted that maturity progression must remain meaningful even when evidence is incomplete. She remarked: “If evidence is informal or indirect, the framework should still capture progress instead of forcing a binary compliant or non-compliant view”.

Design implication: the maturity scoring model was refined to recognize alternative forms of evidence and partial assurance, reinforcing gradual and realistic compliance progression.

4.3.3. Technical Foundations and Mapping Logic

Participant B analyzed how the mapping logic behaved when applied to different CRA control clusters, such as access control and incident handling. They observed: “The sequence works, but only if the mappings remain consistent across domains. Any exception breaks the learning curve for the SME”.

Design implication: the mapping logic was further standardized to ensure uniform navigation and terminology across all CRA clusters, reducing cognitive load for users.

Participant D tested the same scenarios with a focus on technical enforcement and noted that some controls risked being interpreted too abstractly. They commented: “If we don’t explicitly state how a control is enforced, SMEs may assume policy alone is sufficient”.

Design implication: the framework was refined to require explicit identification of at least one technical enforcement mechanism per relevant control, reinforcing the socio-technical balance.

4.3.4. Synthesized Problem Statement and Framework Concept

Participant C synthesized the discussion by reframing the problem statement in operational terms: “The real challenge is not lack of controls, but lack of structure and visibility. Our framework must make fragmented security practices legible, both internally and externally”.

This synthesis reinforced the framework’s role as a structuring and sense-making artefact rather than a prescriptive checklist, aligning it closely with the realities observed in the scenario-based discussion.

4.3.5. Resulting Upgrade of the Lightweight Mapping Framework

The third meeting resulted in targeted refinements rather than structural expansion. The framework was adjusted to better support SMEs with outsourced services and incomplete documentation by introducing flexibility in how controls and evidence are represented. The Mapping Matrix was refined to allow annotations indicating third-party ownership or shared responsibility. The Organizational Responsibility Layer was updated to distinguish between internal accountability and external operational execution.

The maturity scoring logic was recalibrated to explicitly reflect partial assurance and evolving confidence levels, while the Dual-Control Representation was strengthened through clearer guidance on acceptable enforcement mechanisms. These refinements improved the framework’s robustness and realism without increasing complexity, preserving its lightweight nature.

4.3.6. Closure and Next Steps

The meeting concluded with a consensus that the framework had reached a sufficient level of stability to move towards formal demonstration. The team agreed that the next workshop would focus on preparing the artefact for structured application in selected SME contexts, including defining demonstration procedures and evaluation criteria.

This marked the transition from iterative design refinement to preparation for demonstration and evaluation phases within the DSR process, ensuring that subsequent activities would focus on assessing value, usability, and impact rather than core design assumptions.

4.4. Fourth Design Meeting—Preparation for Demonstration and Evaluation

4.4.1. Opening and Alignment with Research Purpose

Participant C opened the fourth meeting by clarifying that the design phase was nearing completion and that the focus now needed to shift towards demonstration and evaluation, as required by the DSR methodology. They emphasized: “We now need to show that the artefact works in context. The goal of this meeting is to decide how we will demonstrate it and how we will evaluate whether it actually delivers legitimacy, clarity, and socio-technical alignment”.

Design implication: the artefact had to be framed not only as a design outcome but also as an evaluable instrument, with clearly defined use scenarios and success criteria.

4.4.2. Identification of SME Barriers and Initial Structuring

Participant E highlighted practical constraints that could affect demonstration activities, particularly time availability and documentation maturity within SMEs. They noted: “In real SMEs, we will not get perfect data. Demonstration must work even if documentation is incomplete or informal”.

Design implication: the demonstration strategy was adapted to allow the partial instantiation of the framework, ensuring that SMEs could engage with the artefact without first completing extensive preparatory work.

Participant A added that evaluation should avoid overly complex metrics and instead focus on observable improvements. They stated: “We should not over-engineer evaluation. What matters is whether SMEs understand their position better and whether partners perceive more clarity”.

Design implication: evaluation indicators were oriented towards perceived clarity, usability, and transparency rather than exhaustive quantitative compliance scores.

4.4.3. Technical Foundations and Mapping Logic

Participant B focused on how the artefact would be instantiated during the demonstration. They argued: “The framework must be presented as a conceptual model supported by simple artefacts, such as structured tables or diagrams, not as a fully automated system”.

Design implication: it was agreed that the artefact would be demonstrated as a conceptual model instantiated through structured representations (e.g., matrices and templates), reinforcing accessibility and methodological rigor.

Participant D reinforced the importance of showing technical realism during demonstration. They commented: “Even if the model is conceptual, examples of real technical controls must be included so that SMEs recognise their own environments”.

Design implication: demonstration materials would include concrete examples of technical configurations and procedural measures to anchor the framework in real-world practice.

4.4.4. Synthesized Problem Statement and Framework Concept

Participant C synthesized the discussion by reframing the evaluation focus: “We are not evaluating whether SMEs become fully compliant, but whether the framework helps them make security maturity visible and discussable”.

This synthesis clarified that evaluation would focus on communication, structure, and legitimacy rather than absolute security outcomes.

4.4.5. Resulting Upgrade of the Lightweight Mapping Framework

As a result of the fourth meeting, the artefact was finalized for demonstration without further structural changes. The main upgrade consisted of defining explicit guidance on how the framework should be instantiated and presented during evaluation. This included the definition of standard artefact outputs, such as a CRA alignment summary, a responsibility overview, and an evidence index.

These outputs ensured that the framework could be consistently demonstrated across different SME contexts while preserving its conceptual nature and socio-technical balance.

4.4.6. Closure and Next Steps

The meeting concluded with agreement that the next phase would consist of applying the framework in selected SME scenarios and collecting evaluation data. The team agreed on the need to prepare interview guides, observation protocols, and documentation templates aligned with Institutional Theory and Socio-Technical Systems Theory.

This marked the formal transition from design activities to demonstration and evaluation within the DSR cycle, setting the foundation for the Results and Discussion Sections of the paper.

5. Results

This section reports the results obtained from the DSR process, focusing on the final artefact that emerged from the design collaboration workshops and its application in anonymized and hypothetical SME contexts. In line with the purpose of this section, the results are presented descriptively, without interpretative claims, which are reserved for the subsequent discussion.

5.1. Final Structure of the Lightweight Mapping Framework

Figure 2 presents the proposed lightweight socio-technical compliance mapping framework developed in this study. It is intended to illustrate how regulatory requirements, recognized security standards, organizational responsibilities, technical controls, and evidentiary outputs are integrated into a single coherent structure. It also provides an overview of the framework’s main components and their relationships, supporting a clear understanding of how the artefact translates abstract compliance obligations into operational practices and partner-facing transparency for SMEs.

The principal outcome of this study is a consolidated lightweight mapping framework designed to support SMEs in translating regulatory cybersecurity requirements into operational and communicable practices. The framework is represented as a conceptual socio-technical model that organizes regulatory, technical, and organizational elements into a coherent structure.

At the top level, the framework captures the Regulatory and Partnership Context, which includes the CRA, contractual and SLA expectations, partner due diligence requirements, and institutional pressure for legitimacy. This contextual layer frames cybersecurity compliance as a condition for partnership formation rather than a purely internal technical exercise.

The Regulatory Interpretation Layer decomposes CRA articles into regulatory control objectives, providing a structured basis for interpretation. These objectives are then aligned in the Standards Alignment Layer with ISO/IEC 27001 control objectives and CIS Critical Security Controls, ensuring consistency with widely recognized reference frameworks.

The Compliance Mapping Matrix constitutes the core of the artefact. It establishes traceability between CRA requirements, aligned standards, SME-oriented control implementations, and associated evidence references. This matrix functions as the primary mechanism through which regulatory expectations are translated into actionable and reviewable controls.

To ensure transparency in the mapping logic, the selection of SME-oriented control implementations followed explicit criteria. First, relevance: each control had to demonstrably address a specific regulatory requirement or obligation, ensuring direct traceability rather than generic best practice inclusion. Second, feasibility: controls were prioritized based on their practical implementability within resource-constrained SME environments, favoring measures that do not require highly specialized infrastructure or excessive financial investment. Third, proportionality: implementations were designed to reflect the scale, complexity, and risk profile typical of SMEs, consistent with risk-based regulatory principles. Fourth, verifiability: each selected control had to allow the identification of observable and documentable evidence, enabling a review by external partners or auditors. Fifth, interoperability: where possible, controls were aligned with widely recognized standards (e.g., ISO-based controls or commonly adopted security baselines) to facilitate cross-framework comparability and reduce duplication of effort.

Table 5. Evaluation criteria and assessment methods across DSR build–evaluate cycles.

Evaluation Criterion	Definition in Context of the Artefact	Assessment Method	When Assessed (DSR Cycle)	Outcome/Refinement Triggered
Clarity and Structural Coherence	Degree to which SMEs can understand the mapping logic (CRA → ISO → CIS → Implementation → Evidence) and navigate the framework consistently.	Expert consensus discussions; structured scenario walk-throughs using hypothetical SME cases; identification of ambiguities during workshops.	Cycles 2 and 3	Standardization of mapping sequence; clustering of CRA domains; clearer terminology and uniform navigation logic.
Operational Feasibility	Practical applicability within resource-constrained SME environments, including partial or outsourced controls.	Scenario-based validation; practitioner feedback (Participant E); stress-testing against fragmented documentation cases.	Cycles 2 and 3	Introduction of flexible starting points; explicit support for shared responsibility and outsourced controls; incremental maturity logic.
Socio-Technical Consistency	Integration of technical enforcement, organizational roles, and procedural controls.	Expert review of dual-control representation; validation against STS principles during design meetings.	Cycles 1–3	Formalization of Dual-Control Representation; requirement for at least one technical enforcement per mapped control.
Legitimacy Support	Extent to which outputs help SMEs demonstrate compliance alignment to external stakeholders.	Theoretical alignment check (Institutional Theory); expert judgement on adequacy of partner-facing outputs.	Cycles 1 and 4	Definition of CRA alignment summary and structured evidence index to strengthen legitimacy signaling.
Partner-Facing Usefulness	Utility of outputs in negotiations, due diligence, and transparency contexts.	Simulated partner review discussions; evaluation of interpretability and transparency of artefact outputs.	Cycle 4	Standardized outputs (responsibility overview, evidence catalogue, maturity summary) to enhance communicability.

summarizes the explicit evaluation criteria applied across the DSR cycles and explains how each was assessed. It distinguishes between clarity, operational feasibility, socio-technical consistency, legitimacy support, and partner-facing usefulness. For each criterion, it specifies the assessment method (e.g., expert consensus, scenario walk-throughs, and theoretical alignment checks), the DSR cycle in which the evaluation occurred, and the resulting refinements. This structured overview strengthens methodological transparency by clearly separating iterative design activities from the evaluation steps and demonstrating how feedback informed progressive artefact improvements.

To illustrate how this process operates in practice, consider the mapping of a CRA requirement concerning protection against unauthorized access to products with digital elements. In the Regulatory Interpretation Layer, this provision is reformulated into the control objective “implementation of structured access control and authentication mechanisms.” Within the Standards Alignment Layer, this objective is mapped to ISO/IEC 27001 control A.5.15 (Access Control) and CIS Control 6 (Access Control Management), ensuring terminological and structural consistency with established frameworks. In the Compliance Mapping Matrix, the SME-oriented implementation specifies enforceable measures such as role-based access control for privileged accounts, multi-factor authentication for remote access, and documented user provisioning and revocation procedures. Finally, the evidence column identifies concrete artefacts—including access control policies, configuration screenshots demonstrating MFA activation, periodic user access review logs, and approval records for access changes—thereby operationalizing the principles of relevance, feasibility, proportionality, verifiability, and interoperability within a single traceable chain from regulation to evidence.

5.2. Socio-Technical Integration

The framework explicitly incorporates socio-technical elements to ensure that compliance is grounded in operational reality. A System and Asset Visibility Component was introduced to associate each mapped control with relevant systems, assets, dependencies, and third-party managed elements.

In addition, the Socio-Technical Control Model structures each control across three dimensions: technical enforcement mechanisms, organizational processes, and responsible roles. This configuration ensures that controls are not represented solely as policies or technical measures, but as coordinated practices involving people, processes, and technology.

An Evidence Catalogue Layer complements this model by defining and organizing acceptable forms of proof, such as configurations, policies, logs, and reports, supporting verification and review.

5.3. Maturity Representation and Outputs

A Lightweight Maturity Scoring Model was integrated into the framework to represent incremental levels of alignment with CRA requirements. The model supports partial compliance and progress visibility over time, allowing SMEs to communicate their current state without requiring full maturity as a prerequisite.

The scoring model follows a three-level structure (0–1–2), where progression between levels is based on explicit qualitative thresholds. Level 0 indicates the absence of a defined control or only informal, undocumented practices. Level 1 reflects documented and partially implemented controls, where responsibility is assigned and initial evidence exists, but systematic monitoring or verification may be limited. Level 2 requires demonstrable operational enforcement, including traceable evidence, periodic review, and corrective action mechanisms.

The transition from Level 0 to Level 1 requires formalization (documented policy or procedure) and observable implementation steps. The transition from Level 1 to Level 2 requires evidence of effectiveness, such as monitoring records, testing results, audit trails, or documented improvement cycles. These thresholds were intentionally designed to balance rigor with SME feasibility, ensuring that advancement reflects substantive capability rather than purely declarative compliance.

Based on the completed mappings, the framework produces structured partner-facing outputs, including a CRA alignment summary, control coverage overview, responsibility overview, and evidence index. These outputs present cybersecurity maturity in a standardized and concise format suitable for contractual and due-diligence contexts.

6. Discussion

6.1. Addressing the Identified Research Gap

The results indicate that the proposed mapping framework responds directly to the gap identified in the literature, namely the absence of practical mechanisms that enable SMEs to credibly demonstrate cybersecurity maturity in regulatory and partnership contexts. Prior studies have highlighted SMEs’ difficulties in interpreting regulatory requirements, aligning internal practices with external expectations, and communicating cybersecurity posture to partners. The framework addresses these challenges by providing a structured yet lightweight approach that translates abstract regulatory obligations into actionable controls and verifiable outputs.

Unlike existing maturity models that primarily support internal improvement, the framework explicitly incorporates partner-facing outputs. This shift reframes cybersecurity compliance from an inward-looking obligation to an outward-facing capability that supports trust formation and reduces uncertainty during contractual negotiations. In doing so, the artefact operationalizes transparency as a practical mechanism rather than a normative aspiration [8,44].

More specifically, the integration of regulatory interpretation, standards alignment, organizational responsibility mapping, and evidence cataloguing enables SMEs to present a coherent and auditable account of their security posture. This directly responds to the recurring concern in the literature that SMEs often possess fragmented or informal security practices which, even when effective, remain invisible or unintelligible to external stakeholders [45,46]. By structuring this information in a consistent and recognizable format, the framework lowers the cognitive and transactional barriers faced by partners when assessing risk and negotiating security-related contractual terms [46].

The framework explicitly distinguishes between documented policy statements and substantive technical or organizational enforcement mechanisms. While formal policies (e.g., access control policies, incident response procedures) are necessary for transparency and governance, they do not in themselves guarantee operational effectiveness. To mitigate the risk of purely “symbolic” compliance—where documentation exists without corresponding implementation—the framework requires traceable evidence of technical controls, monitoring practices, and accountability mechanisms. Examples include configuration records, system logs, access management artefacts, testing reports, and documented corrective actions. Moreover, the maturity scoring model differentiates between declarative compliance (policy existence), implemented controls (technical and procedural enforcement), and verified effectiveness (evidence of monitoring, review, and improvement). This layered approach encourages SMEs to move beyond checkbox-style documentation towards demonstrable security capability.

Furthermore, the inclusion of an incremental maturity scoring model allows SMEs to communicate progress and intent, rather than being judged solely against static compliance thresholds [47]. This feature is particularly relevant in resource-constrained environments, where full alignment with regulatory or standards-based requirements may be achieved gradually [47]. As a result, the framework supports a more realistic and development-oriented interpretation of compliance, aligning regulatory expectations with the operational realities of smaller organizations. However, regulatory environments are dynamic, and instruments such as the CRA, ISO standards, or sector-specific requirements are subject to periodic revision and interpretative updates. To remain effective, the framework must therefore support longitudinal maintenance and structured updating mechanisms. Rather than being treated as a static artefact, the proposed framework is designed as a modular mapping structure in which regulatory requirements, control references, and scoring criteria can be revised independently without altering the overall architecture. This modularity facilitates the incorporation of new regulatory provisions and incorporates emerging best practices.

Taken together, these characteristics position the artefact as a concrete response to the limitations of prior work. It moves beyond descriptive accounts of SME cybersecurity challenges and conceptual discussions of trust and transparency, offering instead an implementable mechanism through which compliance, maturity, and legitimacy can be systematically demonstrated [48]. In this sense, the framework does not merely complement existing maturity models and governance perspectives but extends them by embedding communicability and partner relevance as core design objectives.

6.2. Theoretical Implications

From an Institutional Theory perspective, the framework functions as a legitimacy-enabling mechanism. By systematically mapping CRA requirements to recognized standards and concrete controls, the artefact supports SMEs in responding to coercive and normative institutional pressures in a demonstrable manner. The structured outputs produced by the framework allow SMEs to move beyond symbolic compliance towards more substantive alignment, thereby strengthening their perceived legitimacy in the eyes of partners, regulators, and auditors [19,49]. Furthermore, the theoretical contribution can be further understood through the lens of artifact-mediated transparency. In inter-organizational relationships, information asymmetry is common: SMEs typically possess detailed knowledge of their internal security practices, while external partners face uncertainty regarding the depth, consistency, and reliability of those practices. This asymmetry increases perceived risk and often results in extended due diligence, additional contractual safeguards, or exclusion from partnership opportunities. The framework acts as a mediating artefact that structures and standardizes the disclosure of security-related information, transforming internally dispersed practices into externally interpretable signals.

More importantly, the results suggest that legitimacy in cybersecurity contexts is not achieved solely through the adoption of controls, but through their intelligible presentation and external verifiability. The framework operationalizes this insight by embedding traceability and evidence as core design elements, thus transforming regulatory compliance into a communicable organizational attribute [50]. In this respect, the artefact extends institutional theory by illustrating how legitimacy can be actively constructed through artefact-mediated transparency, rather than passively inferred from formal certification or policy statements alone.

From a Socio-Technical Systems perspective, the results highlight the importance of integrating technical enforcement, organizational processes, and responsible roles. The inclusion of system and asset visibility, dual-control representations, and evidence catalogues reflects the interdependence between social and technical subsystems. This integration mitigates the risk of compliance being treated as a purely technical exercise detached from organizational reality, a limitation frequently noted in SME cybersecurity literature [51].

The findings further reinforce the argument that cybersecurity maturity emerges from the coordinated alignment of people, processes, and technology. Technical safeguards such as authentication mechanisms or monitoring tools acquire practical value only when embedded within clearly defined responsibilities, routines, and decision structures. By explicitly modeling these relationships, the framework contributes to socio-technical theory by demonstrating how regulatory requirements can be translated into stable organizational practices, rather than remaining external constraints imposed upon technical infrastructures [52].

Taken together, these theoretical implications indicate that the framework does more than provide a practical compliance tool. It offers empirical support for the view that institutional legitimacy and socio-technical coherence are mutually reinforcing in regulated digital environments. The artefact thus serves as a bridge between regulatory governance and organizational implementation, illustrating how abstract institutional demands can be stabilized through socio-technical design.

6.3. Practical Implications for SMEs

Practically, the framework offers SMEs a means to manage regulatory compliance in a manner that is compatible with limited financial, technical, and organizational resources. The use of incremental maturity levels, partial compliance support, and standardized mappings reduces the entry barrier commonly associated with comprehensive security frameworks and formal certification schemes. Rather than requiring full alignment as a prerequisite, the artefact allows SMEs to document progress in a gradual and structured way, which reflects the realities of constrained implementation capacity [53].

At the same time, the partner-facing outputs provide SMEs with a tangible artefact that can be used during due diligence processes, service-level agreement negotiations, supplier onboarding, and broader trust-building activities. By translating internal security practices into externally understandable representations, the framework helps SMEs articulate their cybersecurity posture in contexts where technical expertise is unevenly distributed among stakeholders [54]. This reduces reliance on informal assurances and subjective claims, replacing them with standardized and verifiable representations of maturity.

Importantly, the framework does not require SMEs to disclose sensitive technical details. Instead, it supports controlled transparency by enabling the disclosure of structured evidence and compliance summaries that are sufficient for trust formation while preserving operational security and confidentiality. This balance is particularly relevant for smaller organizations that may lack the capacity to manage extensive information sharing without increasing exposure to risk.

Beyond regulatory compliance, the framework may also contribute to strategic positioning. By lowering the informational asymmetry that often disadvantages SMEs in competitive procurement and partnership settings, the artefact enables smaller firms to signal reliability and professionalism in a manner comparable to larger organizations with formal certifications. In this sense, cybersecurity maturity becomes not only a defensive requirement, but also a market-facing capability that can support access to new contracts, participation in regulated supply chains, and longer-term partnership stability [55].

Collectively, these practical implications suggest that the framework supports both operational feasibility and commercial relevance, reinforcing its suitability as a lightweight yet meaningful tool for SMEs operating under increasing regulatory and contractual scrutiny.

6.4. Limitations and Directions for Future Research

While the framework demonstrates conceptual coherence and practical relevance, the study is subject to several limitations. The artefact was developed and examined using anonymized and hypothetical SME scenarios rather than through sustained deployment within operational organizations. As a result, the findings primarily reflect design validity and perceived usefulness, rather than long-term behavioral or organizational effects.

Moreover, the evaluation involved a small expert community of five participants, which is appropriate for formative, early-stage DSR but limits the generalizability of the findings. The purpose of this phase was not statistical validation but exploratory assessment of conceptual soundness, clarity, and applicability. Accordingly, the claims of this study are restricted to demonstrating preliminary utility and structural robustness of the artefact.

To enhance methodological transparency, the evaluation process was structured through predefined interview prompts and a facilitated workshop protocol based on scenario walkthroughs. Expert feedback was systematically organized according to explicit evaluation criteria, including perceived utility (relevance for SME compliance practice), usability (clarity and ease of application), completeness (coverage of regulatory–control mappings), and internal consistency (logical coherence of the framework). While qualitative coding was applied to categorize feedback into thematic clusters, the limited sample size constrains broader inference.

Future research should therefore evaluate the framework in real-world SME contexts over extended periods, with particular attention being paid to its influence on partnership formation, contract negotiations, and trust dynamics. Longitudinal case studies, larger and more diverse expert panels, and a quantitative assessment of adoption outcomes would strengthen external validity and provide more robust evidence of effectiveness. Such studies would provide stronger empirical evidence regarding its effectiveness as a trust-enabling and legitimacy-supporting mechanism.

It is also relevant to note that this research does not include quantitative partnership metrics (e.g., time-to-contract, negotiation cycles, or conversion rates), nor does it provide a formal contractual negotiation analysis. Instead, the framework advances a theoretically grounded and design-oriented proposition: by translating regulatory requirements into clearly mapped and communicable security practices, SMEs are better positioned to respond to due diligence requests and compliance questionnaires in a structured and transparent manner. In this sense, the contribution is conceptual and artefactual rather than statistical. The framework is designed to reduce informational asymmetries between SMEs and prospective partners, provide traceability between regulatory clauses and implemented controls, and support clearer evidence-based communication during partnership discussions. While the present study evaluates the artefact in terms of usability and coherence, future research should empirically test the “partnership acceleration” claim through measurable indicators such as negotiation duration, number of clarification rounds, or successful onboarding rates.

Further work may also consider sector-specific adaptations, as compliance pressures and partnership structures differ across industries. In addition, the development of automated or low-code implementations could improve usability and scalability while maintaining the framework’s lightweight character.

Despite these limitations, the present study offers a foundation for further investigation into how structured compliance communication can reposition cybersecurity from a regulatory obligation to a strategic asset within SME ecosystems.

7. Conclusions

This study set out to examine how cybersecurity compliance can be transformed from a perceived burden into a strategic enabler for small and medium-sized enterprises. By adopting a DSR approach, the paper developed and articulated a lightweight mapping framework that connects regulatory requirements under the CRA with recognized security standards and concrete implementation practices suitable for SME contexts.

The proposed framework conceptually suggests that making cybersecurity maturity visible, structured, and verifiable can contribute to mitigate information asymmetry in partnership negotiations and potentially contribute to institutional legitimacy. In this study, these effects are theorized rather than empirically measured through partnership metrics or contractual analysis. By integrating regulatory interpretation, socio-technical controls, incremental maturity assessment, and partner-facing outputs, the artefact is designed to support both internal operationalization of compliance and external trust formation, with its impact on partnership acceleration remaining a proposition for future empirical validation.

Beyond its practical relevance, this study contributes theoretically by operationalizing key insights from Institutional Theory and Socio-Technical Systems Theory within a concrete design artefact. It shows that effective cybersecurity compliance in SMEs depends not only on technical controls, but also on organizational accountability, transparency, and context-aware communication.

In conclusion, the findings suggest that when appropriately designed, security compliance can act as a catalyst for sustainable partnerships rather than a constraint on SME competitiveness. The framework offers a foundation for further empirical evaluation and refinement and provides a viable pathway for SMEs seeking to align regulatory obligations with long-term business resilience and collaboration. However, it is important to recognize that the framework represents a conceptual instantiation rather than a fully automated compliance system. While it structures controls, responsibilities, and evidence in a coherent and actionable manner, SMEs remain responsible for the implementation, monitoring, and validation of security measures. Unlike automated systems, the framework does not provide real-time enforcement, or continuous assurance, which may limit scalability and responsiveness in rapidly evolving regulatory environments. Despite this limitation, the framework serves as a pragmatic starting point for SMEs to operationalize compliance, enhance transparency, and signal trustworthiness to partners and regulators.