Agile Resilience in Security for Small and Medium-Sized Businesses

Abstract

Small businesses face many of the same cyber threats as larger organisations but often lack equivalent budgets, specialist personnel, and formal security operations capability. This paper proposes Agile Resilience in Security for Enterprises (ARISE), a lightweight cyber-resilience framework and maturity model designed for resource-constrained small businesses. ARISE adapts prevention, detection, response, and recovery into an agile lifecycle so that organisations can improve cybersecurity maturity progressively rather than through a single large compliance project. The study combines framework benchmarking, a practical interpretive case used to position ARISE within reflexive thematic analysis (RTA) and maturity-model benchmarking, and quantitative machine-learning experiments using the UNSW-NB15 intrusion-detection dataset. The experimental component evaluates selected Weka classifiers, including J48, JRip, Random Tree, Decision Table, and Naive Bayes, to examine whether low-cost tools can support network intrusion detection in small-business contexts. Results show very high aggregate performance for tree- and rule-based classifiers, while class-level outcomes highlight that overall accuracy can conceal weak detection of minority attack categories. The paper therefore positions ARISE as a practical, iterative, and standards-informed framework that complements, rather than replaces, enterprise-grade security operations. Its value lies in giving small businesses an accessible starting point for identifying risk, selecting controls, improving cyber awareness, detecting suspicious activity, responding consistently, and learning from incidents.

1. Introduction

Cyber resilience is no longer a concern only for large enterprises, government agencies, and operators of critical infrastructure. Small businesses increasingly rely on cloud services, shared drives, online payments, remote access, customer databases, and digital supply chains. These dependencies create operational value, but they also expose small organisations to phishing, ransomware, malware, botnets, distributed denial-of-service activity, data theft, and network intrusion. For many small businesses, the challenge is not awareness alone. The more practical difficulty is knowing how to translate recognised cybersecurity guidance into affordable and manageable daily practice.

Internationally recognised frameworks such as the NIST Cybersecurity Framework 2.0, ISO/IEC 27001, and the EU NIS2 Directive provide important foundations for cyber risk management [1,2,3]. In Australia, the Essential Eight and SMB1001 offer more locally relevant guidance for improving baseline resilience [4,5]. However, these frameworks can still be difficult for micro and small businesses to interpret, prioritise, and maintain without external support. Small businesses may also operate across borders, meaning that a business based in one jurisdiction may still need to understand the expectations of customers, suppliers, or regulators in another.

This paper addresses that gap by proposing ARISE, a cyber resilience framework designed to be practical for small businesses while remaining aligned with established maturity-model thinking. ARISE is intended as a starting point for organisations that cannot immediately implement a full cybersecurity programme, but that still need a structured pathway for improving resilience. The framework is organised around the following four connected phases: prevention, detection, response, and recovery. These phases are applied iteratively through agile cycles so that cybersecurity improvement becomes part of normal organisational learning rather than a one-off compliance exercise.

The central research question guiding the paper is: how can lightweight machine learning experiments and cybersecurity maturity models provide effective network intrusion detection capabilities for micro-enterprises operating with limited technical and financial resources? To address this question, the paper combines three contributions. First, it positions ARISE against established cybersecurity frameworks and the maturity-model literature. Second, it presents a practical interpretive case that reflects the operational realities of a small business and supports the positioning of ARISE within RTA and maturity-model benchmarking. Third, it evaluates selected Weka [6] machine-learning classifiers using the UNSW-NB15 dataset to examine the feasibility and limitations of low-cost intrusion detection support.

Section 2 positions ARISE within existing cybersecurity and the maturity-model literature. Section 3 defines the ARISE framework and its design principles. Section 4 outlines the research design, including the practical interpretive case (proof-of-concept) and the Weka experiment embedded within the detection phase. Section 5 presents the experimental results, followed by a multi-dimensional validation discussion in Section 6 and implications for small-business deployment in Section 7 and Section 8.

2. Related Work and Framework Positioning

The literature on small-business cybersecurity consistently identifies a mismatch between the threat environment and the resources available to smaller organisations. Small businesses often experience limited cyber awareness, underinvestment, informal governance, reliance on external IT support, and difficulty interpreting technical standards. The ACSC small-business survey reported that 62% of surveyed firms had experienced at least one cybersecurity incident and that 48% planned to spend less than AUD 500 per year on cybersecurity. These findings underline the need for a framework that is not only technically sound, but also realistic for organisations with limited time, funding, and specialist knowledge.

In addition to standards and guidelines issued by governments and standards bodies, several researchers have proposed cyber-resilience frameworks that emphasise proactive defence and strategic preparation for future threats. At the small business level, work in entrepreneurial contexts shows that awareness, leadership, and scalable practices are critical for building resilience in resource-constrained firms [7]. These studies reinforce the need for approaches that combine practical guidance with a staged maturity pathway for small businesses, which is the role ARISE aims to fulfil [8].

Existing cybersecurity frameworks approach the problem from different directions. The Essential Eight is practical and prevention-oriented, but it does not by itself provide a complete resilience lifecycle. SMB1001 is closer to the needs of small businesses because it offers a staged maturity and certification pathway. COBIT [9] is valuable for governance and management of enterprise information and technology, but its scale and language are less suitable for many small firms. NIST CSF 2.0 provides a flexible outcome-based structure built around Govern, Identify, Protect, Detect, Respond, and Recover. ISO/IEC 27001 defines a formal information security management system, but implementation and certification may be difficult for small businesses with very restricted budgets.

Table 1. Comparison of selected cybersecurity frameworks and their relevance to ARISE.

Framework	Primary Focus	Small Business Suitability	Relevance to ARISE
Essential Eight [4]	Practical mitigation strategies and maturity levels for common cyber risks.	Strong baseline for Australian small businesses, especially for prevention and risk reduction.	Informs baseline controls and cyber hygiene in the prevention phase.
SMB1001 [5]	Progressive cybersecurity maturity pathway for small and medium-sized organisations.	Highly relevant because it is written for small business implementation and staged improvement.	Supports maturity thinking, certification awareness, and incremental improvement.
NIST CSF 2.0 [1]	Outcome-based cyber risk management across Govern, Identify, Protect, Detect, Respond, and Recover.	Flexible and adaptable but may require translation into practical small business tasks.	Provides a broader resilience structure and terminology for ARISE alignment.
ISO/IEC 27001 [3]	Formal information security management system and auditable requirements.	Useful as a mature benchmark, although certification may be costly for small firms.	Provides a reference point for governance, risk treatment, and continual improvement.
ISACA COBIT [9]	Governance and management of enterprise information and technology.	More suitable for larger organisations with established management structures.	Informs governance alignment but is not the main operational basis for ARISE.

summarises the comparison of selected cybersecurity frameworks and their relevance to the ARISE framework.

In contrast to broader futurist frameworks and SMB awareness programmes, ARISE combines cyber-resilience lifecycle thinking with explicit maturity levels and a concrete technical detection component based on low-cost tools.

Machine learning has also become an important part of contemporary intrusion-detection research. Supervised, unsupervised, semi-supervised, reinforcement, and evolutionary approaches have been applied to network-traffic analysis, anomaly detection, malware classification, and threat prediction. These methods can improve detection speed and assist with pattern recognition, but they can also introduce new risks; attackers may exploit AI to generate phishing content, automate social engineering, or poison training data. For small businesses, the practical question is therefore not whether machine learning can be powerful, but whether it can be used in a way that is understandable, affordable, and operationally safe.

