OPS.2.3 Use of Outsourcing

Description

Introduction

In outsourcing, institutions (outsourcing users) outsource business processes or activities wholly or partly to one or more external service companies (outsourcing providers). These so-called outsourcing providers operate the business processes or activities within the framework of the agreed outsourcing relationship according to defined criteria. However, the responsibility from the perspective of information security always remains with the outsourcing institution.

Outsourcing can relate to the use and operation of hardware and software, whereby the service can be provided in the premises of the contracting party or in an external operating facility of the outsourcing providers. Typical examples of classical “IT outsourcing,” to which this building block refers, are the operation of a data center, an application, or a website. Outsourcing is an umbrella term that is often further specified by additional terms such as hosting, housing, or colocation.

An outsourcing relationship concerns, in addition to the original outsourcing users and providers, in many cases additional sub-service providers downstream of the outsourcing providers. If parts of business processes or activities are further transferred from outsourcing providers to sub-service providers, the business processes or activities outsourced by users are further fragmented. This affects the complexity of the outsourcing chain, resulting in diminishing transparency for the outsourcing users. The proof that the requirements placed on the outsourcing providers are met extends here both to the outsourcing providers and to the sub-service providers.

For better clarity, the term “process” is used in this building block as a representative for business process, activity, or component that is outsourced.

Objective

The objective of this building block is to ensure the fundamental values of information security — confidentiality, integrity, and availability — throughout the entire lifecycle of outsourcing by the outsourcing users. Outsourcing here means classical “IT outsourcing.”

The requirements of building block OPS.2.3 Use of Outsourcing are intended to help identify, prevent, and reduce potential threats to business operations. Risks to an institution should thereby remain within a controllable framework for the institution. This can be achieved through greater transparency and control instruments. For this purpose, the institution is supported in its planning, implementation, and control of the outsourcing process throughout the entire lifecycle with regard to technical and non-technical aspects of information security.

Scope and Modeling

The building block OPS.2.3 Use of Outsourcing is to be applied once for each outsourcing provider from the perspective of the outsourcing user.

This building block addresses threats and security requirements from the perspective of outsourcing service users and is limited to the requirements for protecting information on the part of the outsourcing institution.

This building block does not address the transmission paths to outsourcing providers.

Likewise, the use of cloud services is not addressed in this building block; for this, building block OPS.2.2 Cloud Use is to be applied.

Scenarios deviating from classical “IT outsourcing” (such as the operation of hardware and software, hosting, housing, etc.) may not always be completely represented by building block OPS.2.3 Use of Outsourcing and may require a separate risk analysis.

Security services, cleaning staff, maintenance services, and external personnel are a special case for which building block OPS.2.3 Use of Outsourcing is not to be applied. These are covered through the requirements on security services, cleaning staff, maintenance services, and external personnel in building blocks ORP.1 Organization and INF.1 General Building.

The counterpart to building block OPS.2.3 Use of Outsourcing is building block OPS.3.2 Providing Outsourcing, which addresses the outsourcing relationship from the perspective of the service providers. Together, the two building blocks form a holistic picture of the outsourcing relationship and, with their requirements, ensure a fundamentally secure outsourcing project.

Threat Landscape

Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used to illustrate the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block OPS.2.3 Use of Outsourcing.

Insufficient Strategy for Outsourcing

An insufficient strategy leads to information security not being adequately taken into account in outsourcing projects. As a result, information security is not adequately observed in the individual phases of the outsourcing lifecycle, and thus a sufficient level of information security is not aimed at and implemented in the institution’s own operations as well as at the outsourcing providers. This can disrupt or halt processes and cause information to flow to unauthorized third parties.

Risk of Outsourcing Institution-Critical Processes

Processes that should remain in the institution due to their criticality or protection needs are outsourced. As a result, the institution can no longer adequately control and manage the process that is necessary for proper business operations. If the process fails or is disrupted, proper business operations cannot be ensured. Furthermore, the outsourcing providers gain greater influence. The outsourcing users risk losing control.

