Method Framework for Developing Enterprise Architecture Security Principles

Organizations need to consider many facets of information security in their daily operations – among others, the rapidly increasing use of IT, emerging technologies and digitalization of organizations’ core resources provoke new threats that can be difficult to anticipate. It has been argued that the security and privacy considerations should be embedded in all the areas of organizational activities instead of only relying technical security mechanisms provided by the underlying systems and software. Enterprise Architecture Management (EAM) offers a holistic approach for managing different dimensions of an organization, and can be conceived as a coherent and consistent set of principles that guide how the enterprise must be designed. This article contributes with a method framework for integrating information security with EAM, aimed at providing support for the decision-making related to formulating context-aware EA security principles. The presented method framework is a result of a constructive research based on both the theoretical body of knowledge and the empirical evidence, obtained by interviewing 35 Finnish EA and information security practitioners.


Introduction
Organizations constantly face new challenges in the area of information security. Digital transformation, networked business models, continuously evolving organizations, emerging technologies, increasing complexity of information systems and technology landscapes, regulatory pressures and changes in legislation, and several other factors necessitate that organizations must constantly keep their eye on the security requirements and redefine them as needed. As an example, since May 2018 the enterprises operating in Europe have been obligated to comply with the General Data Protection Regulation (GDPR); and failing to guarantee organizational security and privacy of their customers' personal data may lead to substantial fines. It has been argued that nowadays the security and privacy considerations should be embedded in all the areas of organizational activities instead of only relying on technical security mechanisms that underlying systems and software provide [1], [2].
The enterprise architecture (EA) management (EAM) has been seen as a viable approach for integrating different layers of information security and aligning them with the context of continuously changing business requirements. (e.g. [3]). As stated by The Open Group [4, p.1] "for too long, information security has been considered a separate discipline, isolated from the business processes and Enterprise Architecture". Although some research on security and EA exist (for instance, enterprise privacy architecture (EPA), enterprise security architecture (ESA), enterprise information security architecture (EISA) and Sherwood Applied Business Security Architecture (SABSA)), these approaches propose additional architectures to reinforce the existing EA method [3]. As discussed later in this article, the information security policy is divided into three categories of abstraction encompassing the whole organization [5], thus necessitating the security perspectives to be immersed into EA itself, instead of being additional architectural viewpoints or extensions. As argued in [25], the current approaches often focus solely on information systems and technology components of the architecture, and as such do not offer a requisite holistic approach to integrate the information security with the practices of EAM. Second, prior research is focused on discussing the risk management aspects on information security. While, for instance, Enterprise Architecture-Based Risk and Security Modelling and Analysis (ERSM) suggests security principles, no guidance for the development of the principles is given.
According to [6], the entire EA can be conceived as a coherent and consistent set of principles that guide how the enterprise must be designed, making EA principles a viable instrument of achieving organizational security. The objective of this study is to develop an abstract design knowledge artefact in the form of a method framework for integrating information security principle development with the EAM. As a practical contribution, the article provides support for decision-making related to formulating context-aware EA security principles, while a theoretical contribution can be found from the coverage of two distinct yet interrelated streams of research: information security and EA. The presented method framework is the result of the constructive research based on both the theoretical body of knowledge and the empirical evidence, which was obtained by interviewing 35 Finnish EA and information security practitioners.
The remainder of this article is organized as follows. In the next section we outline the theoretical foundation for this study by discussing its core concepts, i.e. the enterprise architecture principles and security policies, and their possible relation to each other. The third section describes our constructive research process phase by phase, and then the fourth section presents the results of the constructive work. The fifth section provides a discussion on the results. Finally, the sixth section concludes the paper, addresses limitations of the study, and suggests topics for further research.

Theoretical Background
This section discusses the key concepts of the research domain and establishes the theoretical foundations for the constructive part of the study. The first section addresses the enterprise architecture and, more specifically, the enterprise architecture principles, and the second covers the concept of information security policy. While the clear distinction between the terms principle and policy is not always drawn (cf., [7]), in the following we characterize the former as a rule to be followed and the latter as collection of guidelines to be adopted. By discussing these concepts, we aim to address the need for and the current lack of a holistic approach for integrating aspects of information security into the EAM.