Recent work emphasises that the spread of generative AI is reshaping the cybersecurity landscape by enabling both defensive automation and new forms of AI-powered attack and vulnerability discovery [10,11,12,13]. These studies propose taxonomies and frameworks for AI-driven risk management at enterprise scale, but they typically assume substantial analytical capability and dedicated security teams [10,11,12,13]. For micro and small businesses, the challenge is to benefit from lightweight AI support while remaining within realistic budgets and skill levels, which is the focus of ARISE.

2.1. Cybersecurity Challenges in Australian Small Businesses

Australian small businesses provide a useful context for examining the gap between recognised cybersecurity practice and everyday implementation capability. The ACSC survey results show that many small businesses recognise that cybersecurity is important yet still struggle to translate that recognition into structured investment, planning, and response capability [14,15]. This gap is not simply a technical issue. It reflects competing business priorities, limited time, uncertainty about where to begin, and the perception that cybersecurity frameworks are written for organisations with more staff and larger budgets.

The most relevant challenge for ARISE is that small businesses often experience cyber risk as a practical business problem rather than as a formal governance problem. A sole trader may need to protect customer records, invoices, and email accounts. A micro business may need to maintain access to a shared drive and cloud platform. A small software company may need secure development practices, backups, authentication controls, and incident-response decisions. These organisations need cybersecurity guidance that starts from their operational reality and then links that reality to recognised standards.

The original ARISE problem analysis identifies eight obstacle and vulnerability factors affecting small business cyber resilience. These include limited financial capacity, lack of internal security expertise, underestimation of cyber risk, inconsistent awareness, uncertainty about recovery time, dependence on external advisers, fragmented tool use, and difficulty aligning with formal frameworks. These factors interact with each other. For example, limited budget may prevent professional support, which then increases reliance on informal decisions, which in turn delays response and recovery when an incident occurs.

Table 2. Small business cybersecurity challenges motivating the ARISE framework.

Challenge	Typical Effect on Small Businesses	ARISE Response
Limited cybersecurity budget	Controls, training, and specialist advice may be postponed or avoided.	Prioritises low-cost tools, staged implementation, and practical support options.
Limited internal expertise	Staff may not understand alerts, vulnerabilities, or incident procedures.	Uses plain-language documentation and maturity-based guidance.
Low or uneven awareness	Phishing and social engineering risks remain high.	Places cyber awareness in the prevention phase and tests it through scenarios.
Weak recovery planning	The business may underestimate restoration time and customer impact.	Links backup checks, RTO/RPO thinking, and recovery retrospectives.
Fragmented standards	Frameworks may appear too complex or disconnected from daily work.	Maps recognised guidance into an agile small business workflow.
Dependence on external IT	Response can be delayed if roles and contacts are unclear.	Defines incident roles, escalation points, and decision thresholds.

shows the cybersecurity challenges motivating the ARISE framework.

2.2. Gap Analysis Leading to ARISE

The gap addressed by ARISE is located between mature cybersecurity frameworks and the practical starting point of many small businesses. Existing standards provide strong direction, but they often assume that the organisation can allocate people, time, governance structures, and budget to cybersecurity work. In a small business, the same person may be responsible for operations, customer service, finance, and technology decisions. This creates a need for a maturity pathway that is deliberately lightweight at the beginning, but capable of growing as risk and capability increase.

ARISE therefore does not attempt to replace NIST CSF, ISO/IEC 27001, the Essential Eight, or SMB1001. Instead, it uses them as reference points. The framework translates selected concepts into a more operational sequence: assess the current situation, identify the most important risks, select controls that can realistically be implemented, monitor for suspicious activity, respond using simple playbooks, recover from disruption, and update the next cycle of work. This structure allows recognised cybersecurity principles to be used without requiring the small business to adopt a full enterprise compliance programme from the first iteration.

This gap analysis also explains why the detection component is treated as one part of a wider resilience framework. A machine-learning classifier may help identify suspicious network patterns, but it cannot decide whether the business should notify clients, restore a backup, disable an account, or change staff training. ARISE links the technical detection activity to business decisions and learning cycles.

3. The ARISE Framework

The ARISE framework builds on cyclical resilience thinking, in particular the prevention, detection, response, and recovery logic of the Personal Cyber Security Model (PDR²) [16] The four phases are embedded within an agile improvement cycle so that small businesses can begin from an initial risk profile, implement manageable controls, review progress, and refine their maturity level over time. The remainder of the study uses ARISE as the central framework as follows: the practical interpretive case and Weka experiment are designed to examine, respectively, its organisational applicability and the feasibility of its detection phase. Figure 1 illustrates the generic PDR²-based ARISE maturity lifecycle.

The framework is not intended as a fixed checklist applied identically in every organisation. A micro-business with few staff, limited infrastructure, and low data sensitivity does not require the same implementation depth as a medium-sized organisation handling regulated information or complex software systems. ARISE therefore treats maturity level, operational complexity, system architecture, data sensitivity, and available resources as key implementation variables.

3.1. Design Principles

ARISE is based on four practical design principles. First, the framework must be accessible to organisations that do not employ cybersecurity specialists. Technical activities are therefore expressed as observable tasks, such as checking backups, reviewing privileged accounts, identifying shared drives, or confirming incident contacts. Second, the framework must be affordable. Low-cost and freeware tools cannot replace enterprise platforms but can help small businesses begin monitoring, documenting, and improving their security posture. Third, the framework must be adaptable. Small businesses differ in sector, data sensitivity, supply-chain exposure, and digital maturity, so a single implementation path is neither realistic nor desirable. Fourth, the framework must support learning, so that each sprint, incident, simulation, or audit contributes to the next cycle of prevention.

These principles distinguish ARISE from frameworks written primarily as compliance instruments. Compliance remains important, especially where personal data, regulated information, or contractual requirements are involved. However, many small businesses first require a practical way to understand their current exposure and move toward better practice. ARISE therefore treats alignment with formal standards as a maturity outcome rather than as the initial entry point.

Table 3. ARISE design principles and operational implications.

Principle	Reason for Inclusion	Operational Implication for Small Businesses
Accessibility	Many small businesses lack specialist security knowledge and cannot interpret complex standards.	Use plain-language guidance, examples, checklists, and clear decision points.
Affordability	Small businesses often operate with very limited cybersecurity budgets.	Prioritise freeware or low-cost tools, staged support, and gradual maturity improvement.
Adaptability	Cyber risks vary by sector, data sensitivity, architecture, and customer expectations.	Tailor controls to business context rather than applying a uniform checklist.
Agility	Cybersecurity priorities change as systems, threats, and regulations evolve.	Review risks and controls at the start and end of each sprint or improvement cycle.
Learning orientation	Resilience depends on organisational learning, not only technical restoration.	Use retrospectives, lessons learned, and updated risk registers after incidents or tests.

summarises the design principles and their operational implications.

Table 4. Condensed ARISE lifecycle and implementation focus.

Phase	Purpose	Typical Small Business Activities	Expected Output
Prevention	Make current weaknesses visible and reduce preventable exposure.	Initial risk survey, asset review, cyber awareness, authentication review, backup planning, basic hardening, penetration-test planning.	Prioritised risk register, baseline controls, sprint backlog, and awareness plan.
Detection	Identify suspicious or malicious activity early enough to act.	Packet capture, IDS/SIEM where feasible, Weka (3.8.6) or Python 3.x-based traffic classification, log review, vulnerability scans, malware triage.	Detection workflow, alert criteria, evidence logs, and escalation triggers.
Response	Provide consistent action once an event is detected.	Incident roles, IP blocking decisions, stakeholder notification, backup protection, containment playbooks, cloud-provider support contacts.	Incident response plan, playbooks, decision points, and communication templates.
Recovery	Restore operations and convert incidents into organisational learning.	System restoration, data recovery, integrity checks, business impact review, customer communication, lessons learned retrospective.	Recovery evidence, improvement actions, updated risks, and next-sprint priorities.

