BSI-C5-2020.sql

-- MySQL dump 10.13  Distrib 5.7.29, for Linux (x86_64)
--
-- Host: localhost    Database: securityrat
-- ------------------------------------------------------
-- Server version	5.7.29

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `ALTERNATIVEINSTANCE`
--

DROP TABLE IF EXISTS `ALTERNATIVEINSTANCE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `ALTERNATIVEINSTANCE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `content` text,
  `alternativeset_id` bigint(20) DEFAULT NULL,
  `requirementskeleton_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_alternativeinstance_alternativeset_id` (`alternativeset_id`),
  KEY `fk_alternativeinstance_requirementskeleton_id` (`requirementskeleton_id`),
  CONSTRAINT `fk_alternativeinstance_alternativeset_id` FOREIGN KEY (`alternativeset_id`) REFERENCES `ALTERNATIVESET` (`id`),
  CONSTRAINT `fk_alternativeinstance_requirementskeleton_id` FOREIGN KEY (`requirementskeleton_id`) REFERENCES `REQUIREMENTSKELETON` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `ALTERNATIVEINSTANCE`
--

LOCK TABLES `ALTERNATIVEINSTANCE` WRITE;
/*!40000 ALTER TABLE `ALTERNATIVEINSTANCE` DISABLE KEYS */;
/*!40000 ALTER TABLE `ALTERNATIVEINSTANCE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `ALTERNATIVESET`
--

DROP TABLE IF EXISTS `ALTERNATIVESET`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `ALTERNATIVESET` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `optcolumn_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_alternativeset_optcolumn_id` (`optcolumn_id`),
  CONSTRAINT `fk_alternativeset_optcolumn_id` FOREIGN KEY (`optcolumn_id`) REFERENCES `OPTCOLUMN` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `ALTERNATIVESET`
--

LOCK TABLES `ALTERNATIVESET` WRITE;
/*!40000 ALTER TABLE `ALTERNATIVESET` DISABLE KEYS */;
/*!40000 ALTER TABLE `ALTERNATIVESET` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `COLLECTIONCATEGORY`
--

DROP TABLE IF EXISTS `COLLECTIONCATEGORY`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `COLLECTIONCATEGORY` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `COLLECTIONCATEGORY`
--

LOCK TABLES `COLLECTIONCATEGORY` WRITE;
/*!40000 ALTER TABLE `COLLECTIONCATEGORY` DISABLE KEYS */;
INSERT INTO `COLLECTIONCATEGORY` VALUES (1,'Cloud Computing Compliance Controls Catalogue (C5)','The Cloud Computing Compliance Controls Catalogue (abbreviated \"C5\") is intended primarily for professional cloud service providers, their auditors and customers of the cloud service providers. It is defined which requirements (also referred to as controls in this context) the cloud providers have to comply with or which minimum requirements the cloud providers should be obliged to meet.',0,_binary ''),(2,'Cloud Computing Compliance Controls Catalogue (C5)','The Cloud Computing Compliance Controls Catalogue (abbreviated \"C5\") is intended primarily for professional cloud service providers, their auditors and customers of the cloud service providers. It is defined which requirements (also referred to as controls in this context) the cloud providers have to comply with or which minimum requirements the cloud providers should be obliged to meet.',0,_binary '');
/*!40000 ALTER TABLE `COLLECTIONCATEGORY` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `COLLECTIONINSTANCE`
--

DROP TABLE IF EXISTS `COLLECTIONINSTANCE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `COLLECTIONINSTANCE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `collectioncategory_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_collectioninstance_collectioncategory_id` (`collectioncategory_id`),
  CONSTRAINT `fk_collectioninstance_collectioncategory_id` FOREIGN KEY (`collectioncategory_id`) REFERENCES `COLLECTIONCATEGORY` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=19 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `COLLECTIONINSTANCE`
--

LOCK TABLES `COLLECTIONINSTANCE` WRITE;
/*!40000 ALTER TABLE `COLLECTIONINSTANCE` DISABLE KEYS */;
INSERT INTO `COLLECTIONINSTANCE` VALUES (1,'Organisation of Information Security (OIS)','Organisation of Information Security (OIS)',10,_binary '',2),(2,'Security Policies and Instructions (SP)','Security Policies and Instructions (SP)',20,_binary '',2),(3,'Personnel (HR)','Personnel (HR)',30,_binary '',2),(4,'Asset Management (AM)','Asset Management (AM)',40,_binary '',2),(5,'Physical Security (PS)','Physical Security (PS)',50,_binary '',2),(6,'Operations (OPS)','Operations (OPS)',60,_binary '',2),(7,'Identity and Access Management (IDM)','Identity and Access Management (IDM)',70,_binary '',2),(8,'Cryptography and Key Management (CRY)','Cryptography and Key Management (CRY)',80,_binary '',2),(9,'Communication Security (COS)','Communication Security (COS)',90,_binary '',2),(10,'Portability and Interoperability (PI)','Portability and Interoperability (PI)',100,_binary '',2),(11,'Procurement, Development and Modification of Information Systems (DEV)','Procurement, Development and Modification of Information Systems (DEV)',110,_binary '',2),(12,'Control and Monitoring of Service Providers and Suppliers (SSO)','Control and Monitoring of Service Providers and Suppliers (SSO)',120,_binary '',2),(13,'Security Incident Management (SIM)','Security Incident Management (SIM)',130,_binary '',2),(14,'Business Continuity Management (BCM)','Business Continuity Management (BCM)',140,_binary '',2),(15,'Compliance (COM)','Compliance (COM)',150,_binary '',2),(16,'Dealing with investigation requests from government agencies (INQ)','Dealing with investigation requests from government agencies (INQ)',160,_binary '',2),(17,'Product Safety and Security (PSS)','Product Safety and Security (PSS)',170,_binary '',2),(18,'General Conditions (BC)','General Conditions (BC)',180,_binary '',2);
/*!40000 ALTER TABLE `COLLECTIONINSTANCE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `OPTCOLUMN`
--

DROP TABLE IF EXISTS `OPTCOLUMN`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `OPTCOLUMN` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `optcolumntype_id` bigint(20) DEFAULT NULL,
  `isVisibleByDefault` bit(1) NOT NULL DEFAULT b'1',
  PRIMARY KEY (`id`),
  KEY `fk_optcolumn_optcolumntype_id` (`optcolumntype_id`),
  CONSTRAINT `fk_optcolumn_optcolumntype_id` FOREIGN KEY (`optcolumntype_id`) REFERENCES `OPTCOLUMNTYPE` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `OPTCOLUMN`
--

LOCK TABLES `OPTCOLUMN` WRITE;
/*!40000 ALTER TABLE `OPTCOLUMN` DISABLE KEYS */;
INSERT INTO `OPTCOLUMN` VALUES (2,'Basic Criteria','C5 Requirement description',100,_binary '',1,_binary ''),(3,'Additional Criteria','C5 Requirement description',110,_binary '',1,_binary ''),(4,'Supplementary Information - About the Criteria','Supplementary Information - About the Criteria',120,_binary '',1,_binary ''),(5,'Supplementary Information - Complementary Customer Criteria','Supplementary Information - Complementary Customer Criteria',130,_binary '',1,_binary ''),(6,'Supplementary Information - Notes on Continuous Auditing - Feasibility','Supplementary Information - Notes on Continuous Auditing - Feasibility',140,_binary '',1,_binary ''),(7,'Supplementary Information - Notes on Continuous Auditing','Supplementary Information - Notes on Continuous Auditing',150,_binary '',1,_binary '');
/*!40000 ALTER TABLE `OPTCOLUMN` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `OPTCOLUMNCONTENT`
--

DROP TABLE IF EXISTS `OPTCOLUMNCONTENT`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `OPTCOLUMNCONTENT` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `content` text,
  `optcolumn_id` bigint(20) DEFAULT NULL,
  `requirementskeleton_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_optcolumncontent_optcolumn_id` (`optcolumn_id`),
  KEY `fk_optcolumncontent_requirementskeleton_id` (`requirementskeleton_id`),
  CONSTRAINT `fk_optcolumncontent_optcolumn_id` FOREIGN KEY (`optcolumn_id`) REFERENCES `OPTCOLUMN` (`id`),
  CONSTRAINT `fk_optcolumncontent_requirementskeleton_id` FOREIGN KEY (`requirementskeleton_id`) REFERENCES `REQUIREMENTSKELETON` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=763 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `OPTCOLUMNCONTENT`
--

LOCK TABLES `OPTCOLUMNCONTENT` WRITE;
/*!40000 ALTER TABLE `OPTCOLUMNCONTENT` DISABLE KEYS */;
INSERT INTO `OPTCOLUMNCONTENT` VALUES (1,'The Cloud Service Provider operates an information security management system (ISMS) in accordance with ISO/IEC 27001. The scope of the ISMS covers the Cloud Service Provider\'s organisational units, locations and procedures for providing the cloud service.\nThe measures for setting up, implementing, maintaining and continuously improving the ISMS are documented. \nThe documentation includes:\n\n- Scope of the ISMS (Section 4.3 of ISO/IEC 27001);\n\n- Declaration of applicability (Section 6.1.3), and\n\n- Results of the last management review (Section 9.3).',2,1),(2,'The Information Security Management System (ISMS) has a valid certification according to ISO/IEC 27001 or ISO 27001 based on IT-Grundschutz.',3,1),(3,'The basic criterion can also be fulfilled without valid certification of the ISMS according to ISO/IEC 27001 or ISO 27001 based on IT-Grundschutz, if the submitted documentation meets the requirements of ISO/IEC 27001.',4,1),(4,'-',5,1),(5,'partially',6,1),(6,'A continuous audit of the ISO 27001 certificate is partially feasible because the existence of a certificate can be continuously verified through the creation date of the certificate and passing an authenticity check. However, the certificate is usually issued for three years and there will be no dynamic changes as a rule.',7,1),(7,'The top management of the Cloud Service Provider has adopted an information security policy and communicated it to internal and external employees as well as cloud customers.\nThe policy describes:\n\n- the importance of information security, based on the requirements of cloud customers in relation to information security;\n\n- the security objectives and the desired security level, based on the business goals and tasks of the Cloud Service Provider;\n\n- the most important aspects of the security strategy to achieve the security objectives set; and\n\n- the organisational structure for information security in the ISMS application area.',2,2),(8,'-',3,2),(9,'The top management is a natural person or group of persons who make the final decision for the institution and is responsible for that decision.',4,2),(10,'-',5,2),(11,'partially',6,2),(12,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,2),(13,'Interfaces and dependencies between cloud service delivery activities performed by the Cloud Service Provider and activities performed by third parties are documented and communicated. This includes dealing with the following events:\n\n- Vulnerabilities;\n\n- Security incidents; and\n\n- Malfunctions.\n\nThe type and scope of the documentation is geared towards the information requirements of the subject matter experts of the affected organisations in order to carry out the activities appropriately (e.g. definition of roles and responsibilities in guidelines, description of cooperation obligations in service descriptions and contracts).\n\nThe communication of changes to the interfaces and dependencies takes place in a timely manner so that the affected organisations and third parties can react appropriately with organisational and technical measures before the changes take effect.',2,3),(14,'-',3,3),(15,'The Cloud Service Provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and instructions. For example, Cloud customers\' obligations to cooperate should be described in service descriptions and contracts.\n\nThird parties in the sense of this basic criterion are, e.g. cloud customers and sub-service providers.',4,3),(16,'Cloud customers ensure through suitable controls, that the guidelines and requirements for compliance with the contractual agreements with the Cloud Service Provider (i.e., responsibilities, cooperation obligations and interfaces for reporting security incidents) are adequately defined, documented and set up.',5,3),(17,'no',6,3),(18,'An automated continuous audit for critical dependencies and interfaces is currently only possible at a high cost to the Cloud Service Provider.',7,3),(19,'Conflicting tasks and responsibilities are separated based on an OIS-06 risk assessment to reduce the risk of unauthorised or unintended changes or misuse of cloud customer data processed, stored or transmitted in the cloud service.\n\nThe risk assessment covers the following areas, insofar as these are applicable to the provision of the Cloud Service and are in the area of responsibility of the Cloud Service Provider:\n\n- Administration of rights profiles, approval and assignment of access and access authorisations (cf. IDM-01);\n\n- Development, testing and release of changes (cf. DEV-01); and\n\n- Operation of the system components.\n\nIf separation cannot be established for organisational or technical reasons, measures are in place to monitor the activities in order to detect unauthorised or unintended changes as well as misuse and to take appropriate actions.',2,4),(20,'-',3,4),(21,'Identified events that may constitute unauthorised or unintentional changes to or misuse of cloud customer data may, for example, be treated as a security incident, cf. SIM-01.',4,4),(22,'-',5,4),(23,'yes',6,4),(24,'A continuous audit is possible, especially in the case of changes to role profiles and responsibilities. This would require an initial check of the defined roles and responsibilities by the Cloud Service Provider. The roles that are added or changed on a monthly basis could then be automated and continuously checked.',7,4),(25,'The Cloud Service Provider leverages relevant authorities and interest groups in order to stay informed about current threats and vulnerabilities. The information flows into the procedures for handling risks (cf. OIS-06) and vulnerabilities (cf. OPS-19).',2,5),(26,'If the cloud service is used by public sector organisations in Germany, the Cloud Service Provider leverages contacts with the National IT Situation Centre and the CERT Association of the BSI.',3,5),(27,'Relevant contacts are for example:\n\n- Federal Office for Information Security (BSI);\n\n- OWASP Foundation; and\n\n- CERT networks DFN-CERT, TF-CSIRT etc.\n\nPublic sector organisations in Germany are e.g. authorities and ministries.',4,5),(28,'-',5,5),(29,'yes',6,5),(30,'A continuous audit of the Cloud Service Provider\'s contacts with relevant authorities and stakeholders can be achieved by continuously storing relevant information on a monthly basis, such as a list of contacted entities and evidence of receipt of a response. A continuous flow of information demonstrates a constant connection to relevant authorities and interest groups. Furthermore, the distribution of the information and, if necessary, the documentation of the handling of identified risks and weak points could be continuously audited for the coverage of this criterion.',7,5),(31,'Policies and instructions for risk management procedures are documented, communicated and provided in accordance with SP-01 for the following aspects:\n\n- Identification of risks associated with the loss of confidentiality, integrity, availability and authenticity of information within the scope of the ISMS and assigning risk owners;\n\n- Analysis of the probability and impact of occurrence and determination of the level of risk;\n\n- Evaluation of the risk analysis based on defined criteria for risk acceptance and prioritisation of handling;\n\n- Handling of risks through measures, including approval of authorisation and acceptance of residual risks by risk owners; and\n\n- Documentation of the activities implemented to enable consistent, valid and comparable results.',2,6),(32,'-',3,6),(33,'The risk level can be determined by qualitative, semi-quantitative and quantitative methods (cf. ISO 31010) based on the likelihood and impacts.',4,6),(34,'-',5,6),(35,'partially',6,6),(36,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,6),(37,'The Cloud Service Provider executes the process for handling risks as needed or at least once a year. The following aspects are taken into account when identifying risks, insofar as they are applicable to the cloud service provided and are within the area of responsibility of the Cloud Service Provider:\n\n- Processing, storage or transmission of data of cloud customers with different protection needs;\n\n- Occurrence of weak points and malfunctions in technical protective measures for separating shared resources;\n\n- Attacks via access points, including interfaces accessible from public networks;\n\n- Conflicting tasks and areas of responsibility that cannot be separated for organisational or technical reasons; and\n\n- Dependencies on subservice organisations.\n\nThe analysis, evaluation and treatment of risks, including the approval of actions and acceptance of residual risks, is reviewed for adequacy at least annually by the risk owners.',2,7),(38,'-',3,7),(39,'This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to subservice organisations, the responsibility for these risks remains with the Cloud Service Provider. Requirements for measures to manage these risks can be found in the criteria area “Control and Monitoring of Service Providers and Suppliers (SSO)”.\n\nShared resources are e.g. networks, RAM or storage.',4,7),(40,'-',5,7),(41,'partially',6,7),(42,'The procedure for handling risks must be tested at least once a year and is therefore part of the standard audit cycle. However, the continuous audit of handling risk is only partially feasible as the only attributes that can be tested are the last review date and the status of review or approval, as far as this information is stored in a system. The content of the risks can hardly be tested automatically.',7,7),(43,'Policies and instructions (incl. concepts and guidelines) are derived from the information security policy and are documented according to a uniform structure. They are communicated and made available to all internal and external employees of the Cloud Service Provider in an appropriate manner.\n\nThe policies and instructions are version controlled and approved by the top management of the Cloud Service Provider or an authorised body.\n\nThe policies and instructions describe at least the following aspects:\n\n- Objectives;\n\n- Scope;\n\n- Roles and responsibilities, including staff qualification requirements and the establishment of substitution rules;\n\n- Roles and dependencies on other organisations (especially cloud customers and subservice organisations);\n\n- Steps for the execution of the security strategy; and\n\n- Applicable legal and regulatory requirements.',2,8),(44,'-',3,8),(45,'The appropriateness of the demand-oriented communication and provision must be assessed against the size and complexity of the Cloud Service Provider\'s organisation and the type of cloud service offered. Possible criteria are:\n\n- Integration of guidelines and instructions in the onboarding of new employees\n\n- Training and information campaigns when adopting new or revising existing policies and instructions\n\n- Form of provision\n\nPolicies and instructions are required for the following basic criteria in which the content is specified in more detail:\n\n- Risk management policy (OIS-06)\n\n- Acceptable use and handling of assets policy (AM-02)\n\n- Security requirements for premises and buildings (PS-01)\n\n- Physical site access control (PS-04)\n\n- Concept for protection against malware (OPS-04)\n\n- Concept for data protection and recovery (OPS-06)\n\n- Concept for logging and monitoring (OPS-10)\n\n- Concept for meta data handling (OPS-11)\n\n- Concept for handling of vulnerabilities, malfunctions and errors (OPS-18)\n\n- Policy for system and data access authorisations (IDM-01)\n\n- Policy for the use of encryption procedures and key management (CRY-01)\n\n- Policies for data transmission (COS-08)\n\n- Policies for the development/procurement of information systems (DEV-01)\n\n- Policies for changes to information systems (DEV-03)\n\n- Policies and instructions for controlling and monitoring third parties (SSO-01)\n\n- Policy for security incident management (SIM-01)\n\n- Business impact analysis policies and procedures (BCM-02)\n\n- Policy for planning and conducting audits (COM-02)',4,8),(46,'-',5,8),(47,'partially',6,8),(48,'Regarding the uniformity and content of the policies and instructions, there is a need for manual testing, so continuous testing cannot be fully achieved.\n\nThe communication/provision of policies and instructions can be queried via various registers. Registries for all approved policies and instructions can serve as a basis for reviewing the policies/rejections provided in the usual channels and may be combined with a conditional access check. These requirements must first be met by the Cloud Service Provider.\n\nVersioning after approval by authorised personnel can be automatically audited and is therefore suitable for continuous audit.',7,8),(49,'Information security policies and instructions are reviewed at least annually for adequacy by the Cloud Service Provider\'s subject matter experts.\n\nThe review shall consider at least the following aspects:\n\n- Organisational and technical changes in the procedures for providing the cloud service; and\n\n- Legal and regulatory changes in the Cloud Service Provider\'s environment.\n\nRevised policies and instructions are approved before they become effective.',2,9),(50,'-',3,9),(51,'-',4,9),(52,'-',5,9),(53,'partially',6,9),(54,'A continuous, automated audit of the content changes to policies and instructions is only partially practicable at the current state-of-the-art.\n\nA continuous audit of the reviewers\' authorisation and expertise does not appear to be effective either, as this cannot be linked to specified parameters of an automated evaluation. A continuous examination of this criterion could therefore only consist of returning the date of the last examination.',7,9),(55,'Exceptions to the policies and instructions for information security as well as respective controls go through the OIS-06 risk management process, including approval of these exceptions and acceptance of the associated risks by the risk owners. The approvals of exceptions are documented, limited in time and are reviewed for appropriateness at least annually by the risk owners.',2,10),(56,'-',3,10),(57,'About the Criterion\nExceptions in the sense of the basic criterion can have organisational or technical causes, such as\n\n- An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud customer; and\n\n- A system component lacks technical properties to configure it according to the applicable requirements.\n\nCloud customers can use appropriate controls to ensure that they obtain information from the Cloud Service Provider about deviations from information security policies and instructions in order to assess and appropriately manage the associated risks to their own information security.',4,10),(58,'-',5,10),(59,'partially',6,10),(60,'Exceptions to policies and instructions are to be reviewed annually. However, the continuous audit of these exceptions is only partially feasible as the only attributes that can be tested are the last change date and the status or review or approval, as far as this information is stored in a system. The content of an exception can hardly be tested automatically.',7,10),(61,'The competency and integrity of all internal and external employees of the Cloud Service Provider with access to cloud customer data or system components under the Cloud Service Provider\'s responsibility who are responsible to provide the cloud service in the production environment shall be verified prior to commencement of employment in accordance with local legislation and regulation by the Cloud Service Provider.\n\nTo the extent permitted by law, the review will cover the following areas:\n\n- Verification of the person through identity card;\n\n- Verification of the CV;\n\n- Verification of academic titles and degrees;\n\n- Request of a police clearance certificate for applicants;\n\n- Certificate of good conduct or national equivalent; and\n\n- Evaluation of the risk to be blackmailed.',2,11),(62,'-',3,11),(63,'External employees in the sense of the criteria are those who perform activities in accordance with the processes and procedures of the Cloud Service Provider. Employees of sub-service providers who perform activities according to the sub-service own processes and procedures are not covered by this criterion.\n\nThe verification of qualification and trustworthiness can be supported by a specialised service provider. Depending on national legislation, national equivalents of the German certificate of good conduct may also be permitted. The assessment of the extent to which a potential employee can be blackmailed can be carried out, for example, by checking his creditworthiness.',4,11),(64,'-',5,11),(65,'partially',6,11),(66,'A continuous audit is only partially achievable due to the complications between local deviations in laws and regulations.\n\nIt would be conceivable to continuously query the process steps stored in the system for each new hire in relation to the specified areas based on a list of employees maintained in the HR system in which new hires are registered.\n\nTo do this, the Cloud Service Provider would have to go through and document these steps applying a system-based approach. The auditor could then use an agent or a connected monitoring system to detect any deviations from the standard process.',7,11),(67,'The Cloud Service Provider\'s internal and external employees are required by the employment terms and conditions to comply with applicable policies and instructions relating to information security.\n\nThe information security policy, and the policies and instructions based on it, are to be acknowledged by the internal and external personnel in a documented form before access is granted to any cloud customer data or system components under the responsibility of the Cloud Service Provider used to provide the cloud service in the production environment.',2,12),(68,'-',3,12),(69,'The Cloud Service Provider ensures that the policies and instructions reflect applicable legal and regulatory requirements in accordance with SP-01.',4,12),(70,'-',5,12),(71,'yes',6,12),(72,'Due to the obligation of employees to comply with certain requirements, a continuous audit is not practical as compliance with the requirements can be verified as part of a standard audit cycle\n\nA continuous audit of the granting of access only after acknowledgement of the instructions is achievable as far as the Cloud Service Provider designs the approval system to document the appropriate data (e.g., date of acknowledgement, which data the employee had access to and when). A clear definition and differentiation of customer data as well as data in the productive environment is essential.\n\nWith the help of this data, the auditor can perform a comparison and detect deviations accordingly. The data could be monitored using an agent on a monitoring system.',7,12),(73,'The Cloud Service Provider operates a target group-oriented security awareness and training program, which is completed by all internal and external employees of the Cloud Service Provider on a regular basis. The program is regularly updated based on changes to policies and instructions and the current threat situation and includes the following aspects:\n\n- Handling system components used to provide the cloud service in the production environment in accordance with applicable policies and procedures;\n\n- Handling cloud customer data in accordance with applicable policies and instructions and applicable legal and regulatory requirements;\n\n- Information about the current threat situation; and\n\n- Correct behaviour in the event of security incidents.',2,13),(74,'The learning outcomes achieved through the awareness and training programme are measured and evaluated in a target group-oriented manner. The measurements cover quantitative and qualitative aspects. The results are used to improve the awareness and training programme.',3,13),(75,'-',4,13),(76,'-',5,13),(77,'yes',6,13),(78,'The concept behind the security awareness and training program does not require continuous assessment and is sufficiently covered by the recurring audit.\n\nHowever, the completion of the training can be traced via training portals. For a continuous audit that each employee has completed and, if necessary, repeated the relevant training courses for his role description, a clear system-based definition of the necessary training courses for each role description must be carried out at the Cloud Service Provider. The expected dates which the respective training course is to be completed must also be recorded. The documentation that the training has been completed by the employee and, if necessary, successfully completed with an examination, should take place in the same portal.\n\nThe auditor then has the option of examining the results of the training courses for employees of the Cloud Service Provider for deviations by automatically and continuously comparing the expected training dates with the actual date on which the employees completed the training.',7,13),(79,'In the event of violations of policies and instructions or applicable legal and regulatory requirements, actions are taken in accordance with a defined policy that includes the following aspects:\n\n- Verifying whether a violation has occurred; and\n\n- Consideration of the nature and severity of the violation and its impact.\n\nThe internal and external employees of the Cloud Service Provider are informed about possible disciplinary measures.\n\nThe use of disciplinary measures is appropriately documented.',2,14),(80,'-',3,14),(81,'The Cloud Service Provider ensures that the policies and instructions reflect applicable legal and regulatory requirements in accordance with SP-01.',4,14),(82,'-',5,14),(83,'no',6,14),(84,'Continuous audit not practical, as the associated processes and steps can be tested once within a  recurring audit. \n\nA system-based definition of the violations as well as the corresponding regulations does not appear practical, since in this context individual case decisions are often necessary which cannot be covered by predefined algorithms.',7,14),(85,'Internal and external employees have been informed about which responsibilities, arising from the guidelines and instructions relating to information security, will remain in place when their employment is terminated or changed and for how long.',2,15),(86,'-',3,15),(87,'The Cloud Service Provider ensures that the policies and instructions reflect applicable legal and regulatory requirements in accordance with SP-01.',4,15),(88,'-',5,15),(89,'yes',6,15),(90,'As part of a comprehensive, system-based documentation of HR data, it is conceivable that the employee will receive confirmation that he or she has been informed about the required topics. This should be requested again at the end of the employment relationship.\nIf such documentation was available in standardised and digital form, the auditor would be able to check each termination for this confirmation and identify any deviations. This makes continuous verification possible.',7,15),(91,'The non-disclosure or confidentiality agreements to be agreed with internal employees, external service providers and suppliers of the Cloud Service Provider are based on the requirements identified by the Cloud Service Provider for the protection of confidential information and operational details. \n\nThe agreements are to be accepted by external service providers and suppliers when the contract is agreed. The agreements must be accepted by internal employees of the Cloud Service Provider before authorisation to access data of cloud customers is granted.\n\nThe requirements must be documented and reviewed at regular intervals (at least annually). If the review shows that the requirements need to be adapted, the non-disclosure or confidentiality agreements are updated.\n\nThe Cloud Service Provider must inform the internal employees, external service providers and suppliers and obtain confirmation of the updated confidentiality or non-disclosure agreement.',2,16),(92,'If the review results in adjustments to the confidentiality or non-disclosure agreements, the Cloud Service Provider\'s internal and external employees must be notified, and new confirmations must be obtained.',3,16),(93,'In a confidentiality agreement it should be described:\n\n- Which information must be kept confidential;\n\n- The period for which this confidentiality agreement applies;\n\n- What actions must be taken upon termination of this agreement, e.g. destruction or return of data medium;\n\n- How the ownership of information is regulated;\n\n- What rules apply to the use and disclosure of confidential information to other partners, if necessary; and\n\n- The consequences of a breach of the agreement.\n\nConfidentiality or non-disclosure agreements can be signed by means of an electronic signature, insofar as this is legally binding.',4,16),(94,'-',5,16),(95,'yes',6,16),(96,'The signing of confidentiality agreements with internal employees, external service providers and suppliers can be standardised and stored digitally.\n\nAn automated continuous evaluation can then be carried out to check whether all parties have signed such a confidentiality agreement and whether the agreement is up to date.',7,16),(97,'The Cloud Service Provider has established procedures for inventorying assets.\n\nThe inventory is performed automatically and/or by the people or teams responsible for the assets to ensure complete, accurate, valid and consistent inventory throughout the asset lifecycle.\n\nAssets are recorded with the information needed to apply the Risk Management Procedure (Cf. OIS-07), including the measures taken to manage these risks throughout the asset lifecycle. Changes to this information are logged.',2,17),(98,'Logging and monitoring applications take into account the information collected on the assets in order to identify the impact on cloud services and functions in case of events that could lead to a breach of protection objectives, and to support information provided to affected cloud customers in accordance with contractual agreements.',3,17),(99,'Assets within the meaning of this criteria area are the objects required for the information security of the cloud service during the creation, processing, storage, transmission, deletion or destruction of information in the Cloud Service Provider\'s area of responsibility, e.g. firewalls, load balancers, web servers, application servers and database servers.\n\nThese objects consist of hardware and software objects:\nHardware objects are\n\n- Physical and virtual infrastructure resources (e.g. servers, storage systems, network components); and\n\n- As well as end devices if the Cloud Service Provider has determined in a risk assessment that these could endanger the information security of the cloud service in the event of loss or unauthorised access (e.g. mobile devices used as security tokens for authentication).\n\nSoftware objects are e.g. hypervisors, containers, operating systems, databases, microservices and programming interfaces (APIs).\n\nThe lifecycle of an asset includes:\n\n- Acquisition;\n\n- Commissioning;\n\n- Maintenance;\n\n- Decommissioning; and\n\n- Disposal.',4,17),(100,'-',5,17),(101,'yes',6,17),(102,'The Cloud Service Provider must ensure that assets are automatically captured (in a database). The automatic capture of physical assets must also be ensured. However, it would be conceivable to automatically capture these assets when logging on to a network for the first time. The creation of virtual assets can be directly linked to the entry into the database.\n\nIf all assets are recorded automatically, changes to the database can be documented (logs) and these logs can then be continuously evaluated. It is important to ensure that the information contained in the inventory and logs is complete.\n\nIf automated processes are available, the auditor can create an evaluation of the changes in the inventory based on the logs.\n\nIn order to check the completeness, the first step would be to query all current assets at the Cloud Service Provider. This asset list could then be compared with the entries in the asset management database.',7,17),(103,'Policies and instructions for acceptable use and safe handling of assets are documented, communicated and provided in accordance with SP-01 and address the following aspects of the asset lifecycle as applicable to the asset:\n\n- Approval procedures for acquisition, commissioning, maintenance, decommissioning, and disposal by authorised personnel or system components;\n\n- Inventory;\n\n- Classification and labelling based on the need for protection of the information and measures for the level of protection identified;\n\n- Secure configuration of mechanisms for error handling, logging, encryption, authentication and authorisation;\n\n- Requirements for versions of software and images as well as application of patches;\n\n- Handling of software for which support and security patches are not available anymore;\n\n- Restriction of software installations or use of services;\n\n- Protection against malware;\n\n- Remote deactivation, deletion or blocking;\n\n- Physical delivery and transport;\n\n- dealing with incidents and vulnerabilities; and\n\n- Complete and irrevocable deletion of the data upon decommissioning.',2,18),(104,'-',3,18),(105,'-',4,18),(106,'-',5,18),(107,'partially',6,18),(108,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,18),(109,'The Cloud Service Provider has an approval process for the use of hardware to be commissioned, which is used to provide the cloud service in the production environment, in which the risks arising from the commissioning are identified, analysed and mitigated. Approval is granted after verification of the secure configuration of the mechanisms for error handling, logging, encryption, authentication and authorisation according to the intended use and based on the applicable policies.',2,19),(110,'-',3,19),(111,'The basic criterion applies only to physical hardware objects, such as servers, storage systems, and network components.\n\nVirtual hardware and software objects are considered in the criteria areas (OPS) and (DEV).\n\nThe approval process typically considers both the basic approval to use the hardware and the final approval of the configured assets.',4,19),(112,'-',5,19),(113,'yes',6,19),(114,'The approval of the commissioning of hardware by authorised personnel or system components must be digitally documented to allow continuous testing. A ticketing system, for example, is suitable for this purpose.\n\nBoth the instance and the verification of the configuration must be stored in the respective ticket.\n\nThis makes it possible for the auditor to check the tickets in an automated procedure. This requires an automated comparison of the authorised instance against a database containing all potential approvers. In addition, the verification of the configuration in the ticket must be audited automatically.\n\nThe compliant use of the assets can then be ensured via an agent system which checks active assets. The status of this system can then be queried by the auditor for a continuous audit.',7,19),(115,'The decommissioning of hardware used to operate system components supporting the cloud service production environment under the responsibility of the Cloud Service Provider requires approval based on the applicable policies.\n\nThe decommissioning includes the complete and permanent deletion of the data or proper destruction of the media.',2,20),(116,'-',3,20),(117,'The deletion of data or physical destruction of data mediums can take place, for example, according to DIN 66399 or BSI basic protection module CON.6.',4,20),(118,'-',5,20),(119,'yes',6,20),(120,'The approval of the decommissioning of hardware by authorised personnel or system components must be digitally documented to allow continuous testing. A ticketing system, for example, is suitable for this purpose.\n\nBoth the instance and the verification of the complete deletion of the data must be stored in the respective ticket.\n\nThis enables the auditor to check the tickets in an automated procedure. This requires an automated comparison of the authorised instance against a database containing all potential approvers. In addition, the deletion of the data documented in the ticket must be audited automatically.\n\nThe compliant use of the assets can be ensured via an agent system which checks active assets. The status of this system can then be queried by the auditor for a continuous audit.',7,20),(121,'The Cloud Service Provider\'s internal and external employees are provably committed to the policies and instructions for acceptable use and safe handling of assets before they can be used if the Cloud Service Provider has determined in a risk assessment that loss or unauthorised access could compromise the information security of the Cloud Service.\n\nAny assets handed over are provably returned upon termination of employment.',2,21),(122,'Physical assets of internal and external employees are managed centrally.\n\nCentral management enables software, data, and policy distribution, as well as remote deactivation, deletion, or locking.',3,21),(123,'The basic criterion essentially concerns mobile devices (e.g. notebooks, tablets, smartphones, etc.), where confidential information is stored on them which can be used in the event of unauthorised access to obtain privileged access to the cloud service (e.g. if these are used as security tokens for authentication).',4,21),(124,'-',5,21),(125,'yes',6,21),(126,'The obligation of the employees to follow the policies and instructions can be made in digital form. This can be used to create a monitoring system that documents the non-obligation to employee guidelines in the form of logs.\n\nIn this case, the auditor can check the exceptions in the form of logs and request evidence of what additional steps the Cloud Service Provider has taken in these cases to minimise the risk.\n\nThe compliant use of the assets can then be ensured via an agent system which checks active assets. The status of this system can then be queried by the auditor for a continuous audit.',7,21),(127,'Assets are classified and, if possible, labelled. Classification and labelling of an asset reflects the protection needs of the information it processes, stores, or transmits.\n\nThe need for protection is determined by the individuals or groups responsible for the assets of the Cloud Service Provider according to a uniform schema. The schema provides levels of protection for the confidentiality, integrity, availability, and authenticity protection objectives.',2,22),(128,'Logging and monitoring applications take the asset protection needs into account in order to inform the responsible stakeholder of events that could lead to a violation of the protection goals, so that the necessary measures are taken with an appropriate priority. Actions for events on assets with a higher level of protection take precedence over events on assets with a lower need for protection.',3,22),(129,'If the Cloud Service Provider does not make a differentiated classification of the assets, all assets are to be assigned to the highest defined protection requirement.',4,22),(130,'Cloud customers can use appropriate controls to ensure that the need for protection of the information that can be processed or stored with the cloud service is adequately determined.\n\nCloud customers can also use appropriate controls to ensure that the information processed or stored with the cloud service is protected against tampering, copying, modifying, redirecting or deleting in accordance with its protection needs.',5,22),(131,'yes',6,22),(132,'The classification of the assets and the determination of the need for protection should take place during the initial acquisition of the assets. Thus, the classification should also be documented in an asset management tool. The determination of the protection requirement can also be carried out in a standardised form and stored digitally. If there are changes in the classification, these should also be recorded in logs.\n\nThe auditor can then automatically test whether all assets in the platform are classified and whether the classification was determined using a standardised format. For changes in the classification, it can be automatically reconstructed whether these were also carried out based on the uniform schema. For this purpose, the logs produced can be evaluated as part of a continuous audit.',7,22),(133,'Security requirements for premises and buildings related to the cloud service provided, are based on the security objectives of the information security policy, identified protection requirements for the cloud service and the assessment of risks to physical and environmental security. The security requirements are documented, communicated and provided in a policy or concept according to SP-01.\n\nThe security requirements for data centres are based on criteria which comply with established rules of technology. They are suitable for addressing the following risks in accordance with the applicable legal and contractual requirements:\n\n- Faults in planning;\n\n- Unauthorised access;\n\n- Insufficient surveillance;\n\n- Insufficient air-conditioning;\n\n- Fire and smoke; \n\n- Water;\n\n- Power failure; and\n\n- Air ventilation and filtration.\n\nIf the Cloud Service Provider uses premises or buildings operated by third parties to provide the Cloud Service, the document describes which security requirements the Cloud Service Provider places on these third parties. \n\nThe appropriate and effective verification of implementation is carried out in accordance with the criteria for controlling and monitoring subcontractors (cf. SSO-01, SSO-02).',2,23),(134,'The security requirements include time constraints for self-sufficient operation in the event of exceptional events (e.g. prolonged power outage, heat waves, low water in cold river water supply) and maximum tolerable utility downtime.\n\nThe time limits for self-sufficient operation provide for at least 48 hours in the event of a failure of the external power supply.\n\nFor a self-sufficient operation during a heat period, the highest outside temperatures measured to date within a radius of at least 50 km around the locations of the premises and buildings have been determined with a safety margin of 3 K. The security requirements stipulate that the permissible operating and environmental parameters of the cooling supply must also be observed on at least five consecutive days with these outside temperatures including the safety margin (cf. PS-06 Protection against failure of the supply facilities).\n\nIf water is taken from a river for air conditioning, it is determined at which water levels and water temperatures the air conditioning can be maintained for how long.\n\nThe maximum tolerable downtimes of utility facilities are suitable for meeting the availability requirements contained in the service level agreement.',3,23),(135,'Premises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud customer data and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.). Backup or redundancy computer centres.\n\nPremises and buildings operated by third parties are e.g. server housing, colocation, IaaS.\n\nPremises and buildings in which no data from cloud customers is processed or stored (e.g. offices of the Cloud Service Provider, server rooms with system components for internal development and test systems) are not subject to this criteria area.\n\nThe recognised rules of technology are defined in relevant standards, e.g. EN 50600 (facilities and infrastructures of data centres).\n\nIncorrect planning can endanger the operational safety and availability of the premises or buildings. This can result from an incorrect assessment of elementary hazards at the site (e.g. air traffic, earthquakes, floods, hazardous substances) as well as an incorrect conception of the bandwidth or energy supply.\n\nTime specifications for self-sustaining operation as well as maximum tolerable downtimes of utility facilities are typically collected during the business impact analysis (cf. BCM-02, BCM-03).',4,23),(136,'-',5,23),(137,'partially',6,23),(138,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,23),(139,'The cloud service is provided from two locations that are redundant to each other. The locations meet the security requirements of the Cloud Service Provider (cf. PS-01 Security Concept) and are located in an adequate distance to each other to achieve operational redundancy. Operational redundancy is designed in a way that ensures that the availability requirements specified in the service level agreement are met. The functionality of the redundancy is checked at least annually by suitable tests and exercises (cf. BCM-04 - Verification, updating and testing of business continuity).',2,24),(140,'The cloud service is provided from more than two locations that provide each other with redundancy. The locations are sufficiently far apart to achieve georedundancy. If two locations fail at the same time, at least one third location is still available to prevent a total service failure. The georedundancy is designed in a way that ensures that the availability requirements specified in the service level agreement are met.. The functionality of the redundancy is checked at least annually by suitable tests and exercises (cf. BCM-04 - Verification, updating and testing of business continuity).',3,24),(141,'Operational redundancy of the sites to each other in the sense of the basic requirement is given, if based on the assessment of elementary risks at the site corresponding distances of the premises and buildings to these risks are maintained. Very extensive events which, due to their extent, could affect several sites of the same redundancy group simultaneously or in a timely manner (e.g. floods, earthquakes) are not considered.\n\nA georedundancy of the sites to each other in the sense of the optional, more far-reaching requirement is given if a very extensive event at a site under no circumstances affects several sites of the same redundancy group simultaneously or promptly. The BSI publication \"Kriterien für die Standortwahl höchstverfügbarer und georedundanter Rechenzentren\" provides assistance in this regard. \n\nThere are cloud providers who no longer address the issue of reliability of the cloud service on a physical level through redundancy from two independent locations, but through resilience. The cloud service is provided simultaneously from more than two locations. The underlying distributed data centre architecture ensures that the failure of a location or components of a location does not violate the defined availability criteria of the cloud service. Such an architecture can represent an alternative fulfilment (cf. Chapter 4.4.7) of the criterion. The tests and exercises on functionality required in the criterion also apply analogously to resilient architectures.',4,24),(142,'By means of suitable controls, cloud customers ensure that the existing redundancy model of the cloud provider and the evidence for the verification of the model comply with their own requirements for the availability and reliability of the cloud service.',5,24),(143,'partially',6,24),(144,'An annual audit of the effectiveness of the redundancy is only partially suitable for a continuous audit. A continuous audit could return the date of the last transaction to bring about redundancy.\n\nIn addition, it would be possible to document every transaction that contributes to redundancy by means of logs and to evaluate these logs automatically and continuously. In addition, the status of the redundancy could be continuously queried.',7,24),(145,'The structural shell of premises and buildings related to the cloud service provided are physically solid and protected by adequate security measures that meet the security requirements of the Cloud Service Provider (cf. PS-01 Security Concept).\n\nThe security measures are designed to detect and prevent unauthorised access in a timely manner so that it does not compromise the information security of the cloud service.\n\nThe outer doors, windows and other construction elements reach a level appropriate to the security requirements and withstand a burglary attempt for at least 10 minutes. \n\nThe surrounding wall constructions as well as the locking mechanisms meet the associated requirements.',2,25),(146,'The security measures installed at the site include permanently present security personnel (at least 2 individuals), video surveillance and anti-burglary systems.',3,25),(147,'Security measures for detecting unauthorised access can be security personnel, video surveillance or burglar alarm systems.\n\nThe resistance class RC4 according to DIN EN 1627 stipulates that doors, windows and other components must withstand a break-in attempt for at least 10 minutes. The US standard SD-STD-01.01 Rev.G. is an international equivalent to this standard.',4,25),(148,'-',5,25),(149,'partially',6,25),(150,'A continuous inspection of the structural shell of buildings is only partially feasible. Only the protection against unauthorised access can provide evaluable data in the form of access logs that are stored.',7,25),(151,'At access points to premises and buildings related to the cloud service provided, physical access controls are set up in accordance with the Cloud Service Provider\'s security requirements (cf. PS-01 Security Concept) to prevent unauthorised access.\n\nAccess controls are supported by an access control system.\n\nThe requirements for the access control system are documented, communicated and provided in a policy or concept in accordance with SP-01 and include the following aspects:\n\n- Specified procedure for the granting and revoking of access authorisations (cf. IDM-02) based on the principle of least authorisation (\"least-privilege-principle\") and as necessary for the performance of tasks (\"need-to-know-principle\");\n\n- Automatic revocation of access authorisations if they have not been used for a period of 2 month;\n\n- Automatic withdrawal of access authorisations if they have not been used for a period of 6 months;\n\n- Two-factor authentication for access to areas hosting system components that process cloud customer information;\n\n- Visitors and external personnel are tracked individually by the access control during their work in the premises and buildings, identified as such (e.g. by visible wearing of a visitor pass) and supervised during their stay; and\n\n- Existence and nature of access logging that enables the Cloud Service Provider, in the sense of an effectiveness audit, to check whether only defined personnel have entered the premises and buildings related to the cloud service provided.',2,26),(152,'-',3,26),(153,'-',4,26),(154,'-',5,26),(155,'yes',6,26),(156,'Access control via an access card system can be documented by the Cloud Service Provider in the form of logs. These logs can be evaluated automatically. In addition, unauthorised access can also be traced through these logs. This can also be evaluated automatically.\n\nTherefore, a continuous audit is possible.\n\nInsofar as the withdrawal of access authorisations is standardised and documented in the same way, an automated evaluation is also possible here and thus a continuous audit can be carried out.',7,26),(157,'Premises and buildings related to the cloud service provided are protected from fire and smoke by structural, technical and organisational measures that meet the security requirements of the Cloud Service Provider (cf. PS-01 Security Concept) and include the following aspects: \n\na) Structural Measures:\n\nEstablishment of fire sections with a fire resistance duration of at least 90 minutes for all structural parts.\n\nb) Technical Measures:\n\n- Early fire detection with automatic voltage release. The monitored areas are sufficiently fragmented to ensure that the prevention of the spread of incipient fires is proportionate to the maintenance of the availability of the cloud service provided;\n\n- Extinguishing system or oxygen reduction; and\n\n- Fire alarm system with reporting to the local fire department.\n\nc) Organisational Measures\n\n- Regular fire protection inspections to check compliance with fire protection requirements; and\n\n- Regular fire protection exercises.',2,27),(158,'The environmental parameters are monitored. When the permitted control range is exceeded, alarm messages are generated and forwarded to the Cloud Service Provider’s subject matter experts',3,27),(159,'The monitoring of the environmental parameters is addressed in PS-01. When exceeding the allowed control range, alarm messages are generated and forwarded to the responsible Cloud Service Provider.\nStructural parts are walls, ceilings, floors, doors, ventilation flaps, etc.',4,27),(160,'-',5,27),(161,'yes',6,27),(162,'Continuous testing is possible insofar as the built-in technology for testing the protective measures produces evaluable data and these are stored in a standardised form. This would allow the security measures to be continuously evaluated by the auditor.\n\nIf this technology is not fully available and an inspection of the data centre is necessary, the possibility of continuous auditing is achievable only to a limited extent.',7,27),(163,'Measures to prevent the failure of the technical supply facilities required for the operation of system components with which information from cloud customers is processed, are documented and set up in accordance with the security requirements of the Cloud Service Provider (cf. PS-01 Security Concept) with respect to the following aspects:\n\na) Operational redundancy (N+1) in power and cooling supply\n\nb) Use of appropriately sized uninterruptible power supplies (UPS) and emergency power systems (NEA), designed to ensure that all data remains undamaged in the event of a power failure. The functionality of UPS and NEA is checked at least annually by suitable tests and exercises (cf. BCM-04 - Verification, updating and testing of business continuity).\n\nc) Maintenance (servicing, inspection, repair) of the utilities in accordance with the manufacturer\'s recommendations. \n\nd) Protection of power supply and telecommunications lines against interruption, interference, damage and eavesdropping. The protection is checked regularly, but at least every two years, as well as in case of suspected manipulation by qualified personnel regarding the following aspects:\n\n- Traces of violent attempts to open closed distributors;\n\n- Up-to-datedness of the documentation in the distribution list;\n\n- Conformity of the actual wiring and patching with the documentation;\n\n- The short-circuits and earthing of unneeded cables are intact; and\n\n- Impermissible installations and modifications.',2,28),(164,'Uninterruptible Power Supplies (UPS) and Emergency Power Supplies (NPS) are designed to meet the availability requirements defined in the Service Level Agreement.\n\nThe cooling supply is designed in such a way that the permissible operating and environmental parameters are also ensured on at least five consecutive days with the highest outside temperatures measured to date within a radius of at least 50 km around the locations of the premises and buildings, with a safety margin of 3 K (in relation to the outside temperature). The Cloud Service Provider has previously determined the highest outdoor temperatures measured to date (cf. PS-00-1 Security Concept).\n\nThe connection to the telecommunications network is designed with sufficient redundancy so that the failure of a telecommunications network does not impair the security or performance of the Cloud Service Provider.',3,28),(165,'Measures to prevent the failure of the technical supply facilities are e.g. power supply, cooling, fire-fighting technology, telecommunications, security technology, etc.\n\nCloud Service Providers can ensure that all data remains undamaged in the event of a power failure by shutting down servers following a defined procedure.\n\nPower supply and telecommunications lines can be protected against interruption, interference, damage and eavesdropping by e.g. underground supply via different supply routes.',4,28),(166,'-',5,28),(167,'partially',6,28),(168,'The physical security of premises, as well as failure precautions of the technical supply facilities should be ensured on site by an inspection of the data centre. Therefore, a continuous examination is achievable only to a limited extent. If the built-in technology for failure prevention produces evaluable log data, this requirement can partly be audited continuously. However, this does not replace an inspection.\n\nOtherwise, a continuous inspection can be carried out at least partially by indicating the last inspection date.',7,28),(169,'The operating parameters of the technical utilities (cf. PS-06) and the environmental parameters of the premises and buildings related to the cloud service provided are monitored and controlled in accordance with the security requirements of the Cloud Service Provider (cf. PS-01 Security Concept). When the permitted control range is exceeded, the responsible departments of the Cloud-Provider are automatically informed in order to promptly initiate the necessary measures for return to the control range.',2,29),(170,'-',3,29),(171,'Operating parameters and environmental parameters of the premises and buildings are, e.g. air temperature and humidity, leakage.',4,29),(172,'-',5,29),(173,'yes',6,29),(174,'The monitoring and control of the operating parameters of the technical supply facilities is carried out automatically and documented in a standardised manner, for example in logs. \n\nThese logs are then automated by the inspector and can be continuously evaluated.',7,29),(175,'The planning of capacities and resources (personnel and IT resources) follows an established procedure in order to avoid possible capacity bottlenecks. The procedures include forecasting future capacity requirements in order to identify usage trends and manage system overload. \n\nCloud Service Providers take appropriate measures to ensure that they continue to meet the requirements agreed with cloud customers for the provision of the cloud service in the event of capacity bottlenecks or outages regarding personnel and IT resources, in particular those relating to the dedicated use of system components, in accordance with the respective agreements.',2,30),(176,'The forecasts are considered in accordance with the service level agreement for planning and preparing the provisioning.',3,30),(177,'For economic reasons, Cloud Service Providers typically strive for a high utilisation of IT resources (CPU, RAM, storage space, network). In multi-tenant environments, existing resources must still be shared between cloud users (clients) in such a way that service level agreements are adhered to. In this respect, proper planning and monitoring of IT resources is critical to the availability and competitiveness of the cloud service. If the procedures are not documented or are subject to a higher degree of confidentiality as a trade secret of the Cloud Service Provider, the Cloud Service Provider must be able to explain the procedures at least orally within the scope of this audit.\n\nCloud customers must use appropriate controls to ensure that the capacity and resource requirements to be covered by the Cloud Service Provider are planned and reflected in the SLA with the Cloud Service Provider. The requirements can also be reviewed regularly through appropriate controls and the SLA can be adjusted accordingly.',4,30),(178,'-',5,30),(179,'no',6,30),(180,'An audit of the planning of capacities and resources requires an assessment of the plausibility or meaningfulness of the content. At present, this can hardly be audited automatically and continuously.',7,30),(181,'Technical and organisational safeguards for the monitoring and provisioning and de-provisioning of cloud services are defined. Thus, the Cloud Service Provider ensures that resources are provided and/or services are rendered according to the contractual agreements and that compliance with the service level agreements is ensured.',2,31),(182,'To monitor capacity and availability, the relevant information is available to the cloud customer in a self-service portal.',3,31),(183,'Technical and organisational measures typically include:\n\n- Use of monitoring tools with alarm function when defined threshold values are exceeded;\n\n- Process for correlating events and interface to incident management;\n\n- Continuous monitoring of the systems by qualified personnel; and\n\n- Redundancies in the IT systems.',4,31),(184,'Cloud customers ensure through suitable controls, that the contractual agreements made with the Cloud Service Provider for the provision of resources or services can be monitored. In case of deviations, appropriate controls ensure that the Cloud Service Provider is informed so that the Cloud Service Provider can take appropriate action.',5,31),(185,'yes',6,31),(186,'The part of resource monitoring can be continuously audited by checking capacity forecasts and monitoring the resource management tool. Furthermore, the logs of provisioning and de-provisioning and their impact on resource management can be continuously audited by the changes in resource management.',7,31),(187,'Depending on the capabilities of the respective service model, the cloud customer can control and monitor the allocation of the system resources assigned to the customer for administration/use in order to avoid overcrowding of resources and to achieve sufficient performance.',2,32),(188,'-',3,32),(189,'Resources according to the possibilities of the service model are for example\n\n- Computing capacity;\n\n- Storage capacity;\n\n- Configuration of network properties;\n\n- Application Programming Interfaces (APIs); and\n\n- Databases.',4,32),(190,'Cloud customers ensure through suitable controls, that they manage and monitor the system resources in their area of responsibility.',5,32),(191,'partially',6,32),(192,'The existence of tools for controlling resources by the cloud customers themselves is, in itself, a continuous process, which can be continuously checked provided that the Cloud Service Provider can prove the functionality of these tools by means of logs. However, continuously checking this only generates a limited value. The functionality of the tools provided can be continuously audited, if they are documented and can be evaluated by the Cloud Service Provider.',7,32),(193,'Policies and instructions that provide protection against malware are documented, communicated, and provided in accordance with SP-01 with respect to the following aspects:\n\n- Use of system-specific protection mechanisms;\n\n- Operating protection programs on system components under the responsibility of the Cloud Service Provider that are used to provide the cloud service in the production environment; and\n\n- Operation of protection programs for employees\' terminal equipment.',2,33),(194,'The Cloud Service Provider creates regular reports on the checks performed, which are reviewed and analysed by authorised bodies or committees. Policies and instructions describe the technical measures taken to securely configure and monitor the management console (both the customer\'s self-service and the service provider\'s cloud administration) to protect it from malware. Updates are applied at the highest frequency that the vendor(s) contractually offer(s).',3,33),(195,'Protection programs for employee devices can be, for example, server-based protection programs that scan files in attachments on the server or filter network traffic.',4,33),(196,'-',5,33),(197,'partially',6,33),(198,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,33),(199,'System components under the Cloud Service Provider\'s responsibility that are used to deploy the cloud service in the production environment are configured with malware protection according to the policies and instructions. If protection programs are set up with signature and behaviour-based malware detection and removal, these protection programs are updated at least daily.',2,34),(200,'The configuration of the protection mechanisms is monitored automatically. Deviations from the specifications are automatically reported to the responsible authorities so that they can be immediately assessed and the necessary measures taken.',3,34),(201,'Protection against malicious programs can be implemented by operating system-specific protection mechanisms or explicit protection programs (e.g. for signature- and behaviour-based detection and removal of malicious programs).',4,34),(202,'Cloud customers ensure through suitable controls, that the layers of the cloud service which they are responsible for, have security products in place to detect and remove malware.',5,34),(203,'yes',6,34),(204,'The first step should be to check whether all systems are covered. This should be monitored by continuously checking a tool including the additions and deletions of entries. \n\nIn the second step, the log files for the updates of the individual servers and the regular scans should be audited continuously. Identified malware or irregularities should be marked and tracked as part of the continuous scan.',7,34),(205,'Policies and instructions for data backup and recovery are documented, communicated and provided in accordance with SP-01 regarding the following aspects.\n\n- The extent and frequency of data backups and the duration of data retention are consistent with the contractual agreements with the cloud customers and the Cloud Service Provider\'s operational continuity requirements for Recovery Time Objective (RTO) and Recovery Point Objective (RPO);\n\n- Data is backed up in encrypted, state-of-the-art form; \n\n- Access to the backed-up data and the execution of restores is performed only by authorised persons; and\n\n- Tests of recovery procedures (cf. OPS-08).',2,35),(206,'-',3,35),(207,'The data backup concept specifies which type of data backup is to be carried out (e.g. type, manner, duration) and specifies which data must also be backed up in special cases (e.g. pure use of compute nodes without data storage). When backing up data, a distinction must be made between backups and snapshots of virtual machines. Snapshots do not replace backups, but can be part of the backup strategy to achieve Recovery Point Objectives (RPO) if they are additionally stored outside the original data location. The business requirements of the Cloud Service Provider for the scope, frequency and duration of the data backup result from the business impact analysis (cf. BCM-03) for development and operational processes of the cloud service. If different data backup and recovery procedures exist for data under the responsibility of the cloud customer and the Cloud Service Provider, both variants must be included in a test according to this criteria catalogue. For procedures to secure the data of the Cloud Service Provider, only the adequacy and implementation of the controls must be proven, but not their effectiveness. For procedures to secure the data of cloud customers, proof of effectiveness must also be provided.',4,35),(208,'Cloud customers ensure through suitable controls, that the contractual agreements made with the Cloud Service Provider regarding the scope, frequency and duration of data retention meet business requirements. The business requirements are assessed as part of the Business Impact Analysis (cf. BCM-02).',5,35),(209,'partially',6,35),(210,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,35),(211,'The execution of data backups is monitored by technical and organisational measures. Malfunctions are investigated by qualified staff and rectified promptly to ensure compliance with contractual obligations to cloud customers or the Cloud Service Provider\'s business requirements regarding the scope and frequency of data backup and the duration of storage.',2,36),(212,'The relevant logs or summarised results are available to the cloud customer in a self-service portal for monitoring the data backup.',3,36),(213,'If the data backup is not part of the contract concluded between the Cloud Service Provider and the cloud customer, this criterion is not applicable. The Cloud Service Provider must present this situation transparently in the system description.',4,36),(214,'Cloud customers ensure through suitable controls, that the backup of data within their area of responsibility is monitored by technical and organisational measures.',5,36),(215,'yes',6,36),(216,'The execution of different data backups can be performed by continuously auditing the log files and the associated results of the data backup. Any errors in the data backup would be continuously detected and could be explained by appropriate measures and documentation in the audit.',7,36),(217,'Restore procedures are tested regularly, at least annually. The tests allow an assessment to be made as to whether the contractual agreements as well as the specifications for the maximum tolerable downtime (Recovery Time Objective, RTO) and the maximum permissible data loss (Recovery Point Objective, RPO) are adhered to (cf. BCM-02).\n\nDeviations from the specifications are reported to the responsible personnel or system components so that these can promptly assess the deviations and initiate the necessary actions.',2,37),(218,'At the customer\'s request, the Cloud Service Provider inform the cloud customer of the results of the recovery tests. Recovery tests are embedded in the Cloud Service Provider\'s emergency management.',3,37),(219,'If the data backup is not part of the contract concluded between the Cloud Service Provider and the cloud customer, this criterion is not applicable. The Cloud Service Provider must present this situation transparently in the system description.',4,37),(220,'-',5,37),(221,'partially',6,37),(222,'If the tests on the restoration procedures are performed at regular intervals, the time of execution and results can be audited automatically. However, the effort of a continuous audit of this criterion is high and the added value limited if the tests are carried out in an annual cycle',7,37),(223,'The Cloud Service Provider transfers data to be backed up to a remote location or transports these on backup media to a remote location. If the data backup is transmitted to the remote location via a network, the data backup or the transmission of the data takes place in an encrypted form that corresponds to the state-of-the-art. The distance to the main site is chosen after sufficient consideration of the factors recovery times and impact of disasters on both sites. The physical and environmental security measures at the remote site are at the same level as at the main site.',2,38),(224,'-',3,38),(225,'If the data backup is not part of the contract concluded between the Cloud Service Provider and the cloud customer, this criterion is not applicable. The Cloud Service Provider must present this situation transparently in the system description.\n\nA remote location can be e.g. another data centre of the Cloud Service Provider.',4,38),(226,'-',5,38),(227,'yes',6,38),(228,'If the data is transported physically, a continuous audit of this criterion means that the successful storage has been confirmed. In the case of electronic transmission, the log files of the transmission can be continuously evaluated, and the result of this audit can be transmitted.',7,38),(229,'The Cloud Service Provider has established policies and instructions that govern the logging and monitoring of events on system components within its area of responsibility. These policies and instructions are documented, communicated and provided according to SP-01 with respect to the following aspects:\n\n- Definition of events that could lead to a violation of the protection goals;\n\n- Specifications for activating, stopping and pausing the various logs;\n\n- Information regarding the purpose and retention period of the logs.\n\n- Define roles and responsibilities for setting up and monitoring logging;\n\n- Time synchronisation of system components; and\n\n- Compliance with legal and regulatory frameworks.',2,39),(230,'-',3,39),(231,'Legal and regulatory frameworks can define e.g. legal requirements for retention and deletion of data.',4,39),(232,'Cloud customers ensure through suitable controls, that appropriate logging and monitoring of events that may affect the security and availability of the cloud service (e.g. administrator activities, system failures, authentication checks, data deletions, etc.) takes place for those layers of the cloud service under their responsibility.',5,39),(233,'partially',6,39),(234,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,39),(235,'Policies and instructions for the secure handling of metadata (usage data) are documented, communicated and provided according to SP-01 with regard to the following aspects:\n\n- Metadata is collected and used solely for billing, incident management and security incident management purposes;\n\n- Exclusively anonymous metadata to deploy and enhance the cloud service so that no conclusions can be drawn about the cloud customer or user;\n\n- No commercial use; \n\n- Storage for a fixed period reasonably related to the purposes of the collection;\n\n- Immediate deletion if the purposes of the collection are fulfilled and further storage is no longer necessary.\n\n- Provision to cloud customers according to contractual agreements.',2,40),(236,'Personal data is automatically removed from the log data before the Cloud Service Provider processes it as far as technically possible. The removal is done in a way that allows the Cloud Service Provider to continue to use the log data for the purpose for which it was collected.',3,40),(237,'Metadata is all data that is generated by the Cloud Service Provider through the use of its service by the cloud customer and is not content-related data. This includes login/logout times, IP addresses, customer\'s GPS location, which resources (network, storage, computer) were used, which data was accessed when, with whom data was shared, with whom it was communicated, etc. This data is partly used for billing purposes and for (security) incident management. However, it can also be used to analyse customer behaviour (depending on the cloud service) and to make the decision making and work processes visible to the Cloud Service Provider. The criteria aim to provide a transparent and clear definition of the collection and use of metadata. In addition, metadata refers to data that is generated when the Cloud Service Provider accesses customer data (e.g. for indexing).',4,40),(238,'-',5,40),(239,'partially',6,40),(240,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,40),(241,'The requirements for the logging and monitoring of events and for the secure handling of metadata are implemented by technically supported procedures with regard to the following restrictions:\n\n- Access only to authorised users and systems;\n\n- Retention for the specified period; and\n\n- Deletion when further retention is no longer necessary for the purpose of collection.',2,41),(242,'-',3,41),(243,'-',4,41),(244,'-',5,41),(245,'no',6,41),(246,'A continuous check is only of limited use here, since the primary purpose of checking the handling of metadata is to check the guidelines and the associated configurations of the tools for securing, processing and deleting metadata. In addition, the contractual basis for the use of metadata may also need to be considered. \n\nAlternative suggestion:\n\nA continuous audit could include the configuration for deleting or anonymising the metadata and automatically recording whether the configuration still exists and is implemented correctly. In this case, there would be a partial possibility for continuous auditing.',7,41),(247,'The logging data is automatically monitored for events that may violate the protection goals in accordance with the logging and monitoring requirements. This also includes the detection of relationships between events (event correlation). \n\nIdentified events are automatically reported to the appropriate departments for prompt evaluation and action.',2,42),(248,'-',3,42),(249,'-',4,42),(250,'-',5,42),(251,'yes',6,42),(252,'The Cloud Service Provider can automatically test the list of assets critical for monitoring and record this test in logs.\n\nThe auditor can audit the log files for irregularities automatically and continuously.',7,42),(253,'The Cloud Service Provider retains the generated log data and keeps these in an appropriate, unchangeable and aggregated form, regardless of the source of such data, so that a central, authorised evaluation of the data is possible. Log data is deleted if it is no longer required for the purpose for which they were collected. \n\nBetween logging servers and the assets to be logged, authentication takes place to protect the integrity and authenticity of the information transmitted and stored. The transfer takes place using state-of-the-art encryption or a dedicated administration network (out-of-band management).',2,43),(254,'The Cloud Service Provider provides a customer-specific logging (in terms of scope and duration of retention period) upon request of the Cloud Customer. Depending on the protection requirements of the Cloud Service Provider and the technical feasibility, a logical or physical separation of log and customer data is carried out.',3,43),(255,'-',4,43),(256,'-',5,43),(257,'yes',6,43),(258,'The storage of logging data at a central location can be documented by logs when the data is saved. The deletion of this data can also be automated and documented by logs.\n\nThe auditor can then perform an automated and continuous evaluation of these logs.',7,43),(259,'The log data generated allows an unambiguous identification of user accesses at tenant level to support (forensic) analysis in the event of a security incident. \n\nInterfaces are available to conduct forensic analyses and perform backups of infrastructure components and their network communication.',2,44),(260,'On request of the Cloud customer, the Cloud Service Provider provides the logs relating to the cloud customer in an appropriate form and in a timely manner so that the cloud customer can investigate any incidents relating to them.',3,44),(261,'Infrastructure components in the sense of this criterion are e.g. fabric controllers, network components and virtualisation servers.',4,44),(262,'Cloud customers ensure through suitable controls, that unique user IDs are assigned which allow a corresponding analysis in the event of a security incident.',5,44),(263,'no',6,44),(264,'For the generated logging data to allow unambiguous identification of user accesses at the tenant level, the creation of this data must be configured accordingly. This configuration does not have to be audited continuously, but only if it is changed.\n\nThe interfaces can also be audited initially and then tested again if changes are made.',7,44),(265,'Access to system components for logging and monitoring in the Cloud Service Provider’s area of responsibility is restricted to authorised users. Changes to the configuration are made in accordance with the applicable policies (cf. DEV-03).',2,45),(266,'Access to system components for logging and monitoring in the Cloud Service Provider\'s area of responsibility requires two-factor authentication.',3,45),(267,'-',4,45),(268,'-',5,45),(269,'yes',6,45),(270,'The continuous audit of this access restriction can be tested by log files of all changes to access rights for the system components for logging and monitoring. Changes can be automatically and continuously audited according to the person\'s sense and need for access.',7,45),(271,'The Cloud Service Provider monitors the system components for logging and monitoring in its area of responsibility. Failures are automatically and promptly reported to the Cloud Service Provider’s responsible departments so that these can assess the failures and take required action.',2,46),(272,'The system components for logging and monitoring are designed in such a way that the overall functionality is not restricted if individual components fail.',3,46),(273,'-',4,46),(274,'-',5,46),(275,'yes',6,46),(276,'Automatically communicated failures can be tracked in logs.\n\nA continuous and automated audit of these failures can be carried out by evaluating these logs.',7,46),(277,'Guidelines and instructions with technical and organisational measures are documented, communicated and provided in accordance with SP-01 to ensure the timely identification and addressing of vulnerabilities in the system components used to provide the cloud service. These guidelines and instructions contain specifications regarding the following aspects:\n\n- Regular identification of vulnerabilities;\n\n- Assessment of the severity of identified vulnerabilities;\n\n- Prioritisation and implementation of actions to promptly remediate or mitigate identified vulnerabilities based on severity and according to defined timelines; and\n\n- Handling of system components for which no measures are initiated for the timely remediation or mitigation of vulnerabilities.',2,47),(278,'-',3,47),(279,'Identified vulnerabilities can be classified according to established metrics such as CVSS or OWASP. The decision not to remediate or mitigate identified vulnerabilities must be made by the Cloud Service Provider based on a risk assessment. If necessary, risk-compensating measures must be taken.',4,47),(280,'Cloud customers ensure through suitable controls, that they check system components in their area of responsibility for vulnerabilities on a regular basis and mitigate these with appropriate measures.',5,47),(281,'no',6,47),(282,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,47),(283,'The Cloud Service Provider has penetration tests carried out by qualified internal personnel or external service providers at least once a year. The penetration tests are carried out according to a documented test methodology and include the system components relevant to the provision of the cloud service in the area of responsibility of the Cloud Service Provider, which have been identified as such in a risk analysis. \n\nThe Cloud Service Provider assess the severity of the findings made in penetration tests according to defined criteria.\n\nFor findings with medium or high criticality regarding the confidentiality, integrity or availability of the cloud service, actions must be taken within defined time windows for prompt remediation or mitigation.',2,48),(284,'The tests are carried out every six months. They must always be performed by independent external auditors. Internal personnel for penetration tests may support the external service providers.',3,48),(285,'Vulnerabilities should be classified according to damage potential and a period of time should be specified for the required response. The following classification according to the BSI publication \"Ein Praxis-Leitfaden für IS-\nPenetrationstests\" can serve as an orientation:\n\n- High: Immediate reaction;\n\n- Medium: Short-term response;\n\n- Low: Medium-term response; and\n\n- Information: Long-term response.',4,48),(286,'-',5,48),(287,'partially',6,48),(288,'Since penetration tests are carried out annually, a continuous audit is not practical, since the effort required to automate the execution of the test is probably greater than the benefit.',7,48),(289,'The Cloud Service Provider regularly measures, analyses and assesses the procedures with which vulnerabilities and incidents are handled to verify their continued suitability, appropriateness and effectiveness.\n\nResults are evaluated at least quarterly by accountable departments at the Cloud Service Provider to initiate continuous improvement actions and to verify their effectiveness.',2,49),(290,'-',3,49),(291,'Common Vulnerabilities and Exposures (CVE) or similar methods are a suitable way of documenting vulnerabilities and incidents.',4,49),(292,'-',5,49),(293,'yes',6,49),(294,'The measurements, analyses and evaluations are based on data that could be continuously queried in order to verify the plausibility of the results derived from them.\n\nThe initiation and review of measures for continuous improvement require a manual audit.',7,49),(295,'The Cloud Service Provider periodically informs the cloud customer on the status of incidents affecting the cloud customer, or, where appropriate and necessary, involve the customer in the resolution, in a manner consistent with the contractual agreements.\n\nAs soon as an incident has been resolved from the Cloud Service Provider\'s perspective, the cloud customer is informed according to the contractual agreements, about the actions taken.',2,50),(296,'-',3,50),(297,'-',4,50),(298,'Cloud customers ensure through suitable controls that they receive notifications from the Cloud Service Provider regarding incidents that affect them, and that these notifications are forwarded in a timely manner to the department responsible for processing them so that appropriate action can be taken.',5,50),(299,'yes',6,50),(300,'A continuous audit is possible if customers are informed about incidents via a standardised communication channel and this is documented (e-mails, logs).\n\nThe auditor can then evaluate the compiled documentation automatically and continuously.\n\nHowever, it seems more effective to combine the evaluation of the communication of incidents to cloud customers with the evaluation of the elimination of the incidents. As soon as the incidents have been resolved automatically in the best case, an automatic message is generated and sent to the cloud customer. This message is to be documented.\n\nThis makes it possible for the auditor to evaluate whether the cloud customer has been properly informed on a regular basis about all incidents affecting them, but not beyond.',7,50),(301,'System components in the area of responsibility of the Cloud Service Provider for the provision of the cloud service are automatically checked for known vulnerabilities at least once a month in accordance with the policies for handling vulnerabilities (cf. OPS-18), the severity is assessed in accordance with defined criteria and measures for timely remediation or mitigation are initiated within defined time windows.',2,51),(302,'Available security patches are applied depending on the severity of the vulnerabilities, as determined based on the latest version of the Common Vulnerability Scoring System (CVSS):\n\n- Critical (CVSS = 9.0 - 10.0): 3 hours;\n\n- High (CVSS = 7.0 - 8.9): 3 days;\n\n- Average (CVSS = 4.0 - 6.9): 1 month;\n\n- Low (CVSS = 0.1 - 3.9): 3 months.',3,51),(303,'In contrast to penetration tests (Cf. OPS-20), which are carried out manually and according to an individual scheme, the check for open vulnerabilities is performed automatically, using so-called vulnerability scanners.',4,51),(304,'Cloud customers ensure through suitable controls, that system components under their responsibility are regularly checked for vulnerabilities and to mitigate these by appropriate measures.',5,51),(305,'yes',6,51),(306,'The periodic check for vulnerabilities and the corresponding results as well as the analysis and remediation of identified vulnerabilities are documented by the Cloud Service Provider. \n\nAn automated and continuous audit of this procedure can be implemented by the auditor by automatically evaluating the documented results.',7,51),(307,'System components in the production environment used to provide the cloud service under the Cloud Service Provider\'s responsibility are hardened according to generally accepted industry standards. The hardening requirements for each system component are documented.\n\nIf non-modifiable (\"immutable\") images are used, compliance with the hardening specifications as defined in the hardening requirements is checked upon creation of the images. Configuration and log files regarding the continuous availability of the images are retained.',2,52),(308,'System components in the Cloud Service Provider\'s area of responsibility are automatically monitored for compliance with hardening specifications. Deviations from the specifications are automatically reported to the appropriate departments of the Cloud Service Provider for immediate assessment and action.',3,52),(309,'System components in the sense of the basic criterion are the objects required for the information security of the cloud service during the creation, processing, storage, transmission, deletion or destruction of information in the Cloud Service Provider\'s area of responsibility, e.g. firewalls, load balancers, web servers, application servers and database servers. These system components in turn consist of hardware and software objects. This criterion is limited to software objects such as hypervisors, operating systems, databases, programming interfaces (APIs), images (e.g. for virtual machines and containers) and applications for logging and monitoring security events.\n\nThe configuration and log files for non-modifiable mages include e.g.:\n\n- Configuration of the images used with regards to implemented hardening; and specifications including version history\n\n- Logs for file integrity monitoring of images in productive use.\n\nGenerally accepted industry standards are, for example, the Security Configuration Benchmark of the “Centre for Internet Security” (CIS) or the corresponding modules in the BSI IT-Grundschutz-Kompendium.\n\nCompliance with hardening specifications can be monitored with e.g. file integrity monitoring',4,52),(310,'Cloud customers ensure through suitable controls that layers of the cloud service which are under their responsibility are hardened according to generally established and accepted industry standards. The hardening specifications applied are derived from a risk assessment of the planned usage of the cloud service.',5,52),(311,'yes',6,52),(312,'The verification of compliance with the specifications for the hardening of system components can be automatically tested and subsequently documented (logs).\n\nThe auditor can evaluate these logs automatically and continuously and thus carry out a continuous audit.',7,52),(313,'Cloud customer data stored and processed on shared virtual and physical resources is securely and strictly separated according to a documented approach based on OIS-07 risk analysis to ensure the confidentiality and integrity of this data.',2,53),(314,'Resources in the storage network are segmented by secure zoning (LUN binding and LUN masking).',3,53),(315,'Shared resources include memory, cores and storage networks. Technical segregation (separation) of the stored and processed data of cloud customers into shared resources can be achieved through firewalls, access lists, tagging, VLANs, virtualisation and measures in the storage network (e.g. LUN binding and LUN masking). Where the adequacy and effectiveness of segregation cannot be assessed with reasonable assurance (e.g. due to complex implementation), evidence may also be provided through expert third party review results (e.g. penetration tests to validate the concept). The segregation of transmitted data is subject to control COS-06.',4,53),(316,'Cloud customers ensure through suitable controls that the functions provided by the cloud service for segregating shared virtual and physical resources are used in such way that risks related to segregation are adequately addressed according to the data\'s protection requirements.',5,53),(317,'partially',6,53),(318,'The segregation according to a documented concept is implemented by means of a configuration which does not change with high frequency. A continuous audit of this configuration could check whether the configuration and thus the segregation of the data is implemented correctly. However, the effort for a continuous audit would be high and the benefit limited due to the low change rate of the configuration. Thus, a continuous audit would only be of limited use here. If compliance with the measures taken is monitored, this criterion can be audited automatically.\n\nIt would also be conceivable to continuously audit the actual data segregation. For this purpose, the Cloud Service Provider would have to set up appropriate agents to monitor the data flow between the customer instances (or its absence) on a permanent and documented basis (logs).',7,53),(319,'A role and rights concept based on the business and security requirements of the Cloud Service Provider as well as a policy for managing user accounts and access rights for internal and external employees of the Cloud Service Provider and system components that have a role in automated authorisation processes of the Cloud Service Provider are documented, communicated and made available according to SP-01:\n\n- Assignment of unique usernames; \n\n- Granting and modifying user accounts and access rights based on the “least-privilege- principle” and the “need-to-know” principle;\n\n- Segregation of duties between operational and monitoring functions (“Segregation of Duties”); \n\n- Segregation of duties between managing, approving and assigning user accounts and access rights; \n\n- Approval by authorised individual(s) or system(s) for granting or modifying user accounts and access rights before data of the cloud customer or system components used to provision the cloud service can be accessed; \n\n- Regular review of assigned user accounts and access rights; \n\n- Blocking and removing access accounts in the event of inactivity; \n\n- Time-based or event-driven removal or adjustment of access rights in the event of changes to job responsibility; \n\n- Two-factor or multi-factor authentication for users with privileged access;\n\n- Requirements for the approval and documentation of the management of user accounts and access rights.',2,54),(320,'-',3,54),(321,'System components in the sense of the basic criterion cf. definition in OPS-23. Automated authorisation processes in the sense of this basic criterion concern procedures for automated software provisioning (continuous delivery) as well as for automated provisioning and deprovisioning of user accounts and access rights based on approved requests.',4,54),(322,'-',5,54),(323,'partially',6,54),(324,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.\n\nThe aspects mentioned in the policy can be converted into individual criteria and embedded in a continuous audit. Individual aspects of the policy which can be examined on an ongoing basis: \n\n- Unique user name; \n\n- Segregation of duties; \n\n- Rights profile management (approvals); \n\n- Authorised bodies or individuals; \n\n- Regular review; \n\n- Deactivation due to inactivity; \n\n- Multi-factor authentication; \n\n- Approval and documentation Individual aspects of the policy which cannot be continuously examined in a practicable manner; \n\n- Implementation of least-privilege/need-to-know principles; and\n\n- Withdrawal or adjustment of access rights as the task area changes.',7,54),(325,'Specified procedures for granting and modifying user accounts and access rights for internal and external employees of the Cloud Service Provider as well as for system components involved in automated authorisation processes of the Cloud Service Provider ensure compliance with the role and rights concept as well as the policy for managing user accounts and access rights.',2,55),(326,'The Cloud Service Provider offers cloud customers a self-service with which they can independently assign and change user accounts and access rights.',3,55),(327,'-',4,55),(328,'-',5,55),(329,'no',6,55),(330,'A continuous audit of procedures is strongly dependent on the underlying systematics and automation of the Cloud Service Provider\'s procedures. This may vary in individual cases, but in general a continuous audit does not appear to be effective.',7,55),(331,'User accounts of internal and external employees of the Cloud Service Provider as well as for system components involved in automated authorisation processes of the Cloud Service Provider are automatically locked if they have not been used for a period of two months. Approval from authorised personnel or system components are required to unlock these accounts.\n\nLocked user accounts are automatically revoked after six months. After revocation, the procedure for granting user accounts and access rights (cf. IDM-02) must be repeated.',2,56),(332,'-',3,56),(333,'Locking can result from a longer absence of the employee, for example, due to illness, parental leave, or sabbatical.',4,56),(334,'-',5,56),(335,'yes',6,56),(336,'Automated processes can easily be included in the continuous audit. Appropriate evaluation and reporting mechanisms must be used by the Cloud Service Provider. The auditor must use data analyses to detect deviations.',7,56),(337,'Access rights are promptly revoked if the job responsibilities of the Cloud Service Provider\'s internal or external staff or the tasks of system components involved in the Cloud Service Provider\'s automated authorisation processes change. Privileged access rights are adjusted or revoked within 48 hours after the change taking effect. All other access rights are adjusted or revoked within 14 days. After revocation, the procedure for granting user accounts and access rights (cf. IDM-02) must be repeated.',2,57),(338,'-',3,57),(339,'Changes in the task area of internal and external employees can be triggered by changes in the employment relationship (e.g. termination, transfer) or in contracts and agreements. For privileged access rights the definition in IDM-06 applies.',4,57),(340,'-',5,57),(341,'yes',6,57),(342,'It is necessary to record the changes to the task area in terms of content together with the date of entry into force in order to compare these with the adjustments made to the access rights. A continuous audit seems possible but requires a great deal of effort to implement.',7,57),(343,'Access rights of internal and external employees of the Cloud Service Provider as well as of system components that play a role in automated authorisation processes of the Cloud Service Provider are reviewed at least once a year to ensure that they still correspond to the actual area of use. The review is carried out by authorised persons from the Cloud Service Provider\'s organisational units, who can assess the appropriateness of the assigned access rights based on their knowledge of the task areas of the employees or system components. Identified deviations will be dealt with promptly, but no later than 7 days after their detection, by appropriate modification or withdrawal of the access rights.',2,58),(344,'Privileged access rights are reviewed at least every six months.',3,58),(345,'-',4,58),(346,'-',5,58),(347,'yes',6,58),(348,'The review audit cannot be recorded automatically. A registration of documents used for documentary purposes could take place (e.g. confirmation that the assignment of the access rights has been reviewed). A continuous audit could indicate when this review was last carried out. The Cloud Service Provider must automate the review process (in particular the confirmation that the review has been performed) so that the auditor can audit the steps to be performed in case deviations are detected.',7,58),(349,'Privileged access rights for internal and external employees as well as technical users of the Cloud Service Provider are assigned and changed in accordance to the policy for managing user accounts and access rights (cf. IDM-01) or a separate specific policy.\n\nPrivileged access rights are personalised, limited in time according to a risk assessment and assigned as necessary for the execution of tasks (\"need-to-know principle\"). Technical users are assigned to internal or external employees of the Cloud Service Provider.\n\nActivities of users with privileged access rights are logged in order to detect any misuse of privileged access in suspicious cases. The logged information is automatically monitored for defined events that may indicate misuse. When such an event is identified, the responsible personnel are automatically informed so that they can promptly assess whether misuse has occurred and take corresponding action. In the event of proven misuse of privileged access rights, disciplinary measures are taken in accordance with HR-04.',2,59),(350,'-',3,59),(351,'Privileged access rights in the sense of the Basic Criterion are those that enable employees of the Cloud Service Provider to perform any of the following activities: \n\n- Read or write access to the cloud customers\' data processed, stored or transmitted in the cloud service, unless such data is encrypted or the encryption can be deactivated for access by the Cloud Service Provider; and\n\n- Changes to the operational and/or security configuration of the system components in the production environment, in particular the starting, stopping, deleting or deactivating of system components, if this can affect the confidentiality, integrity or availability of the data of the cloud customers (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events). Misused privileged access rights can be treated e.g. as a security incident, cf. SIM-01.',4,59),(352,'-',5,59),(353,'partially',6,59),(354,'The assignment of audit authorisations must be audited manually. This includes the classification as privileged, personalisation, and evaluation of the need-to-know principle. The time limit could be read, but the implementation effort would be very high. A continuous audit does not appear to be sensible here. Only the system status could be audited continuously. The automatic triggering of a notification in suspicious cases could be compared with documented measures to handle these cases. However, this entire process must be digitised for this purpose, and the effort involved currently appears to be very high. However, a continuous audit could show the time of the last manual audit.',7,59),(355,'The cloud customer is informed by the Cloud Service Provider whenever internal or external employees of the Cloud Service Provider read or write to the cloud customer\'s data processed, stored or transmitted in the cloud service or have accessed it without the prior consent of the cloud customer. The Information is provided whenever data of the cloud customer is/was not encrypted, the encryption is/was disabled for access or the contractual agreements do not explicitly exclude such information. The information contains the cause, time, duration, type and scope of the access. The information is sufficiently detailed to enable subject matter experts of the cloud customer to assess the risks of the access. The information is provided in accordance with the contractual agreements, or within 72 hours after the access.',2,60),(356,'Access to the data processed, stored or transmitted in the cloud service by internal or external employees of the Cloud Service Provider requires the prior consent of an authorised department of the cloud customer, provided that the cloud customer\'s data is not encrypted, encryption is disabled for access, or contractual agreements do not explicitly exclude such consent. For the consent, the cloud customer\'s department is provided with meaningful information about the cause, time, duration, type and scope of the access supporting assessing the risks associated with the access.',3,60),(357,'Subject matter experts in the sense of this basic criterion is personnel from e.g. IT, Compliance or Internal Audit.',4,60),(358,'-',5,60),(359,'yes',6,60),(360,'A continuous audit of the notifications carried out only appears practical if the accesses mentioned are also logged and classified automatically. The content of the notifications can only be audited if the content is specified by the Cloud Service Provider according to a specific scheme. Then, a comparison and plausibility check can take place. A continuous audit would test all notifications after they have been received and thus check whether the process has been executed correctly in all cases.',7,60),(361,'The allocation of authentication information to access system components used to provide the cloud service to internal and external users of the cloud provider and system components that are involved in automated authorisation processes of the cloud provider is done in an orderly manner that ensures the confidentiality of the information. If passwords are used as authentication information, their confidentiality is ensured by the following procedures, as far as technically possible: \n\n- Users can initially create the password themselves or must change an initial password when logging on to the system component for the first time. An initial password loses its validity after a maximum of 14 days.\n\n- When creating passwords, compliance with the password specifications (cf. IDM-12) is enforced as far as technically possible.\n\n- The user is informed about changing or resetting the password.\n\n- The server-side storage takes place using cryptographically strong hash functions.\n\nDeviations are evaluated by means of a risk analysis and mitigating measures derived from this are implemented.',2,61),(362,'The users sign a declaration in which they assure that they treat personal (or shared) authentication information confidentially and keep it exclusively for themselves (within the members of the group).',3,61),(363,'Argon2i, for example, is suitable for using a password hash function.\n\nInsofar as this is legally binding, declarations can be signed using an electronic signature.',4,61),(364,'-',5,61),(365,'yes',6,61),(366,'If the implementation is enforced by appropriate system configuration (automated control), the status or the last change of the configuration can be checked regularly.',7,61),(367,'System components in the Cloud Service Provider\'s area of responsibility that are used to provide the cloud service, authenticate users of the Cloud Service Provider\'s internal and external employees as well as system components that are involved in the Cloud Service Provider\'s automated authorisation processes. Access to the production environment requires two-factor or multi-factor authentication. Within the production environment, user authentication takes place through passwords, digitally signed certificates or procedures that achieve at least an equivalent level of security. If digitally signed certificates are used, administration is carried out in accordance with the Guideline for Key Management (cf. CRY-01). The password requirements are derived from a risk assessment and documented, communicated and provided in a password policy according to SP-01. Compliance with the requirements is enforced by the configuration of the system components, as far as technically possible.',2,62),(368,'Access to the non-production environment requires two-factor or multi-factor authentication. Within the non-production environment, users are authenticated using passwords, digitally signed certificates, or procedures that provide at least an equivalent level of security.',3,62),(369,'-',4,62),(370,'-',5,62),(371,'yes',6,62),(372,'If the implementation is enforced by appropriate system configuration (automated control), the status of the configuration or its last change can be checked regularly.',7,62),(373,'Policies and instructions with technical and organisational safeguards for encryption procedures and key management are documented, communicated and provided according to SP-01, in which the following aspects are described:\n\n- Usage of strong encryption procedures and secure network protocols that correspond to the state-of-the-art;\n\n- Risk-based provisions for the use of encryption which are aligned with the data classification schemes and consider the communication channel, type, strength and quality of the encryption;\n\n- Requirements for the secure generation, storage, archiving, retrieval, distribution, withdrawal and deletion of the keys; and \n\n- Consideration of relevant legal and regulatory obligations and requirements.',2,63),(374,'-',3,63),(375,'The state-of-the-art of strong encryption procedures and secure network protocols is specified in the following BSI Technical Guidelines valid at the given time: \n\n- BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths;\n\n- BSI TR-02102-2 Cryptographic Mechanisms: Use of Transport Layer Security (TLS);\n\n- BSI TR-02102-3 Cryptographic Mechanisms: Use of Internet Protocol Security (IPSec) and Internet Key Exchange (IKEv2); and\n\n- BSI TR-02102-4 Cryptographic Mechanisms: Use of Secure Shell (SSH).',4,63),(376,'-',5,63),(377,'partially',6,63),(378,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,63),(379,'The Cloud Service Provider has established procedures and technical measures for strong encryption and authentication for the transmission of data of cloud customers over public networks.',2,64),(380,'The Cloud Service Provider has established procedures and technical measures for strong encryption and authentication for the transmission of all data.',3,64),(381,'When transmitting data with normal protection requirements within the Cloud Service Provider’s infrastructure, encryption is not mandatory provided that the data is not transmitted via public networks. In this case, the non-public environment of the Cloud Service Provider can generally be deemed trusted. The protocols TLS 1.2 and TLS 1.3 are currently regarded as strong, state-of-the-art transport encryptions, in each case in combination with Perfect Forward Secrecy. The specific configuration should comply with the recommendations of the (current) version of the BSI Technical Guideline TR-02102-2 \"Cryptographic Procedures: Recommendations and key lengths. Part 2 - Use of Transport Layer Security (TLS)\". Generally, the use of wildcard certificates is not considered a secure procedure.\n\nThe basic criterion for the transmission cloud customers\' data, relates to e.g. the sending of electronic messages via public networks.',4,64),(382,'Cloud customers ensure through suitable controls for those parts of the cloud service under their responsibility, that their data is transmitted over encrypted connections in accordance with the respective protection requirements.',5,64),(383,'partially',6,64),(384,'The procedures and technical measures for encrypting data during transmission are configured centrally. This configuration rarely changes. Therefore, a continuous audit would not be sensible, as only changes to this configuration would have to be checked. However, the system status can be audited continuously. This also applies to the additional criterion.',7,64),(385,'The Cloud Service Provider has established procedures and technical safeguards to encrypt cloud customers\' data during storage. The private keys used for encryption are known only to the cloud customer in accordance with applicable legal and regulatory obligations and requirements. Exceptions follow a specified procedure. The procedures for the use of private keys, including any exceptions, must be contractually agreed with the cloud customer.',2,65),(386,'The private keys used for encryption are known to the customer exclusively and without exception in accordance with applicable legal and regulatory obligations and requirements.',3,65),(387,'An exception to the requirement that keys are known only to the cloud customers may be the use of a master key by the Cloud Service Provider. If the Cloud Service Provider established a procedure to use a master key, the Cloud Service Provider must perform sample-based checks regarding the suitability and effectiveness of the procedure, on a regular basis. This criterion does not apply to data that cannot be encrypted for the provision of the cloud service for functional reasons.',4,65),(388,'Cloud customers ensure through suitable controls for those parts of the cloud service under their responsibility (e. g. virtual machines within an IaaS solution), that their data is encrypted during storage in accordance with the respective protection requirements.',5,65),(389,'partially',6,65),(390,'The encryption of data of cloud customers is configured centrally; therefore, it is only suitable for continuous auditing to a limited extent. Exceptions to the encryption of data according to a specified procedure and the coordination of this with cloud customers should be documented and approved. This, too, is only suitable to a limited extent for continuous auditing, as these exceptions are decided on a case-by-case basis and do not occur at a high enough frequency. In a continuous audit, the system status can be queried to determine whether the encryption is active and whether the approved exceptions are being adhered to.',7,65),(391,'Procedures and technical safeguards for secure key management in the area of responsibility of the Cloud Service Provider include at least the following aspects: \n\n- Generation of keys for different cryptographic systems and applications;\n\n- Issuing and obtaining public-key certificates;\n\n- Provisioning and activation of the keys;\n\n- Secure storage of keys (separation of key management system from application and middleware level) including description of how authorised users get access;\n\n- Changing or updating cryptographic keys including policies defining under which conditions and in which manner the changes and/or updates are to be realised;\n\n- Handling of compromised keys; \n\n- Withdrawal and deletion of keys; and \n\n- If pre-shared keys are used, the specific provisions relating to the safe use of this procedure are specified separately.',2,66),(392,'-',3,66),(393,'Keys should be withdrawn or deleted e.g. in the event of compromise or employee changes. The Cloud Service Provider protects the keys which are created and inserted into the cloud service by the cloud customers according to the same criteria as the keys created by the Cloud Service Provider.',4,66),(394,'-',5,66),(395,'partially',6,66),(396,'For procedures and technical measures for key management to take into account the required aspects, these aspects must be implemented in the corresponding configuration. These configurations are rarely changed and only these changes would have to be audited continuously. However, the system status could be reviewed and, in the event of irregularities, indicated and documented.',7,66),(397,'Based on the results of a risk analysis carried out according to OIS-06, the Cloud Service Provider has implemented technical safeguards which are suitable to promptly detect and respond to network-based attacks on the basis of irregular incoming or outgoing traffic patterns and/or Distributed Denial- of-Service (DDoS) attacks. Data from corresponding technical protection measures implemented is fed into a comprehensive SIEM (Security Information and Event Management) system, so that (counter) measures regarding correlating events can be initiated. The safeguards are documented, communicated and provided in accordance with SP-01.',2,67),(398,'Technical measures ensure that no unknown (physical or virtual) devices join the Cloud Service Provider\'s (physical or virtual) network (e.g. MACSec according to IEEE 802.1X:2010).',3,67),(399,'Network-based attacks can be conducted e.g. with MAC spoofing and ARP poisoning attacks. Technical measures to prevent unknown physical or virtual devices from joining a physical or virtual network can be based on e.g. MACSec according to IEEE 802.1X:2010.',4,67),(400,'Cloud customers ensure through suitable controls for parts of the cloud service under their responsibility (e.g. virtual machines within an IaaS solution), that they detect and respond to network-based attacks based on anomalous inbound and outbound traffic patterns (e.g. MAC spoofing and ARP poisoning attacks) and/or Distributed Denial of Service (DDoS), in a timely manner.',5,67),(401,'yes',6,67),(402,'The technical protective measures are suitable for continuous auditing, but are rarely changed. However, the data fed into the overall SIEM system and the detection of correlating events are suitable for continuous auditing. This data can be evaluated automatically and continuously, as can the monitoring of correlating events.',7,67),(403,'Specific security requirements are designed, published and provided for establishing connections within the Cloud Service Provider\'s network. The security requirements define for the Cloud Service Provider\'s area of responsibility: \n\n- in which cases the security zones are to be separated and in which cases cloud customers are to be logically or physically segregated;\n\n- which communication relationships and which network and application protocols are permitted in each case;\n\n- how the data traffic for administration and monitoring is segregated from each on network level;\n\n- which internal, cross-location communication is permitted and;\n\n- which cross-network communication is allowed',2,68),(404,'-',3,68),(405,'Cross-location communication can be realised for e.g. individual regions or data centres via e.g. WAN, LAN, VPN, RAS.',4,68),(406,'-',5,68),(407,'no',6,68),(408,'The required security requirements are centrally documented and rarely changed. Continuous auditing is not practical.',7,68),(409,'A distinction is made between trusted and untrusted networks. Based on a risk assessment, these are separated into different security zones for internal and external network areas (and DMZ, if applicable). Physical and virtualised network environments are designed and configured to restrict and monitor the established connection to trusted or untrusted networks according to the defined security requirements.\n\nThe entirety of the conception and configuration undertaken to monitor the connections mentioned is assessed in a risk-oriented manner, at least annually, with regard to the resulting security requirements.\n\nIdentified vulnerabilities and deviations are subject to risk assessment in accordance with the risk management procedure (cf. OIS-06) and follow-up measures are defined and tracked (cf. OPS-18).\n\nAt specified intervals, the business justification for using all services, protocols, and ports is reviewed. The review also includes the justifications for compensatory measures for the use of protocols that are considered insecure.',2,69),(410,'-',3,69),(411,'The review of the security requirements depends on the measures implemented to design the networks. For example, monitoring and reviewing firewall rules or log files for abnormalities, as well as visual inspections of physical network components for changes.',4,69),(412,'Cloud customers ensure through suitable controls that the virtual networks within the cloud service for which they are responsible are designed, configured and documented in accordance with their network security requirements (e.g. logical segmentation of the cloud customer\'s organisational units).',5,69),(413,'yes',6,69),(414,'If the business justification and the regular review of the monitoring concept are documented in a standardised way, these processes can be evaluated automatically. Thus, a continuous audit can be conducted. The separation of the networks is suitable for continuous auditing as well, since the status of the separation can be continuously audited here.',7,69),(415,'Each network perimeter is controlled by security gateways. The system access authorisation for cross-network access is based on a security assessment based on the requirements of the cloud customers.',2,70),(416,'Each network perimeter is controlled by redundant and highly-available security gateways.',3,70),(417,'Cross-network access is access from one network to another network via a defined network perimeter.',4,70),(418,'Cloud customers ensure through suitable controls that access is controlled according to their protection needs by security gateways on the perimeters of the virtual networks within the cloud service for which they are responsible.',5,70),(419,'yes',6,70),(420,'If the control of the network perimeters is documented (e.g. by logs), these logs can be evaluated automatically. This offers the possibility of a continuous audit for this part of the criterion. If the security evaluation for access authorisations is carried out in a standardised form at the Cloud Service Provider, this can also be evaluated automatically. In this case, a continuous audit for the second part of the criterion would also be possible.',7,70),(421,'There are separate networks for the administrative management of the infrastructure and for the operation of management consoles. These networks are logically or physically separated from the cloud customer\'s network and protected from unauthorised access by multi-factor authentication (cf. IDM-09). Networks used by the Cloud Service Provider to migrate or create virtual machines are also physically or logically separated from other networks',2,71),(422,'-',3,71),(423,'-',4,71),(424,'-',5,71),(425,'no',6,71),(426,'A continuous audit is not practical since infrastructure components and the logical and physical separation of the networks are implemented initially and a continuous audit of these components may require a system status, but it is difficult to test all aspects continuously.',7,71),(427,'Data traffic of cloud customers in jointly used network environments is segregated on network level according to a documented concept to ensure the confidentiality and integrity of the data transmitted.',2,72),(428,'In the case of IaaS/PaaS, the secure segregation is ensured by physically separated networks or by means of strongly encrypted VLANs. For the definition of strong encryption, the technical guideline TR02102 of the BSI must be considered.',3,72),(429,'If the suitability and effectiveness of the logical segmentation cannot be assessed with sufficient certainty (e.g. due to a complex implementation), evidence can also be provided based on audit results of expert third parties (e.g. security audits to validate the concept). The segregation of stored and processed data is subject of the criterion OPS-25. For the secure segmentation of jointly used resources for web applications which are provided as SaaS, the session ID in the basic level should: \n\n- be generated randomly and have an adequate entropy of at least 128 Bit (16 characters) in order to withstand the educated guessing of the session ID (for example, by means of a bruteforce attack);\n\n- be adequately protected for transmission and client-side storage; and\n\n- have limited validity (timeout) which is as short as possible, based on the requirements for the use of the web application.\n\nAfter successful authentication via an insecure communication channel (HTTP), a secure communication channel (HTTPS) is to be used. \n\nWith IaaS/PaaS, secure segregation is ensured by physically separated networks or strong encryption of the networks. For the definition of strong encryption, the technical guideline TR02102 of the BSI must be considered (cf. CRY-01). \n\nIf the Cloud Service Provider does not use shared network environments for cloud customers and instead uses a physical segregation, the basic criterion is not applicable.',4,72),(430,'Cloud customers ensure through suitable controls for those parts of the cloud service under their responsibility that virtual networks are designed, configured and documented in accordance with their network security requirements (e.g. logical segmentation of organizational units).',5,72),(431,'no',6,72),(432,'The logical segregation of cloud customer network traffic at the network level is centrally configured and rarely changed. Thus, a continuous audit is not beneficial, since no highly frequented automated query can be performed to support the continuous audit.',7,72),(433,'The documentation of the logical structure of the network used to provision or operate the Cloud Service, is traceable and up-to-date, in order to avoid administrative errors during live operation and to ensure timely recovery in the event of malfunctions in accordance with contractual obligations. The documentation shows how the subnets are allocated and how the network is zoned and segmented. In addition, the geographical locations in which the cloud customers\' data is stored are indicated.',2,73),(434,'-',3,73),(435,'Zoning is a segmentation of the subnets with a firewall implemented at the network perimeters.',4,73),(436,'-',5,73),(437,'no',6,73),(438,'The documentation of the logical structure of the network is rarely changed and is stored centrally. Therefore, a continuous audit is not effective. However, a continuous audit could return the date of the last change to the documentation.',7,73),(439,'Policies and instructions with technical and organisational safeguards in order to protect the transmission of data against unauthorised interception, manipulation, copying, modification, redirection or destruction are documented, communicated and provided according to SP-01. The policy and instructions establish a reference to the classification of information (cf. AM-06).',2,74),(440,'-',3,74),(441,'A safeguard against unauthorised interception, manipulation, copying, modification, redirection or destruction of data during transmission is e.g. the use of transport encryption according to CRY-02.',4,74),(442,'Cloud customers ensure through suitable controls that the transmitted data transmitted to the cloud service is protected against tampering, copying, modifying, redirecting or deleting in accordance with their protection needs.',5,74),(443,'no',6,74),(444,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,74),(445,'The cloud service can be accessed by other cloud services or IT systems of cloud customers through documented inbound and outbound interfaces. Further, the interfaces are clearly documented for subject matter experts on how they can be used to retrieve the data.\n\nCommunication takes place through standardised communication protocols that ensure the confidentiality and integrity of the transmitted information according to its protection requirements. Communication over untrusted networks is encrypted according to CRY-02.\n\nThe type and scope of the documentation on the interfaces is geared to the needs of the cloud customers\' subject matter experts in order to enable the use of these interfaces. The information is maintained in such a way that it is applicable for the cloud service\'s version which is intended for productive use.',2,75),(446,'-',3,75),(447,'-',4,75),(448,'Cloud customers ensure through suitable controls that the interfaces provided (and their security) are adequate for its protection requirements by means of appropriate checks before the start of use of the cloud service and each time the interfaces are changed.',5,75),(449,'partially',6,75),(450,'The defined input and output interfaces of cloud services are rarely changed. Therefore, it is sufficient for the auditor to test these interfaces, the communication of potential changes, and the associated documentation as part of the recurring audit.\n\nIn a continuous audit, however, the system status of the interfaces could be queried and evaluated, continuously.',7,75),(451,'In contractual agreements, the following aspects are defined with regard to the termination of the contractual relationship, insofar as these are applicable to the cloud service:\n\n- Type, scope and format of the data the Cloud Service Provider provides to the cloud customer;\n\n- Definition of the timeframe, within which the Cloud Service Provider makes the data available to the cloud customer \n\n- Definition of the point in time as of which the Cloud Service Provider makes the data inaccessible to the cloud customer and deletes these; and\n\n- The cloud customers\' responsibilities and obligations to cooperate for the provision of the data.\n\nThe definitions are based on the needs of subject matter experts of potential customers who assess the suitability of the cloud service with regard to a dependency on the Cloud Service Provider as well as legal and regulatory requirements.',2,76),(452,'The design of the aspects is based on legal and regulatory requirements in the environment of the Cloud Service Provider. The Cloud Service Provider identifies the requirements regularly, at least once a year, and checks these for actuality and adjusts the contractual agreements accordingly.',3,76),(453,'The type and scope of the data and the responsibilities for its provision depend on the service model of the cloud service or the services and functions provided:\n\nIn the case of IaaS and PaaS, the cloud customer is generally responsible for extracting and backing up the data which is stored in the cloud service before termination of the contractual relationship (cf. complementary requirement).\n\nThe Cloud Service Provider\'s responsibility is typically limited to the provision of data for the configuration of the infrastructure or platform that the cloud customer has set up within its environment (e.g. configuration of networks, images of virtual machines and containers).\n\nWith SaaS, the cloud customer typically relies on export functions provided by the Cloud Service Provider. Data created by the cloud customer should be available in the same format as stored in the cloud service. Other data, including relevant log files and metadata, should be available in an applicable standard format, such as CSV, JSON or XML.\n\nIn Germany, legal requirements for retention can be found, for example, in the German Tax Code (§147 AO) and the German Commercial Code (§257 HGB). These provide for a retention obligation of six or ten years.',4,76),(454,'Cloud customers ensure through suitable controls that the data to which they are contractually entitled is requested from the Cloud Service Provider at the end of the contract or accessed via defined interfaces (the type and scope of the data correspond to the contractual agreements that were concluded prior to the use of the cloud service) and that it is stored in accordance with the legal requirements applicable to this data.',5,76),(455,'no',6,76),(456,'The Cloud Service Provider should have a standardised template for its contracts. Hence, all contracts are structured according to the same pattern. \n\nThis template is rarely changed. Therefore, a continuous audit is not practical. Therefore, it is sufficient to test the contracts and the associated template as part of the recurring audit.',7,76),(457,'The Cloud Service Provider\'s procedures for deleting the cloud customers\' data upon termination of the contractual relationship ensure compliance with the contractual agreements (cf. PI-02).\n\nThe deletion includes data in the cloud customer\'s environment, metadata and data stored in the data backups.\n\nThe deletion procedures prevent recovery by forensic means.',2,77),(458,'-',3,77),(459,'Suitable methods for data deletion are e.g. multiple overwriting or deletion of the encryption key.',4,77),(460,'Cloud customers ensure through suitable controls that the legal and regulatory framework (e.g. legal requirements for storage and deletion) is identified and that the deletion of their data is initiated accordingly.',5,77),(461,'yes',6,77),(462,'The complete deletion of the data is documented by the Cloud Service Provider using logs. The logs should include which data has been deleted so that it can be tracked whether data has been deleted in the cloud customer\'s environment, metadata and data in the backup.\n\nThe auditor can then perform an automated evaluation of these logs. The auditor can also check the system status of the procedure for deleting the data.\n\nThe fact that the deletion procedures prevent recovery by forensic means does not have to be audited continuously. The deletion procedures used can be tested as part of the recurring audit.',7,77),(463,'Policies and instructions with technical and organisational measures for the secure development of the cloud service are documented, communicated and provided in accordance with SP-01.\n\nThe policies and instructions contain guidelines for the entire life cycle of the cloud service and are based on recognised standards and methods with regard to the following aspects:\n\n- Security in Software Development (Requirements, Design, Implementation, Testing and Verification); \n\n- Security in software deployment (including continuous delivery); and\n\n- Security in operation (reaction to identified faults and vulnerabilities).',2,78),(464,'In procurement, products are preferred which have been certified according to the \"Common Criteria for Information Technology Security Evaluation\" (short: Common Criteria - CC) according Evaluation Assurance Level EAL 4. If non-certified products are to be procured for available certified products, a risk assessment is carried out in accordance with OIS-07.',3,78),(465,'The software provision can be carried out e.g. with Continuous Delivery methods.\n\nAccepted standards and methods are, for example:\n\n- ISO/IEC 27034; and\n\n- OWASP Secure Software Development Lifecycle (S-SDLC).',4,78),(466,'-',5,78),(467,'no',6,78),(468,'The contents of the policies and instructions for the proper development or procurement of information systems do not change at a high frequency. A continuous audit of this documentation is not practical. Therefore, the integration of these tests into the recurring audit is sufficient.',7,78),(469,'In the case of outsourced development of the cloud service (or individual system components), specifications regarding the following aspects are contractually agreed between the Cloud Service Provider and the outsourced development contractor:\n\n- Security in software development (requirements, design, implementation, tests and verifications) in accordance with recognised standards and methods;\n\n- Acceptance testing of the quality of the services provided in accordance with the agreed functional and non-functional requirements; and\n\n- Providing evidence that sufficient verifications have been carried out to rule out the existence of known vulnerabilities.',2,79),(470,'-',3,79),(471,'Outsourced development in the sense of the basic criterion refers to the development of system components used specifically for the cloud service by a contractor of the Cloud Service Provider. The development takes place according to the processes of the contractor.\n\nThe purchase of software available on the market as well as the integration of external employees into the processes of the Cloud Service Provider do not constitute outsourcing in the sense of this basic criterion.',4,79),(472,'-',5,79),(473,'no',6,79),(474,'An outsourced development of a Cloud Service Provider\'s cloud services and the associated contract creation and signing will not be performed with high frequency. Changes in contract structures are also rare. Therefore, a continuous audit in these cases is not effective.',7,79),(475,'Policies and instructions with technical and organisational safeguards for change management of system components of the cloud service within the scope of software deployment are documented, communicated and provided according to SP-01 with regard to the following aspects:\n\n- Criteria for risk assessment, categorisation and prioritisation of changes and related requirements for the type and scope of testing to be performed, and necessary approvals for the development/implementation of the change and releases for deployment in the production environment by authorised personnel or system components;\n\n- Requirements for the performance and documentation of tests;\n\n- Requirements for segregation of duties during development, testing and release of changes;\n\n- Requirements for the proper information of cloud customers about the type and scope of the change as well as the resulting obligations to cooperate in accordance with the contractual agreements;\n\n- Requirements for the documentation of changes in system, operational and user documentation; and\n\n- Requirements for the implementation and documentation of emergency changes that must comply with the same level of security as normal changes.',2,80),(476,'-',3,80),(477,'Changes in the sense of the basic criterion are those that can lead to changes in the configuration, functionality or security of system components of the cloud service in the production environment. This includes changes to the infrastructure as well as to the source code.\n\nIf individual changes are combined in a new release, update, patch or comparable software object for the purpose of software provisioning, this software object is deemed to be a change within the meaning of the basic criterion, but not the individual changes contained therein.\n\nChanges to the existing network configuration must also undergo a specified procedure, as they are necessary for effective segregation of cloud customers.\n\nPersonnel and system components receive authorisation to approve changes in accordance with the requirements for access and access authorisations (cf. IDM-01) via a specified procedure (cf. IDM-02).Relevant information includes descriptions of e.g. new functions.\n\nThe cloud customer\'s obligations to cooperate can define that, e.g. the cloud customer must carry out certain tests.',4,80),(478,'-',5,80),(479,'no',6,80),(480,'The contents of the policies and instructions for managing and modifying system components are not changed at a high frequency. A continuous audit of this documentation is therefore not effective. It is sufficient to integrate these tests into the recurring audit.',7,80),(481,'The Cloud Service Provider provides a training program for regular, target group-oriented security training and awareness for internal and external employees on standards and methods of secure software development and provision as well as on how to use the tools used for this purpose. The program is regularly reviewed and updated with regard to the applicable policies and instructions, the assigned roles and responsibilities and the tools used.',2,81),(482,'-',3,81),(483,'-',4,81),(484,'-',5,81),(485,'yes',6,81),(486,'The Cloud Service Provider can automatically check the valid policies and instructions, the assigned roles and responsibilities and the tools used and document the results in logs.\n\nThese logs can be automatically evaluated by the auditor and thus a continuous audit can be carried out.',7,81),(487,'In accordance with the applicable policies (cf. DEV-03), changes are subjected to a risk assessment with regard to potential effects on the system components concerned and are categorised and prioritised accordingly.',2,82),(488,'In accordance with the contractual agreements, meaningful information about the occasion, time, duration, type and scope of the change is submitted to authorised bodies of the cloud customer so that they can carry out their own risk assessment before the change is made available in the production environment. Regardless of the contractual agreements, this is done for changes that have the highest risk category based on their risk assessment.',3,82),(489,'-',4,82),(490,'-',5,82),(491,'yes',6,82),(492,'The evaluation of changes in releases can be standardised and automated by the Cloud Service Provider. If this evaluation is carried out in standardised and digital form (tickets/logs), an automated evaluation can be carried out by the auditor.',7,82),(493,'Changes to the cloud service are subject to appropriate testing during software development and deployment.\n\nThe type and scope of the tests correspond to the risk assessment. The tests are carried out by appropriately qualified personnel of the Cloud Service Provider or by automated test procedures that comply with the state-of-the-art. Cloud customers are involved into the tests in accordance with the contractual requirements.\n\nThe severity of the errors and vulnerabilities identified in the tests, which are relevant for the deployment decision, is determined according to defined criteria and actions for timely remediation or mitigation are initiated.',2,83),(494,'-',3,83),(495,'The errors and vulnerabilities identified in tests can be assessed, for example, according to the Common Vulnerability Scoring System (CVSS).',4,83),(496,'Where changes are to be tested by the cloud customers in accordance with the contractual agreements prior to deployment in the production environment, the cloud customers ensure through suitable controls that the tests are performed appropriately to identify errors. In particular, this includes timely execution of the tests by qualified personnel in accordance with the conditions specified by the Cloud Service Provider.',5,83),(497,'yes',6,83),(498,'If the tests are carried out automatically, the execution and associated results can be documented in logs. These logs can then be read continuously by the auditor.\n\nMeasures for the elimination of identified vulnerabilities can also be documented and carried out in a standardised manner, so that continuous auditing is possible.',7,83),(499,'System components and tools for source code management and software deployment that are used to make changes to system components of the cloud service in the production environment are subject to a role and rights concept according to IDM-01 and authorisation mechanisms. They must be configured in such a way that all changes are logged and can therefore be traced back to the individuals or system components executing them.',2,84),(500,'-',3,84),(501,'-',4,84),(502,'-',5,84),(503,'yes',6,84),(504,'The changes to the role and rights concept according to IDM-01 are documented in logs by the Cloud Service Provider. Thus, an automatic and continuous evaluation of these logs can be carried out. Irregularities are detected and logged.\n\nThe auditor can perform a continuous audit by automatically evaluating the logs and logged irregularities.',7,84),(505,'Version control procedures are set up to track dependencies of individual changes and to restore affected system components back to their previous state as a result of errors or identified vulnerabilities.',2,85),(506,'Version control procedures provide appropriate safeguards to ensure that the integrity and availability of cloud customer data is not compromised when system components are restored back to their previous state.',3,85),(507,'-',4,85),(508,'-',5,85),(509,'yes',6,85),(510,'The procedures for version control of the Cloud Service Provider and, if necessary, resetting to previous states can be automated. This must be documented in logs. An automatic evaluation of these logs makes continuous auditing possible.',7,85),(511,'Authorised personnel or system components of the Cloud Service Provider approve changes to the cloud service based on defined criteria (e.g. test results and required approvals) before these are made available to the cloud customers in the production environment.\n\nCloud customers are involved in the release according to contractual requirements.',2,86),(512,'-',3,86),(513,'The definitions for criterion DEV-03 apply.',4,86),(514,'Where changes are to be approved by the cloud customers in accordance with the contractual agreements before they are made available in the production environment, the cloud customers ensure through suitable controls that authorised and qualified personnel receives the information made available, assesses the impact on the ISMS framework and decides on the approval in accordance with the conditions specified by the Cloud Service Provider.',5,86),(515,'yes',6,86),(516,'Verification that all tests have been completed, successful and approved by an authorised body can be automated by the Cloud Service Provider and documented in logs.\n\nThese logs can then be evaluated automatically and continuously by the auditor.',7,86),(517,'Production environments are physically or logically separated from test or development environments to prevent unauthorised access to cloud customer data, the spread of malware, or changes to system components. Data contained in the production environments is not used in test or development environments in order not to compromise their confidentiality.',2,87),(518,'-',3,87),(519,'-',4,87),(520,'-',5,87),(521,'yes',6,87),(522,'Since fundamental changes in test and development environments, which would affect the physical or logical separation, are rarely made, a continuous audit is not practical. The respective environments must be tested initially and then audited again if changes are made.',7,87),(523,'Policies and instructions for controlling and monitoring third parties (e.g. service providers or suppliers) whose services contribute to the provision of the cloud service are documented, communicated and provided in accordance with SP-01 with respect to the following aspects:\n\n- Requirements for the assessment of risks resulting from the procurement of third-party services;\n\n- Requirements for the classification of third parties based on the risk assessment by the Cloud Service Provider and the determination of whether the third party is a subcontractor (cf. Supplementary Information);\n\n- Information security requirements for the processing, storage or transmission of information by third parties based on recognised industry standards;\n\n- Information security awareness and training requirements for staff;\n\n- applicable legal and regulatory requirements;\n\n- Requirements for dealing with vulnerabilities, security incidents and malfunctions;\n\n- Specifications for the contractual agreement of these requirements;\n\n- Specifications for the monitoring of these requirements; and\n\n- Specifications for applying these requirements also to service providers used by the third parties, insofar as the services provided by these service providers also contribute to the provision of the cloud service.',2,88),(524,'Subservice organisations of the Cloud Service Provider are contractually obliged to provide regular reports by independent auditors on the suitability of the design and operating effectiveness of their service-related internal control system.\n\nThe reports include the complementary subservice organisations that are required, together with the controls of the Cloud Service Provider, to meet the applicable basic criteria of BSI C5 with reasonable assurance.\n\nIn case no reports can be provided, the Cloud Service Provider agrees appropriate information and audit rights to assess the suitability and effectiveness of the service-related internal control system, including the complementary controls, by qualified personnel.',3,88),(525,'Reports by independent auditors on the suitability of the design and operating effectiveness of their service-related internal control system are, for example, attestation reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5.\n\nQualified personnel works, for example, in the Cloud Service Provider\'s internal audit department or is commissioned by the Cloud Service Provider in form of expert third parties, such as audit firms, and may hold relevant certifications such as \"Certified Internal Auditor (CIA)\". \n\nThe complementary controls at the sub-service provider are necessary in order to, together with the controls of the Cloud Service Provider, fulfil the applicable C5 criteria with reasonable assurance.\n\nApplicable legal and regulatory requirements may exist, for example, in the areas of data protection, intellectual property rights or copyright.\n\nIf legal or regulatory requirements provide for a regulation deviating from these criteria for the control of subcontractors, these regulations remain unaffected by the C5 criteria.',4,88),(526,'-',5,88),(527,'partially',6,88),(528,'Regarding the availability of the documentation, a continuous audit is not practical, since the associated processes and steps can be tested in a recurring audit. \n\nA continuous audit of whether changes have been made to the policies is possible, provided that these changes are documented by the Cloud Service Provider and can be evaluated. However, an automated audit of the meaningfulness of the changes is difficult to implement.\n\nRegarding the proof that a communication/provision has taken place, a continuous audit is considered possible.\n\nFor this, the Cloud Service Provider would have to realise the notification based on a system (e.g. based on tickets or notes in the respective service provider contract).',7,88),(529,'Service providers and suppliers of the Cloud Service Provider undergo a risk assessment in accordance with the policies and instructions for the control and monitoring of third parties prior to contributing to the delivery of the cloud service. The adequacy of the risk assessment is reviewed regularly, at least annually, by qualified personnel of the Cloud Service Provider during service usage.\n \nThe risk assessment includes the identification, analysis, evaluation, handling and documentation of risks with regard to the following aspects:\n\n- Protection needs regarding the confidentiality, integrity, availability and authenticity of information processed, stored or transmitted by the third party; \n\n- Impact of a protection breach on the provision of the cloud service;\n\n- The Cloud Service Provider\'s dependence on the service provider or supplier for the scope, complexity and uniqueness of the service purchased, including the consideration of possible alternatives.',2,89),(530,'-',3,89),(531,'-',4,89),(532,'-',5,89),(533,'no',6,89),(534,'Continuous auditing of the risk assessment is not effective, as only its regular execution could be audited automatically, but not the content. \n\nIn addition, the specified frequency of at least one year is covered by the recurring audit. Risk assessments are rarely carried out dynamically and therefore do not often change during the year.',7,89),(535,'The Cloud Service Provider maintains a directory for controlling and monitoring the service providers and suppliers who contribute services to the delivery of the cloud service. The following information is maintained in the directory:\n\n- Company name;\n\n- Address;\n\n- Locations of data processing and storage;\n\n- Responsible contact person at the service provider/supplier;\n\n- Responsible contact person at the cloud service provider;\n\n- Description of the service;\n\n- Classification based on the risk assessment;\n\n- Beginning of service usage; and\n\n- Proof of compliance with contractually agreed requirements.\n\nThe information in the list is checked at least annually for completeness, accuracy and validity.',2,90),(536,'-',3,90),(537,'It is not necessary to maintain a single central register in order to fulfil the basic criterion.',4,90),(538,'-',5,90),(539,'no',6,90),(540,'An ad-hoc completeness checks on the specified criteria can safely take place automatically, as can a comparison of changed data with relevant company databases. This can be set up by the Cloud Service Provider. \nThe auditor can then examine deviations as part of the recurring audit.\nHowever, due to the frequency and the completeness analysis, a continuous audit is not efficient due to the large effort required.',7,90),(541,'The Cloud Service Provider monitors compliance with information security requirements and applicable legal and regulatory requirements in accordance with policies and instructions concerning controlling and monitoring of third-parties.\n\nMonitoring includes a regular review of the following evidence to the extent that such evidence is to be provided by third parties in accordance with the contractual agreements:\n\n- reports on the quality of the service provided;\n\n- certificates of the management systems\' compliance with international standards;\n\n- independent third-party reports on the suitability and operating effectiveness of their service-related internal control systems; and\n\n- Records of the third parties on the handling of vulnerabilities, security incidents and malfunctions.\n\nThe frequency of the monitoring corresponds to the classification of the third party based on the risk assessment conducted by the Cloud Service Provider (cf. SSO-02). The results of the monitoring are included in the review of the third party\'s risk assessment.\n\nIdentified violations and deviations are subjected to analysis, evaluation and treatment in accordance with the risk management procedure (cf. OIS-07).',2,91),(542,'The procedures for monitoring compliance with the requirements are supplemented by automatic procedures relating to the following aspects:\n\n- Configuration of system components;\n\n- Performance and availability of system components;\n\n- Response time to malfunctions and security incidents; and\n\n- Recovery time (time until completion of error handling).\n\nIdentified violations and discrepancies are automatically reported to the responsible personnel or system components of the Cloud Service Provider for prompt assessment and action.',3,91),(543,'Evidence for the review of the suitability and operating effectiveness of the service-related internal control system include reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5.\n\nIn the evidence provided by the third parties, the Cloud Service Provider reviews, for example, the following aspects and, if necessary, incorporates the findings into the risk assessment in order to derive and initiate mitigating actions:\n\n- The scope and the validity respectively the period covered by the evidence;\n\n- For attestation reports: Qualifications of the opinion, included deviations/other observations including management\'s response and corresponding controls to be implemented and executed by the Cloud Service Provider;\n\n- Disclosed subcontractors incl. any changes among those (e.g. additional subcontractor); and\n\n- Stated security incidents.',4,91),(544,'Cloud customers ensure through suitable controls that they stay informed about subservice organisations of their Cloud Service Provider (e.g. on the basis of the information in the C5 attestation report) and decide on the basis of their need for protection of their data processed and stored in the cloud service whether further action should be taken to monitor and check these subservice organisations.',5,91),(545,'partially',6,91),(546,'A continuous audit of some of the required evidence, such as the reviews conducted and their results, can be performed once the Cloud Service Provider documents the associated steps using a tool.\n\nHowever, a review on content-level, such as reviewing the response to risk assessments and violations of service provider requirements, is difficult as it requires a semantic understanding. As a result, at least parts of the criterion are suitable for continuous audit.',7,91),(547,'The Cloud Service Provider has defined and documented exit strategies for the purchase of services where the risk assessment of the service providers and suppliers regarding the scope, complexity and uniqueness of the purchased service resulted in a very high dependency (cf. Supplementary Information).\n\nExit strategies are aligned with operational continuity plans and include the following aspects:\n\n- Analysis of the potential costs, impacts, resources and timing of the transition of a purchased service to an alternative service provider or supplier;\n\n- Definition and allocation of roles, responsibilities and sufficient resources to perform the activities for a transition;\n\n- Definition of success criteria for the transition;\n\n- Definition of indicators for monitoring the performance of services, which should initiate the withdrawal from the service if the results are unacceptable.',2,92),(548,'-',3,92),(549,'A very high dependency can be assumed in the following situations in particular:\n\n- The purchased service is absolutely required for the provision of the cloud service – this situation is given when the Cloud Service Provider:\n\n    - provides the cloud service from data centres operated by third parties; and\n\n    - provides a SaaS service and uses the IaaS or PaaS of another Cloud Service Provider.\n\n- The service cannot be obtained within one month from an alternative service provider or supplier, as: \n\n- It is unique on the market and no other supplier can deliver it;\n\n- It is strongly individualised by the service provider or supplier and/or the Cloud Service Provider;\n\n- It cannot be supplied by any other provider in the required quality of service; and\n\n- It requires specific knowledge that is only/mainly available to the current service provider or supplier and not to the Cloud Service Provider.',4,92),(550,'-',5,92),(551,'no',6,92),(552,'The existence of individual exit strategies is not a practical test item for continuous audit.',7,92),(553,'Policies and instructions with technical and organisational safeguards are documented, communicated and provided in accordance with SP-01 to ensure a fast, effective and proper response to all known security incidents.\n\nThe Cloud Service Provider defines guidelines for the classification, prioritisation and escalation of security incidents and creates interfaces to the incident management and business continuity management.\n\nIn addition, the Cloud Service Provider has set up a \"Computer Emergency Response Team\" (CERT), which contributes to the coordinated resolution of occurring security incidents.\n\nCustomers affected by security incidents are informed in a timely and appropriate manner.',2,93),(554,'There are instructions as to how the data of a suspicious system can be collected in a conclusive manner in the event of a security incident. In addition, there are analysis plans for typical security incidents and an evaluation methodology so that the collected information does not lose its evidential value in any subsequent legal assessment.',3,93),(555,'-',4,93),(556,'Cloud customers ensure through suitable controls that they receive notifications from the Cloud Service Provider about security incidents that affect them and that these notifications are forwarded in a timely manner to the responsible departments for handling so that an appropriate response can be triggered',5,93),(557,'partially',6,93),(558,'A continuous audit of the documented policies and instructions is not effective because they are not subject to high frequency changes. Thus, the audit of the policies and instructions can be performed in the recurring audit.\n\nSimilarly, setting up a CERT is not suitable for continuous auditing as it is an organisational body and does not require continuous monitoring.\n\nThe timely communication of security incidents to affected customers can be covered by a continuous audit approach. In addition, the Cloud Service Provider can document not only the security incidents by means of logs, but also that they have been communicated to the customer via e-mail, for example. The fact that there was communication to affected customers for every security incident can thus be evaluated automatically and continuously by the auditor. \n\nHowever, this procedure can be combined with the audit approach of further requirements of Security Incident Management.',7,93),(559,'Subject matter experts of the Cloud Service Provider, together with external security providers where appropriate, classify, prioritise and perform root-cause analyses for events that could constitute a security incident.',2,94),(560,'The Cloud Service Provider simulates the identification, analysis and defence of security incidents and attacks at least once a year through appropriate tests and exercises (e.g. Red Team training).',3,94),(561,'-',4,94),(562,'-',5,94),(563,'yes',6,94),(564,'The Cloud Service Provider documents all security incidents in digital form, which contains information about the classification, prioritisation and root cause analysis of the incidents. The root cause analysis should be standardised to facilitate continuous auditing.\n\nAn automatic and continuous evaluation of these security incidents can then be carried out by the auditor by excluding the logs or tickets produced and testing whether the security incident has been classified and prioritised and whether these steps have been carried out based on a standardised root cause analysis. The continuous audit thus provides a constant statement as to whether security incidents have been correctly recorded, classified and subjected to a root cause analysis.',7,94),(565,'After a security incident has been processed, the solution is documented in accordance with the contractual agreements and the report is sent to the affected customers for final acknowledgement or, if applicable, as confirmation.',2,95),(566,'The customer can either actively approve solutions or the solution is automatically approved after a certain period.\n\nInformation on security incidents or confirmed security breaches is made available to all affected customers.\n\nThe contract between the Cloud Service Provider and the cloud customer regulates which data is made available to the cloud customer for his own analysis in the event of security incidents.',3,95),(567,'-',4,95),(568,'Cloud customers ensure through suitable controls that they receive notifications from the Cloud Service Provider about security incident that affect them and their resolution and that these notifications are forwarded promptly to the entity responsible for handling them so that an appropriate response can be made.',5,95),(569,'yes',6,95),(570,'In the logs or tickets that document the security incidents (Cf. SIM-03), the Cloud Service Provider also describes the solution pursued to eliminate the incident. In addition, the Cloud Service Provider also documents the confirmation to the customer.\n\nThe auditor can then automatically and continuously read out whether the documented security incidents have been resolved and whether a solution has been documented. The same applies to the communication of the resolution of the incidents to affected customers. If this is not the case, the unresolved security incident can be documented as the output value of the continuous audit.',7,95),(571,'The Cloud Service Provider informs employees and external business partners of their obligations. If necessary, they agree to or are contractually obliged to report all security events that become known to them and are directly related to the cloud service provided by the Cloud Service Provider to a previously designated central office of the Cloud Service Provider promptly.\n\nIn addition, the Cloud Service Provider communicates that \"false reports\" of events that do not subsequently turn out to be incidents do not have any negative consequences.',2,96),(572,'-',3,96),(573,'-',4,96),(574,'Cloud customers ensure through suitable controls that identified security events, which the Cloud Service Provider is required to process, are communicated promptly to previously designated, responsible personnel.\n\nThe identification of such security events is supported by suitable controls (cf. complementary criterion for OPS-10).',5,96),(575,'partially',6,96),(576,'The Cloud Service Provider should inform its employees and external business partners about their obligations in a standardised and digital format. This obligation usually occurs when the employee joins the company or the business relationship.\n\nThis enables the auditor to automatically and continuously audit whether all employees and external business partners are notified of their obligations by automatically testing whether the clause, if any, is included in the contract when the contract is signed.',7,96),(577,'Mechanisms are in place to measure and monitor the type and scope of security incidents and to report them to support agencies. The information obtained from the evaluation is used to identify recurrent or significant incidents and to identify the need for further protection.',2,97),(578,'-',3,97),(579,'Supporting bodies may be external service providers or government agencies such as the BSI.',4,97),(580,'Cloud customers ensure through suitable controls that they include into their ISMS the findings and measures related to previous security incidents reported by the Cloud Service Provider. The cloud customers evaluate whether and which supporting measures they might take on their side.',5,97),(581,'no',6,97),(582,'The existing mechanisms for measuring the type and scope of security incidents are rarely changed. As a result, continuous auditing is not effective. In addition, in some cases it can be a manual task carried out by employees to identify recurring incidents or incidents with significant consequences and to develop associated protective measures.',7,97),(583,'The top management (or a member of the top management) of the Cloud Service Provider is named as the process owner of business continuity and emergency management and is responsible for establishing the process within the company as well as ensuring compliance with the guidelines. They must ensure that sufficient resources are made available for an effective process.\n\nPeople in management and other relevant leadership positions demonstrate leadership and commitment to this issue by encouraging employees to actively contribute to the effectiveness of continuity and emergency management.',2,98),(584,'-',3,98),(585,'-',4,98),(586,'-',5,98),(587,'no',6,98),(588,'The responsibilities for continuity and emergency management processes are initially named and rarely changed afterwards. Therefore, a continuous audit is not effective. \n\nA continuous audit can, however, return the date of the last revision of the guidelines for continuity and emergency management.',7,98),(589,'Policies and instructions to determine the impact of any malfunction to the cloud service or enterprise are documented, communicated and made available in accordance with SP-01. The following aspects are considered as minimum:\n\n- Possible scenarios based on a risk analysis;\n\n- Identification of critical products and services\n\n- Identify dependencies, including processes (including resources required), applications, business partners and third parties;\n\n- Capture threats to critical products and services;\n\n- Identification of effects resulting from planned and unplanned malfunctions and changes over time;\n\n- Determination of the maximum acceptable duration of malfunctions;\n\n- Identification of restoration priorities;\n\n- Determination of time targets for the resumption of critical products and services within the maximum acceptable time period (RTO);\n\n- Determination of time targets for the maximum reasonable period during which data can be lost and not recovered (RPO); and\n\n- Estimation of the resources needed for resumption.',2,99),(590,'-',3,99),(591,'Scenarios to be considered according to the basic criterion are, for example, the loss of personnel, buildings, infrastructure and service providers.',4,99),(592,'Cloud customers ensure through suitable controls that the scenarios for a failure of the cloud service or the Cloud Service Provider are sufficiently considered in the context of their business impact analysis.',5,99),(593,'partially',6,99),(594,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,99),(595,'Based on the business impact analysis, a single framework for operational continuity and business plan planning will be implemented, documented and enforced to ensure that all plans are consistent. Planning is based on established standards, which are documented in a \"Statement of Applicability\".\n\nBusiness continuity plans and contingency plans take the following aspects into account:\n\n- Defined purpose and scope with consideration of the relevant dependencies;\n\n- Accessibility and comprehensibility of the plans for persons who are to act accordingly;\n\n- Ownership by at least one designated person responsible for review, updating and approval;\n\n- Defined communication channels, roles and responsibilities including notification of the customer;\n\n- Recovery procedures, manual interim solutions and reference information (taking into account prioritisation in the recovery of cloud infrastructure components and services and alignment with customers);\n\n- Methods for putting the plans into effect;\n\n- Continuous process improvement; and\n\n- Interfaces to Security Incident Management.',2,100),(596,'-',3,100),(597,'The consistency of plans according to the basic criterion must also be maintained when different locations are used.',4,100),(598,'Cloud customers ensure through suitable controls that the results of the Business Impact Analysis are sufficiently considered when planning the operational continuity and the business plan in order to provide for the effects of a failure of the cloud service or Cloud Service Provider.\n\nCloud customers ensure through suitable controls that the availability of the cloud service, its recovery time according to the BCM plan and the data loss of the cloud service are consistent with their own availability requirements and tolerable data loss.',5,100),(599,'no',6,100),(600,'The introduction of the framework and the business plan based on a business impact analysis is a manual process of the Cloud Service Provider.\n\nA continuous audit is not practical. The plans can be tested as part of the recurring audit.',7,100),(601,'The business impact analysis, business continuity plans and contingency plans are reviewed, updated and tested on a regular basis (at least annually) or after significant organisational or environmental changes. Tests involve affected customers (tenants) and relevant third parties. The tests are documented and results are taken into account for future operational continuity measures.',2,101),(602,'In addition to the tests, exercises are also carried out which, among other things, have resulted in scenarios from security incidents that have already occurred in the past.',3,101),(603,'Tests are primarily conducted at the operational level and are aimed at operational target groups. Tests include e.g.:\n\n- Test of technical precautionary measures;\n\n- Functional tests; and\n\n- Plan review.\nExercises also take place on a tactical and strategic level. These include e.g.:\n\n- Plan meeting;\n\n- Staff exercise;\n\n- Command post exercise;\n\n- Communication and alerting exercise;\n\n- Simulation of scenarios; and\n\n- Emergency or full exercise.\n\nAfter a completed exercise:\n\n- Review and possible adaptation of the existing alarm plan.\nRelevant third parties are in particular service providers and suppliers of the Cloud Service Provider who contribute to the provision of the cloud service (cf. basic criteria SSO-02 and SSO-05).',4,101),(604,'Cloud customers ensure through suitable controls that measures to prevent the impact of a cloud service or Cloud Service Provider outage are regularly reviewed, updated, tested and exercised. The Cloud Service Provider is involved in the tests and exercises in accordance with the contractual agreements.\n\nCloud customers ensure through suitable controls that the results of the Cloud Service Provider\'s BCM tests and exercises are incorporated into their own BCM and that they are fully appreciated with regard to ensuring the customer\'s operational continuity.\n\nIn tests and exercises that involve the customer and therefore require own measures on the customer side, cloud customers ensure that the appropriate measures for coping with the scenario are practiced and tested by means of suitable BCM controls.',5,101),(605,'partially',6,101),(606,'Implementing the tests of the operational continuity plans in an annual cycle does not make a continuous audit of the entire criterion effective. The effort for both Cloud Service Providers and auditors to automate and continuously test this process would be higher than the results.\n\nHowever, it is possible to continuously audit whether a test was carried out within the required time span. To do this, the Cloud Service Provider must document in a standardised manner that and when a test was carried out.',7,101),(607,'The legal, regulatory, self-imposed and contractual requirements relevant to the information security of the cloud service as well as the Cloud Service Provider\'s procedures for complying with these requirements are explicitly defined and documented.',2,102),(608,'-',3,102),(609,'The Cloud Service Provider\'s documentation may refer to the following requirements, among others:\n\n- Requirements for the protection of personal data (e.g. EU General Data Protection Regulation);\n\n- Compliance requirements based on contractual obligations with cloud customers (e.g. ISO/IEC 27001, SOC 2, PCI-DSS);\n\n- generally accepted accounting principles (e.g. in accordance with HGB or IFRS);\n\n- Requirements regarding access to data and auditability of digital documents (e.g. according to GDPdU); and\n\n- Other laws (e.g. according to BSIG or AktG).',4,102),(610,'-',5,102),(611,'no',6,102),(612,'A continuous audit of contract specifications, regulations and their documentation does not seem to be effective. In this case, the test within the recurring audit is sufficient.\n\nA continuous audit could assist in giving the date of the last audit of the criteria.',7,102),(613,'Policies and instructions for planning and conducting audits are documented, communicated and made available in accordance with SP-01 and address the following aspects:\n\n- Restriction to read-only access to system components in accordance with the agreed audit plan and as necessary to perform the activities;\n\n- Activities that may result in malfunctions to the cloud service or breaches of contractual requirements are performed during scheduled maintenance windows or outside peak periods; and\n\n- Logging and monitoring of activities.',2,103),(614,'The Cloud Service Provider grants its cloud customers contractually guaranteed information and audit rights.',3,103),(615,'-',4,103),(616,'Cloud customers ensure through suitable controls that appropriate responses are made to malfunctions to the cloud service through such audits.\n\nTo the extent that contractually guaranteed information and audit rights exist, the cloud customers ensure through suitable controls that these rights are designed and executed in accordance with their own requirements.',5,103),(617,'partially',6,103),(618,'A policy can change ad-hoc. However, the continuous audit of policies is only partially feasible as the only attributes that can be tested are the last change date and the status of review or approval, as far as this information is stored in a system. The content of a policy can hardly be tested automatically.',7,103),(619,'Subject matter experts check the compliance of the information security management system at regular intervals, at least annually, with the relevant and applicable legal, regulatory, self-imposed or contractual requirements (cf. COM-01) as well as compliance with the policies and instructions (cf. SP-01) within their scope of responsibility (cf. OIS-01) through internal audits (cf. § 9.3 of ISO/IEC 27001).\n\nIdentified vulnerabilities and deviations are subject to risk assessment in accordance with the risk management procedure (cf. OIS-06) and follow-up measures are defined and tracked (cf. OPS-18).',2,104),(620,'Internal audits are supplemented by procedures to automatically monitor applicable requirements of policies and instructions with regard to the following aspects:\n\n- Configuration of system components to provide the cloud service within the Cloud Service Provider\'s area of responsibility;\n\n- Performance and availability of these system components;\n\n- Response time to malfunctions and security incidents;\n\n- Recovery time (time to completion of error handling);\n\nIdentified vulnerabilities and deviations are automatically reported to the appropriate Cloud Service Provider’s subject matter experts for immediate assessment and action.\n \nCloud customers can view compliance with selected contractual requirements in real time.',3,104),(621,'Subject matter experts operate, e.g., in the Cloud Service Provider\'s internal revision department or expert third parties commissioned by the Cloud Service Provider, such as auditing companies, and may hold relevant certifications such as \"Certified Internal Auditor (CIA)\". \n\nWith regard to ISMS compliance, see Section 9.3 of ISO/IEC 27001.',4,104),(622,'-',5,104),(623,'yes',6,104),(624,'The regular performance of an internal audit of the ISMS can be set up as part of compliance monitoring. For this purpose, the results of the internal audit must be digitally documented, as well as the individual audit steps.\n\nA continuous audit of this internal audit is not effective but can only be considered after compliance monitoring has been set up. \n\nThe continuous audit can then supply the date of the last audit as the output value.',7,104),(625,'The top management of the Cloud Service Provider is regularly informed about the information security performance within the scope of the ISMS in order to ensure its continued suitability, adequacy and effectiveness. The information is included in the management review of the ISMS at is performed at least once a year.',2,105),(626,'-',3,105),(627,'The top management is a natural person or group of people who make final decisions for the institution and are responsible for these.\n\nThe aspects to be dealt with in the management review of the ISMS are listed in Section 9.3 of ISO / IEC 27001.',4,105),(628,'-',5,105),(629,'partially',6,105),(630,'The actual transmission of information to the Cloud Service Provider\'s management can be logged and automated. However, the testing of the contents of the communication and the that these have also been included in the management assessment must still be carried out within the regular audit.',7,105),(631,'Investigation requests from government agencies are subjected to a legal assessment by subject matter experts of the Cloud Service Provider. The assessment determines whether the government agency has an applicable and legally valid legal basis and what further steps need to be taken.',2,106),(632,'-',3,106),(633,'-',4,106),(634,'Cloud customers ensure through suitable controls that the type and scope of government investigation requests and the associated disclosure of their own data has been dealt with in their own risk management and that the use of the cloud service only takes place when this risk has been deemed acceptable.',5,106),(635,'no',6,106),(636,'Although a continuous audit of the performance of the assessment and its documentation is conceivable, a continuous audit is not practical. Rather the criterion aims at the qualification of the auditing personnel as well as the process behind it, which is both subject to manual audit.',7,106),(637,'The Cloud Service Provider informs the affected Cloud Customer(s) without undue delay, unless the applicable legal basis on which the government agency is based prohibits this or there are clear indications of illegal actions in connection with the use of the Cloud Service.',2,107),(638,'-',3,107),(639,'This does not affect other legal or regulatory requirements that requires earlier information for cloud customers.',4,107),(640,'Cloud customers ensure through suitable controls that such notifications are received and legally checked according to their own specifications and possibilities.',5,107),(641,'partially',6,107),(642,'For internal process monitoring at the Cloud Service Provider and facilitation of the audit, a continuous audit of the period between receipt of the request and information of the customers is conceivable.\n\nHowever, as this depends on local legal basis, the effort to establish this in the respective regions will be quite high.\n\nIf a transaction processing system is implemented at the Cloud Service Provider, at least the process in this system can be continuously audited.',7,107),(643,'Access to or disclosure of cloud customer data in connection with government investigation requests is subject to the proviso that the Cloud Service Provider\'s legal assessment has shown that an applicable and valid legal basis exists and that the investigation request must be granted on that basis.',2,108),(644,'-',3,108),(645,'-',4,108),(646,'-',5,108),(647,'yes',6,108),(648,'To the extent that a separate role is assigned to the investigator in order to gain access to the data, the prerequisites specified in the request can be entered and checked by the system and linked to the assignment of the investigator role.\n\nA continuous query can then be made to ensure that the role was only granted if the prerequisites defined by the system were fulfilled. Deviations can be audited manually.',7,108),(649,'The Cloud Service Provider\'s procedures for setting up access to or disclosure of cloud customer data as part of an investigation requests, ensure that government agencies only have access to the data they need to investigate.\n\nIf no clear limitation of the data is possible, the Cloud Service Provider anonymises or pseudonymises the data so that government agencies can only assign it to those cloud customers who are subject of the investigation request.',2,109),(650,'-',3,109),(651,'-',4,109),(652,'-',5,109),(653,'partially',6,109),(654,'A separate role for the investigator is to be provided (cf. also INQ-03). It is conceivable that certain data types for this role may not be visible, pseudonymised or anonymised, or that data of customers that are not part of the investigation may be excluded. \n\nHowever, this requires a manual effort in the configuration and assignment of the investigator role.\n\nUnder these conditions, however, a continuous audit of whether and to what extent the investigator had access to data is conceivable.',7,109),(655,'Basic Criterion\nThe Cloud Service Provider provides cloud customers with guidelines and recommendations for the secure use of the cloud service provided. The information contained therein is intended to assist the cloud customer in the secure configuration, installation and use of the cloud service, to the extent applicable to the cloud service and the responsibility of the cloud user.\n\nThe type and scope of the information provided will be based on the needs of subject matter experts of the cloud customers who set information security requirements, implement them or verify the implementation (e.g. IT, Compliance, Internal Audit). The information in the guidelines and recommendations for the secure use of the cloud service address the following aspects, where applicable to the cloud service:\n\n- Instructions for secure configuration;\n\n- Information sources on known vulnerabilities and update mechanisms;\n\n- Error handling and logging mechanisms;\n\n- Authentication mechanisms;\n\n- Roles and rights concept including combinations that result in an \nelevated risk; and\n\n- Services and functions for administration of the cloud service by privileged users. \n\nThe information is maintained so that it is applicable to the cloud service provided in the version intended for productive use.',2,110),(656,'-',3,110),(657,'-',4,110),(658,'Cloud customers ensure through suitable controls that the Cloud Service Provider\'s information is used to derive policies, concepts and measures for the secure configuration and use (according to their own risk assessment) of the cloud service. Compliance with these policies, concepts and measures is checked. Changes to the information are promptly assessed for their impact on these documents and any necessary changes are implemented.',5,110),(659,'partially',6,110),(660,'The provision of information from the Cloud Service Provider to cloud customers can only be audited continuously to a limited extent. For example, the Cloud Service Provider can make the guidelines and recommendations available via its internal customer portal, which makes a continuous audit only partially effective.\n\nHere, only an audit for completeness and the last modification date is conceivable, although a discussion of the content of the changes is not effective. For this, a semantic evaluation would be necessary.',7,110),(661,'The Cloud Service Provider applies appropriate measures to check the cloud service for vulnerabilities which might have been integrated into the cloud service during the software development process.\n\nThe procedures for identifying such vulnerabilities are part of the software development process and, depending on a risk assessment, include the following activities:\n\n- Static Application Security Testing;\n\n- Dynamic Application Security Testing;\n\n- Code reviews by the Cloud Service Provider\'s subject matter experts; and\n\n- Obtaining information about confirmed vulnerabilities in software libraries provided by third parties and used in their own cloud service.\n\nThe severity of identified vulnerabilities is assessed according to defined criteria and measures are taken to immediately eliminate or mitigate them.',2,111),(662,'The procedures for identifying such vulnerabilities also include annual code reviews or security penetration tests by qualified external third parties.',3,111),(663,'Known vulnerabilities in externally related system components (e.g. operating systems) used for the development and provision of the cloud service but not going through the Cloud Service Provider\'s software development process are the subject of criteria OPS-23 (Management of vulnerabilities, malfunctions and errors - open vulnerability assessment).',4,111),(664,'-',5,111),(665,'yes',6,111),(666,'The Cloud Service Provider automatically checks its cloud services for vulnerabilities. This check is documented in a standardised digital form.\n\nBy auditing this documentation, the auditor verifies, whether the Cloud Service Provider has performed a vulnerability scan. In addition, the severity of the identified vulnerabilities can be integrated into this continuous audit if the defined criteria and their application are standardised and machine-readable.\n\nThe information on identified and/or repaired vulnerabilities can also be transferred directly to the affected customer and thus increased transparency can be achieved.',7,111),(667,'The Cloud Service Provider operates or refers to a daily updated online register of known vulnerabilities that affect the Cloud Service Provider and assets provided by the Cloud Service Provider that the cloud customers have to install, provide or operate themselves under the customers responsibility.\n\nThe presentation of the vulnerabilities follows the Common Vulnerability Scoring System (CVSS).\n\nThe online register is easily accessible to any cloud customer. The information contained therein forms a suitable basis for risk assessment and possible follow-up measures on the part of cloud users. \n\nFor each vulnerability, it is indicated whether software updates (e.g. patch, update) are available, when they will be rolled out and whether they will be deployed by the Cloud Service Provider, the cloud customer or both of them together.',2,112),(668,'Assets provided by the Cloud Service Provider, which must be installed, provided or operated by cloud users within their area of responsibility, are equipped with automatic update mechanisms. After approval by the respective cloud user, software updates can be rolled out in such a way that they can be distributed to all affected users without human interaction.',3,112),(669,'Assets provided by the Cloud Service Provider that cloud customers have to install, deploy or operate themselves in their area of responsibility are for example local software clients and apps as well as tools for integrating the cloud service.\n\nIf the cloud service relies on other cloud services, this registry has to incorporate or refer to the vulnerabilities of those other cloud services in order for this criterion to be met.',4,112),(670,'Cloud customers ensure through suitable controls that the information in this register is incorporated sufficiently quickly into their own risk management, evaluated and, if necessary, taken into account in their own area of responsibility.',5,112),(671,'yes',6,112),(672,'A continuous audit includes, above all, whether the information is updated daily. The distribution of software updates must be documented by the Cloud Service Provider (logs). This documentation can then be automatically and continuously evaluated by the auditor to ensure that the software used on assets in the cloud users\' area of responsibility is up-to-date.',7,112),(673,'The cloud service provided is equipped with error handling and logging mechanisms. These enable cloud users to obtain security-related information about the security status of the cloud service as well as the data, services or functions it provides.\n\nThe information is detailed enough to allow cloud users to check the following aspects, insofar as they are applicable to the cloud service:\n\n- Which data, services or functions available to the cloud user within the cloud service, have been accessed by whom and when (Audit Logs);\n\n- Malfunctions during processing of automatic or manual actions; and\n\n- Changes to security-relevant configuration parameters, error handling and logging mechanisms, user authentication, action authorisation, cryptography, and communication security.\n\nThe logged information is protected from unauthorised access and modification and can be deleted by the Cloud Customer.\n\nIf the cloud customer is responsible for the activation or type and scope of logging, the Cloud Service Provider must provide appropriate logging capabilities.',2,113),(674,'Cloud users can retrieve security-related information via documented interfaces which are suitable for further processing this information as part of their Security Information and Event Management (SIEM).',3,113),(675,'In the case of a SaaS service for secure data exchange, the terms data, services or functions would mean, for example, the logging of all read or write accesses to the stored files and their metadata.',4,113),(676,'If the cloud service is equipped with error handling and logging mechanisms, cloud customers must activate these and configure them according to defined requirements. The cloud customer must incorporate his own information security management for this purpose.',5,113),(677,'yes',6,113),(678,'The information about the security status of cloud services and further data provided can be read automatically and continuously, as these must be made available to cloud users in digital form. \n\nThis enables continuous auditing.',7,113),(679,'The Cloud Service Provider provides authentication mechanisms that can force strong authentication (e.g. two or more factors) for users, IT components or applications within the cloud users\' area of responsibility.\nThese authentication mechanisms are set up at all access points that allow users, IT components or applications to interact with the cloud service. \n\nFor privileged users, IT components or applications, these authentication mechanisms are enforced.',2,114),(680,'The cloud service offers out-of-band authentication (OOB), in which the factors are transmitted via different channels (e.g. Internet and mobile network).',3,114),(681,'IT components in the sense of this criterion are independently usable objects with external interfaces that can be connected with other IT components.\n\nAccess points in the sense of this criterion are those that can be accessed by users, IT components or applications via networks (for users, for example, the login screen on the publicly accessible website of the Cloud Service Provider).\n\nMulti-factor authentication can be performed with cryptographic certificates, smart cards or tokens, for example.',4,114),(682,'Cloud customers ensure through suitable controls that the authentication mechanisms offered by the cloud service are used in accordance with the customer\'s identity and authorisation management requirements.',5,114),(683,'partially',6,114),(684,'The implementation of authentication mechanisms for users takes place via configurations that are only adapted at a low frequency. Thus, continuous auditing is only partially effective here.\n\nNevertheless, it is conceivable to monitor the status of the underlying authentication system, but only deviations from target configurations can be checked. Whether these deviations are desired or not must still be recorded in a manual audit.',7,114),(685,'To protect confidentiality, availability, integrity and authenticity during interactions with the cloud service, a suitable session management system is used that at least corresponds to the state-of-the-art and is protected against known attacks. Mechanisms are implemented that invalidate a session after it has been detected as inactive. The inactivity can be detected by time measurement. In this case, the time interval can be configured by the Cloud Service Provider or - if technically possible - by the cloud customer.',2,115),(686,'-',3,115),(687,'Known attacks include manipulation, forgery, session takeover, denial of service attacks, enveloping, replay and null cipher attacks.',4,115),(688,'Cloud customers can use appropriate controls to ensure that they are using the session management protection features of the cloud service in accordance with their own ISMS. They also set the time period after which a session becomes invalid according to their own ISMS specifications.',5,115),(689,'partially',6,115),(690,'The use of Session Management is controlled by configurations. These configurations are changed or adapted at a low frequency, so continuous auditing is only partially effective.\n\nNevertheless, monitoring the status of the underlying authentication system is conceivable, but only deviations from target configurations can be checked. Whether these deviations are normal must still be tested in a manual audit.',7,115),(691,'If passwords are used as authentication information for the cloud service, their confidentiality is ensured by the following procedures:\n\n- Users can initially create the password themselves or must change an initial password when logging in to the cloud service for the first time. An initial password loses its validity after a maximum of 14 days.\n\n- When creating passwords, compliance with the length and complexity requirements of the Cloud Service Provider (cf. IDM-09) or the cloud customer is technically enforced.\n\n- The user is informed about changing or resetting the password.\n\n- The server-side storage takes place using state-of-the-art cryptographically strong hash functions in combination with at least 32-bit long salt values.',2,116),(692,'-',3,116),(693,'The state-of-the-art regarding cryptographically strong hash functions is described in the current version of the Technical Guideline TR-02102-1 \"Cryptographic mechanisms: Recommendations and key lengths\" of the BSI. In version 2019-01 of this guideline these were:\n\n- SHA-256, SHA-512/256, SHA-384, SHA-512; and\n\n- SHA3-256, SHA3-384, SHA3-512.',4,116),(694,'Cloud customers ensure through suitable controls that they use sufficiently secure passwords (cf. IDM-09) according to their own assessment and that the risks of unauthorised access associated with their own choice are borne.',5,116),(695,'no',6,116),(696,'Compliance with security policies for password assignment is configured centrally and adjusted at a low frequency. A continuous audit is therefore only of limited use.',7,116),(697,'The Cloud Service Provider provides cloud users with a roles and rights concept for managing access rights. It describes rights profiles for the functions provided by the cloud service.\n\nThe rights profiles are suitable for enabling cloud users to manage access authorisations and permissions in accordance with the principle of least-privilege and how it is necessary for the performance of tasks (\"need-to-know principle\") and to implement the principle of functional separation between operational and controlling functions (\"separation of duties\").',2,117),(698,'-',3,117),(699,'In IaaS, a role and rights concept would describe, among other things, the rights profiles for the following functions of the cloud service:\n\n- Administration of the states of virtual machines (start, \npause, stop) as well as for their migration or monitoring;\n\n- Management of available images that can be used to create virtual machines; and\n\n- Management of virtual networks (e.g. configuration of virtual routers and switches).',4,117),(700,'Cloud customers ensure through suitable controls that:\n\n- the granting of permissions to users in their area of responsibility is subject to authorisation; and\n\n- the appropriateness of the assigned authorisations is regularly reviewed and authorisations are adjusted or withdrawn in a timely manner in the event of necessary changes (e.g. employee resignation).',5,117),(701,'partially',6,117),(702,'The existence of a roles and rights concept in the form of a configuration in the system can be monitored. However, it should be noted that, regarding the content of this concept, only deviations from target configurations can be checked. Whether these deviations are desired or not must still be recorded in a manual audit.',7,117),(703,'Access to the functions provided by the cloud service is restricted by access controls (authorisation mechanisms) that verify whether users, IT components, or applications are authorised to perform certain actions.\n\nThe Cloud Service Provider validates the functionality of the authorisation mechanisms before new functions are made available to cloud users and in the event of changes to the authorisation mechanisms of existing functions (cf. DEV-06). The severity of identified vulnerabilities is assessed according to defined criteria based on industry standard metrics (e.g. Common Vulnerability Scoring System) and measures for timely resolution or mitigation are initiated. Vulnerabilities that have not been fixed are listed in the online register of known vulnerabilities (cf. PSS-02).',2,118),(704,'Access controls are attribute-based to enable granular and contextual checks against multiple attributes of a user, IT component, or application (e.g., role, location, authentication method).',3,118),(705,'-',4,118),(706,'-',5,118),(707,'yes',6,118),(708,'The changes to authorisation mechanisms and the identification of vulnerabilities are documented in a standardised manner by the Cloud Service Provider. This documentation can be automated and continuously audited. If the elimination of the vulnerabilities and their prioritisation also takes place in a standardised form (according to standardised criteria), these points can be integrated into the continuous audit.',7,118),(709,'If the Cloud Service offers functions for software-defined networking (SDN), the confidentiality of the data of the cloud user is ensured by suitable SDN procedures.\n\nThe Cloud Service Provider validates the functionality of the SDN functions before providing new SDN features to cloud users or modifying existing SDN features. Identified defects are assessed and corrected in a risk-oriented manner.',2,119),(710,'-',3,119),(711,'This criterion is typically not applicable to the SaaS service model.\n\nSuitable SDN methods for increasing confidentiality are, for example, L2 overlay networking (tagging) or tunnelling/encapsulation.',4,119),(712,'-',5,119),(713,'yes',6,119),(714,'Validation during provision and modification of SDN functions and identification of defects can be documented in a standardised manner by the Cloud Service Provider.\n\nThis documentation can be audited continuously and automatically by the auditor.\n\nThe \"marking\" of the data is carried out by a configuration that has to be tested centrally. A continuous audit of all transmitted data packets would not be effective here. \n\nThe status of the configuration can be continuously audited against a target value, a content evaluation must be carried out manually.',7,119),(715,'If cloud customers operate virtual machines or containers with the cloud service, the Cloud Service Provider must ensure the following aspects:\n\n- The cloud customer can restrict the selection of images of virtual machines or containers according to his specifications, so that users of this cloud customer can only launch the images or containers released according to these restrictions.\n\n- If the Cloud Service Provider provides images of virtual machines or containers to the Cloud Customer, the Cloud Service Provider appropriately inform the Cloud Customer of the changes made to the previous version.\n\n- In addition, these images provided by the Cloud Service Provider are hardened according to generally accepted industry standards.',2,120),(716,'At startup and runtime of virtual machine or container images, an integrity check is performed that detects image manipulations and reports them to the cloud customer.',3,120),(717,'This criterion is typically not applicable to the SaaS service model.\n\nGenerally accepted industry standards are, for example, the Security Configuration Benchmark of the Centre for Internet Security (CIS) or the corresponding modules in the BSI IT-Grundschutz-Kompendium.',4,120),(718,'Cloud customers use appropriate controls to ensure that the images of virtual machines or containers they operate with the cloud service comply with their information security management requirements and that the results of the integrity checks at startup and at runtime are processed according to these requirements.',5,120),(719,'partially',6,120),(720,'These functions must be centrally audited at regular intervals, but not continuously. Therefore, it is sufficient to integrate this into the recurring audit.\n\nWith an agent system, it would be possible to continuously query the configurations of the individual virtual machines and thus compare them with the target image. This could also be set up on demand and thus become part of the control that takes over the integrity check.',7,120),(721,'The cloud customer is able to specify the locations (location/country) of the data processing and storage including data backups according to the contractually available options.\n\nThis must be ensured by the cloud architecture.',2,121),(722,'-',3,121),(723,'This criterion supplements the General Condition BC-01.\n\nThe cloud architecture must exist in such a way that it enables the technical design of the IT infrastructure to provide the cloud service in accordance with the data location specifications agreed with the customer.',4,121),(724,'Cloud customers ensure through suitable controls that, when selecting service providers and configuring the cloud service, they are informed about the available data processing and storage locations and, if there is a choice between different locations, that they select those that meet their own requirements.\n\nDepending on the use case and especially when using services of a Cloud Service Provider which is based in another country, cloud customers take the laws applicable to them into account when making their selection (e.g. when processing personal data; compliance with legal retention obligations for business documents, etc.).',5,121),(725,'yes',6,121),(726,'A continuous survey of the location of the data and the country from which the service is provided can be carried out automatically by the Cloud Service Provider.\n\nThis information can then be made available to the customer, for example on his dashboard or on request.',7,121),(727,'In the system description and the contractual agreements (e.g. service description), the Cloud Service Provider clearly provides comprehensible and transparent information on: \n\n- Its jurisdiction; and \n\n- System component locations, including its subcontractors, where the cloud customer\'s data is processed, stored and backed up.\n\nThe scope of information is based on the requirements of subject matter experts of the cloud customers who define information security requirements, implement them or check their effectiveness and assess the suitability of the cloud service from a legal and regulatory perspective (e.g. IT, compliance, internal audit).',2,122),(728,'If the processing, backup and storage of customer data takes place in different locations, this is to be described comprehensibly and transparently in the system description.',3,122),(729,'',4,122),(730,'',5,122),(731,'',6,122),(732,'',7,122),(733,'In contractual agreements (e.g. service description), the Cloud Service Provider provides comprehensible, binding and transparent information on: \n\n- Availability of the cloud service; \n\n- Categorisation and Prioritisation of incidents; \n\n- Response times for disruptions of regular operation according to the categorisation (time elapsed between the reporting and the resolution of the disruption by the Cloud Service Provider); \n\n- Recovery time (time elapsed until the incident has been resolved); and \n\n- Legal consequences of non-compliance. \n\nThe details are based on definitions that allow subject matter experts of the cloud customers to assess the Cloud service against their business requirements. \n\nThe system description describes where this information can be found. \n\nIf information on availability and remediation of disruptions represent average values that are not binding in individual cases, this is highlighted separately.',2,123),(734,'In addition to the reference in the system description where this information can be found, the information itself may also be an optional part of the report, e.g. in a section \"Other information provided by the legal representatives of the Cloud Service Provider\". The auditor does not provide an opinion on the information.',3,123),(735,'',4,123),(736,'',5,123),(737,'',6,123),(738,'',7,123),(739,'The Cloud Service Provider provides subject matter experts of the Cloud customers with comprehensible and transparent information on the following recovery parameters of the cloud service, if required: \n\n- Maximum tolerable downtime / Recovery Time Objective (RTO) \n\n- Maximum allowable data loss / Recovery Point Objective (RPO) \n\n- Recovery time to start emergency operation \n\n- Recovery level (capacity related to regular operation) \n\n- Restore time until normal operation \n\nThe information enables Cloud customers to evaluate the Cloud service as part of their own business impact analysis.',2,124),(740,'In addition to the reference in the system description where this information can be found, the information itself may also be an optional part of the report, e.g. in a section \"Other information provided by the legal representatives of the Cloud Service Provider\". The auditor does not provide an opinion on the information.',3,124),(741,'',4,124),(742,'',5,124),(743,'',6,124),(744,'',7,124),(745,'The Cloud provider provides subject matter experts of Cloud customers with comprehensible and transparent information on the availability of the data centres used to provide the Cloud service (including data centres operated by subcontractors), as needed. The information shows availability and downtime over one year according to industry standard classification schemes. The information enables Cloud customers to assess the Cloud service as part of their business impact analysis.',2,125),(746,'The Uptime Institute\'s Tier classification system is a classification customary in the industry. It defines the following levels (Tiers) for availability and downtime in relation to one year: \n\n- Tier I: 99.671 %; up to 28.8 hours cumulative downtime per year \n\n- Tier II: 99.741 %; up to 22.7 hours cumulative downtime per year \n\n- Tier III: 99.982 %; up to 1.6 hours cumulative downtime per year \n\n- Tier IV: 99.995 %; up to 25 minutes cumulative downtime per year \n\nIf there are requirements towards high availability of a data centre, the BSI HV benchmark, which provides the following availability classes (AC), is suitable: \n\n- AC 0: without availability requirements (~95%); up to 438 hours cumulative downtime per year \n\n- AC 1: normal availability (99%); up to 88 hours cumulative downtime per year \n\n- AC 2: high availability (99.9%); up to 9 hours cumulative downtime per year \n\n- AC 3: very high availability (99.99%); up to 53 minutes cumulative downtime per year \n\n- AC 4: highest availability (99.999%); up to 6 minutes cumulative downtime per year \n\n- AC 5: Disaster-tolerant \n\nThis information may be an optional part of the report, e.g. in a section \"Other information provided by the legal representatives of the Cloud provider\". The practitioner themselves do not provide an opinion on the information.',3,125),(747,'',4,125),(748,'',5,125),(749,'',6,125),(750,'',7,125),(751,'In the system description, the Cloud Service Provider provides comprehensible and transparent information on how investigation enquiries by government agencies for access to or disclosure of cloud customer data are handled. The information includes the following aspects: \n\n- Procedures to verify the legal basis of such enquiries; \n\n- Procedures for informing and involving the affected cloud customers upon receipt of such enquiries; \n\n- the ability of the affected Cloud customers to object; and \n\n- whether the Cloud Service Provider has the ability to decrypt encrypted data of the cloud customers in case of such requests and how this ability for access or disclosure is used. \n\nThe scope of the information corresponds to the needs of the subject matter experts of the Cloud customers who define specifications on information security, implement these or validate their implementation and assess the suitability of the cloud service from a legal and regulatory point of view (e.g. IT, compliance, internal audit).',2,126),(752,'The legal foundation on which these governmental services are based (e.g. law enforcement agencies, intelligence services) vary from region to region. In particular, the applicable jurisdiction at the locations where data of cloud customers is processed, stored, backed up and stored must be considered. \n\nIn Germany, such powers are governed by the laws of the German Federal Criminal Police Office (or the laws of the respective state offices), various procedural codes for courts and the laws for intelligence services (BNDG, BVerfSchG, respective laws on the constitutional protection offices of the federal states, MADG) and the G10 Act. \n\nIn other countries, other laws are relevant, and the cloud customer may only occasionally be aware of them from the media, e.g. the CLOUD Act (\"Clarifying Lawful Overseas Use of Data Act\") from the United States of America or the Cyber Security Law of the People\'s Republic of China. In conjunction with the other information on the cloud service, the cloud customer should be able to use this information to carry out a risk assessment assessing if and how these are relevant.',3,126),(753,'',4,126),(754,'',5,126),(755,'',6,126),(756,'',7,126),(757,'In the system description, the Cloud Service Provider provides comprehensible and transparent information on existing and valid certifications or attestations by independent third parties relating to the following aspects of the cloud service: \n\n- compliance of the management systems for information security, business continuity and quality with applicable international standards; \n\n- compliance with the European General Data Protection Regulation (GDPR); \n\n- the suitability and effectiveness of the internal control system in relation to the applicable criteria; and \n\n- certifications or attestations according to industry-specific requirements of cloud customers. \n\nTo the extent applicable for the certification or attestation, the following information are provided: \n\n- date of issuance;\n\n- issuing organisation; and\n\n- date or period of validity or coverage. \n\nThe scope of the information corresponds to the needs of the subject matter experts of the Cloud customers who define specifications on information security, implement these or validate their implementation and assess the suitability of the cloud service from a legal and regulatory point of view (e.g. IT, compliance, internal audit).',2,127),(758,'Transparency can be additionally increased by disclosing SLAs based on ISO/IEC 19086 or comparable standards.\n\nFulfilment of the General Condition does not require the Cloud Service Provider to hold a certification or attestation for all listed aspects.',3,127),(759,'',4,127),(760,'',5,127),(761,'',6,127),(762,'',7,127);
/*!40000 ALTER TABLE `OPTCOLUMNCONTENT` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `OPTCOLUMNTYPE`
--

DROP TABLE IF EXISTS `OPTCOLUMNTYPE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `OPTCOLUMNTYPE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `OPTCOLUMNTYPE`
--

LOCK TABLES `OPTCOLUMNTYPE` WRITE;
/*!40000 ALTER TABLE `OPTCOLUMNTYPE` DISABLE KEYS */;
INSERT INTO `OPTCOLUMNTYPE` VALUES (1,'shortString','A short String');
/*!40000 ALTER TABLE `OPTCOLUMNTYPE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `PROJECTTYPE`
--

DROP TABLE IF EXISTS `PROJECTTYPE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `PROJECTTYPE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `PROJECTTYPE`
--

LOCK TABLES `PROJECTTYPE` WRITE;
/*!40000 ALTER TABLE `PROJECTTYPE` DISABLE KEYS */;
INSERT INTO `PROJECTTYPE` VALUES (1,'BSI C5',NULL,0,_binary '');
/*!40000 ALTER TABLE `PROJECTTYPE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `PROJECTTYPE_OPTCOLUMN`
--

DROP TABLE IF EXISTS `PROJECTTYPE_OPTCOLUMN`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `PROJECTTYPE_OPTCOLUMN` (
  `optcolumns_id` bigint(20) NOT NULL,
  `projecttypes_id` bigint(20) NOT NULL,
  PRIMARY KEY (`projecttypes_id`,`optcolumns_id`),
  KEY `fk_optcolumn_optcolumn_projecttype_id` (`optcolumns_id`),
  CONSTRAINT `fk_optcolumn_optcolumn_projecttype_id` FOREIGN KEY (`optcolumns_id`) REFERENCES `OPTCOLUMN` (`id`),
  CONSTRAINT `fk_projecttype_optcolumn_optcolumn_id` FOREIGN KEY (`projecttypes_id`) REFERENCES `PROJECTTYPE` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `PROJECTTYPE_OPTCOLUMN`
--

LOCK TABLES `PROJECTTYPE_OPTCOLUMN` WRITE;
/*!40000 ALTER TABLE `PROJECTTYPE_OPTCOLUMN` DISABLE KEYS */;
INSERT INTO `PROJECTTYPE_OPTCOLUMN` VALUES (2,1),(3,1),(4,1),(5,1),(6,1);
/*!40000 ALTER TABLE `PROJECTTYPE_OPTCOLUMN` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `PROJECTTYPE_STATUSCOLUMN`
--

DROP TABLE IF EXISTS `PROJECTTYPE_STATUSCOLUMN`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `PROJECTTYPE_STATUSCOLUMN` (
  `statuscolumns_id` bigint(20) NOT NULL,
  `projecttypes_id` bigint(20) NOT NULL,
  PRIMARY KEY (`projecttypes_id`,`statuscolumns_id`),
  KEY `fk_statuscolumn_statuscolumn_projecttype_id` (`statuscolumns_id`),
  CONSTRAINT `fk_projecttype_statuscolumn_statuscolumn_id` FOREIGN KEY (`projecttypes_id`) REFERENCES `PROJECTTYPE` (`id`),
  CONSTRAINT `fk_statuscolumn_statuscolumn_projecttype_id` FOREIGN KEY (`statuscolumns_id`) REFERENCES `STATUSCOLUMN` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `PROJECTTYPE_STATUSCOLUMN`
--

LOCK TABLES `PROJECTTYPE_STATUSCOLUMN` WRITE;
/*!40000 ALTER TABLE `PROJECTTYPE_STATUSCOLUMN` DISABLE KEYS */;
INSERT INTO `PROJECTTYPE_STATUSCOLUMN` VALUES (1,1);
/*!40000 ALTER TABLE `PROJECTTYPE_STATUSCOLUMN` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `REQCATEGORY`
--

DROP TABLE IF EXISTS `REQCATEGORY`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `REQCATEGORY` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `shortcut` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=19 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `REQCATEGORY`
--

LOCK TABLES `REQCATEGORY` WRITE;
/*!40000 ALTER TABLE `REQCATEGORY` DISABLE KEYS */;
INSERT INTO `REQCATEGORY` VALUES (1,'Organisation of Information Security (OIS)','OIS','',10,_binary ''),(2,'Security Policies and Instructions (SP)','SP','',20,_binary ''),(3,'Personnel (HR)','HR','',30,_binary ''),(4,'Asset Management (AM)','AM','',40,_binary ''),(5,'Physical Security (PS)','PS','',50,_binary ''),(6,'Operations (OPS)','OPS','',60,_binary ''),(7,'Identity and Access Management (IDM)','IDM','',70,_binary ''),(8,'Cryptography and Key Management (CRY)','CRY','',80,_binary ''),(9,'Communication Security (COS)','COS','',90,_binary ''),(10,'Portability and Interoperability (PI)','PI','',100,_binary ''),(11,'Procurement, Development and Modification of Information Systems (DEV)','DEV','',110,_binary ''),(12,'Control and Monitoring of Service Providers and Suppliers (SSO)','SSO','',120,_binary ''),(13,'Security Incident Management (SIM)','SIM','',130,_binary ''),(14,'Business Continuity Management (BCM)','BCM','',140,_binary ''),(15,'Compliance (COM)','COM','',150,_binary ''),(16,'Dealing with investigation requests from government agencies (INQ)','INQ','',160,_binary ''),(17,'Product Safety and Security (PSS)','PSS','',170,_binary ''),(18,'General Conditions (BC)','BC','',180,_binary '');
/*!40000 ALTER TABLE `REQCATEGORY` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `REQUIREMENTSKELETON`
--

DROP TABLE IF EXISTS `REQUIREMENTSKELETON`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `REQUIREMENTSKELETON` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `universal_id` varchar(255) DEFAULT NULL,
  `short_name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `reqcategory_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_requirementskeleton_reqcategory_id` (`reqcategory_id`),
  CONSTRAINT `fk_requirementskeleton_reqcategory_id` FOREIGN KEY (`reqcategory_id`) REFERENCES `REQCATEGORY` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=128 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `REQUIREMENTSKELETON`
--

LOCK TABLES `REQUIREMENTSKELETON` WRITE;
/*!40000 ALTER TABLE `REQUIREMENTSKELETON` DISABLE KEYS */;
INSERT INTO `REQUIREMENTSKELETON` VALUES (1,NULL,'OIS-01','Information Security Management System (ISMS)',10,_binary '',1),(2,NULL,'OIS-02','Information Security Policy',20,_binary '',1),(3,NULL,'OIS-03','Interfaces and Dependencies',30,_binary '',1),(4,NULL,'OIS-04','Segregation of Duties',40,_binary '',1),(5,NULL,'OIS-05','Contact with Relevant Government Agencies and Interest Groups',50,_binary '',1),(6,NULL,'OIS-06','Risk Management Policy',60,_binary '',1),(7,NULL,'OIS-07','Application of the Risk Management Policy',70,_binary '',1),(8,NULL,'SP-01','Documentation, communication and provision of policies and instructions',80,_binary '',2),(9,NULL,'SP-02','Review and Approval of Policies and Instructions',90,_binary '',2),(10,NULL,'SP-03','Exceptions from Existing Policies and Instructions',100,_binary '',2),(11,NULL,'HR-01','Verification of qualification and trustworthiness',110,_binary '',3),(12,NULL,'HR-02','Employment terms and conditions',120,_binary '',3),(13,NULL,'HR-03','Security training and awareness programme',130,_binary '',3),(14,NULL,'HR-04','Disciplinary measures',140,_binary '',3),(15,NULL,'HR-05','Responsibilities in the event of termination or change of employment',150,_binary '',3),(16,NULL,'HR-06','Confidentiality agreements',160,_binary '',3),(17,NULL,'AM-01','Asset Inventory',170,_binary '',4),(18,NULL,'AM-02','Acceptable Use and Safe Handling of Assets Policy',180,_binary '',4),(19,NULL,'AM-03','Commissioning of Hardware',190,_binary '',4),(20,NULL,'AM-04','Decommissioning of Hardware',200,_binary '',4),(21,NULL,'AM-05','Commitment to Permissible Use, Safe Handling and Return of Assets',210,_binary '',4),(22,NULL,'AM-06','Asset Classification and Labelling',220,_binary '',4),(23,NULL,'PS-01','Physical Security and Environmental Control Requirements',230,_binary '',5),(24,NULL,'PS-02','Redundancy model',240,_binary '',5),(25,NULL,'PS-03','Perimeter Protection',250,_binary '',5),(26,NULL,'PS-04','Physical site access control',260,_binary '',5),(27,NULL,'PS-05','Protection against threats from outside and from the environment',270,_binary '',5),(28,NULL,'PS-06','Protection against interruptions caused by power failures and other such risks',280,_binary '',5),(29,NULL,'PS-07','Surveillance of operational and environmental parameters',290,_binary '',5),(30,NULL,'OPS-01','Capacity Management - Planning',300,_binary '',6),(31,NULL,'OPS-02','Capacity Management - Monitoring',310,_binary '',6),(32,NULL,'OPS-03','Capacity Management - Controlling of Resources',320,_binary '',6),(33,NULL,'OPS-04','Protection Against Malware - Concept',330,_binary '',6),(34,NULL,'OPS-05','Protection Against Malware - Implementation',340,_binary '',6),(35,NULL,'OPS-06','Data Protection and Recovery - Concept',350,_binary '',6),(36,NULL,'OPS-07','Data Backup and Recovery - Monitoring',360,_binary '',6),(37,NULL,'OPS-08','Data Backup and Recovery - Regular Testing',370,_binary '',6),(38,NULL,'OPS-09','Data Backup and Recovery - Storage',380,_binary '',6),(39,NULL,'OPS-10','Logging and Monitoring - Concept',390,_binary '',6),(40,NULL,'OPS-11','Logging and Monitoring - Metadata Management Concept',400,_binary '',6),(41,NULL,'OPS-12','Logging and Monitoring - Access, Storage and Deletion',410,_binary '',6),(42,NULL,'OPS-13','Logging and Monitoring - Identification of Events',420,_binary '',6),(43,NULL,'OPS-14','Logging and Monitoring - Storage of the Logging Data',430,_binary '',6),(44,NULL,'OPS-15','Logging and Monitoring - Accountability',440,_binary '',6),(45,NULL,'OPS-16','Logging and Monitoring - Configuration',450,_binary '',6),(46,NULL,'OPS-17','Logging and Monitoring - Availability of the Monitoring Software',460,_binary '',6),(47,NULL,'OPS-18','Managing Vulnerabilities, Malfunctions and Errors - Concept',470,_binary '',6),(48,NULL,'OPS-19','Managing Vulnerabilities, Malfunctions and Errors - Penetration Tests',480,_binary '',6),(49,NULL,'OPS-20','Managing Vulnerabilities, Malfunctions and Errors - Measurements, Analyses and Assessments of Procedures',490,_binary '',6),(50,NULL,'OPS-21','Involvement of Cloud customers in the event of incidents',500,_binary '',6),(51,NULL,'OPS-22','Testing and Documentation of known Vulnerabilities',510,_binary '',6),(52,NULL,'OPS-23','Managing Vulnerabilities, Malfunctions and Errors - System Hardening',520,_binary '',6),(53,NULL,'OPS-24','Separation of Datasets in the Cloud Infrastructure',530,_binary '',6),(54,NULL,'IDM-01','Policy for user accounts and access rights',540,_binary '',7),(55,NULL,'IDM-02','Granting and change of user accounts and access rights',550,_binary '',7),(56,NULL,'IDM-03','Locking and withdrawal of user accounts in the event of inactivity or multiple failed logins',560,_binary '',7),(57,NULL,'IDM-04','Withdraw or adjust access rights as the task area changes',570,_binary '',7),(58,NULL,'IDM-05','Regular review of access rights',580,_binary '',7),(59,NULL,'IDM-06','Privileged access rights',590,_binary '',7),(60,NULL,'IDM-07','Access to cloud customer data',600,_binary '',7),(61,NULL,'IDM-08','Confidentiality of authentication information',610,_binary '',7),(62,NULL,'IDM-09','Authentication mechanisms',620,_binary '',7),(63,NULL,'CRY-01','Policy for the use of encryption procedures and key management',630,_binary '',8),(64,NULL,'CRY-02','Encryption of data for transmission (transport encryption)',640,_binary '',8),(65,NULL,'CRY-03','Encryption of sensitive data for storage',650,_binary '',8),(66,NULL,'CRY-04','Secure key management',660,_binary '',8),(67,NULL,'COS-01','Technical safeguards',670,_binary '',9),(68,NULL,'COS-02','Security requirements for connections in the Cloud Service Provider\'s network',680,_binary '',9),(69,NULL,'COS-03','Monitoring of connections in the Cloud Service Provider\'s network',690,_binary '',9),(70,NULL,'COS-04','Cross-network access',700,_binary '',9),(71,NULL,'COS-05','Networks for administration',710,_binary '',9),(72,NULL,'COS-06','Segregation of data traffic in jointly used network environments',720,_binary '',9),(73,NULL,'COS-07','Documentation of the network topology',730,_binary '',9),(74,NULL,'COS-08','Policies for data transmission',740,_binary '',9),(75,NULL,'PI-01','Documentation and safety of input and output interfaces',750,_binary '',10),(76,NULL,'PI-02','Contractual agreements for the provision of data',760,_binary '',10),(77,NULL,'PI-03','Secure deletion of data',770,_binary '',10),(78,NULL,'DEV-01','Policies for the development/procurement of information systems',780,_binary '',11),(79,NULL,'DEV-02','Outsourcing of the development',790,_binary '',11),(80,NULL,'DEV-03','Policies for changes to information systems',800,_binary '',11),(81,NULL,'DEV-04','Safety training and awareness programme regarding continuous software delivery and associated systems, components or tools.',810,_binary '',11),(82,NULL,'DEV-05','Risk assessment, categorisation and prioritisation of changes',820,_binary '',11),(83,NULL,'DEV-06','Testing changes',830,_binary '',11),(84,NULL,'DEV-07','Logging of changes',840,_binary '',11),(85,NULL,'DEV-08','Version Control',850,_binary '',11),(86,NULL,'DEV-09','Approvals for provision in the production environment',860,_binary '',11),(87,NULL,'DEV-10','Separation of environments',870,_binary '',11),(88,NULL,'SSO-01','Policies and instructions for controlling and monitoring third parties',880,_binary '',12),(89,NULL,'SSO-02','Risk assessment of service providers and suppliers',890,_binary '',12),(90,NULL,'SSO-03','Directory of service providers and suppliers',900,_binary '',12),(91,NULL,'SSO-04','Monitoring of compliance with requirements',910,_binary '',12),(92,NULL,'SSO-05','Exit strategy for the receipt of benefits',920,_binary '',12),(93,NULL,'SIM-01','Policy for security incident management',930,_binary '',13),(94,NULL,'SIM-02','Processing of security incidents',940,_binary '',13),(95,NULL,'SIM-03','Documentation and reporting of security incidents',950,_binary '',13),(96,NULL,'SIM-04','Duty of the users to report security incidents to a central body',960,_binary '',13),(97,NULL,'SIM-05','Evaluation and learning process',970,_binary '',13),(98,NULL,'BCM-01','Top management responsibility',980,_binary '',14),(99,NULL,'BCM-02','Business impact analysis policies and instructions',990,_binary '',14),(100,NULL,'BCM-03','Planning business continuity',1000,_binary '',14),(101,NULL,'BCM-04','Verification, updating and testing of the business continuity',1010,_binary '',14),(102,NULL,'COM-01','Identification of applicable legal, regulatory, self-imposed or contractual requirements',1020,_binary '',15),(103,NULL,'COM-02','Policy for planning and conducting audits',1030,_binary '',15),(104,NULL,'COM-03','Internal audits of the information security management system',1040,_binary '',15),(105,NULL,'COM-04','Information on information security performance and management assessment of the ISMS',1050,_binary '',15),(106,NULL,'INQ-01','Legal Assessment of Investigative Inquiries',1060,_binary '',16),(107,NULL,'INQ-02','INQ-02 Informing Cloud Customers about Investigation Requests',1070,_binary '',16),(108,NULL,'INQ-03','Conditions for Access to or Disclosure of Data in Investigation Requests',1080,_binary '',16),(109,NULL,'INQ-04','Limiting Access to or Disclosure of Data in Investigation Requests',1090,_binary '',16),(110,NULL,'PSS-01','Guidelines and Recommendations for Cloud Customers',1100,_binary '',17),(111,NULL,'PSS-02','Identification of Vulnerabilities of the Cloud Service',1110,_binary '',17),(112,NULL,'PSS-03','Online Register of Known Vulnerabilities',1120,_binary '',17),(113,NULL,'PSS-04','Error handling and Logging Mechanisms',1130,_binary '',17),(114,NULL,'PSS-05','Authentication Mechanisms',1140,_binary '',17),(115,NULL,'PSS-06','Session Management',1150,_binary '',17),(116,NULL,'PSS-07','Confidentiality of Authentication Information',1160,_binary '',17),(117,NULL,'PSS-08','Roles and Rights Concept',1170,_binary '',17),(118,NULL,'PSS-09','Authorisation Mechanisms',1180,_binary '',17),(119,NULL,'PSS-10','Software Defined Networking',1190,_binary '',17),(120,NULL,'PSS-11','Images for Virtual Machines and Containers',1200,_binary '',17),(121,NULL,'PSS-12','Locations of Data Processing and Storage',1210,_binary '',17),(122,NULL,'BC-01','Information on jurisdiction and locations',1220,_binary '',18),(123,NULL,'BC-02','Information on availability and incident handling during regular operation',1230,_binary '',18),(124,NULL,'BC-03','Information on recovery parameters in emergency operation',1240,_binary '',18),(125,NULL,'BC-04','Information on the availability of the data centre',1250,_binary '',18),(126,NULL,'BC-05','Information on how investigation enquiries from government authorities are handled',1260,_binary '',18),(127,NULL,'BC-06','Information on certifications or attestations',1270,_binary '',18);
/*!40000 ALTER TABLE `REQUIREMENTSKELETON` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `REQUIREMENTSKELETON_COLLECTIONINSTANCE`
--

DROP TABLE IF EXISTS `REQUIREMENTSKELETON_COLLECTIONINSTANCE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `REQUIREMENTSKELETON_COLLECTIONINSTANCE` (
  `collectioninstances_id` bigint(20) NOT NULL,
  `requirementskeletons_id` bigint(20) NOT NULL,
  PRIMARY KEY (`requirementskeletons_id`,`collectioninstances_id`),
  KEY `fk_collectioninstance_collectioninstance_requirementskeleton_id` (`collectioninstances_id`),
  CONSTRAINT `fk_collectioninstance_collectioninstance_requirementskeleton_id` FOREIGN KEY (`collectioninstances_id`) REFERENCES `COLLECTIONINSTANCE` (`id`),
  CONSTRAINT `fk_requirementskeleton_collectioninstance_collectioninstance_id` FOREIGN KEY (`requirementskeletons_id`) REFERENCES `REQUIREMENTSKELETON` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `REQUIREMENTSKELETON_COLLECTIONINSTANCE`
--

LOCK TABLES `REQUIREMENTSKELETON_COLLECTIONINSTANCE` WRITE;
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_COLLECTIONINSTANCE` DISABLE KEYS */;
INSERT INTO `REQUIREMENTSKELETON_COLLECTIONINSTANCE` VALUES (1,1),(1,2),(1,3),(1,4),(1,5),(1,6),(1,7),(2,8),(2,9),(2,10),(3,11),(3,12),(3,13),(3,14),(3,15),(3,16),(4,17),(4,18),(4,19),(4,20),(4,21),(4,22),(5,23),(5,24),(5,25),(5,26),(5,27),(5,28),(5,29),(6,30),(6,31),(6,32),(6,33),(6,34),(6,35),(6,36),(6,37),(6,38),(6,39),(6,40),(6,41),(6,42),(6,43),(6,44),(6,45),(6,46),(6,47),(6,48),(6,49),(6,50),(6,51),(6,52),(6,53),(7,54),(7,55),(7,56),(7,57),(7,58),(7,59),(7,60),(7,61),(7,62),(8,63),(8,64),(8,65),(8,66),(9,67),(9,68),(9,69),(9,70),(9,71),(9,72),(9,73),(9,74),(10,75),(10,76),(10,77),(11,78),(11,79),(11,80),(11,81),(11,82),(11,83),(11,84),(11,85),(11,86),(11,87),(12,88),(12,89),(12,90),(12,91),(12,92),(13,93),(13,94),(13,95),(13,96),(13,97),(14,98),(14,99),(14,100),(14,101),(15,102),(15,103),(15,104),(15,105),(16,106),(16,107),(16,108),(16,109),(17,110),(17,111),(17,112),(17,113),(17,114),(17,115),(17,116),(17,117),(17,118),(17,119),(17,120),(17,121),(18,122),(18,123),(18,124),(18,125),(18,126),(18,127);
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_COLLECTIONINSTANCE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `REQUIREMENTSKELETON_PROJECTTYPE`
--