Enterprise Architecture Principles
The EAM offers a holistic approach for managing different dimensions of an organization, such as its goals and objectives, business activities, software applications, data and information, and technology infrastructures. It fosters the use of common language and supports the co-operation between stakeholder groups [8]. EAM is widely used in strategy formation, planning, and implementation and in aligning business capabilities with the supporting IT resources [9].
To structure and guide the EAM-related activities, organizations use different methodologies, which have been developed both in the academia and industry. The origins of the modern EA can be traced to the Business Systems Planning methodology in the 1960s [10]. However, the term "enterprise architecture" and the related terminology were coined later in the early publications regarding the PRISM architecture framework (cf., [11]) and the Zachman Framework [12]. Currently, The Open Group Architecture Framework (TOGAF ® ), introduced in 1995, is the most widely adopted EA methodology in the industry [13]. However, most of the organizations have taken a "hybrid framework approach". [14] argues that no single methodology meets all requirements or addresses all the needs of a particular organization [13]. In a hybrid approach, aspects, ideas and approach are combined from a multiple different methodologies and frameworks.
There are some characteristics that are common to the majority of EAM methodologies. These include the separation of different viewpoints (such as business-related elements and technologyrelated elements) when an organization's architectural structures are being designed to constitute an aligned whole. Second, architectural planning and development is advised to consider the current state of the architectural structures in relation to the desired target state that would better serve the implementation of business objectives. By analyzing gaps between the current and desired structures, it is possible to identify and prioritize the relevant areas for development. Third, the EA frameworks, which can be considered as a form of enterprise ontology (cf., [15], [16], [17]), provide different viewpoints and different levels of abstraction (such as contextual, conceptual, logical and physical) for different stakeholders and their distinctive needs. For instance, a CIO might be interested in finding outdated software applications using the overall view provided by the application portfolio model, while a software developer designing the bestfitted integration approach might be interested in studying the APIs supported by the current information systems architecture. The design of actual implementable architectural structures is guided by the strategy-level considerations. For instance, along with the business architecture, information systems architecture, and technology architecture, the TOGAF ® content metamodel separates the architecture vision derived from the business and technology strategies, the architecture requirements and constraints, and the architecture principles, which formulate the general underlying rules and guidelines for the architecture development.
As the principles manifest general rules and guidelines to support an organization fulfilling its mission, defining the architecture principles is recommended as the initiating activity of EAM [18]; whereas principles constitute a foundation of thinking about the systems design [19] and the requirements, and, on the other hand, state the functional and constructional properties for a system to have [20]. Therefore, the principles can be seen as boundary conditions from which the implementable requirements are derived.
The EA principles can either serve as the designing principles that are used to describe the design of actual system artefacts or the regulative principles to convey a prescriptive notion limiting the design options allowed in a system design [21]. [20] characterizes the EA principles being the latter. It is argued that the EA principles are a specific form normative principles that "guide/direct the enterprise normatively restricting design freedom" [20, p. 11]. Normative principles are based on artifacts such as strategy, the existing environment, and external developments [20]. The EA principles pursue the organization-wide consensus in the development, maintenance, and use of EA as well as in guiding its implementation as operational activities and supporting assets. As such the principles bridge the strategy and operations. In practice, the EA principles are widely formulated in organizations and used, for instance, for reviewing development initiatives and projects. Therefore, the documentation and communication of EA principles is essential. The documentation should include, as a profound element, a clear definition of a principle's structure and the relations it has with its environment [22]. Furthermore, the documentation should address the principle's motivating rationale, concrete implications, and measures with which its fulfillment is evaluated [23], [24].