provides a condensed view of the ARISE lifecycle and implementation focus.

The prevention phase establishes the cybersecurity baseline. In a small business, this baseline includes an inventory of devices, accounts, software, cloud services, shared drives, backup locations, and externally managed services, together with identification of critical business processes such as invoicing, customer communication, product delivery, payroll, and access to project files. Risk assessment remains proportionate and uses a lightweight risk matrix to classify issues by likelihood and impact. The objective is not to produce an extensive risk-management document, but to create a manageable backlog of improvement tasks that can be addressed over several sprints. Penetration testing and vulnerability scanning are included because they help staff understand how an attacker might view the environment; for example, a nmap scan (e.g., nmap <IP address> -Pn -sV) in a controlled setting can illustrate the consequences of exposed services and outdated software.

Cyber awareness is treated as a core control rather than an optional training activity. Staff members are often the first to observe phishing emails, unusual shared-drive activity, unexpected login prompts, or suspicious attachments. ARISE therefore encourages practical awareness materials, scenario-based exercises, and short tests that match the organisation’s maturity level. Third-party resources may be used initially, while future versions of ARISE should include structured awareness pathways for different maturity levels.

The detection phase introduces the technical component of the framework. In this study, detection is explored through Weka-based machine learning experiments and a lightweight workflow using tools such as Wireshark [17] and NetworkMiner [18]. Wireshark captures network traffic in PCAP format, while NetworkMiner supports host and traffic analysis and exports relevant information for further processing. These tools are selected because their graphical interfaces enable small-business staff or external advisers to conduct basic monitoring and experimentation without developing a full software pipeline. To remain effective, ARISE must also provide accessible explanations of network traffic fundamentals and basic machine learning concepts so that non-specialist staff can interpret outputs and limitations.

Response and recovery phases convert detection into resilience. Detection is useful only if the organisation knows who will act, what will be isolated, when stakeholders will be notified, and how clean systems or data will be restored. The response phase therefore focuses on predefined playbooks and decision points, while the recovery phase ensures restoration of operations, confirmation that systems are safe, communication with affected stakeholders, and a retrospective review. The retrospective is central to ARISE because it transforms each incident, exercise, or simulation into concrete improvement actions for the next prevention cycle.

The Weka-based component of this study sits within the detection phase. It demonstrates how labelled network traffic can be used to train and compare classifiers using low-cost tools. In practical deployment, Weka should be treated as a learning and prototyping environment unless the organisation has a reliable pipeline for data collection, model updating, alert review, and response. Consistent with the overall design of ARISE, detection results are considered valuable only when they are integrated with clear response and recovery procedures.

3.2. ARISE Architecture and Workflows

ARISE is implemented as a lightweight socio-technical architecture that integrates organisational processes with low-cost technical controls. Figure 2 provides an overview of the architectural components and their relationships across the prevention, detection, response, and recovery phases.

At the infrastructure level, a typical small business is assumed to operate a small office network with several endpoint devices (workstations or laptops), a router or firewall providing internet access, shared storage (on-premises file server or cloud drive), and one administration workstation used by the owner or external IT support. Within this environment, ARISE introduces the following three main technical elements: (i) basic hardening and backup controls in the prevention phase, (ii) traffic and log capture for the detection phase, and (iii) incident logging and recovery artefacts for the response and recovery phases. These elements are complemented by organisational artefacts such as awareness materials, incident playbooks, and recovery checklists.

The detection phase embeds a simple packet-capture and analysis workflow. Network traffic is collected periodically from a monitoring point, such as a mirrored switch port, a designated gateway device, or a workstation configured to capture relevant flows. Wireshark is used to record traffic in PCAP format, and NetworkMiner is optionally employed to extract host- and session-level features that are exported as CSV or ARFF files. These files are then loaded into Weka, where pre-trained classifiers based on the UNSW-NB15 study [19] are applied to label network instances as benign or suspicious. The analysis is performed on the administration workstation or a dedicated low-cost laptop, which avoids the need for specialised server infrastructure.

Within this architecture, data flows proceed through a series of steps that align with the ARISE lifecycle:

Prevention. The organisation establishes an inventory of assets, defines critical business processes, applies baseline controls (such as backups, authentication hardening, and endpoint protection), and documents these activities in a simple risk register and sprint backlog.

Detection. At scheduled intervals or following specific triggers (e.g., suspected phishing emails), packet capture and log collection are initiated on the monitoring host. Captured data are pre-processed and analysed in Weka using selected classifiers and parameter settings derived from the experimental study (e.g., J48 with specified confidence factor and minimum leaf size). The analysis produces a summary of flows or hosts flagged as suspicious, together with basic metrics such as the proportion of traffic labelled as anomalous.

Response. When suspicious activity is identified, the ARISE response workflow specifies concrete actions: isolating affected endpoints from the network, disabling or resetting accounts, protecting backups, consulting external IT support, and initiating stakeholder communication as required. These actions follow predefined playbooks that assign roles, escalation thresholds, and decision points.

Recovery. After containment, systems and data are restored from known-good backups, integrity checks are performed, and operational and financial impacts are assessed. The organisation documents recovery time, residual issues, and lessons learned, which feed into the next prevention cycle via updated risk registers and sprint plans.

The security model for this architecture assumes that the monitoring host and analysis tools are trustworthy, that Weka is used in a decision-support role rather than as an automatic blocking mechanism, and that data capture is conducted in accordance with applicable privacy and regulatory requirements. In practice, this means that alerts and classifier outputs are reviewed by a responsible staff member or external adviser before any containment or notification decisions are taken.

By specifying where monitoring occurs, how data and classifier outputs flow through the ARISE phases, and how organisational artefacts such as playbooks and retrospectives are used, this architecture provides a reproducible blueprint that can be adapted to different small-business contexts without requiring enterprise-grade infrastructure.

3.3. Prevention Phase

The prevention phase establishes the cybersecurity baseline for ARISE deployments. In a small business, this baseline consists of a concise inventory of devices, user accounts, software applications, cloud services, shared drives, backup locations, and externally managed services. The inventory is linked to critical business processes (e.g., invoicing, customer communication, service delivery, payroll, and access to project files) so that technical assets can be prioritised according to business impact.

Risk assessment in ARISE is deliberately proportionate. A lightweight risk matrix assigns each identified issue a likelihood and impact score, for example classifying weak passwords as high likelihood/medium impact and shared-drive ransomware as lower likelihood/very high impact. The output is a ranked backlog of cybersecurity user stories and tasks, rather than an extensive risk-management document. This backlog is used to plan successive sprints and to track reductions in high-priority risks over time, providing input to the success indicators explained in Section 6.4.

Penetration testing and vulnerability scanning are included in the prevention phase to expose the environment from an attacker’s perspective. Commands such as nmap <IP address> -Pn -sV are executed in a controlled setting to identify open ports, running services, and software versions. For small businesses, this activity has both technical and educational value: staff and external advisers can directly observe which services are exposed, why outdated software or unnecessary open ports increase risk, and how mitigation actions (e.g., patching, port closure) reduce the attack surface.

3.4. Detection Phase

The detection phase focuses on identifying abnormal or malicious activity early enough to enable an effective response. ARISE does not assume that a small business can operate a full security operations centre; instead, it adopts a staged model. At the lowest maturity levels, detection relies on existing controls such as endpoint alerts, router or firewall logs, cloud-service notifications, and support from external IT providers. At higher maturity levels, organisations progressively add network traffic capture, intrusion detection rules, security information and event management (SIEM) dashboards, and machine learning-based analysis.