Dependency on Outsourcing Providers

When an institution decides to outsource, it also becomes dependent on the outsourcing providers. With this dependency, knowledge can be lost and the outsourced processes can no longer be fully controlled. Additionally, the protection needs of the outsourced business processes and information could be assessed differently. This can lead to security measures being implemented that are inappropriately suited to the protection needs. Institutions often outsource entire business processes to outsourcing providers. The outsourcing providers can thereby fully control the business processes with sensitive information, resources, and IT systems. At the same time, knowledge about these areas decreases among outsourcing users. As a consequence, it is possible that the outsourcing users no longer notice deficiencies in information security. This situation could be exploited by outsourcing providers, e.g. by drastically increasing prices or reducing the quality of services.

Insufficient Level of Information Security in Outsourcing

An insufficient level of information security can lead to information security not being adequately taken into account in outsourcing projects. The consequence is that the outsourcing providers maintain no, or only an insufficient, standard of information security for the outsourcing process. This results in vulnerabilities from which IT-supported attacks and data losses can originate. In addition, legal consequences with financial implications and reputational losses can arise for the outsourcing users.

Inadequate Outsourcing Management

Non-existent or only partially implemented outsourcing management manifests itself in the fact that the ongoing outsourced processes are inadequately managed. This reduces or eliminates transparency over the outsourced processes. As a result, outsourcing users can no longer control and adequately manage the outsourcing providers. The outsourcing users can no longer ensure that the outsourcing providers handle information security diligently in the outsourced process.

Inadequate Contractual Arrangements with Outsourcing Providers

Inadequate contractual arrangements with outsourcing providers can lead to vulnerabilities in information security throughout the entire outsourcing lifecycle. The contractual arrangements define the entire outsourcing process and represent the starting point for the users’ claims against the outsourcing providers. Due to inadequate contractual arrangements with the outsourcing providers, a wide variety of serious security problems can arise. If tasks, performance parameters, or expenditures were insufficiently or ambiguously described, security measures may possibly not be implemented out of ignorance or due to a lack of resources. This can have many negative consequences, for example if regulatory requirements and obligations are not met or disclosure obligations and laws are not complied with. If the aspect of information security is not taken into account in contract design, the processes and data of the outsourcing users can be inadequately secured.

Inappropriate Management of Access, Admission, and Access Rights

Depending on the outsourcing project, it may be necessary for employees of outsourcing providers to need access, admission, and access rights to IT systems, information, buildings, or premises of the outsourcing users. These rights can be inappropriately granted, managed, and controlled; in extreme cases, rights may even be granted without authorization. Furthermore, the necessary protection of the information of the outsourcing users can no longer be guaranteed. For example, it is a serious security risk to grant uncontrolled administrative authorizations to employees of outsourcing providers. These could exploit authorizations and copy or manipulate sensitive information.

Loss of Control and Management Due to Further Transfers

Parts of business processes or activities may be fully or partially transferred from outsourcing providers to sub-service providers. Since the outsourcing process becomes more complex due to the additional participants, it becomes more opaque for the outsourcing users. Due to this lack of transparency, the outsourcing users can no longer adequately control and manage the outsourced processes. Furthermore, outsourcing providers may fail to demand from sub-service providers the minimum level of information security required by the outsourcing users. A consequence is that the agreed information security aspects may not be fully implemented by the sub-service providers.

Missing and Inadequate Instruments for Managing Outsourcing Providers

In order for an institution to be able to check whether the outsourced processes are being properly implemented by outsourcing providers, it requires not only corresponding agreements but also the instruments for doing so. These can be, for example, qualitative and quantitative performance indicators (KPIs). In order to be able to respond to underperformance and poor performance, correspondingly defined performance indicators are required. Missing and inadequate instruments lead to the outsourcing providers not being able to be adequately controlled and managed. This means that it can no longer be checked and traced whether the specified security requirements are being complied with.