Information Security Policy
Organizations need to consider many facets of information security in their daily operations. The rapidly increasing use of IT, emerging technologies and digitalization of organizations' core resources provoke new threats that can be difficult to anticipate [25]. Attacks that damage or modify data can affect the critical infrastructure without any awareness of its owner. It is noteworthy that at the same time as new security threats have appeared alongside emerging technologies, an increasing number of threats are located inside the organization. Many of these threats are caused by unintentional, careless or negligent behavior [26], [27], [28]. Therefore, a majority of the literature on information security focuses on the user's perspective and how the users of information and technology resources can by their actions prevent, detect and respond to security threats [29].
Information security also encompasses data sources that are not in digital formats. Information that is based on physical documents or employees' knowledge can as well be a target to security threats [30]. Individual knowledge can be a key competitive advantage for an organization and therefore needs to be protected. Information security vulnerabilities contain a significant risk, not only to the operations of an organization, but also from the point of view of the organization's reputation. To this end, several organizations have been increasingly focusing on developing safety-related policies and aligning them with non-organizational regulations.
The number of studies on the implementation and efficiency of information security has significantly increased in the 21st century and the information security policy development is an area of growing scholarly interest. Generally, the concept of the information security policy is divided into the three categories of abstraction. At the lowest level of abstraction, information security is looked at from a technical point of view [5]. At this level, the key concern is the security architecture of technical systems, usually focusing on standards and procedures for the systems configuration or maintenance. At the next level of abstraction, information security is viewed from the user's point of view [5]. Here, certain areas of technology, such as the use of internet services, are addressed. These policies may include instructions and procedures that employees must observe in their daily interactions with the information and technology resources. The majority of extant research literature is examining the security policies through an individual and operational abstraction level [29]. At the highest level of abstraction, the information security is approached from the senior management point of view [5]. At this level, instead of the actual operative principles, the focus is on the strategic direction of the organization and the extent and nature of security objectives. These guide the development, implementation and management of the security programs and assign responsibilities to the various security areas at the most abstract, philosophical level [29].
To gain a needed broader perspective on the problem area, the topic of security has been approached from the perspectives of policy compliance and information security culture [29]. However, [31] argue that the extant literature on information security policies focuses on describing the structures and content, but usually does not describe a detailed development process. The professionals involved in the information security policy development are provided with little knowledge about the processes they should follow. They often need to rely on guidelines which are not specifically designed for their organizations and thus fail to recognize and answer to their specific threats and requirements [5], [31].
For constructing the information security policy, [5] argues for three matters to be considered. First, an organization must be able to compile and update its information security policy in an agile manner. This is especially important when the organization strives for a change that may conflict with the existing information security policy. However, this does not mean that the information security objectives should be ignored, but the security elements should, as quickly as possible, be aligned with the changed requirements. The goal is that the organization is both capable of effectively seeking the change, but also capable of achieving an appropriate level of information security. This kind of agile aspect is essential as organizational change can also help to meet the information security requirements. Therefore, the principles for managing the information security must always be synchronized with the organizational priorities and the processes that support these goals.
The second matter is political simplicity. [5] notes that inflexible policies induce secret and poorly considered non-compliance. Therefore, the process of policy construction must be transparent, aware of its context, and involve the stakeholders at the different levels of an organization. The policy-related decisions need to be well-reasoned and their implications explicit. Thirdly, an information security policy must implement the existing criteria that can be obtained, for instance, from legislation or organization's own priorities. It should be noted, however, that if these criteria are not detailed, it is permissible for policy makers to have a better chance of responding flexibly in modifying the organization's information security policy so that the organization can react efficiently in the organizational changes.
Cyber security risks are socio-technical in nature as they include not only technical vulnerabilities but often also include factors related to behavior of human actors [28]. Consequently, several researchers have phrased the potential of the EAM to serve as an encompassing instrument for approaching information security related questions. For instance, [32] notes that the EAM provides a mean to mitigate the limiting siloed thinking of traditional risk management processes as it gives a better understanding on how an asset and its value can be affect by a manifestation of a risk. Similarly, [2] argues that the EAM is a promising approach to deal with the increasing complexity of organizations, technologies and the related security threats. Most of the current efforts, however, have focused only on individual areas on the domain of EAM, such as information systems risk management (e.g. [2], [33], [34]). Therefore, as argued in [35], the holistic approach to the security in EA is still lacking.