The Weka-based component of this study is situated within this phase. Using the UNSW-NB15 dataset [19], ARISE defines a set of network-traffic features and classifier configurations that can be applied to captured traffic in a small-business environment. In an operational deployment, packet captures from Wireshark or extracted flow features from NetworkMiner are exported as ARFF or CSV files and analysed on an administration workstation using pre-configured Weka classifiers (e.g., J48, JRip, RandomTree, Naive Bayes, and Decision Table) with the parameterisations reported in Section 4.6. The analysis produces labelled instances and summary statistics, such as the proportion of traffic classified as suspicious or the presence of flows resembling known attack categories.

In practice, Weka is treated as a learning and prototyping tool rather than as an autonomous blocking mechanism. Classifier outputs are reviewed by a designated staff member or external adviser and then fed into the ARISE response workflow. This ensures that detection results are linked to concrete decisions and playbooks, and that false positives or model limitations can be managed within the organisation’s risk appetite.

3.5. Response and Recovery Phases

The response phase specifies the actions that follow detection events. For small businesses, initial response procedures are intentionally simple and pre-agreed to avoid ad hoc decision making during an incident. Typical actions include disconnecting a suspected device from the network, disabling or resetting compromised accounts, suspending access to specific shared folders or cloud resources, contacting external IT support, preserving relevant logs or packet captures, and determining who is authorised to communicate with customers, regulators, or insurers. These actions are documented as short playbooks that assign roles, escalation thresholds, and decision points.

The recovery phase restores normal business operations and feeds structured learning back into the prevention phase. Recovery activities include restoration of systems and data from verified backups, integrity checks on restored services, assessment of operational and financial impact, and communication with affected stakeholders. Each incident or exercise concludes with a retrospective meeting, during which participants review what occurred, identify strengths and weaknesses in the response, and record improvement actions. These actions update the ARISE risk register, sprint backlog, and maturity scores, thereby closing the resilience loop and providing measurable input to the success criteria defined in Section 6.4.

4. Materials and ARISE Framework Methodology

This study adopts a multicomponent framework-development design rather than a single standalone experiment. Its purpose is to develop, position, and partially evaluate the ARISE framework from conceptual, practical, and technical perspectives that are appropriate for small businesses. The components of this design are: (i) a literature review and framework benchmarking that position ARISE in relation to recognised cybersecurity and maturity-model guidance, (ii) conceptual framework development that defines the prevention–detection–response–recovery lifecycle and associated design principles, (iii) a practical interpretive case used as a proof-of-concept context for RTA-informed interpretation and maturity-model benchmarking, and (iv) a Weka-based machine-learning experiment that examines the feasibility and limitations of low-cost intrusion-detection support using the UNSW-NB15 dataset.

The literature review and benchmarking work define the problem context and derive design requirements for ARISE, while the practical interpretive case provides a proof-of-concept setting for RTA-informed interpretation and maturity-model benchmarking. The full ARISE practical interpretive case and RTA benchmarking results are summarised here, with complete tables in Appendix A. The Weka-based machine-learning experiment represents the technical component of this design and focuses specifically on the detection phase of ARISE by evaluating lightweight classifiers on the UNSW-NB15 dataset. Figure 3 depicts the quantitative experimental workflow within this broader framework-development study, and

Table 5. Research design components and their contribution to the ARISE Framework.

Research Component	Purpose	Evidence or Data Source	Contribution to ARISE
Literature review and framework benchmarking	To position ARISE against recognised cybersecurity and maturity frameworks.	NIST CSF, ISO/IEC 27001, Essential Eight, SMB1001, COBIT, and the related literature.	Establishes theoretical grounding and standards alignment.
Conceptual framework development	To define ARISE phases, design principles, and maturity logic.	Framework synthesis and small business cybersecurity requirements.	Produces the prevention, detection, response, and recovery lifecycle.
Practical interpretive case	To examine how ARISE may be applied in a realistic small business context.	Scenario-based Case A, RTA-informed interpretation, and maturity-model benchmarking.	Supports practical positioning, usability reflection, and future empirical validation planning.
Weka machine-learning experiment	To evaluate whether low-cost machine-learning tools can support the detection phase.	UNSW-NB15 dataset and selected Weka classifiers.	Provides technical evidence for the detection component, but not full validation of ARISE.
Validation discussion	To assess ARISE using practical and conceptual criteria.	Usability, affordability, scalability, standards alignment, compliance readiness, and success criteria.	Explains how ARISE should be evaluated beyond classifier performance.

summarises how this experiment, together with the other components, contributes to the overall development and partial evaluation of the ARISE framework.

The methodological purpose of the practical interpretive case is not to claim statistical validation of ARISE across all small-business contexts. Instead, it provides a situated example through which ARISE can be interpreted, positioned, and compared with recognised maturity-model concepts. This is consistent with reflexive thematic analysis (RTA) [20], where quality is supported through reflexive interpretation, coherence, transparency, and contextual fit, and with maturity-model development, where early models are commonly assessed through conceptual relevance, practical usefulness, expert reflection, and iterative refinement before broader empirical testing.

4.1. Research Design Overview

This study adopts a multi-component framework-development design. The purpose of this design is to develop, position, and partially evaluate the ARISE framework from conceptual, practical, and technical perspectives. The study is therefore not presented as a single experimental validation of the entire framework. Instead, each component contributes a distinct form of evidence to the overall development and assessment of ARISE.

The literature review and framework benchmarking position ARISE in relation to established cybersecurity and maturity-model guidance. The practical interpretive case, used as a proof-of-concept evaluation, provides a realistic small-business context in which the framework can be examined using RTA-informed interpretation and maturity-model benchmarking. The Weka-based machine-learning experiment evaluates the feasibility of using low-cost tools to support the detection phase of ARISE. These components are integrated through the overarching objective of developing a practical, affordable, and iterative cyber-resilience framework for small businesses. Table 5 summarises the research design components and their contribution to ARISE.

4.2. Qualitative Model-Building Logic

The qualitative and design-oriented component of the study supports the conceptual development of ARISE. This component draws on framework benchmarking, small-business cybersecurity requirements, and scenario-based reasoning to define the prevention, detection, response, and recovery lifecycle. The resulting design is not intended to replace established frameworks such as NIST CSF, ISO/IEC 27001, the Essential Eight, or SMB1001, but to translate selected principles from these frameworks into a more accessible operational form for small businesses.

This model-building logic is also aligned with maturity-model thinking. Rather than if small businesses can implement a full cybersecurity programme from the outset, ARISE provides a staged pathway in which controls, monitoring, documentation, and response capability can be expanded progressively over time.

Table 6. Qualitative model-building activities in ARISE.

Stage	Main Questions	Output for the Framework
Comparative framework analysis	Which elements of recognised frameworks are useful for small business cyber resilience?	Reference concepts from Essential Eight, SMB1001, NIST CSF, ISO/IEC 27001, and COBIT.
Situation analysis	What risks, resources, systems, skills, and constraints does the small business currently have?	Initial maturity profile, risk register, and implementation assumptions.
ARISE model building	How can prevention, detection, response, and recovery be organised as an agile maturity cycle?	Framework phases, maturity attributes, sprint workflow, and support model.
Practical interpretive case	How can a realistic small business incident scenario help position ARISE within RTA and maturity-model benchmarking?	Phishing/shared-drive exercise, roles, metrics, interpretive insights, and lessons-learned process.
Refinement	What should change after each iteration or feedback cycle?	Updated guidance, revised maturity scoring, and future validation requirements.

summarises qualitative model-building activities in ARISE.