Inadequate Regulations for a Planned or Unplanned Termination of an Outsourcing Relationship

An outsourcing relationship can be terminated by ordinary notice or also for extraordinary reasons. Here, inadequate or missing regulations can lead to hardware, data, and access not being returned or transmitted to the outsourcing users correctly or at all.

Insufficient Contingency Concept

In the event of a disruption, emergency, or crisis, insufficient emergency management can lead to the outsourced processes failing. In particular, insufficient emergency preparedness inadequately prepares the institution for an emergency or crisis situation. Effective emergency management cannot be ensured on this basis. Disruptions, emergencies, and crises cannot be controlled and can lead to immediate economic impacts. In this case, not only the institution itself, but also all connected institutions that must be taken into account in emergency preparedness and emergency management, are affected. Cascade effects from upstream and downstream service providers lead to considerable impacts on the business operations of the outsourcing users.

Requirements

The following are the specific requirements of building block OPS.2.3 Use of Outsourcing. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO MUST always be involved in strategic decisions.

The IT-Grundschutz Compendium additionally defines further roles. They should be staffed insofar as this is reasonable and appropriate.

Exactly one role should be Primarily responsible. Beyond that, there may be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, this role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many persons should fill these roles.

Basic Requirements

The following requirements MUST be fulfilled as a priority for this building block.

OPS.2.3.A1 Creation of Requirements Profiles for Processes (B) [Specialist Responsible Persons]

If no Business Impact Analysis (BIA) is available, requirements profiles in the form of fact sheets MUST be prepared for the processes that are potentially to be outsourced. These requirements profiles MUST contain the function, processed data, interfaces, and an assessment of information security. In particular, the dependencies between the processes as well as subordinate sub-processes MUST be taken into account. The requirements profiles MUST reflect the criticality of the respective process for proper business operations.

OPS.2.3.A2 Pursuing a Risk-Oriented Approach in Outsourcing Management (B)

For processes that are potentially to be outsourced, a risk-oriented consideration and decision MUST be made as to whether they can be outsourced. The requirements profiles SHOULD be used as a basis for this assessment. If the process is outsourced, the result SHOULD be stored in the outsourcing register. In order to take into account changes to processes or the threat situation, the outsourced processes MUST be subjected to a renewed risk-oriented consideration at regular intervals and on an ad-hoc basis.

OPS.2.3.A3 Definition of Suitability Requirements for Outsourcing Providers (B) [Specialist Responsible Persons, Top Management]

Internal suitability requirements for potential outsourcing providers MUST be defined. These suitability requirements MUST take into account the required competencies to secure the process from an information security perspective, as well as the reputation with regard to trustworthiness and reliability. These suitability requirements SHOULD be developed on the basis of the corporate strategy (see OPS.2.3.A8 Creation of a Strategy for Outsourcing Projects). It MUST be checked whether potential conflicts of interest exist. Furthermore, the outsourcing providers SHOULD be regularly checked against the suitability requirements. If the outsourcing providers do not meet the suitability requirements, action measures SHOULD be taken and recorded in a measures catalogue.

OPS.2.3.A4 Basic Requirements for Contracts with Outsourcing Providers (B)

Uniform basic requirements for outsourcing contracts MUST be developed. These basic requirements MUST include aspects of information security, a consent reservation for further transfers, and a right to examination, revision, and audit. When developing the basic requirements, the results of the risk-oriented consideration and suitability requirements for outsourcing providers SHOULD be incorporated. A confidentiality agreement to protect sensitive data SHOULD be agreed with the outsourcing providers. The basic requirements MUST be uniformly implemented in agreements and contracts. On the basis of the basic requirements, a uniform contract template SHOULD be created and used for all outsourcing projects.

OPS.2.3.A5 Agreement on Multi-Tenancy (B)