The Constructive Research Approach
As stated previously, the objective of this study is to develop an abstract design knowledge artefact. Design knowledge, produced by design research, can be separated into two outcomes, namely, abstract and situational design knowledge. Abstract design knowledge comes from meta-design, for instance, literature review, modelling and engagement scholarship [36] and produces abstract concepts, generic models, guidelines for design practices and systems abstractions with key properties [36]. The method framework is created based on the literature from both research fields: the EA and the information security. Engagement scholarship was executed through interviews.
Both the meta-design and the design practice have diverse types of evaluation that should be conducted during the design and development phase. Design science evaluation has two forms: artificial and naturalistic evaluation [46] of which artificial evaluation was used in this study. In design science research, there are two evaluation related phases, evaluation and demonstration. In this study, the demonstration phase was conducted as a series of expert interviews.
Interviewees were asked to evaluate the suitability of the method framework, and the artefact was evaluated based on the views of the interviewees. The method framework was modified the first time after four interviews, and the second time after all the nine interviews were conducted.
In the field of method engineering, it is often argued that no method is suitable as such and some situational adaptation is always needed. The method adaptation refers to the activities of enhancement, extension or restriction to make a method suitable for a specific domain, an organization, or a project [14], [37], [38]. Adaptability of the EA methods is particularly important due to the considerable heterogeneity of organizations and their business environments [39], [40], [41], [42]. In comparison to a method, a method framework is purposefully a more abstract methodological element that supports the definition of methods [43]. The method framework can be considered as a generalization of a method, which is then adjusted and specified to the context of a certain organization.
This section describes step-by-step the constructive research process that adopts ideas from several notable works on the design science research (e.g. [44], [45], [46], [47]). Also, the goals and requirements regarding the method framework's content and expedience are presented. Figure 1 summarizes the phases of the research process that was followed while constructing the Method Framework for Enterprise Architecture Security Principles (MF4EASP).

Problem Identification and Motivation
The problem, i.e. the need for and the current lack of a holistic approach for integrating aspects of information security into EAM, has been raised in recent studies. For instance, a study [35] argues that the integration of security and risk related concerns into the holistic approaches of EAM are currently at an inadequate level. Consequently, recent efforts have focused on information systems risk management (e.g. [2], [7], [35], [48]). However, in a review of 15 years of academic EA endeavors, a study [1] notes that although some progress has been made, EA has not yet reached the state of being a viable tool for addressing emerging security challenges and new threats to organizations' complex information systems. For instance, although EAM is mandated by legislation in the Finnish public sector, the National Audit Office of Finland, in their 2017 report, discovered several problems in the area of information security. Their report states that EA descriptions would serve as a valuable tool for evaluating the criticality of electronic services but EAM is not properly integrated with the operational requirements and practices. It was also found that the criticality of the ICT systems is not regularly checked, although the frequent changes occurring in the operating environment would absolutely need it. Finally, the report states that the information security is commonly instituted as the responsibility of the IT units, even though they may not be aware of all the necessary business-related concerns, and thereby the holistic view to the information security remains lacking.

Requirements and Objectives
We analyzed the rich qualitative data obtained by interviewing 26 seasoned experts on EA, who contributed to the problem identification and to capturing the requirements and objectives for the MF4EASP. These informants serve in different positions in both private IT companies and public sector and their experience in EA-related activities range from 3 to 40 years with the average of 15 years. The interviews addressed the informants' views of the past, present and future practices of EAM. The data were screened for the information relevant to the objectives of this study. The details of the data collection can be found in [48]. The identified generic requirements for the MF4EASP are presented in Table 1. These are accompanied with the representative examples of citations from the interview transcripts. The excerpts are translated from Finnish to English.