4.3. Practical Interpretive Case for RTA and Maturity-Model Benchmarking

The practical interpretive case is used as a proof-of-concept evaluation to examine how ARISE may operate in a realistic small-business environment. Its purpose is not statistical generalisation but contextual interpretation, usability reflection, and maturity-model positioning. Through this case, the study considers how organisational constraints such as limited staffing, budget pressure, uneven cyber awareness, and reliance on external IT support affect the implementation of prevention, detection, response, and recovery activities.

This use of a practical interpretive case is consistent with RTA-informed reasoning, in which emphasis is placed on coherence, transparency, and contextual fit rather than positivist claims of full validation. It also supports early-stage maturity-model development, where conceptual usefulness and practical relevance are important before broader empirical testing is undertaken.

Accordingly, the case functions as a bridge between conceptual framework development and future field validation. It enables assessment of the framework’s practical applicability, usability, affordability, and alignment with established cybersecurity maturity concepts, while also identifying elements that require clearer documentation or further empirical testing. Future work should extend this case-based analysis through direct engagement with small-business participants, including interviews, workshops, retrospective feedback, and real-world implementation data.

For RTA preparation, the scenario simulates realistic stakeholder feedback across different business roles. The resulting data structure is intended for subsequent analysis using Braun and Clarke’s six-phase RTA framework. This analysis will be used to identify and interpret patterns in how non-technical business owners and technically specialised staff understand and operationalise the ARISE requirements.

For maturity-model benchmarking, the simulated operational constraints of the scenario provide a controlled basis for comparing the ARISE 0–100 scoring model with established standards. Specifically, the case is used to examine the extent to which ARISE tier requirements align with the maturity levels of the Essential Eight, SMB1001, NIST CSF, and ISO/IEC 27001. In doing so, it highlights areas in which high-level frameworks may not adequately address the needs of resource-constrained micro-businesses. However, this case does not constitute full empirical validation; rather, it supports initial methodological positioning, framework refinement, and comparative benchmarking.

Table 7. Phishing and shared-drive encryption scenario for a small business.

Scenario Element	Operational Design	ARISE Relevance
Business context	A small office with approximately 10 employees, a shared drive containing client files, invoices, contracts, and reports, external IT support, and limited internal cybersecurity expertise.	Reflects a common small-business environment in which business continuity depends on access to shared data.
Trigger event	A simulated phishing email encourages a staff member to open a harmless test attachment or link, followed by controlled creation of “.locked” test files in a non-production folder.	Tests cyber awareness, early detection, and escalation without damaging real data.
Detection objectives	Observe whether staff recognise phishing indicators, identify unusual shared-drive behaviour, notify the appropriate person, and preserve basic evidence.	Connects staff awareness with technical monitoring and reporting.
Response objectives	Isolate the affected endpoint, disable the test shared folder if required, contact external IT support, and decide whether customers or authorities would need to be informed.	Tests incident roles, communication paths, and decision thresholds.
Recovery objectives	Restore the test folder from backup, confirm data integrity, document time to recovery, and conduct a short retrospective.	Demonstrates whether the business can return to normal operation and learn from the exercise.
Evaluation metrics	Time to detect, time to report, time to contain, recovery time, quality of communication, and number of improvement actions identified.	Provides measurable evidence for maturity improvement between iterations.

summarises the phishing and shared-drive encryption scenario used in this study.

The phishing-plus-shared-drive pattern was selected because it is readily understandable to non-specialist staff and closely resembles common ransomware entry pathways in small organisations. It also enables the prevention, detection, response, and recovery phases of ARISE to be examined within a single exercise. The scenario may initially be conducted as a tabletop exercise and subsequently extended into a controlled technical simulation.

4.4. Dataset

The quantitative experiment used the UNSW-NB15 dataset [17], which contains contemporary network traffic records representing both normal activity and multiple attack categories. The original dataset contains 45 attributes and more than 2.39 million records. For the present study, a ranked subset containing 1,048,575 instances and 11 selected attributes was used to support efficient experimentation in Weka and to focus on features with higher discriminatory value.

Table 8. Selected UNSW-NB15 attributes used in the Weka experiment.

No.	Attribute	Interpretation
1	Info	Summary information about packet or flow characteristics.
2	FLOW_DURATION_MILLISECONDS	Duration of the network flow in milliseconds.
3	SERVER_TCP_FLAGS	TCP flag information observed from the server side.
4	DURATION_OUT	Outbound duration indicator.
5	DURATION_IN	Inbound duration indicator.
6	MIN_TTL	Minimum time-to-live value observed in the flow.
7	FTP_COMMAND_RET_CODE	FTP command return code where applicable.
8	SHORTEST_FLOW_PKT	Shortest packet length in the flow.
9	LONGEST_FLOW_PKT	Longest packet length in the flow.
10	MAX_TTL	Maximum time-to-live value observed in the flow.
11	Attack	Target class label.

shows these selected attributes used in the Weka experiment.

The use of UNSW-NB15 is appropriate for the study because it provides a recognised benchmark for intrusion-detection research while remaining suitable for comparison across multiple classifiers in a low-cost experimental environment. This aligns with the aim of examining whether accessible tools can contribute to the detection phase of ARISE without requiring enterprise-scale infrastructure.

4.5. Preprocessing and Attribute Selection

Preprocessing focused on reducing dimensionality and retaining attributes most useful for classifier performance. Attribute selection was performed using Weka’s ClassifierAttributeEval, which evaluates the usefulness of individual attributes in relation to classification performance. The resulting reduced dataset retained 11 attributes, including flow-duration, flag-related, packet-length, and time-to-live features, together with the class label used for attack categorisation.

This preprocessing step was intended to simplify experimentation, reduce computational overhead, and reflect a workflow that could realistically be reproduced by small businesses or external advisers using limited resources. Table 8 summarises the selected attributes used in the experiment.

4.6. Classifier Selection and Parameterisation

The following five classifiers available through the Weka graphical interface were selected for the experiment: J48, JRip, Random Tree, Decision Table, and Naive Bayes. These algorithms were chosen because they are widely used in applied machine learning, comparatively interpretable, and suitable for experimentation with labelled ARFF or CSV data without requiring a dedicated software-development pipeline. This selection is consistent with the ARISE objective of using methods that can be understood by small businesses, external advisers, or technically capable staff working with limited resources.

Unless otherwise stated, classifiers were executed using the default parameter settings provided in Weka. This choice improves reproducibility for non-specialist users and reflects the practical assumption that many small businesses or external advisers would initially rely on standard software configurations rather than advanced hyperparameter tuning.

Table 9. Selected Weka classifiers and key parameter settings.

Classifier	Weka Class Name	Parameter	Value Used
J48	weka.classifiers.trees.J48	Confidence factor (-C)	0.25
		Minimum instances per leaf (-M)	2
Decision Table	weka.classifiers.rules. DecisionTable	Cross-validation folds (-X)	1
		Search method (-S)	BestFirst (direction: 1, look-ahead: 5)
JRip	weka.classifiers.rules.JRip	Folds for reduced-error pruning (-F)	3
		Minimum total weight of instances (-N)	2.0
		Optimisation runs (-O)	2
		Random seed (-S)	1
Naive Bayes	weka.classifiers.bayes. NaiveBayes	—	Default configuration
Random Tree	weka.classifiers.trees. RandomTree	Attributes considered per split (-K)	4
		Minimum total weight per leaf (-M)	1.0
		Minimum variance proportion (-V)	0.001
		Random seed (-S)	1

summarises the classifiers and the key parameter settings applied in the experiment.