In an agreement on multi-tenancy with the outsourcing providers, it MUST be ensured that the data and processing contexts are sufficiently securely separated by the outsourcing provider. In this agreement, a tenant separation concept SHOULD be required from the outsourcing providers. The tenant separation concept SHOULD distinguish between tenant-dependent and tenant-independent data and objects and set out the mechanisms used by the outsourcing providers for separation.

OPS.2.3.A6 Definition of Security Requirements and Creation of a Security Concept for the Outsourcing Project (B)

With the outsourcing providers, it MUST be contractually agreed that IT-Grundschutz is implemented or at least the requirements from the relevant building blocks are appropriately fulfilled. Furthermore, it SHOULD be agreed with the outsourcing providers that they establish an information security management system (ISMS). The outsourcing users MUST create a security concept for each outsourcing project based on the security requirements arising from IT-Grundschutz. In doing so, the security concept of the users MUST be coordinated with the outsourcing providers. Likewise, each provider SHOULD present an individual security concept for the respective outsourcing project. The security concept of the outsourcing providers and its implementation SHOULD be merged into a comprehensive security concept. If risk analyses are necessary, agreements MUST be made on how the risk analysis can be reviewed and, if necessary, transferred to the institution’s own risk management. The outsourcing users or independent third parties MUST regularly check whether the security concept is effective.

OPS.2.3.A7 Regulations for a Planned or Unplanned Termination of an Outsourcing Relationship (B) [Specialist Responsible Persons, Top Management]

Regulations MUST be established for planned and unplanned terminations of the outsourcing relationship. It MUST be specified how all information, data, and hardware of the users are returned by the outsourcing provider. In doing so, statutory requirements for the retention of data MUST be observed. Furthermore, it SHOULD be checked whether the access, admission, and access rights for the outsourcing providers were revoked upon termination of the outsourcing relationship.

Standard Requirements

Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be fulfilled.

OPS.2.3.A8 Creation of a Strategy for Outsourcing Projects (S) [Top Management]

A strategy for outsourcing projects SHOULD be created and established. In this strategy, the objectives, opportunities, and risks of the outsourcing projects SHOULD be described. The strategy SHALL provide the institution with a framework for the requirements profiles, suitability requirements for outsourcing providers, and outsourcing management. In addition to the economic, technical, organizational, and legal framework conditions, the relevant aspects of information security SHOULD also be taken into account. A multi-sourcing strategy SHOULD be pursued in order to avoid bottlenecks and dependencies on outsourcing providers. The outsourcing users SHOULD retain sufficient capabilities, competencies, and resources to prevent a dependency on outsourcing providers.

OPS.2.3.A9 Establishing a Policy for Outsourcing (S) [Top Management]

Based on the strategy for outsourcing projects, a policy for the procurement of outsourcing services SHOULD be created and established in the institution. This SHOULD standardize the general requirements based on requirement OPS.2.3.A4 Basic Requirements for Contracts with Outsourcing Providers as well as further aspects of information security for outsourcing projects. The testing and approval procedure for outsourcing projects SHOULD be regulated in this policy. In addition, measures SHOULD be taken into account to manage compliance risks at outsourcing providers and sub-service providers.

OPS.2.3.A10 Establishing a Responsible Person for Outsourcing Management (S) [HR Department]

The various outsourcing projects SHOULD be managed by a responsible person for outsourcing management. The responsible person SHOULD be appointed and the powers defined and documented. The responsible person SHOULD be used as an interface in communication between the outsourcing users and providers. In addition, the responsible person SHOULD prepare reports on outsourcing at regular intervals and on an ad-hoc basis and submit them to top management. The responsible person SHOULD be involved in contract design. The responsible person SHOULD be allocated an appropriate contingent of working days for the tasks of outsourcing management. In addition, the responsible person SHOULD be trained and sensitized with regard to information security.

OPS.2.3.A11 Maintaining an Outsourcing Register (S)

