This paper aims to examine what contextual knowledge should be documented during the information classification process and how such knowledge can be structured to support information security risk management. Although many tools support documentation of basic classification outputs, they often lack functionality for capturing decision rationales or supporting classification discussions to be kept in a record.
The study used a qualitative approach. Data were collected through 16 semi-structured interviews with information security professionals and observations of 14 tool demonstrations. A thematic analysis was conducted and guided by an existing classification method based on ISO/IEC 27002.
The study identifies a range of contextual knowledge that practitioners consider important to document, including the classification level, decision rationale and responsible roles. Furthermore, it proposes a structured approach consisting of recommended contextual knowledge to include in a classification record, which may serve as a starting point for organisations conducting information classification. Finally, the study contributes procedural knowledge by clarifying how classification decisions are documented and what information should be retained.
This study addresses an identified gap in both research and practice by specifying what contextual knowledge should be documented during information classification. It provides practical guidance for improving documentation practices and highlights opportunities for tool development in information classification.
1. Introduction
Most, if not all, organisations must manage information security risks to avoid, for example, operational, financial or reputational damage (Whitman and Mattord, 2022). Managing risk is particularly important in the public sector, where risk realisation can not only disrupt essential services and erode public trust but also cause consequences that extend beyond the organisation itself, causing societal effects (van Laere and Lindblom, 2019). Organisations can adopt information security risk management (ISRM) frameworks, which offer structured approaches to mitigate and reduce risk (Gritzalis et al., 2018). ISRM generally centre around three key activities forming the process of risk assessment: asset identification and classification, risk analysis and risk treatment (Silva and Jacob, 2018; ISO/IEC 27005, 2022). These activities are interdependent, with each step relying on the output of the previous one, underscoring the importance of reliable inputs at every stage. That is, an organisation identifies and classifies an asset, followed by a risk analysis targeting threats to that asset. Finally, the organisation will have to either accept the level of risk or implement security controls to lower it.
A critical input for risk analysis is the classification of assets based on their value to the organisation, known as information classification (Gerber and Von Solms, 2005; Tankard, 2015). If the information classification process is not performed correctly, it could lead to unreliable input to the risk analysis and, consequently, inaccurate risk management, following the principle of “garbage in, garbage out” (Shamala et al., 2017, p. 2). If the classification is not conducted at all, organisations risk consequences beyond the loss of input to the risk analysis. In several countries, public sector organisations are legally required to work systematically with information security. For example, in Sweden, regulations stipulate that public authorities must work in a risk-based manner by classifying their information assets, identifying risks, and applying and monitoring appropriate security measures (MSB, 2020). Similarly, in Japan, subcontractors are required to establish and apply information classification to be considered for government contracts (METI, 2025).
Despite its importance, information classification is still an understudied area (Shedden et al., 2016; Bergquist et al., 2021), and it is widely recognised as a challenging process, with difficulties such as subjective judgments, deciding which security aspects (for example, confidentiality, integrity and/or availability) to consider, choosing the right level of granularity for classifying assets and determining what information to include in the classification (Andersson, 2023; Shedden et al., 2016; Fibikova and Müller, 2011; Whitman and Mattord, 2022; Grimaila and Fortson, 2007). In other words, classification contains several challenges besides making a classification decision.
Although the literature on information classification is limited, some contributions address the classification process. For instance, Bergström et al. (2021) developed a method based on ISO/IEC 27002 (2022). Other studies, such as Bergquist et al. (2021), investigated tools and specific parts of the classification process, while Bradford et al. (2022), examined the process and provided general insights from security managers. What these contributions have in common, whether describing the process or only parts of it, is that none address what should be documented and kept in a record during the classification process in any depth. This is problematic, as records are essential for understanding why classification decisions were made and which factors were considered. Such understanding is particularly important for reclassification and for providing input to the risk analysis.
While we do know that some aspects of the classification process must be documented, such as the final classification value assigned to an asset, existing research does not provide comprehensive guidance on what else should be documented. Current literature, such as Bergström et al. (2021), suggests that a record should be created but does not explicate its contents. A concept similar to records is that of documents, which can be understood as carriers of knowledge (Alavi and Leidner, 2001), or as records that have been further contextualised and formalised. Although the terms “record” and “document” are often used interchangeably, in this paper, a record refers specifically to the knowledge gathered throughout the execution of a process. The process of creating the record we refer to as “documenting”.
The value of records aligns with key concepts in knowledge management, where they are seen as vehicles for capturing, sharing and reusing organisational knowledge (Alavi and Leidner, 2001; Yeo, 2018). In particular, contextual knowledge, such as organisational members’ understanding of asset values in a specific organisational setting, can be preserved through structured documentation and be used to support future decisions (Nunes et al., 2009). Capturing contextual knowledge helps ensure that important insights are not lost over time, which aligns with knowledge management efforts to promote continuity and shared understanding across the organisation (Nonaka et al., 2000). Procedural knowledge, on the other hand, refers to the knowledge of how to perform a specific task (Anderson and Crawford, 1995), such as tasks or activities in the information classification process. To clarify the difference between the two in the context of information classification, we argue that contextual knowledge refers to what type of knowledge is to be gathered, and procedural knowledge is how to gather it. To support the collection of such knowledge, a knowledge management strategy can be formulated, which is a statement on how knowledge should be gathered and used. Using such a strategy has been shown to improve decision-making performance (Willman et al., 2022).
Records connected to ISRM have, in previous literature, been explained to be important for several reasons. Keeping up-to-date records is considered to be a cornerstone of good information security management (Mattord and Wiant, 2016), this is achieved by documenting, sharing and verifying the outcomes of different security processes to ensure that well-informed choices are made (Barraza de la Paz et al., 2023). Records are also essential in the event of audits or when revisiting risk analyses and classifications, as information security experts must be able to understand the reasoning for earlier decisions (Beckers et al., 2014).
In other sectors, such as healthcare and engineering, records containing decision rationale are considered as standard. Clinical records, for example, track a patient’s condition and communicate the actions made, as well as the reasoning behind them, to other members in a care team (Kuhn et al., 2015). Similarly, in engineering, capturing design rationale (for instance, why an IT-artifact is designed the way it is) is viewed to be critical (Bracewell et al., 2009). Both domains show how records support accountability, motivate decision-making, and provide a history of previous rationale. However, this type of approach has not yet been adopted in classification, and investigating what to document and add to a record in the information classification process has largely remained unaddressed in research.
The lack of guidance regarding records in information classification is a significant problem in practice. In contrast to other parts of the ISRM process, such as risk analysis and risk treatment, where established frameworks clearly describe what should be documented, for example, in a risk registry, there is no comparable guidance for information classification. As a result, practitioners are left without clear instructions on what to document beyond the classification result. This often leads to inconsistent records, where only the final classification level is captured while the rationale and contextual knowledge behind the decision are overlooked.
Addressing this gap is important, as inadequate records reduce transparency and hinder the reuse of underlying reasoning for past decisions, both of which are essential during reclassification or audit. Poor documentation practices can also undermine organisational risk management and increase exposure to the growing frequency and severity of cyber threats, given the current risk landscape (ENISA, 2024; Orlando, 2021). An example of this is Capita, a UK outsourcing company that was the target of a cyberattack and later fined £14m for failing to ensure the security of personal data affected by the breach. Part of the reason the breach was successful was noted to be a failure of proper systematic ISRM work (ICO, 2025).
Without a structured approach to documenting in the classification process, organisations risk inconsistent practices and an inability to build on past insights. This lack of clarity can also lead to a loss of organisational knowledge, especially when members involved in classification are replaced, resulting in the loss of past understanding of decisions. In other words, documenting more than just the classification result is important, yet there is a lack of understanding of what contextual knowledge to actually gather.
As such, the aim of this paper is to address how to support risk analysis with reliable and structured input from the information classification process. Given the aim, this study set out to shed light on the following question:
Q1. What contextual knowledge should be documented in the information classification process?
The remainder of this paper is structured as follows: Section 2 provides an overview of the information classification process, contextual and procedural knowledge, knowledge management strategy, the use of records in ISRM and tool use in ISRM. Section 3 explains the research approach and the methods used to gather and analyse the data. Section 4 presents the results. Section 5 then discusses and emphasises the study’s key findings, and finally, Section 6 offers the concluding insights.
2. Background
The process of information classification is described in standards, such as ISO/IEC 27002 (2022) and the NIST Risk Management Framework (NIST RMF) (NIST, 2018), it is also described in different national supporting documents in, for example, the UK (Cabinet Office, 2024) and Sweden (MSB, 2023). The mentioned resources describe the classification process in a holistic sense and a normative manner, that is, they explain what should be done and are vague at best in how to do it (Tehler, 2023; Wangen et al., 2018). While the normative approach is understandable, as part of the purpose of a standard is to provide general advice and best practices for organisations to adopt and adapt, information classification is known to be a difficult process to implement in an organisation (Niemimaa and Niemimaa, 2017). Why this is the case likely differs between organisations; however, classifying assets has been noted to be difficult (Andersson, 2023; Fenz et al., 2014; Fibikova and Müller, 2011; Bergström et al., 2021; Kaarst-Brown and Thompson, 2009).
The information classification process is often conducted in a workshop setting with a group of individuals who have varying levels of expertise and familiarity with the information asset being classified (Bergström et al., 2021). Doing it in a workshop allows for a more nuanced view and understanding, leading to more informed classification decisions. However, as previously mentioned, the contextual knowledge and rationale are seldom documented or included in a record as a result of the classification.
Bergström et al. (2021) expanded on the ISO 27002 standard by developing a method based on a low-granularity approach, where an entire system or business process is classified. This is also described as the most common approach in practice (Fibikova and Müller, 2011). While the method refers to records being kept and created, it offers little guidance on what those records should include beyond the name of an asset, requirements, and the classification result. In addition, it does not mention the documentation of decision rationale, which is considered an important part of information security management (Mattord and Wiant, 2016; Barraza de la Paz et al., 2023). An adapted version of the ISO/IEC 27002 method, expanded by Bergström et al. (2021), is presented in Figure 1, and the five main steps are briefly explained:
The flowchart presents an information classification process divided into five numbered sections. Section 1 is Business process or system analysis. It includes Identify next asset in business process or system application, a List of all business processes or systems applications, and a decision diamond marked X with branches Found and Not found. Section 2 is Requirements. It includes Identify external requirements affecting the asset linked to a List of all external requirements, and Identify internal requirements affecting the asset linked to a List of all internal requirements. Section 3 is Classification of information. Three parallel boxes read Confidentiality check, Integrity check, and Availability check, each producing a corresponding classification result. Section 4 is Labelling. It includes Analyse labelling of the information and archive the result linked to a Database of all classified assets, followed by a decision diamond marked X and a box labelled Label the asset. Section 5 is Selection of final business process system classification. It includes Read classification results from all classified assets, Select highest classification results from confidentiality integrity and availability, and Information classification done.A low granularity approach to information classification, the record highlighted in red – Adapted from (Bergström et al., 2021) based on ISO/IEC 27002
The flowchart presents an information classification process divided into five numbered sections. Section 1 is Business process or system analysis. It includes Identify next asset in business process or system application, a List of all business processes or systems applications, and a decision diamond marked X with branches Found and Not found. Section 2 is Requirements. It includes Identify external requirements affecting the asset linked to a List of all external requirements, and Identify internal requirements affecting the asset linked to a List of all internal requirements. Section 3 is Classification of information. Three parallel boxes read Confidentiality check, Integrity check, and Availability check, each producing a corresponding classification result. Section 4 is Labelling. It includes Analyse labelling of the information and archive the result linked to a Database of all classified assets, followed by a decision diamond marked X and a box labelled Label the asset. Section 5 is Selection of final business process system classification. It includes Read classification results from all classified assets, Select highest classification results from confidentiality integrity and availability, and Information classification done.A low granularity approach to information classification, the record highlighted in red – Adapted from (Bergström et al., 2021) based on ISO/IEC 27002
Business Process/System Analysis: Within a business process/system, primary assets, such as information related to customers, and secondary assets, such as servers, are identified, as well as their use, roles and context. This creates an inventory that serves as the foundation for classification.
Requirement Identification: Internal and external requirements are identified. Internal requirements refer to, for example, internal policies and external requirements refer to, for example, laws and regulations, such as the General Data Protection Regulation (GDPR). Both types of requirements should be documented.
Classification of Information: Classification levels are assigned using a classification matrix based on a description of the potential consequence of a loss of confidentiality, integrity and availability. The results are documented and connected to each asset.
Labelling of Information: The records containing the classification results and other information are archived, and a decision is taken on whether to label the asset. If yes, it is labelled according to its classification.
Selection of Final Business Process/System Classification: The business process or system inherits the highest classification level among its assets and is classified accordingly.
2.1 Contextual and procedural knowledge
Knowledge is often discussed as being either explicit or tacit. Explicit knowledge, according to Nonaka et al. (2000), is readily and easily communicated through structured means, such as documents and manuals, and can be expressed in a systematic language. Tacit knowledge, however, is personal, experiential, and difficult to formalise.
Contextual knowledge refers to knowledge about a situation in which a task or decision occurs, including its environment (Nunes et al., 2009; Brezillon and Pomerol, 1999). This can include who was involved, why a decision was made and how it was reached within a particular organisational or situational context (Nunes et al., 2009; Davenport and Prusak, 1997; Greenberg, 2001). In the case of information classification, contextual knowledge may include what shapes the participants’ understanding of asset value in classification workshops, their understanding of the use of specific assets and the rationale behind a certain classification decision. Contextual knowledge is often not readily observable from the outside and must be captured and made explicit for reuse. In other words, for classification outcomes to remain meaningful, they must be conducted within the organisational context and take it into consideration, and the contextual knowledge must be documented to support future reclassification and to allow for traceability.
Procedural knowledge can be defined as knowledge about how to perform a specific task, such as conducting a particular process or applying a specific framework (Georgeff and Lansky, 1986; Anderson and Crawford, 1995). Such knowledge can be made explicit in, for example, guidelines, documents or as part of a workflow in a tool. In the context of information classification, procedural knowledge is partially reflected in existing models and frameworks, for example, in the method developed by Bergström et al. (2021) based on ISO/IEC 27002 (2022), which outlines key steps in the classification process. As previously described and shown in Figure 1, however, such models do not provide explicit procedural guidance on what should be documented throughout the classification process. That is, while they describe how to perform classification, they lack specificity about how to capture contextual knowledge during the process.
In the classification process, contextual knowledge often emerges through discussion among participants in classification workshops, based on their understanding of organisational processes and information assets. This knowledge also resides in the individuals involved in the classification activity. However, without procedural knowledge specifying what should be documented, the contextual knowledge may remain undocumented or only partially captured. As a result, decision rationale and organisational details affecting the decision may be lost, leading to incomplete inputs for subsequent risk analysis. Providing procedural guidance on documentation practices can help organisations capture contextual knowledge more consistently as part of the classification process.
2.2 Knowledge management strategy
A knowledge management strategy is essentially a statement of how knowledge is to be captured and used, and Jennex (2010) found that implementing one can improve decision-making. Although the strategy is not itself the reason for creating a record, it shapes what is included, and these choices should be justified through use-cases that illustrate the purpose of collecting knowledge. According to Willman et al. (2022), a knowledge management strategy typically identifies the intended users of knowledge, the forms of information to be captured, the sources from which knowledge is drawn, and how it will be represented, stored and supported technologically. It also establishes organisational commitment, metrics for evaluating use, and processes for ongoing feedback and adjustment.
In the context of information classification, such a strategy would clarify not only what knowledge should be captured but also why it should be captured, by contextualising each classification record in a use-case. Such an approach supports, for example, reclassification, enables auditability and facilitates novices in a classification workshop.
2.3 Records in information security risk management
Documenting processes and activities is essential for understanding what actions were taken, how they were performed and what the outcomes were (Conklin and Yakemovic, 1991). In an Information Security Management System (ISMS), records involve the identification, documentation, updating, and controlling of informations that is determined to be necessary for the functions of the ISMS, including ISRM (Haufe et al., 2016; ISO/IEC 27001, 2022). Furthermore, ISO/IEC 27001 (2022) emphasises that the required extent of records will vary across organisations, stating that records should be sufficiently available to confirm that processes are carried out as intended. What this means in practice, however, is not stated.
In ISMS, records are used both as input to processes and as outputs or deliverables generated by said processes (Suhaimi et al., 2014). One example is that the results of information classification are used as the main input for the risk analysis. Keeping records up-to-date is not only a recommended practice (Johnson and Schulte, 2004) but is also essential for effective information security management. Records that are the outcome of a process should contain the rationale behind decisions, which is especially valuable when revisiting risk analysis results to understand why specific security controls were chosen (Beckers et al., 2014; Barraza de la Paz et al., 2023). Additionally, thorough records and support external audits by allowing the organisation to clearly present and justify its decisions, making the decision-making process transparent to other security experts (Beckers et al., 2014). According to Fung et al. (2003), comprehensive records serve as evidence that security officers have acted professionally and competently. Along with other factors, comprehensive records are also a key success factor in information security and risk management (Mattord and Wiant, 2016; Sillaber and Breu, 2015).
Existing literature on records in ISRM processes focuses on the one hand, on the use of existing records and, on the other, on creating and updating records throughout the risk management process, meaning documenting. In two such cases, user involvement has been studied (Sillaber and Breu, 2015; Spears and Barki, 2010). When using records on systems and previous risk assessments, high-quality information, meaning it is accurate and complete, improves the reliability of risk assessments by providing clear, current details for informed decision-making. This reliability is further supported by records that include a clear description of a business process or asset used as the basis for the assessment, often created in part by users with in-depth knowledge of the system or process (Sillaber and Breu, 2015; Spears and Barki, 2010). In this way, records play an important role in managing risk and supporting the ISRM process.
The ISRM process is iterative in nature (Whitman and Mattord, 2022), and revisiting previously made decisions in the different steps is a natural action. This is known to be good practice, as the value of information may change over time. As a result, it is necessary to revisit the classification process (Everett, 2011). If a reclassification is not done, it could result in an outdated view of the criticality of assets to the organisation. However, if records containing contextual knowledge from previous iterations exist, the classification level and basis for decisions can be evaluated and discussed rather than starting from scratch. This further cements the need for records and procedural knowledge on what they should include in information classification.
Ngoepe (2014) investigated the role of records within risk management and found that the success of risk management is partly dependent on the accuracy of records, as decisions must be made on accurate and complete information. In addition, it was identified that if nothing is documented, it is difficult to prove that it happened and that relying on human memory is a dangerous practice. Further, Ngoepe (2014) identified risks related to the lack of records, for example, the inability to find mission-critical information, lack of records of who knows what and when, and a loss of proof of ownership, rights and obligations.
In information classification, there is no method or approach describing what should be documented apart from the results of the classification, that is, the final classification level. This makes the process susceptible to the risks described by Ngoepe (2014). However, previous research suggests that support regarding both the documentation and records is an area that needs to be addressed (Bergström, 2023; Grimaila and Fortson, 2007; Sillaber and Breu, 2015).
2.4 Tool support in information security risk management
One way of supporting the ISRM process and information classification is through the use of tools. What a tool entails in the context of ISRM has previously been discussed in for example Bergström (2023) and Gritzalis et al. (2018), who define tools as either dedicated software for conducting ISRM activities or more rudimentary supports, such as spreadsheets or templates used in ISRM work (Gritzalis et al., 2018; Wangen et al., 2018). Different tools provide different types of support. Typical properties of dedicated tools include task automation, reduction of manual work, minimisation of user input to limit the possibility of user errors, and the creation of a more streamlined workflow that guides users through an ISRM activity or process (Gritzalis et al., 2018; Sánchez-García et al., 2023).
While rudimentary supports like spreadsheets are seen as helpful, they are often considered restrictive, and dedicated tools are generally preferred (Gritzalis et al., 2018). However, even dedicated tools are not without limitations. Gritzalis et al. (2018) identified that input constraints, meaning what can be documented, are often seen as limiting. Similarly, Lundgren and Bergström (2019) investigated stress among practitioners working in an ISRM process. In that study, respondents used a specific tool for information classification, and the tool was found to be inflexible in terms of documenting classification results. These examples suggest that although tools can offer some structure, they often lack sufficient functionality to support comprehensive documentation practices. Notably, one common feature, minimising user input to reduce errors, may inadvertently hinder the ability to document important ISRM and classification details (Gritzalis et al., 2018).
Few overviews of ISRM tools exist. For example, European Union Agency for Cybersecurity (ENISA) (2023) provides a list of tools related to risk management methods. In addition, Sánchez-García et al. (2023) identified 25 tools for risk management and risk assessment, while Bergström (2023) found 18 tools related to ISRM. There is, however, little literature on ISRM tools in general and even less so on tools targeting information classification specifically. The reason why there are so few tools targeting information classification could be that ISRM tools include information classification as an activity. However, there is a distinct lack of research exploring tools that focus on both ISRM and classification aspects and even more so on tools that support documentation practices. This gap suggests that further exploration and development in these areas could be beneficial to risk management overall.
3. Research approach
This study aimed to investigate what contextual knowledge should be documented in the information classification process. Given the explorative nature of this endeavour, we opted to use a qualitative research approach (Lim, 2024). Choosing a qualitative approach meant that we aimed to identify recurring patterns in our collected data and looked for saturation in answers rather than trying or assessing a pre-existing hypothesis (Oates, 2006). To conduct our data collection, we used semi-structured interviews as our main approach, given the explorative nature of the study. In addition, we participated as observers in tool demonstrations aimed at supporting classification and risk management.
3.1 Data collection
The main data collection method used were semi-structured interviews (Adams, 2015). The reasoning for using semi-structured interviews was, in part, that they are characterised by asking open-ended questions, allowing respondents to formulate their answers freely; this was perceived as beneficial given the explorative approach (Kallio et al., 2016). Semi-structured interviews also allow the researcher to ask follow-up questions when investigating unexplored territory (Reynolds and Gutman, 1988). An interview guide was created before the interviews, including questions surrounding the information classification process as such, and more specifically, what respondents deem to be the main results of the classification and what they find important to document. This allowed respondents to freely formulate their answers surrounding the general process and what they perceived to be the results before we more specifically asked them what they documented and what they considered to be important to include in a record. Finally, semi-structured interviews were deemed to be a good fit for the study in terms of gathering and understanding contextual knowledge described by respondents, as explained in Kallio et al. (2016); Magaldi and Berler (2018); Ruslin et al. (2022).
To follow ethical guidelines for in-depth and semi-structured interviews, we took several steps based on Allmark et al. (2009). Each interview began with a brief introduction explaining the agenda, how the data would be used, and explaining the respondents’ right to withdraw at any time. We also asked for consent to record the interview both before and after starting the interview, ensuring informed consent. To maintain privacy, all identifying details, like respondents’ names and their organisations, were removed from the transcripts and replaced with pseudonyms. The transcription was done verbatim, word for word (Halcomb and Davidson, 2006).
In total, we interviewed 16 respondents regarding records connected to information classification. All respondents had some sort of managing role connected to information security work, such as a Chief Information Security Officer (CISO), Information Security Specialist or IT security manager. We perceived the roles of the respondents as relevant to the study, as they were the persons responsible for the records and documentation outputs of the process. The interviews all lasted between 1 and 1.5 h and were conducted using conferencing software in an online setting. A summary of the respondents and their roles can be seen in Table 1. In addition to the interviews, we also participated as observers in 14 tool demonstrations aimed at supporting organisations in areas such as governance, risk and compliance (GRC) management. Each session involved a live walkthrough of the tool via screen sharing, during which the presenters demonstrated its use in real time. Importantly, we did not use or evaluate the tools ourselves as our role was strictly observational.
An overview of the respondents and their organisational role and size
| Respondent | Role in the organisation | Organisation size |
|---|---|---|
| 1 | Information security specialist | 1001–2500 |
| 2 | Information security specialist | 1001–2500 |
| 3 | Administrative manager, IT | 1001–2500 |
| 4 | Security coordinator | 501–1000 |
| 5 | Head of division, IT | 0–500 |
| 6 | CISO | 2501–5000 |
| 7 | CISO | 0–500 |
| 8 | Information security specialist | 501–1000 |
| 9 | CISO | 0–500 |
| 10 | CISO | 5000+ |
| 11 | Information security specialist | 5000+ |
| 12 | CISO | 1001–2500 |
| 13 | CISO | 5000+ |
| 14 | IT security manager | 1001–2500 |
| 15 | CISO | 501–1000 |
| 16 | CISO | 1001–2500 |
| Respondent | Role in the organisation | Organisation size |
|---|---|---|
| 1 | Information security specialist | 1001–2500 |
| 2 | Information security specialist | 1001–2500 |
| 3 | Administrative manager, | 1001–2500 |
| 4 | Security coordinator | 501–1000 |
| 5 | Head of division, | 0–500 |
| 6 | 2501–5000 | |
| 7 | 0–500 | |
| 8 | Information security specialist | 501–1000 |
| 9 | 0–500 | |
| 10 | 5000+ | |
| 11 | Information security specialist | 5000+ |
| 12 | 1001–2500 | |
| 13 | 5000+ | |
| 14 | 1001–2500 | |
| 15 | 501–1000 | |
| 16 | 1001–2500 |
The selection of tools was carried out in collaboration with a Swedish national interest group focused on risk analysis, comprising 22 members from both industry and academia. Tool selection was guided by the ENISA list of Risk Management tools [European Union Agency for Cybersecurity (ENISA), 2023] and additional suggestions from members of the interest group. The demonstrations were hosted by the interest group, with tool developers invited to present and answer questions. Each session followed a consistent structure: a walkthrough of the tool’s interface and features, followed by a Q&A session. These sessions enabled us to explore the tools in greater depth and allowed us to ask questions such as, “Practically, how does the tool support classification?” which were of a more procedural nature. However, we also asked questions of a contextual nature, such as, “How do you capture external requirements in practice?” The reason for asking questions of a contextual nature was to investigate what contextual knowledge is being captured in existing tools. The demonstrations also allowed us to get access and insight into proprietary tools, which would have been difficult otherwise. We used a combination of screenshots and text to document the fields in the respective tool used to capture contextual knowledge.
An overview of the different tools, their intended area of use, nation of origin, and intended national or international use can be seen in Table 2. We include the international use column to reflect the practical considerations in terms of language availability. Several tools, for example, were only available in Swedish. The tools are not mentioned by name, as this study did not aim to evaluate individual tools, and some were proprietary or subject to copyright restrictions. The tools have no connection to the respondents we interviewed, and the two should be viewed as separate and complementary data collection activities. By observing which documentation fields were consistently implemented in the tools, we gained additional insight into what procedural knowledge tool developers have included to assist with documenting the information classification process.
An overview of the tools presented, their intended area of use, country of origin and if the tool is intended for national or international use
| Tool | Intended area of use | Country of origin | International use |
|---|---|---|---|
| Tool 1 | GRC | Sweden | X |
| Tool 2 | GRC | Sweden | X |
| Tool 3 | Incident management | Sweden | |
| Tool 4 | GRC | USA | X |
| Tool 5 | Risk management | Israel | X |
| Tool 6 | GRC | Sweden | X |
| Tool 7 | GRC/ISMS | Sweden | |
| Tool 8 | Risk management | Sweden | |
| Tool 9 | Risk management | France | X |
| Tool 10 | GRC | USA | X |
| Tool 11 | GRC | Slovakia | X |
| Tool 12 | Information classification | Sweden | |
| Tool 13 | Issue/project tracking – Showcased as a risk management tool | Australia | X |
| Tool 14 | GRC | Luxembourg | X |
| Tool | Intended area of use | Country of origin | International use |
|---|---|---|---|
| Tool 1 | Sweden | X | |
| Tool 2 | Sweden | X | |
| Tool 3 | Incident management | Sweden | |
| Tool 4 | X | ||
| Tool 5 | Risk management | Israel | X |
| Tool 6 | Sweden | X | |
| Tool 7 | GRC/ISMS | Sweden | |
| Tool 8 | Risk management | Sweden | |
| Tool 9 | Risk management | France | X |
| Tool 10 | X | ||
| Tool 11 | Slovakia | X | |
| Tool 12 | Information classification | Sweden | |
| Tool 13 | Issue/project tracking – Showcased as a risk management tool | Australia | X |
| Tool 14 | Luxembourg | X |
3.2 Data analysis
In our analysis, we followed Saldaña’s thematic analysis coding guidelines (Saldaña, 2021), which recommend a two-cycle approach to qualitative coding. For the initial cycle, we employed structural coding, which is particularly suited to data gathered through semi-structured interviews (Saldaña, 2021). The initial coding structure was based on the main activity categories in Figure 1: “Business Process / System Analysis”, “Requirements”, “Classification of Information”, “Labelling” and “Selection of Final Business Process/System Classification”. In this first cycle, we used these activity categories as codes and grouped excerpts from the interview transcripts under them based on what type of activity or process step they related to. This helped us identify where and in what step of the classification process records were used and described by the respondents.
In the second cycle, we reviewed and re-evaluated the initial coding to better reflect the focus of the study. We also used the contextual knowledge gathered from the tool demonstrations as input in the second coding cycle. During this stage, we removed “Labelling” and “Selection of Final Business Process/System Classification”, as these steps do not typically produce a record, but rather use one as input. We retained and slightly adjusted the remaining three categories, which became: “Business Process / System Analysis”, “Requirements” and “Classification Results”. Within each of these final categories, we then coded more specifically for record types and parts of records mentioned by respondents, such as asset type, rationale and responsible role. As an example, one respondent explained how they document the reasoning behind classification decisions. Such a quote was initially coded under “Classification of Information” and later recategorised under “Classification Results”, with the specific code of “Rationale for classification decision”. All coding was done manually in Microsoft Word using comment and highlighting features to mark and compare coded excerpts.
3.3 Validation
In ISRM research, validation is often missing (Fenz and Ekelhart, 2011). One way of validating ISRM research is presenting research results to a panel of experts (Fenz and Ekelhart, 2011; Thornhill et al., 2016). Although an expert panel is opinion-based, it remains one of the few ways to validate ISRM findings (Fenz and Ekelhart, 2011).
In this paper, the preliminary results were brought to a panel of 14 information security experts with roles such as CISO and Senior Information Security Consultant. The choice of participants was done in accordance with the suggestions in Fenz and Ekelhart (2011). The participants represented organisations from both the private and public sectors, which allowed for a wide variety of experiences and knowledge to provide feedback. The session lasted for about one hour, starting with a presentation of the purpose and the presentation of the results, followed by a Q&A. A typical question that was asked and discussed were: “Do you think our results could improve the classification work?”. In a similar sense to the semi-structured interviews, the session was recorded with everyone’s consent and later transcribed verbatim. The validation session primarily strengthened the validity of the findings, and provided information for the use-cases.
4. Results and analysis
Based on the analysis, this section presents findings from the interviews and tool demonstrations, structured around the coding categories: Business Process/System Analysis, Requirements and Classification Results. Within each phase, we identify what practitioners and tool developers consider important to document. Each subsection begins with perspectives from interview respondents, followed by relevant observations from the tool demonstrations, and concludes with a table summarising the contextual knowledge identified as necessary for that category. The findings provide a structured view of what contextual knowledge is considered important to capture during the information classification process. At the end of each subchapter, a purpose and a brief use-case example are provided to illustrate the use in gathering the contextual knowledge.
4.1 Business process/system analysis
Respondents describe creating records in the business process/system analysis as a valuable task. Organisational knowledge is preserved not only through the records themselves but also through the collaborative discussions and analyses leading to their creation. These activities are said to increase awareness among both employees and the organisation, and improve the end result of the classification.
A variety of information found necessary to document by respondents, aside from the actual asset itself, were identified. In particular, respondents mentioned the importance of personally identifiable information (PII). Some respondents have internal tools they use to document if the asset being classified does indeed include PII, often by a checkbox or a drop-down menu. Others use, for example, an Excel sheet developed by the organisation internally, and document information they perceive as important in a free-text field. However, it was explained that most of the time, this free-text field does not exist, and they have to manually create it by themselves and come up with the contextual knowledge to document. It is noted, however, that while the free-text fields are used, they tend to be quite scarce with information; respondent 6 explained:
[…] there is a small box where you have to fill in a description of the classification object so that, yes, you define some kind of contextual information, even if that information is usually quite scarce. – Respondent 6
Other respondents discussed contextual knowledge; for example, respondents 4 and 5 explained that it could be a detailed description of an asset and how it connects to a specific process. The same respondents also note that contextual descriptions, such as how assets relate to organisational processes, can support and further the understanding of the asset during classification by providing additional information and context.
Respondent 15 explained that they always document the main process the asset is used in, such as education, administration, or research. They then put the asset in a more specific process or sub-process, such as administering students; thus, it can be identified where the asset is used. Furthermore, what the asset contains is documented, such as PII of certain types, and lastly, its location in a secondary asset, that is, in which system it resides. In a similar sense, respondent 8 presses on the need to include the information flow of the identified asset, meaning, how the asset moves between systems/secondary assets during its lifecycle.
The tool demonstrations showcased pieces of records that respondents did not discuss, such as who the potential external recipient would be, the location in the secondary asset, the purpose of the asset, the stakeholders of relevance and the person/role responsible for the asset. The manner in which these are entered are text fields, which are then connected to the identified asset, and it will follow the asset throughout the classification and risk analysis.
Purpose and use-case example:
During a classification workshop, participants are to assess the potential consequences of confidentiality, integrity, or availability loss for a specific asset. By having the contextual knowledge in Table 3, such as information flows, business processes, stakeholders and asset location, the team can more accurately determine the asset’s organisational criticality. For example, knowing that the asset is used in both admissions and financial processes, and that it flows through multiple systems, may shift the classification towards a higher classification. The documented context ensures that the classification decision is grounded in how the asset functions in practice. After the classification, this contextual knowledge supports future reclassification and the inclusion of novices by allowing them to quickly understand the asset’s purpose and organisational importance without having to reconstruct that understanding from scratch.
Contextual knowledge in the business process/system analysis
| Contextual knowledge documented | Explanation |
|---|---|
| Asset name | A descriptive name of the asset |
| Asset description | A description of the asset |
| Business process | Which business process(es) the asset is relevant to |
| Person/role responsible | A statement on who/what role is responsible for the asset |
| Usage | A brief description of the intended use of the asset |
| Information flows | A statement on how the asset moves in and between different systems in a process |
| Location in secondary asset | Where, and in which system(s) the asset is located. Such as in a service or a storage solution |
| Owner of the asset | The person or role who is the owner of the asset |
| External recipient | A statement on the external recipient of the asset if applicable |
| Stakeholders | Stakeholders of relevance affected by the asset |
| Contextual knowledge documented | Explanation |
|---|---|
| Asset name | A descriptive name of the asset |
| Asset description | A description of the asset |
| Business process | Which business process(es) the asset is relevant to |
| Person/role responsible | A statement on who/what role is responsible for the asset |
| Usage | A brief description of the intended use of the asset |
| Information flows | A statement on how the asset moves in and between different systems in a process |
| Location in secondary asset | Where, and in which system(s) the asset is located. Such as in a service or a storage solution |
| Owner of the asset | The person or role who is the owner of the asset |
| External recipient | A statement on the external recipient of the asset if applicable |
| Stakeholders | Stakeholders of relevance affected by the asset |
4.2 Requirements
Documenting external and/or internal requirements are only described to be done by some respondents, and it is mentioned to be connected to either laws or other contract-based requirements made with outside actors. They do, however, have a big effect on the classification as such. For example, if the asset includes, for example, PII, then that will have to be taken into consideration in the classification. This is brought up by respondent 5, who explains that as soon as they handle PII, they also have to comply with the regulations stated by the GDPR. The same respondent also mentions that contextual information they gather in the first step, “Identify asset”, can sometimes point towards laws they must adhere to, such as the Swedish law “Public Access to Secrecy”, or other privacy laws and regulations. Another example of a requirement that can affect classification is brought up by respondent 6, who explains that, due to archiving laws and regulations, there are cases where information and documents must be disposed of, something that must be considered during the classification process. There is also mention of agreements with outside stakeholders that must be taken into consideration. One example being IT provider agreements, and investigating what their contracts mention regarding, for example, handling PII and similar assets.
Pertaining to the requirements section, the tool demonstrations showcased a variety of internal and external requirements present in tools that were not mentioned by respondents. In the tool demonstrations, examples were often used with generic requirements, such as the GDPR, sector-specific laws and regulations, or how the information management plan would have to be taken into consideration, for example.
Purpose and use-case example:
When classifying, workshop participants must consider the laws and regulations that affect the asset. Using the requirement types listed in Table 4, the team can identify relevant mandatory constraints, such as PII-related obligations, retention rules from archiving legislation, or internal access-control policies. These requirements can influence the level of strictness required for classification. For example, if the asset is subject to or includes regulated patient information, specific confidentiality and integrity levels must be taken into consideration. The documented requirements, therefore, provide justification for adjusting the classification level, which might otherwise be overlooked. After classification, this documentation provides a record of why certain requirements influenced the outcome, supporting audits and compliance reviews.
Contextual knowledge in Requirements – Internal and external requirements are exemplified
| Contextual knowledge documented | Explanation |
|---|---|
| External requirements | Requirements from an external source |
| Privacy laws and regulations | National and/or international laws regulating privacy in some sense |
| NIS-2 | EU law enforcing cybersecurity measures and incident reporting for essential and important service providers |
| GDPR | EU regulation governing data protection and privacy, giving individuals control over their personal data |
| Public access to information | Laws and regulations regulating public access to official documents while protecting sensitive information |
| Sector-specific laws and regulations | National and/or international laws and regulations regulating sector-specific requirements |
| Patient data laws and regulations | Laws and regulations managing and protecting patient journal information, ensuring traceability and secure handling of patient data |
| Archiving laws and regulations | National and international laws and regulations that dictate the retention and management of records |
| Archives act | Dictates the preservation and management of public records for long-term archiving |
| Public records act | Governs transparency and archiving of public documents to maintain public access |
| IT provider agreements | Statement on how the information asset can be handled in relation to external providers of IT services to the organisation. An example of this is service level agreements (SLAs) |
| Internal requirements | Requirements from an internal source |
| Internal policies | Policies stemming from within the organisation, such as ones touching on organisational privacy, information security and data retention. An example affecting the classification could be, for example, certain access-control requirements to particular assets |
| Disaster recovery plan | Strategy for restoring systems and data after disruptions to ensure business continuity. This can affect, for example, storage requirements, and in turn, the classification of identified assets |
| Information management plan | Internal guidelines on structuring, storing and managing information efficiently. This can affect the classification level by, for example, limiting the use of certain identified assets |
| Contextual knowledge documented | Explanation |
|---|---|
| External requirements | Requirements from an external source |
| Privacy laws and regulations | National and/or international laws regulating privacy in some sense |
| NIS-2 | |
| Public access to information | Laws and regulations regulating public access to official documents while protecting sensitive information |
| Sector-specific laws and regulations | National and/or international laws and regulations regulating sector-specific requirements |
| Patient data laws and regulations | Laws and regulations managing and protecting patient journal information, ensuring traceability and secure handling of patient data |
| Archiving laws and regulations | National and international laws and regulations that dictate the retention and management of records |
| Archives act | Dictates the preservation and management of public records for long-term archiving |
| Public records act | Governs transparency and archiving of public documents to maintain public access |
| Statement on how the information asset can be handled in relation to external providers of | |
| Internal requirements | Requirements from an internal source |
| Internal policies | Policies stemming from within the organisation, such as ones touching on organisational privacy, information security and data retention. An example affecting the classification could be, for example, certain access-control requirements to particular assets |
| Disaster recovery plan | Strategy for restoring systems and data after disruptions to ensure business continuity. This can affect, for example, storage requirements, and in turn, the classification of identified assets |
| Information management plan | Internal guidelines on structuring, storing and managing information efficiently. This can affect the classification level by, for example, limiting the use of certain identified assets |
4.3 Classification results
Respondents who discussed the classification results mentioned that the actual classification level, such as “level 3”, is a key output. The same level is later used in the risk analysis, and respondents make it clear that it is important to document. However, respondents 8, 10 and 13, stress that classification involves more than just assigning a level and emphasise the importance of documenting the rationale behind decisions, and the roles responsible. As Respondent 10 explains:
It’s kind of about making sure there is room for justifications and, in a way, that you can demonstrate reflections — basically, reflections that occurred before defining a value in some way, right? That there is clarity, so you can go back to the classification documentation and see on what premises this decision was reached, even a year later”. – Respondent 10
Respondent 10 further described classification as a collaborative process where reaching consensus is as important as the classification level itself. Including the rationale for classification decisions allows users to revisit and understand why a decision was made.
Respondent 15 explains that they have an internal tool that supports and encourages the documentation of rationale and perspectives of consequence (such as health, reputation and/or core business functions) by including text fields targeting those areas.
Respondent 7 emphasised the awareness-raising effect of classification workshops and explained that a classification workshop brings together different stakeholders, offering a rare opportunity to reflect on the value of the information being processed. This contributes to increased awareness of what types of information the organisation uses and manages.
Many respondents highlighted the classification activity as the most important step in the classification process. Not only does it produce the classification level, but it also brings together internal stakeholders. Respondent 7 describes it as one of the few opportunities for organisational reflection on the value of information. Such discussions are said to foster information security awareness, both individually and organisationally. Respondent 7 also noted that participants gained a better understanding of the types of information in organisational processes. According to Respondent 15, the discussion surrounding the classification creates a form of “collective memory” that, if documented, helps the organisation remember and build on previous discussions. Respondent 13 further explained:
Yes, well, if you haven’t documented it, you haven’t done it. I mean, it’s like this – we can sit here and talk as much as we want, but I mean […] You might have a “picture” memory so you remember everything, but the third person who is participating does not, and if you leave the organisation then it [the rationale] no longer exists. – Respondent 13
The tool demonstrations did not highlight any additional information to be documented, but confirmed the importance of documenting both the classification level and rationale.
Purpose and use-case example:
During classification workshops, the participants determine the classification level. Capturing the rationale described in Table 5, including the arguments raised, potential consequences and perspectives considered, supports the team in making a well-founded and transparent decision. This also prevents having to do all of the work again in future classification sessions by making it clear what reasoning led to the chosen level. As such, the rationale becomes part of the classification result itself, ensuring that the assigned level is not just a number but an argued-for conclusion. After classification, this rationale serves as an organisational memory that supports reclassification, avoids repeated arguments, and can help novices understand the reasoning behind earlier decisions.
Contextual knowledge in the classification results
| Contextual knowledge documented | Explanation |
|---|---|
| Classification level | The level of classification of the asset received from a confidentiality, integrity and availability perspective |
| Rationale for classification decision | A summary statement on the rationale of the classification decision, that is, on what grounds/basis the classification decisions were taken |
| Contextual knowledge documented | Explanation |
|---|---|
| Classification level | The level of classification of the asset received from a confidentiality, integrity and availability perspective |
| Rationale for classification decision | A summary statement on the rationale of the classification decision, that is, on what grounds/basis the classification decisions were taken |
5. Discussion
A central finding in this study is that while classification decisions are often documented in some sense in most organisations, contextual knowledge surrounding such decisions is only partially captured, if at all. Respondents consistently emphasised that documenting only the classification level is insufficient to support reclassification. Instead, they highlight the importance of also documenting, for example, contextual knowledge of specific assets, internal and external requirements, and the rationale for making a classification decision. Even when the classification process is defined, such contextual knowledge is often not captured.
A possible explanation for this shortcoming is a gap identified in this study, namely, the lack of comprehensive guidance on what should be documented during the classification process. While existing methods, such as the one proposed by Bergström et al. (2021) based on ISO/IEC 27002 (2022), outline the main steps of a classification process, they provide little guidance on what the contents of the classification record should be. The lack of guidance may contribute to the variability observed in practice, where decisions are often based on subjective judgement but with limited documented contextual knowledge (Andersson, 2023; Shedden et al., 2016). This study extends existing methods by identifying contextual knowledge that practitioners and tool developers consider essential to capture, and provides procedural knowledge in the form of a structured overview of what to document during a classification process. In doing so, we address a gap in current methods and offer a more complete view of how the information classification process can be supported.
A recurring mention in our findings is to record contextual knowledge, such as the rationale behind decisions and the roles of participants. Respondents emphasised the value of maintaining records that capture the discussions and reflections made during workshops, as these help preserve organisational memory, ensure transparency, and keep the rationale of decisions. The mention of such records aligns with assertions made by Barraza de la Paz et al. (2023) and Beckers et al. (2014), claiming that rationale is important for revisiting and justifying security choices during audits or future reviews. Similarly, Sillaber and Breu (2015) stresses the importance of documentation and its contribution to ISRM work.
While contextual knowledge is valuable in itself, there is also an argument to make surrounding how it is produced by the workshop participants. Classification workshops are viewed as an activity that increases information security awareness and understanding, indicating that while contextual knowledge is an important output, meaning the record, its creation is just as important. This suggests a “the journey is the goal” type of approach, where the value lies not only in the record itself but also in the activities and discussions that lead to its creation. In a similar setting, Lundgren and Bergström (2019) identified a scenario where the contextual information of assets found through analysis could potentially be more valuable than their actual valuation.
Our study also highlights additional organisational benefits of the information classification process. While the primary output of information classification is often understood to be the assigned classification level (Bergström et al., 2021; Tankard, 2015; Bradford et al., 2022), respondents emphasised two other key outcomes: a deeper understanding of the information being processed and an increased level of security awareness, both at the individual and organisational level. Both benefits are attributed to the participation of different stakeholders within the organisation in discussions during the information classification workshops, where the group discusses and reflects on the value of information. The workshops are stated to be one of the few moments where it is feasible and fitting to do so. In other words, users participate in security processes and, as a result, gain increased organisational awareness, which aligns with the findings in earlier work focusing on including organisational members in security processes (Spears and Barki, 2010). These workshops, while valuable for fostering awareness, also produce contextual knowledge that is important to document and preserve.
The approach that we propose in this work helps guide and focus classification by offering the procedural knowledge needed for each step of the classification process, and the contextual knowledge on what to consider documenting during the classification. In doing so, an organisation can create a structure for documenting the activity and create a record that can be retrieved and reused during reclassification.
The tool demonstrations provided further insight into how classification records are currently structured in practice. Many tools include predefined fields for assets and regulatory requirements [in line with (Gritzalis et al., 2018)], however, they offer limited support for capturing decision rationale and contextual discussions, both of which respondents emphasised as important for transparency and reclassification. While tools in their current form assist in structuring classification documentation, they still lack functionalities that respondents consider necessary. These gaps may contribute to variations in documentation practices, as some respondents rely on the structured input fields provided by tools, while others create additional fields and document contextual knowledge to compensate for missing functionalities. This became particularly evident among respondents who reported using spreadsheets rather than proprietary software. In addition, while the tools primarily support the organisation of classification records, they do little to assist users in making the actual classification decisions. In other words, there is a lack of functional tools that support decision-making in information classification.
Our findings include a variety of items to include in a record that tools could support. It is worth mentioning, however, that the structure we suggest does not require an advanced tool, it could be realised in a text file or a spreadsheet and support organisations with a structure when creating their records. However, as seen in other research [e.g. Gritzalis et al. (2018) and Bergström (2023)], a better scenario would likely be to integrate our proposed structure into a tool that covers the whole ISRM process rather than having a specific tool only for information classification.
Finally, the results of this study were validated through the use of a panel of information security experts. In the validation session, the experts confirmed that the contextual knowledge elements identified in the study reflected their own experiences with information classification and were aligned with the practical challenges they encounter in their work, thereby confirming their practical relevance.
5.1 Limitations
The results of this study are generalisable in the sense that they highlight types of contextual knowledge that practitioners commonly consider important to document. However, they are not directly applicable to all organisations or all asset types without adaptation to specific organisational contexts. Some elements of the proposed record structure are likely to be of greater value to certain organisations than others, depending on their size, sector, and maturity of information security practices.
The findings also reflect the perspectives of a limited set of respondents, primarily CISOs and information security specialists, and observations of a selected number of tools. A broader sample, including additional organisational roles and sectors, may have yielded a wider range of perspectives and potentially expanded the list of contextual knowledge identified.
Concerning the data collection, there is a potential bias. The interviews were conducted with only Swedish representatives, and the tools are predominantly from Sweden and Europe, even though four continents are represented in the study. All the tools and respondents that were interviewed followed an existing information classification model based on the ISO/IEC 27002 standard. We did not find any inconsistencies based on the country of origin.
6. Conclusion
This study explored which types of contextual knowledge should be recorded during the information classification process. In doing so, it contributes procedural knowledge by outlining how organisations can identify and document such knowledge when conducting information classification. Using an existing model based on ISO/IEC 27002 as a frame of reference, we examined how contextual knowledge is currently captured in practice and identified knowledge elements that security practitioners and tool developers consider essential to document.
A key takeaway is that current classification models provide little guidance on what should be documented beyond the final classification level. This gap could be a reason why documentation practices differ so much in practice, both in what is documented and how they do it. At the same time, the collaborative nature of classification workshops presents an opportunity for reflection, shared understanding and increased security awareness. However, without structured approaches to capture the contextual knowledge that emerges in these settings, much of the potential value of these insights risks being lost. To address this, we propose a structured approach consisting of recommended contextual knowledge to document, which can serve as a starting point for integration into an organisation’s classification process. Each part of the structured approach is linked to a use-case example, illustrating why the associated contextual knowledge should be captured and how it can be used.
The paper contributes to practitioners who conduct information classification as part of their profession by suggesting contextual knowledge that could be captured during the classification process more extensively than what is currently described in literature and standards. In doing so, organisations can get a better basis for classification decisions. In addition, the gathered knowledge will follow the asset to the risk analysis, thereby providing a better basis for starting that work. The contribution could also support practice and future development of guidelines and standards.
In addition, for research, it showcases that there is a clear need for developing guidelines on what to document throughout the classification process and, in doing so, providing some much-needed structure to the practice. Finally, the study highlights that there is a lot of value to be found in classifying information when adopting a “the journey is the goal” approach, resulting in increased security awareness both as an organisation and as individuals and at the same time probably producing a better classification output. In addition, the results of this study could be of value to tool developers, as it offers insight into the contextual knowledge that is collected and the missing functionality of existing tools.
Future research could focus on further developing existing methods to include structured documentation practices. One approach to this could be to develop standardised templates that could be integrated into existing ISRM tools to ease the administrative burden and assist users in determining what to capture during record creation. Another topic of interest is investigating how tools can assist users in making classification decisions, not just support them by gathering more contextual knowledge. A last suggestion for future research is to investigate how different types of gathered contextual knowledge affect the classification decision.