DROP TABLE IF EXISTS `REQUIREMENTSKELETON_PROJECTTYPE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `REQUIREMENTSKELETON_PROJECTTYPE` (
  `projecttypes_id` bigint(20) NOT NULL,
  `requirementskeletons_id` bigint(20) NOT NULL,
  PRIMARY KEY (`requirementskeletons_id`,`projecttypes_id`),
  KEY `fk_projecttype_projecttype_requirementskeleton_id` (`projecttypes_id`),
  CONSTRAINT `fk_projecttype_projecttype_requirementskeleton_id` FOREIGN KEY (`projecttypes_id`) REFERENCES `PROJECTTYPE` (`id`),
  CONSTRAINT `fk_requirementskeleton_projecttype_projecttype_id` FOREIGN KEY (`requirementskeletons_id`) REFERENCES `REQUIREMENTSKELETON` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `REQUIREMENTSKELETON_PROJECTTYPE`
--

LOCK TABLES `REQUIREMENTSKELETON_PROJECTTYPE` WRITE;
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_PROJECTTYPE` DISABLE KEYS */;
INSERT INTO `REQUIREMENTSKELETON_PROJECTTYPE` VALUES (1,1),(1,2),(1,3),(1,4),(1,5),(1,6),(1,7),(1,8),(1,9),(1,10),(1,11),(1,12),(1,13),(1,14),(1,15),(1,16),(1,17),(1,18),(1,19),(1,20),(1,21),(1,22),(1,23),(1,24),(1,25),(1,26),(1,27),(1,28),(1,29),(1,30),(1,31),(1,32),(1,33),(1,34),(1,35),(1,36),(1,37),(1,38),(1,39),(1,40),(1,41),(1,42),(1,43),(1,44),(1,45),(1,46),(1,47),(1,48),(1,49),(1,50),(1,51),(1,52),(1,53),(1,54),(1,55),(1,56),(1,57),(1,58),(1,59),(1,60),(1,61),(1,62),(1,63),(1,64),(1,65),(1,66),(1,67),(1,68),(1,69),(1,70),(1,71),(1,72),(1,73),(1,74),(1,75),(1,76),(1,77),(1,78),(1,79),(1,80),(1,81),(1,82),(1,83),(1,84),(1,85),(1,86),(1,87),(1,88),(1,89),(1,90),(1,91),(1,92),(1,93),(1,94),(1,95),(1,96),(1,97),(1,98),(1,99),(1,100),(1,101),(1,102),(1,103),(1,104),(1,105),(1,106),(1,107),(1,108),(1,109),(1,110),(1,111),(1,112),(1,113),(1,114),(1,115),(1,116),(1,117),(1,118),(1,119),(1,120),(1,121),(1,122),(1,123),(1,124),(1,125),(1,126),(1,127);
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_PROJECTTYPE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `REQUIREMENTSKELETON_TAGINSTANCE`
--

