Application, achievements and summary

Application and flexibility

It is important that the Third Party Integration Model supports multiple tiers in the supply chain and supports supplier networks as well. This is due to the nature of concepts behind it, namely the Taxonomy (see Release 1 of the association[8]). The Taxonomy is highly modular; it organizes security in different areas which can be split into subareas. The specification of security in each area is done in form of single security measures. Each security measure defines a feature or activity which can be assigned to an entity (such as a team or a company). The Taxonomy organizes areas in the so-called Orchestration layer which is located in the middle of a Hierarchy of Security Standards. This layer and the level of abstraction associated with it are used for managing security agreements in the supplier network.

  • An example of a multi-tier supply chain is shown in Figure 6:
    • A cluster of an area in the ESARIS Security Taxonomy can be split into smaller sets (decomposition). In the example, the Supplier 1 uses deliverables from Supplier 2 and Supplier 3 in order to deliver an ICT service to the next in the supply-chain (which is the Provider 1 in the figure).
    • Supplier networks are supported since all suppliers can deliver both to Provider 1 and Provider 2. (The division of labor may differ.) This works well if the same ESARIS Security Taxonomy with the same set of security measures is used. Note that the support of supplier networks requires standardization as demanded through ESARIS.

Figure 6: Support of hierarchy and supplier networks

Note that such support is based on rigorous modularity provided by the ESARIS Security Taxonomy, by the standardized structure of the underlying ICT Security Standard, by the decision to define all security aspects by means of security measures (both technical and procedural) and by the structure and characteristics of the security measures.

The schema is very flexible and dynamic. The actual security standards are not defined in this paper nor the security measures defined in those standards. Here different sources may be used. Only the level of detail of the security measures is defined. Though the Taxonomy covers all possible aspects, the filter (called Provider Scope of Control) ensures that those security measures are actually used which relate to the product, component or service being provided by the supplying party and purchased by the consuming party in the supplier network. One of the security standards in the Taxonomy defines the interaction between the two parties. This standard can also be company specific. It is important that the Product Requirement Document (PRD) can be used in different contexts. This is ensured by its common structure (which will be defined by the group in a separate paper) and by defining how security measures are defined (level of detail/abstraction etc.). It is important that the security measures are defined in a rather implementation independent way. This is necessary in an industrialized environment where independent, largely specialized corporations interact and cooperate. It is also worth mentioning that, due to the nature of the Taxonomy, this model can be applied to hardware, software and even to “management” activities as defined by ITIL or ISO 20000 (confer also Figure 1).


Without a methodology it is likely that security gaps are introduced in such a complex environment like a supplier network in today’s IT industry. Even if security specifications exist, there is the risk that they are inconsistently applied, interpreted differently, or incompletely implemented. Even if all involved parties do their best with respect to integrating security, there is the risk that not all relevant security requirements are considered and that the combination of components and services is not secure or does not meet the expectations of the consuming party. Current security standards do not provide sufficient guidance to deal with this situation.

The methodology described in this paper provides guidance how to organize that products, components or services exchanged in the supplier network are actually secure and meet the security requirements of the consuming party. It helps to agree upon security while maintaining the necessary flexibility. The methodology considerably helps to decompose and compose/integrate deliverables and their security features.

The model, including the Taxonomy from Release 1 which is used, does not replace existing mainly technical security standards. It shall be regarded as a means to apply them in an environment characterized by a high degree of division of labor.


The Third Party Integration Model allows managing external suppliers or partners, more specifically, the security of products and services they are providing. It describes how the 31 ICT Security Standards are applied in the relationship between the supplier and consuming party. These standards are organized using the ESARIS Security Taxonomy which also outlines their content. The ESARIS Security Taxonomy decomposes the “whole world of security” into areas that relate to and can be assigned to individual businesses (i.e. production units like organizations, departments, teams). In this way, it supports the division of labor. The ESARIS Security Taxonomy and the content of its ICT Security Standards have already been released as a best practice by the Zero Outage Industry Standard association.[9]

The ICT Security Standard – Systems Acquisition and Contracting (SAC) defines the sequence of actions for managing third-party products and services. One of the security measures defined in this standard should require defining a so-called Product Requirement Document (PRD). The PRD defines the security measures which need to be implemented by the individual IT service or product provided by the supplying party. The security measures should be defined on the level of the Orchestration Layer which means that they are implementation independent. Hence, corporations should maintain a Hierarchy of Security Standards including (a) guiding principles (above the Orchestration Layer), (b) the largely implementation independent definitions of security measures (on the Orchestration Layer) as well as (c) security specifications below the Orchestration Layer providing all detail for the actual implementation.

The methodology Provider Scope of Control plays a major role to select the relevant areas from the Taxonomy. The ESARIS Third Party Integration Model primarily uses the definitions from the Orchestration Layer. Note that the security measures defined there do comprise those relating to

  • genuine IT services, i.e. IT functions generated by hardware and software,
  • IT service management activities[10] that produce and maintain those genuine IT services, and
  • overarching practices concerning the other two groups.

In this way it can be ensured that all security aspects are considered when managing a supplier network. This is crucial since one of the main problems in complex supply chains is that the responsibility for performing activities in the area of IT service management is not clearly defined and assigned to at least one of the parties. This and related issues shall be fixed by model described in this paper. The model also works within a multi-tier supplier network.

The verification of compliance with the Product Requirement Document (PRD) is out of scope and not yet described in this paper.

In the next release we will publish further alignment with the Zero Outage Architecture and add further details on how the topic contributes to Zero Outage. In addition, a template for a Product Requirement Document (PRD) will be provided and an example as well.

[8] ESARIS Security Taxonomy – Synopsis, Scope and Content; Zero Outage Industry Standard, Release 1 about Security, February 2017, [2] [9] ESARIS Security Taxonomy – Synopsis, Scope and Content; Zero Outage Industry Standard, Release 1 about Security, February 2017, [2] [10] Refer to e.g. ISO/IEC 20000 – Information technology – Service management – Part 1: Service management system requirements, Part 2: Guidance on the application of service management systems [5]. This standard defines “IT service management” activities.