The responsible person for outsourcing management SHOULD create and maintain an outsourcing register that centralizes the documentation of outsourcing processes and projects in the institution. This SHOULD be created on the basis of the requirements profiles and contain information on outsourcing providers, performance indicators, criticality of the process, concluded contracts and agreements, and changes. Changes to the outsourcing register SHOULD be appropriately tracked.

OPS.2.3.A12 Creation of Outsourcing Reports (S)

The responsible person for outsourcing management SHOULD regularly create internal outsourcing reports on the basis of the outsourcing register. These outsourcing reports SHOULD contain the current status of the outsourcing project with general problems and risks as well as aspects of information security. The outsourcing report SHOULD be submitted to top management.

OPS.2.3.A13 Provision of Required Competencies in Contract Design (S) [Top Management]

The contracts SHOULD be designed by various representatives from different areas. In doing so, a conflict of interest between operational business and information security SHOULD be avoided.

OPS.2.3.A14 Extended Requirements for Contracts with Outsourcing Providers (S)

With outsourcing providers, it SHOULD be agreed which areas and services the providers may access in the network of the outsourcing users. The handling of incidental metadata SHOULD be regulated. The users SHOULD define performance indicators for the outsourcing providers and specify them in the contract. In the event that the agreed performance indicators are insufficiently met, consequences such as contractual penalties SHOULD be agreed with the outsourcing providers. The contracts SHOULD contain cancellation options to dissolve the outsourcing relationship. It SHOULD also be regulated how the property of the outsourcing users is returned. Responsibilities with regard to emergency and crisis management SHOULD be defined and named in the contract.

OPS.2.3.A15 Connection to the Networks of Outsourcing Partners (S)

Before the data network of the users is connected to the data network of the outsourcing providers, all security-relevant aspects SHOULD be agreed in writing. It SHOULD be checked and documented that the agreements for the network connection are being complied with. The required security level SHOULD be demonstrably implemented and verified at the outsourcing providers before the network connection to the outsourcing users is activated. Before the networks are connected, the connection SHOULD be tested with test data. If there are security problems on either side, it SHOULD be specified who is to be informed and how escalation is handled.

OPS.2.3.A16 Review of Outsourcing Providers (S)

The outsourcing providers SHOULD be reviewed with regard to the contractually specified security requirements and the results documented. The outsourcing providers are to be audited at regular intervals and on an ad-hoc basis.

OPS.2.3.A17 Regulations for the Deployment of Personnel from Outsourcing Providers (S)

The employees of outsourcing providers SHOULD be obligated in writing to comply with relevant laws, regulations, and the regulations of the outsourcing users. The employees of outsourcing providers SHOULD be systematically briefed on their tasks and informed about existing information security regulations. Substitution regulations SHOULD exist for the employees of outsourcing providers. A regulated procedure SHOULD be defined that describes how the service relationship with employees of outsourcing providers is terminated. External personnel from outsourcing providers who are deployed at short notice or only once SHOULD be treated like visitors.

OPS.2.3.A18 Review of Agreements with Outsourcing Providers (S)

Agreements with outsourcing providers regarding the appropriateness of the specified security requirements and other security requirements SHOULD be reviewed at regular intervals and on an ad-hoc basis. Agreements with outsourcing providers with insufficiently defined security requirements SHOULD be improved. The outsourcing providers SHOULD be obligated to improve the specified security requirements when the threat situation or legal situation changes.

OPS.2.3.A19 Review of Courses of Action Regarding a Planned or Unplanned Termination of an Outsourcing Relationship (S) [Procurement Office]

Courses of action SHOULD be developed for the case of a planned or unplanned termination of the outsourcing relationship. The result SHOULD be documented in a measures catalogue for planned and unplanned termination of the outsourcing relationship. In doing so, alternative outsourcing providers SHOULD also be identified that have the necessary level of information security to implement the process securely. This SHOULD be checked at regular intervals and on an ad-hoc basis.

