Enterprise information security architecture (EISA) incorporates comprehensive and rigorous methods for describing a current and/or future structure and behavior for an organization's security processes, information security systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction. These practices and methodologies relate more broadly to the security practice of business optimization to address modalities in business security architecture, performance management and security process architectue.


From a business enablement perspective, the primary purpose of creating an enterprise information security architecture is to ensure that business strategy and IT security are aligned. As such, EISA allows traceability from the business strategy down to the supporting technology, standards, processes, procedures and guidelines. Security architectural change imperatives include:


  • Business roadmaps

  • Regulatory, legislative and legal requirements

  • Technology roadmapsIndustry trends

  • Risk trends

  • Dynamic Information Security/Cybersecurity Drivers


The practice of enterprise information security architecture involves developing an architecture security framework to describe a series of "as is" and “to be” or “target” reference architectures and applying them to align programs of change. These frameworks detail the organizations, roles, entities and relationships that exist or should exist to perform a set of secure business processes. This framework provides a rigorous taxonomy and ontology that clearly identifies the criticality of information and data and what processes a business performs with detailed information about how those processes are executed and secured. The end product is a set of artifacts that describes, in varying degrees, details of exactly what and how a business operates and what security controls are required. Visualization and graphical artifacts are essential. The main goal of this effort is to:


  • Provide structure, coherence and cohesiveness.

  • Enable business-to-security alignment.

  • Define a ‘top-down’ approach and integrated business strategy.

  • Ensure that all models and implementations can be traced back to the business strategy, specific business requirements and key principles.

  • Provide abstraction so that complicating factors, such as geography and technology, can be removed and reinstated at different levels of detail.

  • Establish a common "language" for information security/cybersecurity within the organization.


The level of detail will vary according to size, affordability and other practical considerations of the company. As such, decision makers are provided the means to make informed decisions about where to invest resources, where to realign organizational goals and processes, and what policies and procedures will support core missions or business functions.


Implementing enterprise information security architecture generally starts with interviews and documenting the organization's strategy and other necessary details such as ‘where’ and ‘how’ it operates. The process then cascades down to documenting discrete core competencies, business processes, and how the organization interacts with itself and with external parties such as customers, suppliers, and government entities. The depth and rigor of this process is directly related to the size and complexity of the enterprise and its true “risk appetite”.


Having documented the organization's strategy and structure, the architecture process then flows down into the discrete information technology components such as:


  • Organizational charts, activities, and process flows of how the IT Organization operates

  • Organization cycles, periods, timing and ongoing “in-flight” projects

  • Suppliers of technology hardware, software, and services

  • Applications and software inventories and diagramsInterfaces between applications - that is: events, messages and data flows

  • Intranet, Extranet, Internet, eCommerce, EDI links with parties within and outside of the organization

  • Data classifications, Databases and supporting data models

  • Hardware, platforms, hosting: servers, network components and security devices and where they are kept

  • Local and wide area networks, Internet connectivity diagrams


Wherever possible, all of the above should be related explicitly to the organization's strategy, security goals, and operations. The enterprise information security architecture will document the current state of the technical security components listed above, as well as an ideal-world desired future state (i.e., Reference Architecture) and finally a "Target" future state which is the result of engineering tradeoffs and compromises vs. the ideal. Essentially the result is a nested and interrelated set of models, managed and maintained with existing systems and proposed specialized application software readily available on the market.


Along with the models and diagrams, a set of best practices aimed at securing adaptability, scalability, manageability, etc. is provided. An intermediate outcome of a security architecture process is a comprehensive inventory of business security strategy, business security processes, organizational charts, technical security inventories, system and interface diagrams, and network topologies, and the explicit relationships between them. The inventories and diagrams are merely tools that support decision making. But this is not sufficient; it must be a living process that the organization embraces and nurtures.


The organization must design and implement a process that ensures continual movement from the current state (as is) to the future (to be) state. The future state will generally be a combination of one or more initiatives:


  • Closing gaps that are present between the current organization strategy and the ability of the IT security dimensions to support it

  • Closing gaps that are present between the desired future organization strategy and the ability of the security dimensions to support it

  • Necessary upgrades and replacements that must be made to the IT security architecture based on supplier viability, age and performance of hardware and software, capacity issues, known or anticipated regulatory requirements, and other issues not driven explicitly by the organization's functional management.

  • On a regular basis, the current state and future state are redefined to account for evolution of the architecture, changes in organizational strategy, and purely external factors such as changes in technology and customer/vendor/government requirements, and changes to both internal and external threat landscapes over time.