Table 9 summarises the exact classifier configurations applied in Weka. J48 was run with a confidence factor of 0.25 and a minimum of two instances per leaf, representing the standard pruning settings for this decision-tree implementation. Decision Table used a single cross-validation fold with a BestFirst attribute-search strategy, allowing the algorithm to identify the most informative feature subset efficiently. JRip was configured with three folds for reduced-error pruning, a minimum instance weight of 2.0, and two optimisation runs. Naive Bayes was applied using default settings without kernel estimation or supervised discretisation. Random Tree was configured to consider four randomly selected attributes at each split node, with a minimum leaf weight of 1.0 and a variance threshold of 0.001. All classifiers were evaluated using ten-fold cross-validation on the selected UNSW-NB15 feature set. These configurations are reproducible within the Weka 3.8 graphical interface without requiring custom code or scripting, which is consistent with the ARISE principle of affordability and accessibility for small-business advisers.

4.7. Evaluation Procedure

The experiment used the following two evaluation settings: a 75/25 train-test split and five-fold cross-validation. These complementary settings were used to examine both hold-out predictive performance and internal stability across repeated partitions of the dataset.

Aggregate performance metrics included accuracy, mean absolute error, root mean squared error, true positive rate, false positive rate, precision, recall, F-measure, Matthews correlation coefficient, ROC area, and PRC area. These measures were selected to provide a broader view of classifier behaviour than accuracy alone, especially in the context of class imbalance and uneven attack representation. In addition to aggregate results, class-level findings were reviewed to determine whether strong overall performance concealed weak detection of minority attack classes, which is a practical concern in intrusion-detection settings.

The purpose of the experiment was to examine whether selected low-cost and accessible machine-learning tools could classify network intrusion data with sufficient performance to support the ARISE detection phase. The experiment therefore provides technical evidence for one component of ARISE rather than full validation of the entire framework.

5. Results

Section 5 reports the quantitative results of the Weka-based machine-learning experiment, which forms the technical component of the multicomponent framework-development design described in Section 4. In line with the ARISE detection phase, the experiment evaluates selected lightweight classifiers on the UNSW-NB15 dataset to examine their feasibility for supporting small-business intrusion detection. The focus of this section is therefore on classifier performance, trade-offs, and limitations, rather than on validating the entire ARISE framework.

Within the multicomponent framework-development design, this section reports the quantitative results of the Weka-based experiment that examines the detection phase of ARISE. The aggregate results show that tree- and rule-based methods performed strongly on the selected dataset. J48 achieved the highest accuracy under both evaluation settings, while JRip and Random Tree also performed well. Naive Bayes produced lower aggregate performance and weaker correlation, indicating that its independence assumptions were less suitable for the selected feature set. However, the results should be interpreted carefully. Near-perfect ROC and PRC values indicate excellent discrimination within this experimental setting, but they do not prove that the model will generalise unchanged to live small business traffic.

Table 10. Weka weighted average classifier results including MAE, RMSE, ROC are and PRC using a 75/25 train-test split.

Classifier	Accuracy (%)	MAE	RMSE	ROC Area	PRC Area	Interpretation
JRip	99.9245	0.0002	0.0112	0.981	0.999	Strong rule-based performance, with some false-positive sensitivity.
J48	99.9294	0.0002	0.0106	1.000	0.999	Best aggregate result and strong interpretability for decision paths.
Random Tree	99.9203	0.0002	0.0119	1.000	0.999	Very strong aggregate result, but individual trees can be less stable.
Decision Table	99.9172	0.0005	0.0129	1.000	0.999	Strong result with a simple rule-table structure.
Naive Bayes	99.3412	0.0015	0.0347	0.998	0.998	Lower overall performance and weaker Matthews correlation.

shows the results with 75/25 train-test split. A detailed exploratory analysis of the UNSW-NB15 dataset is provided in Appendix A.

Table 11. Weka weighted average classifier results including TP-rate, FP-rate, F-Measure, Precision and Recall values using a 75/25 train-test split.

Classifier	TP Rate	FP Rate	Precision	Recall	F-Measure	Summary Interpretation
JRip	0.999	0.038	N/A	0.999	N/A	Very high detection and recall, but a moderate false-positive rate means some normal traffic may be incorrectly flagged. Precision and F-measure were not reported.
J48	0.999	0.000	N/A	0.999	N/A	Very high detection and recall with no reported false positives, making it one of the strongest models for practical intrusion detection. Precision and F-measure were not reported.
Random Tree	0.999	0.000	0.999	0.999	0.999	Excellent and balanced performance across all reported metrics, with very high detection, precision, recall, and F-measure, and no reported false positives.
Decision Table	0.999	0.036	N/A	0.999	N/A	Very high detection and recall, but a moderate false-positive rate suggests a higher chance of false alerts than J48 and Random Tree.
Naive Bayes	0.993	0.192	0.997	0.993	0.995	Strong overall performance, but the highest false-positive rate indicates weaker practical reliability compared with the tree-based models.

shows the Weka classifier results including TP-rate, FP-rate, F-Measure, Precision and Recall values using a 75/25 train-test split.

Table 12. Weka weighted average classifier results including TP-rate, FP-rate, F-Measure, Precision and Recall using a five-fold cross-validation.

Classifier	TP Rate	FP Rate	Precision	Recall	F-Measure	Summary Interpretation
JRip	0.999	0.044	N/A	0.999	N/A	Very high detection and recall, but the false-positive rate is higher than J48, Random Tree, and Decision Table, meaning more normal traffic may be incorrectly flagged.
J48	0.999	0.000	N/A	0.999	N/A	Very high detection and recall with no reported false positives, indicating very strong practical performance for intrusion detection.
Random Tree	0.999	0.000	N/A	0.999	N/A	Very high detection and recall with no reported false positives, showing similarly strong performance to J48 in this evaluation.
Decision Table	0.999	0.033	N/A	0.999	N/A	Very high detection and recall, but a moderate false-positive rate suggests some risk of false alerts in practical use.
Naive Bayes	0.993	0.013	0.998	0.993	0.995	Strong overall performance with high precision, recall, and F-measure; its false-positive rate is low, although its TP rate is slightly lower than the tree-based models.

and

Table 13. Weka weighted average classifier results including ROC and PRC using a five-fold cross-validation.

Classifier	Accuracy (%)	ROC Area	PRC Area	Summary
JRip	99.9264	0.981	0.999	Stable rule-based performance across folds.
J48	99.9333	1.000	0.999	Highest cross-validation accuracy and strong discriminative performance.
Random Tree	99.9241	1.000	0.999	High accuracy, with results close to train-test performance.
Decision Table	99.9241	1.000	0.999	Simple structure with strong aggregate results.
Naive Bayes	99.3262	0.999	0.998	Lower performance relative to tree and rule-based methods.

show Weka weighted average classifier results using five-fold cross-validation.

The class-level analysis is more cautious than the aggregate metrics. J48 produced very strong results for common classes such as benign traffic, exploits, fuzzers, reconnaissance, and shellcode. However, categories such as generic, backdoor, denial-of-service, worms, and analysis were more difficult to classify reliably in the selected experimental configuration. This matters for practical deployment because small businesses should not rely only on a single headline accuracy value. In operational use, the model should be checked against class-specific recall, false positives, and false negatives, especially for attack categories that are rare but high impact.

The results support the feasibility of lightweight machine learning experimentation within the ARISE detection phase, but they also show why human review, threshold tuning, and iterative improvement remain necessary. A model that performs well on a public dataset still needs local calibration, ongoing monitoring, and a clear response process before it can support operational cyber resilience.

5.1. Interpretation of ROC and PRC Results