Design and Development
The overall structure for the artefact presented in this paper draws from the previous works on the design of EA principles and information security policies. A number of academic contributions on the EA principle development can also be found (e.g. [6], [23], [24]), although their applicability is somewhat limited due to their generality and purposefully wide scope. Based on the literature review [49], the consolidated metamodel of EA principles has been presented [22]. By itemizing the elements of a principle, this metamodel differentiates the core definition of the EA principle, including its statement, rationale, implications, key actions, and related measures, and also provides an extended definition that considers the principle's impact on its environment. We used the work presented in [22] for defining the key components and the areas of concern for MF4EASP. Next, for the structure of EA security principle development process, we adapted the process of the policy development framework [31] and the relevant components presented in the Comprehensive Information Security Policy Process Model [50]. Finally, we strived to balance the requirements found in our empirical data with the requirements of suppleness, political simplicity and criterion-orientation as discussed in relation to information security meta-policy in [5].
The MF4EASP was constructed using the ArchiMate ® 3.0.1 specification. The ArchiMate ® modeling language is an Open Group standard, which provides a TOGAF ® compliant modeling notation that covers all the EA domains. It is widely used in both public and private organizations around the world and is supported by the majority of EA modeling tools. As a semi-formal modeling language, it provides a coherent and visually uniform representation for EA artefacts covering different components of an architecture and their dependencies. As such it aims at enabling communication among stakeholders, and guides complicated change processes on architectural structures.

Demonstration and Evaluation
Nine expert practitioners took part in evaluating the tentative versions of MF4EASP. The evaluators were selected using the criterion sampling (c.f., [48]) so that the informants could provide profound and well-reasoned insights to support the further development of the construct. Four of the evaluators have their expertise both in the fields of EA and information security, three in the information security, and two in the EA. Their occupational positions included Chief Information Officer, Chief Digital Officer, Enterprise Architect, Specialist, Researcher, and different managerial positions. The evaluators' professional experience in the field of their expertise ranged from 2 to 30 years with the average of 14 years.
The evaluation of the method framework was conducted by presenting the MF4EASP to the evaluator who was then asked to give feedback, criticism and constructive ideas regarding various aspects. Each evaluator was met individually by the first author, to ensure that their views and opinions would not affect the other evaluators. The aspects of evaluation were based in the method engineering knowledge and adhered to shell model presented in [52]. Table 2 presents the themes covered during the evaluation and the questions they were addressed with. Overall, the evaluation was targeted to the correctness, completeness and applicability of the MF4EASP.
The evaluation was conducted for the two versions of MF4EASP in the two rounds. Some changes were implemented to the first version of construct according to the feedback given by the first four evaluators. These included, for instance, a possibility for both objectives and constraints to define requirements for design principles, the acknowledgement of possible stakeholder-induced risks, and that the process needs to, in addition to security principle development, consider their implementation in an organization.

Values and Assumptions
-EAM is a beneficial approach to information security issues. -EA principles and information security policies share similar approaches, goals and levels of abstraction and can be used in union to develop an information security principle.
-Are the assumptions correct? -Are the assumptions relevant? -Are there any other assumptions to be considered?

Development Objectives and
Decisions -The objective is to develop a method for EA information security design principle development.
-Is it possible to develop an efficient EA information security design principle with the MF4EASP? -Are the presented development decisions correct? -Are the presented development decisions coherent?

Participation and Roles
-The participating roles include management; legal counseling; HR; IT staff; end-users; external representatives.
-Is there a stakeholder role missing or excessive?

Process
-The process combines the aspects of EA principle development and security principle development.
-Do the sub-processes represent suitable content for the development process? -Are the sub-processes orderly arranged? -Is there a sub-process missing or excessive?

Notation
-The method framework is represented using the industry standard ArchiMate ® modeling notation.
-Are the notational constructs understandably and correctly related to the concepts used (for instance, fidelity, completeness, only one construct used per concept)? -Is the modeled representation of MF4EASP understandable? -Are the concepts meaningful, relevant and sufficient?

Conceptual
Structure -The conceptual structure is based on and extends the ArchiMate ® metamodel and previous information security policy development frameworks.
-Are the relationships between concepts meaningful, relevant and sufficient? -Is there a concept missing or excessive? -Is the level of detail adequate for the MF4EASP to be used in different organizations?
On the next round, both the original and the altered versions of the construct were presented to the five evaluators. Overall, the review feedback resulted in some corrections, alterations and adjustments to the method framework. The comments addressed details of the graphical representation (i.e. the ArchiMate ® notation and its use), a need to alter the types of relationships or to add new relationships between concepts, missing sources of security threats, alleged challenges related to the implementation of the suggested development process, and concerns regarding the monitoring an organization's compliance to the principles. The last two, while absolutely critical and present important topics for the future research, go beyond the scope of this study. Therefore, we purposefully omitted the details of the context-specific process implementation and the enforcement of principle adherence. Some of the comments, although each of them were thoroughly contemplated during the evaluation and redesign of the method framework, were omitted because did not clearly meet the objectives of MF4EASP. The evaluator comments are summarized in Table 3. Table 3 Evaluation comments requesting for alteration