OPS.2.3.A20 Establishing and Integrating Outsourcing Providers in the Contingency Concept (S) [Emergency Officers]

A contingency concept SHOULD be established in the institution. This SHOULD be based on a Business Impact Analysis and take into account the dependencies of the outsourced processes with the processes remaining internally. The contingency concept SHOULD take into account the outsourcing providers in their emergency preparedness and emergency management and be coordinated with them. The interfaces to outsourcing providers SHOULD be named and staffed with responsible persons in order to enable information exchange and effective collaboration in an emergency or crisis situation. Joint emergency and crisis plans SHOULD be created for a disruption or failure of the outsourcing providers. Standardized protocols and reports SHOULD be established for reporting security incidents.

Requirements for High Protection Needs

The following are exemplary proposals for requirements for this building block that go beyond the level of protection corresponding to the state of the art. The proposals SHOULD be considered for high protection needs. The specific determination is made within the framework of an individual risk analysis.

OPS.2.3.A21 Conclusion of ESCROW Contracts for Software-Related Services (H)

If software is procured from outsourcing providers, an ESCROW contract SHOULD be concluded. This SHOULD regulate exploitation and processing rights for the software as well as cases for release of the source code. In addition, it SHOULD be specified how often the source code is deposited and documented. Furthermore, confidentiality obligations regarding the deposited source code and the associated documentation SHOULD be regulated.

OPS.2.3A22 Conducting Joint Emergency and Crisis Exercises (H) [Emergency Officers]

Joint emergency and crisis exercises with the outsourcing providers SHOULD be conducted and documented (see DER.4 Emergency Management). The result of the exercise SHOULD be used to improve the contingency concept and in particular the joint action plans. The emergency and crisis exercises SHOULD be conducted regularly and on an ad-hoc basis.

OPS.2.3.A23 Use of Encryption (H)

Sensitive data SHOULD be appropriately encrypted when transmitted to outsourcing providers. The stored data SHOULD be protected by data encryption or encryption of the storage medium. Where possible, encryption software reviewed and approved by the BSI SHOULD be used.

OPS.2.3.A24 Security and Suitability Vetting of Employees (H) [HR Department]

With external outsourcing providers, it SHOULD be contractually agreed that the trustworthiness of the personnel deployed is verified in an appropriate manner. For this purpose, criteria SHOULD be jointly defined and documented.

OPS.2.3.A25 Establishment and Use of a Sandbox for Incoming Data from Outsourcing Providers (H)

A sandbox SHOULD be set up for incoming data from outsourcing providers. In doing so, email attachments SHOULD be opened in a standardized manner in the sandbox. Updates and applications from a software-related outsourcing provider SHOULD initially be tested in the sandbox.

Additional Information

Good to Know

The International Organization for Standardization (ISO) provides in the standard ISO/IEC 27001:2013 in Chapter A.15.2 “Management of supplier service delivery” requirements for the management of outsourcing providers. In DIN ISO 37500:2015-08, further information on dealing with outsourcing providers is provided in the “Outsourcing Guide.”

Furthermore, in ISO 27002:2021 the outsourcing relationship is detailed and specified from Chapter 5.19 to 5.22, thereby specifying the requirements of ISO/IEC 27001:2013.

The Information Security Forum (ISF) defines in its standard “The Standard of Good Practice for Information Security” various requirements (SC1) for outsourcing providers.

The “Guide to Business Process Outsourcing: BPO as an Opportunity for Germany as a Business Location” of the Federal Association for Information Technology, Telecommunications and New Media (Bitkom) provides information on how business processes can be outsourced to outsourcing providers.

Likewise, Bitkom has published the “Guide to Legal Aspects of Outsourcing in Practice,” which addresses the legal aspects of outsourcing.

The National Institute of Standards and Technology (NIST) specifies in NIST Special Publication 800-53 requirements for outsourcing providers.