ROC and PRC areas close to 1.000 indicate that the classifier separates the evaluated classes very well under the test conditions. In this experiment, the high values achieved by J48, Random Tree, and Decision Table suggest that the selected features contain strong discriminatory information. However, such results should not be interpreted as proof that intrusion detection is solved. Public datasets may contain patterns that are easier to learn than live traffic, and preprocessing decisions can strongly influence performance.

The PRC area is particularly important in intrusion detection because attack classes are often imbalanced. A high ROC area can remain impressive even when rare classes are not detected well. PRC values provide a more direct view of precision and recall, which helps assess whether positive attack predictions are useful and whether relevant attacks are being missed. For ARISE, this means that small business-facing guidance should explain not only how to run classifiers, but also how to read evaluation outputs responsibly.

In practical terms, a small business should not deploy a model simply because the weighted ROC or PRC area is high. It should first examine confusion matrices, class-level recall, false positives, false negatives, and the business cost of different errors. A false positive may interrupt work, but a false negative may allow an intrusion to continue unnoticed. The best threshold therefore depends on the organisation’s tolerance for disruption, the sensitivity of its data, and the availability of staff or external support to investigate alerts.

5.2. Implications for Small Business Deployment

The experimental results support the inclusion of Weka in the ARISE toolset because it offers a practical entry point for small businesses and advisers who need to understand machine learning without writing code. Weka’s graphical interface, attribute selection options, classifier library, and visual evaluation tools can help users learn how network traffic features relate to attack classification. This educational value is important because small businesses often need to build cyber capability gradually.

At the same time, Weka should be positioned carefully. It is suitable for experimentation, training, and prototyping, but a live detection environment also requires reliable data collection, secure storage, automated or semi-automated processing, alert review, and documented response actions. For this reason, ARISE treats Weka as part of a staged maturity path. Early-stage users may use it to understand detection concepts. More mature users may integrate Python libraries, SIEM tools, cloud logging, or managed detection services as their capability grows.

6. Validation Discussion

Section 6 integrates the findings from the preceding components to provide a multidimensional, but explicitly partial, validation of the ARISE framework. Conceptual validation is drawn from the alignment of the ARISE framework with recognised cybersecurity standards and maturity-model guidance; practical validation is initiated through the practical interpretive case and its RTA-informed interpretation; and technical validation is provided by the Weka experiment, which assesses the behaviour of lightweight classifiers within the detection phase. Together, these strands support an initial assessment of ARISE as a practical and affordable framework for small businesses, while also identifying the need for future empirical deployment studies across multiple organisations.

Within the multicomponent framework-development design, the validation of the ARISE framework is approached as a multidimensional process. The Weka experiment evaluates the feasibility of the detection phase, while the broader framework is assessed through conceptual coherence, standards alignment, practical applicability, usability, affordability, scalability, compliance readiness, and sustainability. This distinction is important because ARISE is a cybersecurity maturity framework, not only an intrusion detection model. A high-performing classifier may support one part of ARISE, but it does not demonstrate that the framework is usable, affordable, scalable, or sustainable for small businesses.

Table 14. Multi-dimensional validation approach for the ARISE Framework.

Validation Dimension	How It Is Addressed in This Study	Limitation	Future Validation Requirement
Conceptual coherence	ARISE is structured around prevention, detection, response, and recovery.	Framework logic is currently developed conceptually.	Expert review and stakeholder validation.
Standards alignment	ARISE is benchmarked against Essential Eight, SMB1001, NIST CSF, ISO/IEC 27001, and COBIT.	Alignment is interpretive rather than independently audited.	Formal mapping and external review.
Detection feasibility	Weka classifiers are tested using the UNSW-NB15 dataset.	Public dataset does not represent live small business traffic.	Testing with real or simulated network data.
Practical applicability	A practical interpretive case is used to examine small business use.	Scenario-based, not a live deployment.	Pilot implementation with small business participants.
Usability	The framework emphasises plain language, checklists, and low-cost tools.	User testing has not yet been completed.	Interviews, surveys, and usability feedback.
Affordability	ARISE prioritises low-cost tools and staged support.	Cost assumptions require testing.	Cost–benefit evaluation in real small businesses.
Compliance readiness	APP, GDPR, and breach-response readiness are discussed.	ARISE is not a legal certification mechanism.	Privacy expert review and jurisdiction-specific mapping.
Sustainability	Agile retrospectives and sprint-based improvement are built into ARISE.	Long-term adoption has not yet been observed.	Longitudinal field study.

summarises the validation dimensions for the ARISE Framework.

In the Australian context, the Office of the Australian Information Commissioner (OAIC) codifies privacy obligations through the Australian Privacy Principles (APPs), which govern the collection, use, and disclosure of personal information. When combined with the GDPR for organisations handling EU data, these principles create explicit expectations regarding breach notification, data minimisation, and security safeguards that small businesses must address within their resilience planning.

6.1. Global Compliance and Data Protection

Although ARISE is initially designed for Australian small businesses, its future relevance depends on the ability to recognise global compliance obligations. Small businesses may serve international customers, store data in cloud platforms located overseas, or collaborate with partners subject to different privacy and cybersecurity rules. For this reason, future versions of ARISE should include a compliance mapping layer that translates local and international requirements into practical small business tasks.

The General Data Protection Regulation (GDPR) is particularly relevant when a small business offers goods or services to individuals in the European Union or monitors their behaviour. ARISE should therefore incorporate privacy-by-design and data-protection-by-default principles into the prevention phase. This would include data minimisation, purpose limitation, access control, retention planning, encryption where appropriate, and clear incident reporting responsibilities [10,11,12,13]. In the Australian context, alignment with the Australian Privacy Principles can support consistency with local privacy expectations, especially where personal information is collected, stored, or processed [21].

The compliance layer should not make ARISE a legal certification scheme. Instead, it should help small businesses recognise when legal advice, privacy review, breach notification, or customer communication may be required. This approach keeps the framework practical while acknowledging that cyber resilience is increasingly connected to data governance, privacy rights, and cross-border accountability.

6.2. Affordability and Real-World Deployment

A central reason for developing ARISE is the gap between recognised cybersecurity guidance and the practical capacity of many small businesses. A framework that requires expensive certification, continuous consultant support, or enterprise-grade platforms may be conceptually strong but operationally unrealistic. ARISE therefore prioritises low-cost tools, incremental maturity, and guided decision-making. The proposed basic support model of AUD 350 per year, including up to 50 h of support, is intended to give small organisations a realistic entry point. More advanced options involving generative AI, managed detection, or specialist support may require higher costs and should be treated as optional maturity steps rather than as baseline requirements.

Real-world deployment should begin with a small and manageable sprint. The first iteration can focus on the following highest-value basics: asset visibility, cyber awareness, backups, authentication, shared-drive protection, incident contacts, and a simple detection workflow. Later sprints can introduce penetration testing, log analysis, Weka experiments, SIEM integration, or automated response. This gradual approach is important because small businesses often need to keep operating while improving security.

6.3. Applicability to Different Small Business Contexts

The applicability of ARISE lies in its ability to support organisations that require a structured but realistic pathway to cyber resilience. Its main value is not only in the four phases of prevention, detection, response, and recovery, but in the way those phases are organised as an iterative process. This makes the framework suitable for organisations that cannot implement a complete cybersecurity program immediately but can improve their maturity progressively.

ARISE is particularly applicable to resource-constrained small business organisations with low cybersecurity maturity, early-stage digital product teams, and businesses that need practical guidance rather than complex standards. It may also be useful for organisations that already follow agile project management, because cybersecurity tasks can be included in sprint planning, sprint reviews, and retrospectives. In this setting, cyber resilience becomes part of normal work rather than a separate technical project.