Area of Evaluation Evaluator comments requesting for alteration Values and Assumptions
-None.

Development Objectives and Assumptions
-The high level of abstraction makes it difficult to implement an efficient method.

Participation and Roles
-Senior level management roles need to be added as stakeholders.
-Stakeholder groups should cover also 'leadership roles' as it is different from the managerial roles. -It should be possible to acknowledge stakeholders as potential security threats.

Process
-The process could be difficult to implement.
-There is a risk that information security ends up guiding business activities. -The principles are not a sufficient mean to guide an organization.
More specific guidelines and instructions are needed. -More specific guidelines are needed for practical implementation.
-It can be difficult to recognize the needed factors in an organization.
-The use of Balanced Score Card and SWOT analysis could provide additional support while implementing the process. -The method is better suited for implementing slow changes and improvements.

Notation
-The use of some ArchiMate ® elements does not adhere to the language specification. -The method framework is difficult to understand without written explanation. -The ArchiMate ® -based representation is not well-suited for supporting the communication between different stakeholders.

Conceptual Structure
-The concepts should be specified in more detail.
-The level of abstraction is high, which makes it impossible to identify the expected elements from an organizational context. -The level of detail does not cover "two-speed IT" and is more suitable for slow changes. -Two-speed IT should be considered.
-The method framework claims that the risk assessment could be done without the knowledge about possible threats. -The legislation is not only a requirement. It can also be a constraint.
-The risk assessment alone is not sufficient. It must be preceded by risk analysis.

