chrisbst48/IT-Grundschutz-Compendium_2022_EN huggingface dataset:
OPS.2.1.A10 Agreement on the Exchange of Data Between the Outsourcing Partners (S)
The security safeguards required for regular exchanges of data with fixed communication partners SHOULD be agreed. Data formats and approaches for the secure exchange of data SHOULD also be defined. There SHOULD be contact persons for organisational and technical problems. Contact persons SHOULD also be named for any security-relevant events that occur when exchanging data with third parties. Availability and response times SHOULD be agreed for data exchanges with third parties. It SHOULD be defined which exchanged data may be used for what purposes.
OPS.2.1.A11 Planning and Continuity of Information Security During Ongoing Outsourcing Operations (S)
An operational concept SHOULD be drawn up which also takes the security aspects of a given outsourcing project into account. The security concepts of the outsourcing partners SHOULD be regularly checked to ensure that they are up to date and consistent with each other. The status of the security safeguards agreed SHOULD be checked at regular intervals. There SHOULD be regular communication between the outsourcing partners. Proposals for changes and improvements SHOULD be discussed and agreed regularly. The outsourcing partners SHOULD perform regular joint drills and tests to maintain the established level of security. Information on security risks and how to handle them SHOULD be exchanged between the outsourcing partners at regular intervals. A process SHOULD be defined to secure the flow of information in case of security incidents that affect the respective contractual partners.
OPS.2.1.A12 Change Management [Process Owner] (S)
Outsourcing customers SHOULD be given sufficient notice of major changes. Outsourcing customers SHOULD regularly request documentation of all significant changes regarding planning, testing, approval, and documentation. Before any changes are made, fallback solutions SHOULD be developed in cooperation with the outsourcing service provider in question.
OPS.2.1.A13 Secure Migration in Outsourcing Projects (S)
A security management team consisting of qualified employees of the outsourcing customer and the outsourcing service provider SHOULD be established for the migration phase. For the migration phase, a preliminary security concept SHOULD be drawn up that also considers the test and introduction phase. It SHOULD be ensured that production data is not used as test data in an unprotected manner during the migration phase. All changes SHOULD be documented. Upon completion of the migration, the security concept SHOULD be updated. It SHOULD be ensured that all exceptions are reversed at the end of the migration phase. In the event of changes during the migration phase, the extent to which the contractual basis has to be adapted SHOULD be checked.
OPS.2.1.A14 Contingency Planning for Outsourcing [BCM Officer] (S)
A contingency planning concept for outsourcing SHOULD exist that covers the components of the outsourcing customer and the outsourcing service provider in question, as well as the associated interfaces and communication channels. The contingency planning concept for outsourcing SHOULD specify the responsibilities, contact persons, and processes between the outsourcing customer and the outsourcing service provider. The outsourcing customer SHOULD monitor whether the outsourcing service provider has implemented the business continuity safeguards defined. Outsourcing customers and service providers SHOULD conduct joint emergency drills for this purpose.
OPS.2.1.A15 Organised Termination of an Outsourcing Relationship [Procurement Department] (S)
Contracts with outsourcing service providers SHOULD specify all aspects regarding the termination of the service relationship concerned, including for both planned and unplanned termination. The business of an outsourcing customer SHOULD NOT be affected if its service relationship with its outsourcing service provider is terminated. All information and data SHOULD be returned to the outsourcing customer upon termination. The outsourcing service provider SHOULD securely delete all related data once this information and data has been returned.
OPS.2.1.A16 Security Vetting of Employees (H)
There SHOULD be contractual agreements with outsourcing service providers that state that the trustworthiness of the personnel deployed will be checked appropriately. To this end, the provider and customer SHOULD work together to define corresponding criteria.
OPS.2.1.A2 Timely Involvement of Employee Representatives [Central Administration] (S)
Employee Representatives SHOULD be informed of an outsourcing project in good time. Employee Representatives SHOULD be involved from the tender phase onwards. Depending on the outsourcing project in question, the statutory rights of co-determination SHOULD be taken into consideration.
OPS.2.1.A3 Selection of a Suitable Outsourcing Service Provider (S)
A requirements profile containing the security requirements for a given outsourcing project SHOULD be created for selecting an outsourcing service provider. Assessment criteria for the outsourcing service provider and its staff SHOULD also exist. These SHOULD be based on the requirements profile.
OPS.2.1.A4 Contractual Arrangements with the Outsourcing Service Provider (S)
All aspects of an outsourcing project SHOULD be agreed in writing with the outsourcing service provider in question. In addition, all roles and duties of cooperation for the creation, review, and modification of a security concept SHOULD be regulated with the outsourcing service provider (e.g. if personnel changes occur). The rights and obligations of the contractual parties SHOULD be agreed in writing. For the purpose of checking compliance with the requirements at hand on a regular basis, the outsourcing service provider SHOULD enable the outsourcing customer to conduct audits.
OPS.2.1.A5 Establishing an Outsourcing Strategy (S)
A strategy for outsourcing SHOULD be defined. This SHOULD take into account the economic, technical, organisational, and legal framework conditions, as well as the relevant aspects of information security. The business processes, tasks, or applications generally associated with outsourcing SHOULD be clarified. An outsourcing customer SHOULD retain sufficient skills, competencies, and resources to be able to determine and control the information security requirements for each outsourcing project on its own. An outsourcing strategy SHOULD describe the goals, opportunities, and risks of the corresponding outsourcing project.
OPS.2.1.A6 Drawing up a Security Concept for the Outsourcing Project [Process Owner] (S)
An outsourcing customer SHOULD draw up an information security concept based on the associated security requirements for each of its outsourcing projects. Every outsourcing service provider SHOULD also provide an individual security concept for the respective outsourcing project. The two security concepts SHOULD be coordinated. The outsourcing service provider's security concept and its implementation SHOULD be merged into an overall security concept. The outsourcing customer or independent third parties SHOULD regularly check the effectiveness of the security concept.
OPS.2.1.A7 Definition of Possible Communication Partners [Central Administration] (S)
The internal and external communication partners who may transmit and receive specific information about a given outsourcing project SHOULD be defined. There SHOULD be a process that can be used to check the functions of the communication partners on both sides. The communication partners permitted and their respective authorisations MUST always be documented and kept up to date.
OPS.2.1.A8 Provisions for Deploying the Personnel of the Outsourcing Service Provider [Human Resources Department] (S)
The employees of an outsourcing service provider SHOULD be obliged in writing to comply with relevant laws, regulations, and the outsourcing customer's rules. The employees of the outsourcing service provider SHOULD be briefed on their tasks and informed of existing information security regulations in a controlled manner. Deputising rules SHOULD be in place for the employees of the outsourcing service provider. There SHOULD be a controlled process that defines how the outsourcing service provider terminates its contractual relationships with its employees. Third-party personnel of the outsourcing service provider who are used on a short-term or one-off basis SHOULD be treated as visitors.
OPS.2.1.A9 Agreements on Connecting to Outsourcing Partner Networks (S)
Before the network of an outsourcing customer is connected to the network of its outsourcing service provider, all security-relevant aspects SHOULD be agreed in writing. The agreement SHOULD specifically define the areas and services to which the outsourcing service provider will be granted access in the network of the outsourcing customer. The affected areas SHOULD be suitably separated from each other. Compliance with the network connection agreements SHOULD be checked and documented. Contact persons SHOULD be appointed on both sides for organisational and technical questions about the network connection. The required security level SHOULD be ensured and verified with the outsourcing service provider before the network connection to the outsourcing service provider is activated. If there are security issues on one or both sides, it SHOULD be specified who must be informed and what escalation steps are to be initiated.
OPS.2.2 Cloud Usage
Target Object: Information domain/generic aspects / Order: R2
OPS.2.2.A1 Drawing Up a Strategy for Cloud Usage [Process Owner, Top Management, Data Protection Officer] (B)
A strategy MUST be established for cloud usage. It MUST define the objectives, opportunities, and risks that a given organisation associates with cloud use. In addition, the legal and organisational framework conditions and the technical requirements arising from the use of cloud services MUST be examined. The results of this investigation MUST be documented in a feasibility study. The services to be purchased from a cloud service provider in the future MUST be documented along with the chosen delivery model. In addition, it MUST be ensured that all fundamental aspects of technical and organisational security are sufficiently considered in the planning phase for cloud use. A rough individual security analysis SHOULD be carried out for the planned cloud service. This SHOULD be repeated if technical and organisational framework conditions change significantly. For larger cloud projects, a roadmap SHOULD also be developed to determine when and how a cloud service will be deployed.
OPS.2.2.A10 Secure Migration to a Cloud Service [Process Owner] (S)
An organisation's migration to a cloud service SHOULD take place on the basis of its established migration concept. Whether its security concept for cloud usage needs to be adapted to potential new requirements SHOULD be checked during the migration. All preventive safeguards for emergencies SHOULD also be complete and up to date. The migration to a cloud service SHOULD first be verified in a test run. Once the cloud service has gone live, it SHOULD be checked whether the cloud service provider meets the cloud customer's defined requirements.
OPS.2.2.A11 Drawing Up a Contingency Concept for a Cloud Service (S)
Cloud customers SHOULD create a contingency concept for the cloud services they use. It SHOULD contain all the necessary information about responsibilities and contact persons. In addition, detailed rules SHOULD be drawn up for backups. The specifications for redundant management tools and interface systems SHOULD also be recorded.
OPS.2.2.A12 Maintaining Information Security During Live Cloud Operations (S)
Cloud customers SHOULD regularly update all the documentation and policies they have created for the cloud services in use. Cloud customers SHOULD also periodically check whether their cloud service providers are rendering the contractually guaranteed services. Cloud service providers and their customers SHOULD also coordinate regularly if possible. Plans SHOULD be made and drills carried out on how to respond to system failures.
OPS.2.2.A13 Evidence of Sufficient Information Security for Cloud Usage (S)
Cloud customers SHOULD have their cloud service providers regularly prove that the agreed security requirements are being met. Such evidence SHOULD be based on an internationally recognised set of rules (e.g. IT-Grundschutz, ISO/IEC 27001, Compliance Control Catalogue (C5), Cloud Controls Matrix of the Cloud Security Alliance). Cloud customers SHOULD check whether the scope and protection needs cover the cloud services used. If a cloud service provider uses subcontractors to provide its cloud services, it SHOULD regularly demonstrate to its cloud customers that they are performing the necessary audits.
OPS.2.2.A14 Orderly Termination of a Cloud Service Relationship [Process Owner, Top Management] (S)
If a cloud customer terminates its service relationship with a cloud service provider, it SHOULD ensure that this will not interfere with its business operations or processes. Contracts with cloud service providers SHOULD regulate how the service relationship in question can be terminated in an orderly manner.
OPS.2.2.A15 Ensuring the Portability of Cloud Services [Process Owner] (H)
Cloud customers SHOULD define all the requirements necessary to change cloud service providers or bring the cloud service or data back into their own IT infrastructure. Cloud customers SHOULD also conduct regular portability tests. Contracts with cloud service providers SHOULD include specifications to ensure the necessary portability.
OPS.2.2.A16 Implementing In-House Backups [Process Owner] (H)
Cloud customers SHOULD check whether they should create their own data backups in addition to the contractually specified data backups of their cloud service providers. In addition, they SHOULD create detailed requirements for a backup service.
OPS.2.2.A17 Use of Encryption When Using the Cloud (H)
If data is encrypted by a cloud service provider, the encryption mechanisms and key lengths that may be used SHOULD be contractually agreed. If the customer’s own encryption mechanisms are used, suitable key management SHOULD be ensured. The encryption SHOULD take into account any special features of the selected cloud service model.
OPS.2.2.A18 Use of Federation Services [Process Owner] (H)
Customers SHOULD check whether Federation Services are being used in their cloud computing projects. It SHOULD be ensured that a Security Assertion Markup Language (SAML) ticket only transmits the necessary information to the cloud service provider in question. Authorisations SHOULD be checked regularly so that only authorised users are issued an SAML ticket.
OPS.2.2.A19 Security Vetting of Employees [Human Resources Department] (H)
It SHOULD be contractually agreed with external cloud service providers that appropriate checks will be carried out to ensure that the personnel used are qualified and trustworthy. To this end, providers and customers SHOULD work together to define corresponding criteria.
OPS.2.2.A2 Drawing Up a Security Policy for Cloud Usage [Process Owner] (B)
A security policy for cloud usage MUST be created based on an organisation's strategy for cloud usage. It MUST include specific security requirements for implementing cloud services within the organisation. It MUST also document specific security requirements for the cloud service provider in question and the defined level of protection for cloud services in terms of confidentiality, integrity, and availability. If cloud services from international providers are used, the special country-specific requirements and legal regulations at hand MUST be taken into account.
OPS.2.2.A3 Service Definition for Cloud Services by the Customer [Process Owner] (B)
Cloud customers MUST develop a service definition for each cloud service they intend to use. All the cloud services planned and used SHOULD also be documented.
OPS.2.2.A4 Definition of Areas of Responsibility and Interfaces [Process Owner] (B)
Based on their service definitions for cloud services, cloud customers MUST identify and document all the interfaces and responsibilities relevant to cloud usage. The differentiation between the responsibilities of a given customer and its cloud service provider MUST be clearly evident..
OPS.2.2.A5 Planning a Secure Migration to a Cloud Service [Process Owner] (S)
Before migrating to a cloud service, cloud customers SHOULD draw up a migration concept. To this end, organisational regulations and the distribution of tasks SHOULD first be defined. In addition, existing business processes that will be affected by the planned cloud usage SHOULD be identified and adjusted accordingly. It SHOULD be ensured that an organisation's own IT is sufficiently considered in the migration process. Those in charge SHOULD also determine whether the organisation's employees should receive additional training.
OPS.2.2.A6 Planning the Secure Integration of Cloud Services (S)
Before using a cloud service, organisations SHOULD carefully plan how it is to be integrated into their IT. For this purpose, they SHOULD check (at minimum) whether adaptations of interfaces, network connections, or the administration and data management models at hand are necessary. The results SHOULD be documented and updated at regular intervals.
OPS.2.2.A7 Drawing Up a Security Concept for Cloud Usage (S)
Cloud customers SHOULD develop a security concept for the use of cloud services based on the security requirements they have identified (see OPS.2.2.A2 Drawing Up a Security Policy for Cloud Usage).
OPS.2.2.A8 Careful Selection of a Cloud Service Provider [Top Management] (S)
Cloud customers SHOULD create a detailed requirements profile for their future cloud service provider based on their service definition of the cloud service they intend to use. A service specification and a requirements specification SHOULD be drawn up. Supplementary sources of information SHOULD also be used to assess cloud service providers. The service descriptions available from cloud service providers SHOULD also be carefully examined and reviewed.
OPS.2.2.A9 Contractual Arrangements with the Cloud Service Provider [Top Management] (S)
The contractual provisions between cloud customers and cloud service providers SHOULD be adapted in terms of their type, scope, and level of detail to the protection needs of the information to be used in the cloud. The locations in which cloud service providers render their services SHOULD be regulated. In addition, escalation levels and communication channels SHOULD be defined between a given organisation and its cloud service provider. The manner in which the organisation's data should be securely deleted SHOULD also be agreed. Termination provisions SHOULD also be established in writing. Cloud service providers SHOULD disclose all the subcontractors they require to provide their service.
OPS.3.1 Outsourcing for Service Providers
Target Object: Information domain/generic aspects / Order: R3
OPS.3.1.A1 Drawing Up a Rough Concept for the Outsourcing Service (B)
Outsourcing service providers MUST prepare rough concepts for the services they offer. These rough concepts MUST account for the framework conditions of the outsourcing in question, such as special requests. They MUST answer basic questions about the security level and the security requirements of outsourcing customers.
OPS.3.1.A10 Planning and Maintaining Information Security During Ongoing Outsourcing Operations (S)
The security concepts of outsourcing partners SHOULD be regularly checked to ensure that they are still up to date and consistent with each other. The status of the security safeguards agreed SHOULD be checked at regular intervals. Outsourcing partners SHOULD cooperate appropriately. They SHOULD also coordinate regularly on changes and improvements. In addition, outsourcing partners SHOULD perform regular joint drills and tests. Information on security risks and how to handle them SHOULD be exchanged between outsourcing partners at regular intervals. A process SHOULD be a defined to secure the flow of information in case of security incidents that affect the contractual partners in question.
OPS.3.1.A11 Site, System, and Data Access Control [Central Administration] (S)
Site, system, and data access authorisations SHOULD be regulated for the employees of both outsourcing service providers and outsourcing customers. It SHOULD also be specified which authorisations are to be granted to auditors and other inspectors. Rights SHOULD always only be granted when they are necessary to perform a task. There SHOULD be a controlled procedure for granting, managing, and withdrawing authorisations.
OPS.3.1.A12 Change Management [Organisation] (S)
There SHOULD be policies for making changes to IT components, software, and configuration data. When making changes, the relevant security aspects SHOULD also be considered. All changes MUST be planned, tested, approved, and documented. How and to what extent the changes are documented SHOULD be agreed with outsourcing customers. The documentation SHOULD be made available to outsourcing customers. Fallback solutions SHOULD be developed before changes are carried out. In the event of major security-relevant changes, the information security management department of the outsourcing organisation in question SHOULD already be involved in advance.
OPS.3.1.A13 Secure Migration in Outsourcing Projects (S)
For the migration phase of a given outsourcing project, a security management team consisting of qualified employees of the outsourcing customer and the outsourcing service provider SHOULD be established. A security concept SHOULD be drawn up for the migration phase. Upon completion of the migration, the security concept SHOULD be updated. It SHOULD be ensured that all exceptions are reversed at the end of the migration phase. If there are changes during the migration phase, it SHOULD be checked whether the contractual basis and existing documents need to be adjusted accordingly
OPS.3.1.A14 Contingency Planning for Outsourcing [BCM Officer] (S)
There SHOULD be a contingency planning concept for outsourcing that comprises the components of the outsourcing customer and the outsourcing service provider in question, as well as the associated interfaces. The contingency planning concept for outsourcing SHOULD specify the responsibilities, contact persons, and processes between the outsourcing customer and the outsourcing service provider. Regular joint emergency drills SHOULD be performed.
OPS.3.1.A15 Orderly Termination of an Outsourcing Relationship [Top Management] (S)
If a contractual relationship with an outsourcing customer is terminated, the business activities of the customer and the outsourcing provider SHOULD NOT be affected. The outsourcing contract with the outsourcing customer SHOULD specify all aspects regarding the termination of the service relationship in question, including for both a planned and an unplanned end of the contractual relationship. The outsourcing service provider SHOULD return all the information and data of the outsourcing customer. The outsourcing service provider SHOULD then securely delete all data belonging to the customer. All authorisations configured within the framework of the outsourcing project in question SHOULD be reviewed and deleted if required.
OPS.3.1.A16 Security Vetting of Employees [Human Resources Department] (H)
The trustworthiness of an outsourcing service provider's new employees and external personnel SHOULD be checked with the help of appropriate certificates. To this end, criteria SHOULD be contractually stipulated with outsourcing customers.
OPS.3.1.A2 Contractual Arrangements with Outsourcing Customers (S)
All the aspects of outsourcing projects SHOULD be agreed in writing with the respective outsourcing customers. All responsibilities and duties to collaborate on creating, reviewing, and changing these aspects (e.g. persons) SHOULD be specified within the framework of each agreement, or also directly in the security concepts between outsourcing service providers and their customers.