DROP TABLE IF EXISTS `REQUIREMENTSKELETON_TAGINSTANCE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `REQUIREMENTSKELETON_TAGINSTANCE` (
  `taginstances_id` bigint(20) NOT NULL,
  `requirementskeletons_id` bigint(20) NOT NULL,
  PRIMARY KEY (`requirementskeletons_id`,`taginstances_id`),
  KEY `fk_taginstance_taginstance_requirementskeleton_id` (`taginstances_id`),
  CONSTRAINT `fk_requirementskeleton_taginstance_taginstance_id` FOREIGN KEY (`requirementskeletons_id`) REFERENCES `REQUIREMENTSKELETON` (`id`),
  CONSTRAINT `fk_taginstance_taginstance_requirementskeleton_id` FOREIGN KEY (`taginstances_id`) REFERENCES `TAGINSTANCE` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `REQUIREMENTSKELETON_TAGINSTANCE`
--

LOCK TABLES `REQUIREMENTSKELETON_TAGINSTANCE` WRITE;
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_TAGINSTANCE` DISABLE KEYS */;
/*!40000 ALTER TABLE `REQUIREMENTSKELETON_TAGINSTANCE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `SLIDETEMPLATE`
--

DROP TABLE IF EXISTS `SLIDETEMPLATE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `SLIDETEMPLATE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `content` text,
  `created_by` varchar(50) NOT NULL,
  `created_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `last_modified_by` varchar(50) DEFAULT NULL,
  `last_modified_date` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `SLIDETEMPLATE`
--

LOCK TABLES `SLIDETEMPLATE` WRITE;
/*!40000 ALTER TABLE `SLIDETEMPLATE` DISABLE KEYS */;
/*!40000 ALTER TABLE `SLIDETEMPLATE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `STATUSCOLUMN`
--

DROP TABLE IF EXISTS `STATUSCOLUMN`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `STATUSCOLUMN` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `is_enum` bit(1) DEFAULT NULL,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `STATUSCOLUMN`
--

LOCK TABLES `STATUSCOLUMN` WRITE;
/*!40000 ALTER TABLE `STATUSCOLUMN` DISABLE KEYS */;
INSERT INTO `STATUSCOLUMN` VALUES (1,'Notes',NULL,_binary '\0',0,_binary '');
/*!40000 ALTER TABLE `STATUSCOLUMN` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `STATUSCOLUMNVALUE`
--

DROP TABLE IF EXISTS `STATUSCOLUMNVALUE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `STATUSCOLUMNVALUE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `statuscolumn_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_statuscolumnvalue_statuscolumn_id` (`statuscolumn_id`),
  CONSTRAINT `fk_statuscolumnvalue_statuscolumn_id` FOREIGN KEY (`statuscolumn_id`) REFERENCES `STATUSCOLUMN` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `STATUSCOLUMNVALUE`
--

LOCK TABLES `STATUSCOLUMNVALUE` WRITE;
/*!40000 ALTER TABLE `STATUSCOLUMNVALUE` DISABLE KEYS */;
/*!40000 ALTER TABLE `STATUSCOLUMNVALUE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TAGCATEGORY`
--

DROP TABLE IF EXISTS `TAGCATEGORY`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TAGCATEGORY` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TAGCATEGORY`
--

LOCK TABLES `TAGCATEGORY` WRITE;
/*!40000 ALTER TABLE `TAGCATEGORY` DISABLE KEYS */;
/*!40000 ALTER TABLE `TAGCATEGORY` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TAGINSTANCE`
--

DROP TABLE IF EXISTS `TAGINSTANCE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TAGINSTANCE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `show_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `tagcategory_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_taginstance_tagcategory_id` (`tagcategory_id`),
  CONSTRAINT `fk_taginstance_tagcategory_id` FOREIGN KEY (`tagcategory_id`) REFERENCES `TAGCATEGORY` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TAGINSTANCE`
--

LOCK TABLES `TAGINSTANCE` WRITE;
/*!40000 ALTER TABLE `TAGINSTANCE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TAGINSTANCE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAINING`
--

DROP TABLE IF EXISTS `TRAINING`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAINING` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `description` text,
  `created_by` varchar(50) NOT NULL,
  `created_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `last_modified_by` varchar(50) DEFAULT NULL,
  `last_modified_date` timestamp NULL DEFAULT NULL,
  `all_requirements_selected` bit(1) NOT NULL DEFAULT b'1',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAINING`
--

LOCK TABLES `TRAINING` WRITE;
/*!40000 ALTER TABLE `TRAINING` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAINING` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGBRANCHNODE`
--

DROP TABLE IF EXISTS `TRAININGBRANCHNODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGBRANCHNODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `anchor` int(11) DEFAULT NULL,
  `node_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_trainingbranchnode_node_id` (`node_id`),
  CONSTRAINT `fk_trainingbranchnode_node_id` FOREIGN KEY (`node_id`) REFERENCES `TRAININGTREENODE` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGBRANCHNODE`
--

LOCK TABLES `TRAININGBRANCHNODE` WRITE;
/*!40000 ALTER TABLE `TRAININGBRANCHNODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGBRANCHNODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGCATEGORYNODE`
--

DROP TABLE IF EXISTS `TRAININGCATEGORYNODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGCATEGORYNODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `node_id` bigint(20) DEFAULT NULL,
  `category_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_trainingcategorynode_node_id` (`node_id`),
  KEY `fk_trainingcategorynode_category_id` (`category_id`),
  CONSTRAINT `fk_trainingcategorynode_category_id` FOREIGN KEY (`category_id`) REFERENCES `REQCATEGORY` (`id`),
  CONSTRAINT `fk_trainingcategorynode_node_id` FOREIGN KEY (`node_id`) REFERENCES `TRAININGTREENODE` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGCATEGORYNODE`
--

LOCK TABLES `TRAININGCATEGORYNODE` WRITE;
/*!40000 ALTER TABLE `TRAININGCATEGORYNODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGCATEGORYNODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGCUSTOMSLIDENODE`
--

DROP TABLE IF EXISTS `TRAININGCUSTOMSLIDENODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGCUSTOMSLIDENODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `content` text,
  `anchor` int(11) DEFAULT NULL,
  `node_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_trainingcustomslidenode_node_id` (`node_id`),
  CONSTRAINT `fk_trainingcustomslidenode_node_id` FOREIGN KEY (`node_id`) REFERENCES `TRAININGTREENODE` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGCUSTOMSLIDENODE`
--

LOCK TABLES `TRAININGCUSTOMSLIDENODE` WRITE;
/*!40000 ALTER TABLE `TRAININGCUSTOMSLIDENODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGCUSTOMSLIDENODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGGENERATEDSLIDENODE`
--

DROP TABLE IF EXISTS `TRAININGGENERATEDSLIDENODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGGENERATEDSLIDENODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `node_id` bigint(20) DEFAULT NULL,
  `optcolumn_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_traininggeneratedslidenode_node_id` (`node_id`),
  KEY `fk_traininggeneratedslidenode_optcolumn_id` (`optcolumn_id`),
  CONSTRAINT `fk_traininggeneratedslidenode_node_id` FOREIGN KEY (`node_id`) REFERENCES `TRAININGTREENODE` (`id`),
  CONSTRAINT `fk_traininggeneratedslidenode_optcolumn_id` FOREIGN KEY (`optcolumn_id`) REFERENCES `OPTCOLUMN` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGGENERATEDSLIDENODE`
--

LOCK TABLES `TRAININGGENERATEDSLIDENODE` WRITE;
/*!40000 ALTER TABLE `TRAININGGENERATEDSLIDENODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGGENERATEDSLIDENODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGREQUIREMENTNODE`
--

DROP TABLE IF EXISTS `TRAININGREQUIREMENTNODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGREQUIREMENTNODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `node_id` bigint(20) DEFAULT NULL,
  `requirementskeleton_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_trainingrequirementnode_node_id` (`node_id`),
  KEY `fk_trainingrequirementnode_requirementskeleton_id` (`requirementskeleton_id`),
  CONSTRAINT `fk_trainingrequirementnode_node_id` FOREIGN KEY (`node_id`) REFERENCES `TRAININGTREENODE` (`id`),
  CONSTRAINT `fk_trainingrequirementnode_requirementskeleton_id` FOREIGN KEY (`requirementskeleton_id`) REFERENCES `REQUIREMENTSKELETON` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGREQUIREMENTNODE`
--

LOCK TABLES `TRAININGREQUIREMENTNODE` WRITE;
/*!40000 ALTER TABLE `TRAININGREQUIREMENTNODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGREQUIREMENTNODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAININGTREENODE`
--

DROP TABLE IF EXISTS `TRAININGTREENODE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAININGTREENODE` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `node_type` varchar(255) DEFAULT NULL,
  `sort_order` int(11) DEFAULT NULL,
  `active` bit(1) DEFAULT NULL,
  `parent_id_id` bigint(20) DEFAULT NULL,
  `training_id_id` bigint(20) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_trainingtreenode_parent_id_id` (`parent_id_id`),
  KEY `fk_trainingtreenode_training_id_id` (`training_id_id`),
  CONSTRAINT `fk_trainingtreenode_parent_id_id` FOREIGN KEY (`parent_id_id`) REFERENCES `TRAININGTREENODE` (`id`),
  CONSTRAINT `fk_trainingtreenode_training_id_id` FOREIGN KEY (`training_id_id`) REFERENCES `TRAINING` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAININGTREENODE`
--

LOCK TABLES `TRAININGTREENODE` WRITE;
/*!40000 ALTER TABLE `TRAININGTREENODE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAININGTREENODE` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAINING_COLLECTION`
--

DROP TABLE IF EXISTS `TRAINING_COLLECTION`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAINING_COLLECTION` (
  `collections_id` bigint(20) NOT NULL,
  `trainings_id` bigint(20) NOT NULL,
  PRIMARY KEY (`trainings_id`,`collections_id`),
  KEY `fk_collectioninstance_collection_training_id` (`collections_id`),
  CONSTRAINT `fk_collectioninstance_collection_training_id` FOREIGN KEY (`collections_id`) REFERENCES `COLLECTIONINSTANCE` (`id`),
  CONSTRAINT `fk_training_collection_collectioninstance_id` FOREIGN KEY (`trainings_id`) REFERENCES `TRAINING` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAINING_COLLECTION`
--

LOCK TABLES `TRAINING_COLLECTION` WRITE;
/*!40000 ALTER TABLE `TRAINING_COLLECTION` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAINING_COLLECTION` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAINING_OPTCOLUMN`
--

DROP TABLE IF EXISTS `TRAINING_OPTCOLUMN`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAINING_OPTCOLUMN` (
  `optcolumns_id` bigint(20) NOT NULL,
  `trainings_id` bigint(20) NOT NULL,
  PRIMARY KEY (`trainings_id`,`optcolumns_id`),
  KEY `fk_optcolumn_optcolumn_training_id` (`optcolumns_id`),
  CONSTRAINT `fk_optcolumn_optcolumn_training_id` FOREIGN KEY (`optcolumns_id`) REFERENCES `OPTCOLUMN` (`id`),
  CONSTRAINT `fk_training_optcolumn_optcolumn_id` FOREIGN KEY (`trainings_id`) REFERENCES `TRAINING` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAINING_OPTCOLUMN`
--

LOCK TABLES `TRAINING_OPTCOLUMN` WRITE;
/*!40000 ALTER TABLE `TRAINING_OPTCOLUMN` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAINING_OPTCOLUMN` ENABLE KEYS */;
UNLOCK TABLES;

--
-- Table structure for table `TRAINING_PROJECTTYPE`
--

DROP TABLE IF EXISTS `TRAINING_PROJECTTYPE`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `TRAINING_PROJECTTYPE` (
  `projecttypes_id` bigint(20) NOT NULL,
  `trainings_id` bigint(20) NOT NULL,
  PRIMARY KEY (`trainings_id`,`projecttypes_id`),
  KEY `fk_projecttype_projecttype_training_id` (`projecttypes_id`),
  CONSTRAINT `fk_projecttype_projecttype_training_id` FOREIGN KEY (`projecttypes_id`) REFERENCES `PROJECTTYPE` (`id`),
  CONSTRAINT `fk_training_projecttype_projecttype_id` FOREIGN KEY (`trainings_id`) REFERENCES `TRAINING` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `TRAINING_PROJECTTYPE`
--

LOCK TABLES `TRAINING_PROJECTTYPE` WRITE;
/*!40000 ALTER TABLE `TRAINING_PROJECTTYPE` DISABLE KEYS */;
/*!40000 ALTER TABLE `TRAINING_PROJECTTYPE` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=@OLD_TIME_ZONE */;

/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=@OLD_SQL_NOTES */;

-- Dump completed on 2020-02-21 11:48:34