MF4EASP -The Method Framework for Developing Enterprise Architecture Security Principles
The design of the MF4EASP method framework, as presented in Figure 2, was based on the literature on EA principles and information security policy construction as well as interviews of 26 seasoned EA practitioners and 9 experts on EA and/or information security. In the following, the components of MF4EASP are structured to adhere to the layers of SABSA † business driven enterprise security architecture framework, due to its commonly acknowledged position. The SABSA compliant layers included in the MF4EASP are the contextual, conceptual, logical, physical and component layer. SABSA suggests these layers for the management of delivery of security solutions throughout their entire lifecycle. The contextual architecture layer's (i.e. business view) main function is to identify and extract security requirements from the business environment. The risk assessment is conducted based on these requirements [53]. The conceptual architecture layer (i.e. architect's view) generalizes the business concerns and considerations into policies and procedures. The logical architecture layer (i.e. designer's view) defines detailed security controls and management objectives to, for instance, access control and monitoring operations. This layer transforms the abstract business requirements to applicable security specifications [53]. Finally, the physical architecture layer (i.e. constructor's view) and the component architecture layer (i.e. technician's view) are the fields of operations managers and systems developers, respectively, who implement the security mechanisms according to the above layers. When using the MF4EASP, enterprise architects are to operate on the areas related to the conceptual and logical layers. They define the EA security principles, carefully align them with the organization's EA, and bridge the domains of the business requirements and the related security implementations.

Figure 2
The MF4EASP method framework The implementation of the MF4EASP starts from the upper left-hand side corner ( Figure 2). An organization might have concerns arising from minor or major changes in the organization itself, its economic sector or business domain, legislation, or technology. Then, the identified changes are channeled through the processes of risk analysis and risk assessment, whose detailed implementation should be fitted for each particular organization and its branch of industry. The risk analysis and assessment may state a concern being a potential security threat. An identified threat does not necessarily trigger a need to establish a new EA security principle. It is well possible that the organization already has functional principles to handle these emergent changes. However, if the threat is considered to potentially have a negative impact on the goals of the organization, and it is assessed that the related risks need to be mitigated, the outcome of the risk assessment process will initiate the EA security principle development and deployment process.
The process starts with the evaluation of the situation at hand. The relevant stakeholders revise the business and IT objectives and evaluate the constraints they set. The objectives and constraints specify the requirements that the principle must meet. Even though the requirements can be treated as the specified types of the constraints, requirements analysis must also consider the needs derived from the organizational goals. It is also possible that there are non-constraining requirements, which still set conditions for the principle. The principle construction should acknowledge all the stakeholders to whom the principle will have an effect on.
The next sub-process covers the principle's implementation to the related structures of an organization's EA. A principle may have an impact on an entire organization, its certain business unit, an expected professional behavior, a work practice, an information system, technology, etc. Once a principle has been implemented, the compliance monitoring will commence, focusing on the appropriate indicators and utilizing the means best suited for the purpose. If the monitoring of the adherence to the principle reveals either that the principle as such does not reflect the actual business concerns to the appropriate expedient or the organization, for this or some other reason, fails to comply with the requirements it posits, the process returns to the evaluation phase. The re-evaluation of the already implemented principle may either lead to strengthening its rationale or enforcement practices, to the principle's readjustment, or even its dismissal.
An organization can integrate its information security policy with the practices of EAM by following the principles constructed and implemented using the MF4EASP. All the layers of EA should be compliant to the principles, as discussed in Section 2.1. For instance, a generic security principle stating that the data related to the personal information must be treated securely and confidentially, would extend over professionally conducted work practices, the information systems supporting these practices as well as the technology layer, such as the data storages, upon which the systems' data management processes are executed. The EA security principles constructed using the MF4EASP can be, and should be, used as both the design principles and the regulative principles, and, on the other hand, are applicable on all the target areas of information security policies.

Discussion
Although the presented method framework was carefully evaluated by several professionals of the fields of information security and enterprise architecture, its actual capability to serve in real life situations still remains to be seen. This will require further studies on the implementations of MF4EASP. The evaluators also pointed to some concerns regarding the suggested method framework that we did not see feasible to include at this stage, or that were outright impossible to implement, as they would have necessitated the formulation of universally normative guidelines. For instance, some of the evaluators were skeptical about the practical implementation capability of the EA security principle development and deployment process. Likewise, another evaluator uttered that more specific guidelines would be required for this purpose. However, as we presented a generic and context-independent method framework, we purposefully did not want to formulate organization-specific guidelines. The principle implementation undeniably affects the organizational culture and its embedded mechanisms, which are not only the targets of change but also the effectors in this process. These fine-grained details are impossible to address within the scope of this study.
Another evaluator also expressed a concern regarding that the MF4EASP would lead to a situation where the security principles end up guiding business activities and thus limit possibilities for innovation and experimentation, which can be highly important for nurturing new business opportunities. In a similar manner, two evaluators addressed concerns related to the 'two-speed IT', which is argued being an enabling requisite for digital innovation. On this regard, we want to re-emphasize that the contextual architecture (i.e. business view) is the driving viewpoint for the security principle development. It is not the purpose of the MF4EASP that it should limit the organization's capability to innovate and experiment for the sake of information security adherence. However, these experimentations, naturally, need to be in line with the business goals and constraints, and should they be decided to be released into the production environment, they need to comply with the organization's security policy guided by the business objectives.

Conclusions and Future Work
The objective of this study was to develop an abstract design knowledge artefact in the form of a method framework for integrating information security principle development with EAM. The presented method framework is a result of constructive research based on both the theoretical body of knowledge and the empirical evidence, which was obtained by interviewing 35 Finnish EA and information security practitioners. The empirical data served the major role in constructing the results of this study. All our informants are based in Finland and therefore mostly reflect the local standpoints and the European standards and regulations to the information security. A theoretical contribution can be found from the coverage of two distinct yet interrelated streams of research: information security and EA. Therefore, the results presented in this paper contribute to the currently lacking theoretical body of knowledge on EAM-driven information security management practices and their practical implications should be generally applicable. While the proposed method framework still needs to be tested with actual use cases, the current results provide actionable guidelines for the organizations struggling with the challenges related to the information security in the constantly changing business environments.