Table 15. Applicability areas for ARISE.

Applicability Area	Reason ARISE Is Suitable
Resource-constrained small businesses	The framework supports businesses that cannot afford full-time cybersecurity experts or enterprise security platforms.
Low-maturity environments	ARISE provides a structured starting point for organisations with limited cyber awareness or informal controls.
Australian small businesses	The initial design aligns with local guidance such as the Essential Eight and SMB1001.
Early-stage system development	Cybersecurity can be considered before systems, products, or services are fully deployed.
Continuous improvement environments	The agile cycle supports regular review of risks, controls, incidents, and maturity.
Practical guidance needs	The framework uses checklists, examples, decision points, and staged implementation rather than dense technical language.

shows different applicability areas for ARISE framework.

6.4. Success Criteria

The success of the ARISE framework should be assessed using both quantitative and qualitative indicators. Quantitative indicators include changes in cybersecurity maturity scores, reductions in the number of unmanaged high-risk issues, shorter detection, response, and recovery times, and improvements in class-level detection performance in technical experiments. Qualitative indicators include staff confidence, clarity of incident roles, quality of documentation, realism of budget planning, and the degree to which cybersecurity activities are integrated into normal business processes.

Because ARISE is iterative, success is not measured at a single point in time but by comparing the organisation’s position across several improvement cycles. For example, in the phishing-and-shared-drive encryption exercise, an initial iteration may reveal that no formal incident roles exist, backups have not been recently tested, and detection relies solely on ad hoc staff reporting. After four ARISE cycles, the same organisation would be expected to have assigned explicit incident roles, introduced a basic packet-capture and Weka analysis workflow, reduced the time from simulated phishing click to detection alert, documented recovery steps for the shared drive, and increased its ARISE detection score from, for instance, 20/100 to 40/100. These values are not universal thresholds, but they illustrate how the framework can be evaluated using observable changes rather than declarative statements alone.

Similarly, in the Weka experiment based on the UNSW-NB15 dataset, success for the detection component is evidenced by classifier configurations that achieve high overall accuracy while also improving detection of selected attack categories compared with a naive baseline. In practical deployment, such results would be interpreted as technical feasibility evidence that low-cost tools can meaningfully support the detection phase within ARISE, subject to the organisational constraints described in Section 3.2.

Because ARISE is iterative, success should not be measured only once. A more suitable approach is to compare the organisation’s position across several sprints. For example, after four improvement cycles, a business may be expected to complete most of its high-priority cybersecurity user stories, improve its awareness score, document response actions, and demonstrate that backups can be restored. These indicators are not universal thresholds, but they provide a practical basis for evaluating whether the framework is producing visible progress.

Table 16. Example ARISE success indicators.

Indicator Type	Example Measure	Interpretation
Risk management	Number of high-priority risks reduced or assigned to a treatment plan.	Shows whether the prevention phase is producing action.
Detection	Time from suspicious event to alert or staff report.	Shows whether monitoring and awareness are improving.
Response	Time from report to containment decision.	Shows whether roles and playbooks are clear.
Recovery	Time to restore test files or services and confirm integrity.	Shows whether backup and restoration processes are reliable.
Maturity	Change in ARISE score across iterations.	Shows whether improvement is visible over time.
Learning	Number and quality of retrospective actions completed.	Shows whether incidents and exercises lead to organisational learning.

lists example ARISE success indicators.

7. Discussion

The findings suggest that ARISE should be understood as an integrated organisational framework rather than as a standalone technical detection model. The machine learning results demonstrate that accessible tools such as Weka can support the detection phase, particularly in experimental or training contexts. However, detection is only one part of cyber resilience. In practice, a small business must also understand its risks, implement feasible controls, respond consistently to incidents, recover operations, and use lessons learned to improve the next iteration [22].

The practical interpretive case suggests that ARISE should operate as an organisational process rather than as a purely technical model. A phishing email, shared-drive compromise, or ransomware incident can affect staff behaviour, customer trust, business continuity, backup strategy, and legal decision-making. For this reason, ARISE connects technical detection with response planning, recovery processes, stakeholder communication, and retrospective learning.

The primary limitation of this study is that ARISE has not yet been validated through multiple live small business deployments. The Weka experiment uses a public dataset rather than live small business traffic, and the practical interpretive case is scenario-based. Future work should therefore apply ARISE in real small business environments, collect stakeholder feedback, test the maturity scoring model, and evaluate whether the framework improves resilience across several agile iterations. Taken together, the framework benchmarking, interpretive case, and Weka experiment therefore provide complementary conceptual, practical, and technical evidence for ARISE, while also identifying concrete requirements for future empirical validation.

Although ARISE currently focuses on low-cost tools such as Weka, future iterations could incorporate selected generative AI capabilities, for example, to assist with log summarisation or prioritisation of incidents, while remaining aligned with emerging AI-focused cybersecurity frameworks [17,18,19].

8. Conclusions and Future Work

This paper proposed ARISE as a practical and iterative cyber resilience framework for small businesses. The study combined framework benchmarking, conceptual framework development, a practical interpretive case, and Weka-based machine-learning experiments. These components contribute different forms of evidence. Framework benchmarking supports theoretical and standards alignment. The practical interpretive case supports methodological positioning and future field validation planning. The Weka experiment provides technical evidence for the feasibility of the detection phase.

The study does not claim that the entire ARISE framework has been fully validated through the classifier experiment. Rather, it shows that ARISE has practical potential and that its detection phase can be supported by accessible machine learning tools. The validation of ARISE requires future empirical research with small business participants, expert review, usability testing, maturity scoring refinement, and longitudinal assessment. This staged approach is appropriate because ARISE is intended to evolve through agile learning, practical feedback, and continuous improvement.

Future research will transition ARISE into an empirically validated model by testing its usability in real small business environments and benchmarking its scoring against established standards like NIST CSF and ISO/IEC 27001 or EU NIS2 Directive. Additionally, future work will cautiously investigate AI-driven, agent-based threat intelligence, ensuring robust ethical governance and human oversight for small business applications.

Table 17. Proposed future research directions.

Future Work Area	Purpose	Expected Contribution to ARISE
Real small business evaluation	Apply ARISE in micro and small business settings	Tests practical usability, affordability, and organisational fit
Reflexive thematic analysis	Analyse stakeholder feedback from interviews, workshops, and retrospectives	Identifies themes for improving ARISE documentation, phases, and maturity guidance
Maturity scoring refinement	Test and improve the ARISE scoring model	Supports more transparent and repeatable maturity assessment
Framework benchmarking	Compare ARISE with Essential Eight, SMB1001, NIST CSF, and ISO/IEC 27001	Positions ARISE within the established cybersecurity maturity-model literature
GenAI-supported prevention	Explore LLMs, XAI, synthetic data, and simulation for vulnerability assessment and risk prioritisation	May strengthen the prevention phase, but requires careful validation
AI-agent-based threat intelligence	Investigate controlled agent harvesting for collecting and prioritising threat signals	May support small businesses with limited cybersecurity expertise if human oversight and governance are included
Ethical and governance controls	Examine privacy, data retention, explainability, and misuse risks	Ensures future AI-supported ARISE functions remain responsible and legally appropriate

summarises the proposed future research directions.

Overall, future work should develop ARISE gradually and avoid presenting GenAI or agent-based automation as a replacement for human judgement. These technologies may support small business cyber resilience, particularly in threat intelligence and risk prioritisation, but their role must be tested through controlled studies, expert review, and real-world feedback. In this way, ARISE can evolve toward more proactive cybersecurity support while remaining practical, affordable, and methodologically defensible for small business environments.