{"catalog":{"uuid":"7f2c34e7-f9c6-4c02-939a-197555760804","metadata":{"props":[{"name":"keywords","value":"C5, cloud computing, compliance, BSI, security criteria"}],"roles":[{"id":"publisher","title":"Bundesamt für Sicherheit in der Informationstechnik (BSI)"}],"title":"Cloud Computing Compliance Criteria Catalogue (C5:2026)","parties":[{"name":"Bundesamt für Sicherheit in der Informationstechnik (BSI)","type":"organization","uuid":"18328dda-39e5-4671-be9a-f61727df529d","links":[{"rel":"homepage","href":"https://www.bsi.bund.de"},{"rel":"license","href":"https://creativecommons.org/licenses/by-nd/4.0/","text":"Creative Commons Attribution-NoDerivatives 4.0 International (CC BY-ND 4.0)"},{"rel":"alternate","href":"https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html","text":"Offizielle BSI C5 Publikation"}],"addresses":[{"city":"Bonn","country":"DE","addr-lines":["Godesberger Allee 185-189"],"postal-code":"53175"}],"short-name":"BSI"}],"version":"C5:2026","published":"2026-03-30T00:00:00+02:00","document-ids":[{"scheme":"http://oscal.io/oscal/identifier/content-uuid","identifier":"35dda0cf-5105-4f05-8e0d-a04c94461dc0"}],"last-modified":"2026-04-10T07:29:49.535Z","oscal-version":"1.1.2","responsible-parties":[{"role-id":"publisher","party-uuids":["18328dda-39e5-4671-be9a-f61727df529d"]}]},"groups":[{"id":"ois","title":"Organisation of Information Security (OIS)","controls":[{"id":"ois-01","title":"Information Security Management System (ISMS)","controls":[{"id":"ois-01-01b","class":"basic","parts":[{"id":"ois-01-01b_stmt","name":"statement","prose":"The cloud service provider maintains an ISO/IEC 27001-compliant information security management system (ISMS). The scope of the ISMS covers the cloud service provider's organisational units, locations, zones, regions and procedures relevant to the development and operation of the cloud service."},{"id":"ois-01-01b_guidance-1","name":"guidance","prose":"The basic criterion can also be fulfilled without valid certification of the ISMS according to ISO/IEC 27001 or ISO 27001 based on BSI IT-Grundschutz, if the submitted documentation meets the requirements of ISO/IEC 27001. The auditor has to evaluate whether the documentation meets the referenced requirements of the ISO standard. This does not require a full certification audit of the management system in accordance with ISO 17021, but a focused inspection of the related documentation.\n\nCross-sectional functions do not need to be integrated into a single ISMS. Instead, multiple ISMS can be established to cover both, cloud service-specific internal control systems and organisation-wide/central functions effectively.\n\nThe scope of the ISMS may go beyond the scope of the cloud service provider's system of internal control for the cloud service in scope of an assurance engagement with this criteria catalogue. If the scope of the ISMS is broader than the scope of the assurance engagement, evidence to be obtained about the design and operation of the ISMS can be limited to records that are applicable to the cloud service in scope of the assurance engagement."}],"title":"OIS-01 Basic 01B"},{"id":"ois-01-02b","class":"basic","parts":[{"id":"ois-01-02b_stmt","name":"statement","prose":"The measures for setting up, implementing, maintaining and continuously improving the ISMS are documented. The documentation includes:\n\n1. Context of the cloud service provider;\n2. Scope of the ISMS (section 4.3 of ISO/IEC 27001);\n3. Statement of applicability (section 6.1.3 of ISO/IEC 27001); \n4. Overview of how activities in the ISMS cover the cloud service;\n5. Description of how the cloud service provider maintains and improves the cloud service's security; and\n6. Results of the last management review (section 9.3 of ISO/IEC 27001)."}],"title":"OIS-01 Basic 02B"},{"id":"ois-01-03b","class":"basic","parts":[{"id":"ois-01-03b_stmt","name":"statement","prose":"Additionally, the cloud service provider documents the scope and boundaries of the cloud service under its operational control, including any exclusions or shared-responsibility areas."}],"title":"OIS-01 Basic 03B"},{"id":"ois-01-01as","class":"additional-sharpen","parts":[{"id":"ois-01-01as_stmt","name":"statement","prose":"The Information Security Management System (ISMS) has a valid certification according to ISO/IEC 27001 or ISO 27001 based on BSI IT-Grundschutz. The scope of the certification covers the cloud service provider's organisational units, locations, zones, regions, and procedures relevant to the development and operation of the cloud service."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"OIS-01 Additional Sharpen 01AS"},{"id":"ois-01-01ac","class":"additional-complement","parts":[{"id":"ois-01-01ac_stmt","name":"statement","prose":"Existing valid certifications according to ISO/IEC 27001 are issued and recognised by an accredited certification body."}],"title":"OIS-01 Additional Complement 01AC"}]},{"id":"ois-02","title":"Information Security Policy","controls":[{"id":"ois-02-01b","class":"basic","parts":[{"id":"ois-02-01b_stmt","name":"statement","prose":"Top management of the cloud service provider has adopted an information security policy."},{"id":"ois-02-01b_guidance-1","name":"guidance","prose":"The top management is a natural person or group of persons who make the final decision for the organisation and is responsible for that decision."}],"title":"OIS-02 Basic 01B"},{"id":"ois-02-02b","class":"basic","parts":[{"id":"ois-02-02b_stmt","name":"statement","prose":"Top management of the cloud service provider has communicated the information security policy to internal and external personnel as well as cloud service customers."},{"id":"ois-02-02b_guidance-1","name":"guidance","prose":"The top management is a natural person or group of persons who make the final decision for the organisation and is responsible for that decision."}],"title":"OIS-02 Basic 02B"},{"id":"ois-02-03b","class":"basic","parts":[{"id":"ois-02-03b_stmt","name":"statement","prose":"The information security policy describes:\n\n1. The importance of information security, based on the requirements of cloud service customers in relation to information security;\n2. The security objectives and the desired security level, based on the business goals and activities as well as compliance obligations of the cloud service provider;\n3. The cloud service provider's commitment to implement the necessary security measures for fulfilling the established security objectives;\n4. The most important aspects of the security strategy to achieve the security objectives set; and\n5. The organisational structure for information security in the scope of the ISMS."}],"title":"OIS-02 Basic 03B"}]},{"id":"ois-03","parts":[{"id":"ois-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Interfaces and Dependencies","controls":[{"id":"ois-03-01b","class":"basic","parts":[{"id":"ois-03-01b_stmt","name":"statement","prose":"The cloud service provider establishes, documents, and communicates a Shared Security Responsibility Model (SSRM) to define and manage interfaces and dependencies between cloud service delivery activities performed by the cloud service provider and those performed by cloud service customers."},{"id":"ois-03-01b_guidance-1","name":"guidance","prose":"Third parties in the sense of this basic criterion are, e.g. cloud service customers and service organisations (including cloud service broker).\nA SSRM provides a consolidated view of the key interfaces and dependencies between the cloud service provider and third parties. Detailed information on interfaces and dependencies can be defined in separate documents that are referenced in the SSRM, such as  guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts.\nThe cloud service provider can present the underlying Shared Responsibility Model of their cloud service in the guidelines and procedures to help cloud service customers understand their roles and responsibilities in terms of security and operational management.\n\nIf cloud services are delivered through a cloud service broker, the SSRM should clearly delineate responsibilities among the cloud service provider, the cloud service broker and the cloud service customer, in particular:\n\n1. Data ownership and processing boundaries;\n2. Security control implementation by each party;\n3. Incident notification and escalation paths; and\n4. Compliance attestation scope."},{"id":"ois-03-01b_guidance-2","name":"guidance","prose":"The cloud service provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts (or appendices thereof).\n\nThe cloud service provider can leverage existing documentation, such as guidelines, contractual agreements or procedures to present the underlying Shared Responsibility Model of their cloud service, thereby clarifying cloud service customers' security and operation responsibilities."}],"title":"OIS-03 Basic 01B"},{"id":"ois-03-02b","class":"basic","parts":[{"id":"ois-03-02b_stmt","name":"statement","prose":"The SSRM documentation clearly defines the responsibilities between both parties for handling vulnerabilities, security incidents, and incidents. The 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)."},{"id":"ois-03-02b_guidance-1","name":"guidance","prose":"The cloud service provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts (or appendices thereof).\n\nThe cloud service provider can leverage existing documentation, such as guidelines, contractual agreements or procedures to present the underlying Shared Responsibility Model of their cloud service, thereby clarifying cloud service customers' security and operation responsibilities."}],"title":"OIS-03 Basic 02B"},{"id":"ois-03-03b","class":"basic","parts":[{"id":"ois-03-03b_stmt","name":"statement","prose":"The cloud service provider regularly reviews and validates the SSRM documentation in accordance with SP-02 to ensure its accuracy and relevance for all cloud service offerings."},{"id":"ois-03-03b_guidance-1","name":"guidance","prose":"The cloud service provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts (or appendices thereof).\n\nThe cloud service provider can leverage existing documentation, such as guidelines, contractual agreements or procedures to present the underlying Shared Responsibility Model of their cloud service, thereby clarifying cloud service customers' security and operation responsibilities."},{"id":"ois-03-03b_guidance-2","name":"guidance","prose":"By maintaining an up-to-date and clearly communicated SSRM, the cloud service provider ensures a comprehensive understanding of security responsibilities, fostering a secure and reliable cloud environment for all stakeholders."}],"title":"OIS-03 Basic 03B"},{"id":"ois-03-04b","class":"basic","parts":[{"id":"ois-03-04b_stmt","name":"statement","prose":"The cloud service provider implements, operates, and reviews the SSRM components for which it is responsible, ensuring adherence to the defined security measures."},{"id":"ois-03-04b_guidance-1","name":"guidance","prose":"The cloud service provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts (or appendices thereof).\n\nThe cloud service provider can leverage existing documentation, such as guidelines, contractual agreements or procedures to present the underlying Shared Responsibility Model of their cloud service, thereby clarifying cloud service customers' security and operation responsibilities."}],"title":"OIS-03 Basic 04B"},{"id":"ois-03-05b","class":"basic","parts":[{"id":"ois-03-05b_stmt","name":"statement","prose":"The communication of changes to the SSRM, 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."},{"id":"ois-03-05b_guidance-1","name":"guidance","prose":"The cloud service provider can define and document the interfaces and dependencies described in the basic criterion in guidelines and procedures. For example, cloud service customers' obligations to cooperate should be described in service descriptions and contracts (or appendices thereof).\n\nThe cloud service provider can leverage existing documentation, such as guidelines, contractual agreements or procedures to present the underlying Shared Responsibility Model of their cloud service, thereby clarifying cloud service customers' security and operation responsibilities."},{"id":"ois-03-05b_guidance-2","name":"guidance","prose":"By maintaining an up-to-date and clearly communicated SSRM, the cloud service provider ensures a comprehensive understanding of security responsibilities, fostering a secure and reliable cloud environment for all stakeholders."}],"title":"OIS-03 Basic 05B"}]},{"id":"ois-04","title":"Segregation of Duties","controls":[{"id":"ois-04-01b","class":"basic","parts":[{"id":"ois-04-01b_stmt","name":"statement","prose":"Conflicting tasks and responsibilities are segregated based on a risk assessment in accordance with OIS-07 to reduce the risk of unauthorised or unintended changes or misuse of cloud service customer data, cloud service derived data and cloud service provider data. The 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\n1. Administration of a role, rights and authorisation framework based on role-based access control and the business and security requirements of the cloud service provider (cf. IAM-01);\n2. Development, testing and release of changes (cf. DEV-01); \n3. Risk management (cf. OIS-07); and\n4. Operation of the system components."},{"id":"ois-04-01b_guidance-1","name":"guidance","prose":"Identified events that may constitute unauthorised or unintentional changes to or misuse of cloud service customer data, cloud service derived data and cloud service provider data may, for example, be treated as a security incident, cf. SIM-01.\nThe area of risk management in the context of segregation of duties refers to the so-called different lines of defense, i.e. roles that review risks (2nd line of defense) are different from roles that own risks (1st line of defense)."}],"title":"OIS-04 Basic 01B"},{"id":"ois-04-02b","class":"basic","parts":[{"id":"ois-04-02b_stmt","name":"statement","prose":"Mitigating measures are outlined in the risk treatment plan (cf. OIS-09) and implemented by the cloud service provider in a way that prioritises the segregation of duties."}],"title":"OIS-04 Basic 02B"},{"id":"ois-04-03b","class":"basic","parts":[{"id":"ois-04-03b_stmt","name":"statement","prose":"If segregation of duties cannot be implemented due to organisational or technical constraints, the cloud service provider establishes and operates compensating controls to monitor relevant activities. These controls are designed to detect unauthorised or unintended changes, misuse of data, or violations of operational policies, and enable timely and appropriate response actions."}],"title":"OIS-04 Basic 03B"},{"id":"ois-04-04b","class":"basic","parts":[{"id":"ois-04-04b_stmt","name":"statement","prose":"An inventory consisting of conflicting tasks, responsibilities and resolving measures is established and maintained by the cloud service provider. For the assignment, change or revocation of roles, rights and authorities, the cloud service provider enforces the segregation of duties."}],"title":"OIS-04 Basic 04B"},{"id":"ois-04-01ac","class":"additional-complement","parts":[{"id":"ois-04-01ac_stmt","name":"statement","prose":"To resolve conflicting roles, measures associated with the segregation of duties are monitored and enforced by the cloud service provider."}],"title":"OIS-04 Additional Complement 01AC"},{"id":"ois-04-02ac","class":"additional-complement","parts":[{"id":"ois-04-02ac_stmt","name":"statement","prose":"Timely and appropriate remediation measures address any deviations identified during monitoring."}],"title":"OIS-04 Additional Complement 02AC"}]},{"id":"ois-05","title":"Threat Intelligence","controls":[{"id":"ois-05-01b","class":"basic","parts":[{"id":"ois-05-01b_stmt","name":"statement","prose":"The cloud service provider collects information from selected internal and external sources to gain a comprehensive view of the threat landscape that lead to cybersecurity risks."},{"id":"ois-05-01b_guidance-1","name":"guidance","prose":"Internal sources that can be used to collect information include, for example, the cloud service provider's internal security monitoring. External sources that can be used to collect information include, for example, threat intelligence feeds from government agencies, commercial threat intelligence providers or industry consortiums.\nThreat intelligence generally includes different areas like cybersecurity risk intelligence gathering (e.g. monitoring relevant internal or external sources), threat modelling and risk management."}],"title":"OIS-05 Basic 01B"},{"id":"ois-05-02b","class":"basic","parts":[{"id":"ois-05-02b_stmt","name":"statement","prose":"The collected information is correlated and analysed to identify its potential impact on the cloud service provider's organisation."},{"id":"ois-05-02b_guidance-1","name":"guidance","prose":"This process can, for example, include correlating threat intelligence with organisational assets, vulnerabilities, and business processes to identify relevant and actionable threats. The results can be used to provide regular threat briefings to cloud service provider's management and security teams."}],"title":"OIS-05 Basic 02B"},{"id":"ois-05-03b","class":"basic","parts":[{"id":"ois-05-03b_stmt","name":"statement","prose":"The cloud service provider integrates threat intelligence insights into its risk management process (cf. OIS-07, OIS-08 and OIS-09)."},{"id":"ois-05-03b_guidance-1","name":"guidance","prose":"If a threat model is used for this process, the cloud service provider can, for example:\n\n1. Use structured methodologies (e.g., STRIDE, PASTA, LINDDUN) appropriate to the cloud service architecture;\n2. Map current threat landscape intelligence to specific system components, data flows, and trust boundaries;\n3. Incorporate real-time threat intelligence to update threat models dynamically rather than relying on static annual assessments;\n4. Consider emerging attack vectors, techniques, and procedures (TTPs) documented in frameworks such as MITRE ATT&CK; and\n5. Account for supply chain and third-party risks through extended threat modelling.\n\nThe aim of threat modelling is to ensure that the current internal and external threats are reflected in risk handling measures."}],"title":"OIS-05 Basic 03B"}]},{"id":"ois-06","title":"Contact with Relevant Government Agencies and Interest Groups","controls":[{"id":"ois-06-01b","class":"basic","parts":[{"id":"ois-06-01b_stmt","name":"statement","prose":"If the cloud service is used by public sector organisations in Germany, the cloud service provider establishes and maintains contacts with the National IT Situation Centre and the CERT Association of the BSI as appropriate."},{"id":"ois-06-01b_guidance-1","name":"guidance","prose":"Public sector organisations in Germany are e.g. ministries and authorities. If the cloud service provider does not have customers in the public sector, this criterion is not applicable.\n\nAs appropriate means that contacts are established when there is an actual need to do so. For instance, establishing contact with CERT typically involves the reporting of security incidents to CERT and following CERT's communication channels to stay informed about current threats, vulnerabilities and security guidance. Maintaining contact in the sense of OIS-06.01B does in this instance not require the cloud service provider to proactively communicate with CERT unprompted.\n\nFor KRITIS (critical infrastructure), as defined in section 2(10) of the BSI Act (BSIG), similar requirements to maintain contact with government agencies and stakeholders may apply under German national law."}],"title":"OIS-06 Basic 01B"}]},{"id":"ois-07","title":"Risk Management Policy","controls":[{"id":"ois-07-01b","class":"basic","parts":[{"id":"ois-07-01b_stmt","name":"statement","prose":"Policies and procedures for risk management procedures are documented, communicated and provided in accordance with SP-01. Risk management procedures are based on a methodology for risk assessments. The methodology allows comparability and reproducibility for the following aspects:\n\n1. Identification of cybersecurity risks and other risks associated with the loss of confidentiality, integrity, availability and authenticity of information within the scope of the ISMS and assigning risk owners;\n2. Analysis of the probability and impact of occurrence and determination of the level of risk;\n3. Evaluation of the risk assessment based on defined criteria for risk acceptance and prioritisation of risk management;\n4. Treatment of risks through measures, including approval of authorisation and acceptance of residual risks by risk owners;\n5. Documentation of the activities implemented to enable consistent, valid and comparable results; and\n6. Evaluation of the risk assessment and the status of risk treatment plans by the level of management responsible for the security of the cloud service."},{"id":"ois-07-01b_guidance-1","name":"guidance","prose":"The risk level can be determined by qualitative, semiquantitative and quantitative methods (cf. ISO 31010) based on the likelihood and impact of the risks.\n\nFor identifying, evaluating, and prioritising potential threats and vulnerabilities associated with processes, systems, and data flows, threat modelling can provide a structured methodology: The cloud service provider can systematically analyse attack vectors and possible impacts to support auditors and stakeholders in validating the suitability of the design of implemented controls, highlight gaps in existing security measures, and ensure alignment with best practices for proactive risk mitigation."}],"title":"OIS-07 Basic 01B"}]},{"id":"ois-08","title":"Application of the Risk Management Policy - Risk Assessment","controls":[{"id":"ois-08-01b","class":"basic","parts":[{"id":"ois-08-01b_stmt","name":"statement","prose":"The cloud service provider performs the risk management process specified by OIS-07 as needed and at least annually."},{"id":"ois-08-01b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."},{"id":"ois-08-01b_guidance-2","name":"guidance","prose":"Examples of scenarios in which the risk management process may be executed 'as needed' include, but are not limited to, the following:\n\n1. Changes to the threat landscape (cf. OIS-05);\n2. Security incidents or business disruptions;\n3. Changes to the cloud service provider's legal, regulatory, self-imposed and contractual requirements relevant to the information security of the cloud service (cf. COM-01);\n4. Changes to the cloud service provider's organisational structure with impact on roles, responsibilties or procedures for provisioning the cloud service;\n5. Changes to the achitecture of the cloud service (cf. OPS-31);\n6. Events related to the cloud service provider's service organisations (cf. SSO-05);\n7. Exceptions to policies or procedures (cf. SP-03); and\n8. Identification of critical vulnerabilities (cf. OPS-22) or compliance deviations (cf. COM-03)."}],"title":"OIS-08 Basic 01B"},{"id":"ois-08-02b","class":"basic","parts":[{"id":"ois-08-02b_stmt","name":"statement","prose":"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\n1. Processing, storage or transmission of cloud service customer data and cloud service derived data with different protection needs;\n2. Occurrence of vulnerabilities and incidents in technical protective measures for separating shared resources;\n3. Attacks via access points, including interfaces accessible from public networks and accidentally exposed interfaces;\n4. Dependencies on service organisations;\n5. An encryption and key management risk programme which addresses the risks of unauthorised disclosure, modification, destruction, or information loss of cryptographic keys; and\n6. Separation of cloud service customers and their data within systems, networks and storage."},{"id":"ois-08-02b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."},{"id":"ois-08-02b_guidance-2","name":"guidance","prose":"Shared resources are e.g. networks, RAM or storage.\n\nWhen determining protection needs of customer data, regulatory requirements applicable to customer data should be considered such as PCI-DSS, HIPAA, DORA (regulation on digital operational resilience for the financial sector and amending regulations), NIS 2 Directive and KRITIS."}],"title":"OIS-08 Basic 02B"},{"id":"ois-08-03b","class":"basic","parts":[{"id":"ois-08-03b_stmt","name":"statement","prose":"Policies and procedures covering risk assessments relevant for the delivery and operation of the cloud service are implemented by the cloud service provider."},{"id":"ois-08-03b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."}],"title":"OIS-08 Basic 03B"},{"id":"ois-08-04b","class":"basic","parts":[{"id":"ois-08-04b_stmt","name":"statement","prose":"The risk assessment's results are provided to relevant internal parties."},{"id":"ois-08-04b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."},{"id":"ois-08-04b_guidance-2","name":"guidance","prose":"Relevant internal parties can include the cloud service provider's management and security teams."}],"title":"OIS-08 Basic 04B"},{"id":"ois-08-05b","class":"basic","parts":[{"id":"ois-08-05b_stmt","name":"statement","prose":"Relevant external parties are provided with information, specific to the parties' purposes, resulting from the risk assessments."},{"id":"ois-08-05b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."},{"id":"ois-08-05b_guidance-2","name":"guidance","prose":"Relevant external parties can include cloud service customers, subservice organisations and regulatory agencies.\n\nInformation that can be relevant in this context includes information about identified vulnerabilities, security incidents and threat intelligence.\n\nThe cloud service provider can choose to make this information accessible through its SSRM (cf. OIS-03), its documentation and guidelines (cf. PSS-01) or its processes for informing cloud service customers about known vulnerabilities (cf. PSS-03)."}],"title":"OIS-08 Basic 05B"},{"id":"ois-08-06b","class":"basic","parts":[{"id":"ois-08-06b_stmt","name":"statement","prose":"The analysis, evaluation and treatment of risks, including the approval of actions and acceptance of residual risks, is reviewed by the risk owners for adequacy at least annually. In addition, in case of significant changes to the cloud service, a review is carried out focusing on the parts of the risk assessment relevant to the change."},{"id":"ois-08-06b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."}],"title":"OIS-08 Basic 06B"},{"id":"ois-08-01as","class":"additional-sharpen","parts":[{"id":"ois-08-01as_stmt","name":"statement","prose":"The cloud service provider performs the risk management process as specified by OIS-07 as needed and at least annually. The evolution of the risks is monitored and the risk assessments are reviewed correspondingly."},{"id":"ois-08-01as_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"OIS-08 Additional Sharpen 01AS"},{"id":"ois-08-01ac","class":"additional-complement","parts":[{"id":"ois-08-01ac_stmt","name":"statement","prose":"The cloud service provider integrates information security risks into a documented Enterprise Risk Management (ERM) programme which addresses the following aspects:\n\n1. Integration of information security risks at the enterprise level to promote information security risk-awareness across the entire organisation;\n2. Leadership awareness and support for identification, analysis and treatment of information security risks to foster continuous improvement; and\n3. Consideration of the cloud service provider's strategic objectives when managing risks to align risk treatment with the organisation's goals."},{"id":"ois-08-01ac_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."}],"title":"OIS-08 Additional Complement 01AC"},{"id":"ois-08-02ac","class":"additional-complement","parts":[{"id":"ois-08-02ac_stmt","name":"statement","prose":"When identifying risks, the cloud service provider also takes into account the detection of unusual and harmful actions of internal threat actors, insofar as it is applicable to the cloud service provided and is within the area of responsibility of the cloud service provider."},{"id":"ois-08-02ac_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service customer when using the cloud service are not covered by this criterion. When outsourcing activities for the provision of cloud services to service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-08 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-08 subcriteria."}],"title":"OIS-08 Additional Complement 02AC"}]},{"id":"ois-09","title":"Application of the Risk Management Policy - Risk Treatment","controls":[{"id":"ois-09-01b","class":"basic","parts":[{"id":"ois-09-01b_stmt","name":"statement","prose":"The risk treatment is prioritised corresponding to the level of cybersecurity risks associated with the cloud service."},{"id":"ois-09-01b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."},{"id":"ois-09-01b_guidance-2","name":"guidance","prose":"The priorisation can, for example, be performed by setting appropriate time limits for the treatment of the risks."}],"title":"OIS-09 Basic 01B"},{"id":"ois-09-02b","class":"basic","parts":[{"id":"ois-09-02b_stmt","name":"statement","prose":"A risk treatment plan according to the risk assessment (cf. OIS-08) is documented and implemented."},{"id":"ois-09-02b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."}],"title":"OIS-09 Basic 02B"},{"id":"ois-09-03b","class":"basic","parts":[{"id":"ois-09-03b_stmt","name":"statement","prose":"Actions defined in the risk treatment plan reduce the risk level to a residual risk that risk owners are able to accept."},{"id":"ois-09-03b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."}],"title":"OIS-09 Basic 03B"},{"id":"ois-09-04b","class":"basic","parts":[{"id":"ois-09-04b_stmt","name":"statement","prose":"The risk treatment plan, as well as suitably summarised and abstracted versions, is provided to relevant internal parties."},{"id":"ois-09-04b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."}],"title":"OIS-09 Basic 04B"},{"id":"ois-09-05b","class":"basic","parts":[{"id":"ois-09-05b_stmt","name":"statement","prose":"Based on contractual agreements and relevant legal and regulatory requirements, the cloud service provider determines which relevant external parties are provided with information, specific to the parties' purposes, about the risk treatment plan. The cloud service provider also determines the extent to which this should happen."},{"id":"ois-09-05b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."}],"title":"OIS-09 Basic 05B"},{"id":"ois-09-06b","class":"basic","parts":[{"id":"ois-09-06b_stmt","name":"statement","prose":"The selected options for risk treatment are reviewed by the risk owners every time the risk assessment is modified. The review considers the criteria for risk acceptance and prioritisation of risk treatment."},{"id":"ois-09-06b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."},{"id":"ois-09-06b_guidance-2","name":"guidance","prose":"Options for risk treatment may involve one or more of the following:\n\n1. Avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;\n2. Taking or increasing the risk in order to pursue an opportunity;\n3. Removing the risk source;\n4. Changing the likelihood;\n5. Changing the consequences;\n6. Sharing the risk (e.g. through contracts, buying insurance); and\n7. Retaining the risk by informed decision."}],"title":"OIS-09 Basic 06B"},{"id":"ois-09-07b","class":"basic","parts":[{"id":"ois-09-07b_stmt","name":"statement","prose":"In case of the cloud service provider sharing risks with the cloud service customers, the cloud service provider maps shared risks to complementary customer controls and describes them in the user documentation (cf. PSS-01)."},{"id":"ois-09-07b_guidance-1","name":"guidance","prose":"This criterion applies only to risks that reside within the area of responsibility of the cloud service provider. Risks that arise for the cloud service 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\nCloud service providers may leverage established risk management standards, such as ISO 27005 or the ISO 31000 family of standards to address risks related to the cloud service. Risk management procedures already implemented at the cloud service provider may be leveraged for OIS-09 where possible to reduce redundancies. Documentation of risks, treatment plans and risk acceptance in the sense of this criterion does not require specific formal frameworks; lean forms of documentation can be leveraged wherever appropriate to address the OIS-09 subcriteria."},{"id":"ois-09-07b_guidance-2","name":"guidance","prose":"Risks that the cloud service provider shares with the cloud service customer are described as part of the SSRM (cf. OIS-03)."}],"title":"OIS-09 Basic 07B"}]},{"id":"ois-10","title":"Information Security in Project Management","controls":[{"id":"ois-10-01b","class":"basic","parts":[{"id":"ois-10-01b_stmt","name":"statement","prose":"Information security is integrated into project management. Risks are assessed by the cloud service provider according to OIS-07, and the risk treatment is performed if necessary. Risks are treated in all projects that may have a direct or significant impact on the provision, operation, or security of the cloud service."},{"id":"ois-10-01b_guidance-1","name":"guidance","prose":"Risks with a significant impact are those that, if they were to occur, would cause a damage of such a scale as to materially affect the information security of the cloud service, control effectiveness or service commitments of the cloud service provider."}],"title":"OIS-10 Basic 01B"}]}]},{"id":"sp","title":"Security Policies and Procedures (SP)","controls":[{"id":"sp-01","title":"Documentation, Communication and Provision of Policies and Procedures","controls":[{"id":"sp-01-01b","class":"basic","parts":[{"id":"sp-01-01b_stmt","name":"statement","prose":"Policies and procedures (incl. frameworks and guidelines) are derived from the information security policy and are documented according to a uniform structure. The policies and procedures describe at least the following aspects:\n\n1. Objectives;\n2. Scope;\n3. Roles and responsibilities, including personnel qualification requirements and the establishment of substitution rules;\n4. Roles and dependencies on other organisations (especially cloud service customers and subservice organisations);\n5. Steps for the execution of the security strategy; and\n6. Applicable legal and regulatory requirements."},{"id":"sp-01-01b_guidance-1","name":"guidance","prose":"Policies and procedures are required for the following basic criteria in which the content is specified in more detail:\n\n1. Information Security Policy (OIS-02)\n2. Risk Management Policy (OIS-07);\n3. Remote Working - Policy (HR-07);\n4. Asset Management Framework (AM-01);\n5. Policy for the Proper and Secure Use of Assets (AM-05);\n6. Physical Security and Environmental Control Requirements (PS-01);\n7. Physical Site Access Control (PS-04);\n8. Workplace Security Requirements (PS-08);\n9. Protection Against Malware - Policies and Procedures (OPS-04);\n10. Data Backup and Recovery - Policies and Procedures (OPS-06);\n11. Logging and Monitoring - Policies and Procedures (OPS-10);\n12. Logging and Monitoring - Policies and Procedures for Handling Cloud Service Derived Data and Account Data (OPS-11);\n13. Managing Vulnerabilities - Policies and Procedures (OPS-18);\n14. Managing Incidents and Crashes - Policies and Procedures (OPS-19);\n15. Managing Vulnerabilities - Patch Management Policies and Procedures (OPS-27);\n16. Separation of Datasets - Policies and Procedures (OPS-30);\n17. Confidential Computing - Policies and Procedures (OPS-32);\n18. Container Management - Policies and Procedures (OPS-34);\n19. Policy for Identities and Access Rights (IAM-01);\n20. Authentication Mechanisms (authentication policy) (IAM-08);\n21. Policy for the Use of Cryptographic Mechanisms (CRY-01);\n22. Technical Safeguards (COS-01);\n23. Policies for Data Transmission (COS-08);\n24. Policies for the Development/Procurement of System Components (DEV-01);\n25. Policies for Changes to System Components (DEV-03);\n26. Secure Use of Third Party Hardware and Software (policies and procedures for the use of third party and open source software) (DEV-14);\n27. Policies and Procedures for Controlling and Monitoring Service Organisations (SSO-01);\n28. Controlling Exchanges with Suppliers of Functional Components (SSO-08);\n29. Policy for Security Incident Management (SIM-01);\n30. Business Continuity and Emergency Management System (BCM-01);\n31. Policy for Planning and Conducting Audits (COM-02); and\n32. Communication of Technical Procedures for Data Disclosure in Investigation Requests (INQ-04)."}],"title":"SP-01 Basic 01B"},{"id":"sp-01-02b","class":"basic","parts":[{"id":"sp-01-02b_stmt","name":"statement","prose":"The policies and procedures are communicated and made available to all relevant internal and external personnel of the cloud service provider in an appropriate manner."},{"id":"sp-01-02b_guidance-1","name":"guidance","prose":"The appropriateness of the demand-oriented communication and provision should 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\n1. Integration of guidelines and procedures in the onboarding of new personnel;\n2. Training and information campaigns when adopting new or revising existing policies and procedures; and\n3. Form of provision."}],"title":"SP-01 Basic 02B"},{"id":"sp-01-03b","class":"basic","parts":[{"id":"sp-01-03b_stmt","name":"statement","prose":"The policies and procedures are subject to version control."}],"title":"SP-01 Basic 03B"},{"id":"sp-01-04b","class":"basic","parts":[{"id":"sp-01-04b_stmt","name":"statement","prose":"The policies and procedures are approved by the top management of the cloud service provider or an authorised body."}],"title":"SP-01 Basic 04B"}]},{"id":"sp-02","title":"Review and Approval of Policies and Procedures","controls":[{"id":"sp-02-01b","class":"basic","parts":[{"id":"sp-02-01b_stmt","name":"statement","prose":"Information security policies and procedures are reviewed for adequacy by the cloud service provider's subject matter experts at least annually, and in case of significant changes to the cloud service. The review shall consider at least the following aspects:\n\n1. Organisational and technical changes in the procedures for providing the cloud service; and\n2. Legal and regulatory changes in the cloud service provider's environment."},{"id":"sp-02-01b_guidance-1","name":"guidance","prose":"During an ISO 27001 certification audit, the controls to this criteria are most likely also tested. If it is a joint audit (C5 and ISO), efficiency of audit-once-certify-many may be gained here. If it is a separate audit, the auditor of the C5 attestation engagement can choose to inspect the ISO report instead of testing the control again, if the provided evidence is conclusive enough."}],"title":"SP-02 Basic 01B"},{"id":"sp-02-02b","class":"basic","parts":[{"id":"sp-02-02b_stmt","name":"statement","prose":"Revised policies and procedures are approved by the appropriate level of management before they become effective and are communicated and made available to internal and external personnel."},{"id":"sp-02-02b_guidance-1","name":"guidance","prose":"Significant changes include, but are not limited to, any circumstances or events that materially affect the scope, effectiveness, or objectives of the information security policy. Specifically, significant changes are e.g.:\n\n1. Major technical or architectural changes to the cloud platform (e.g., adoption of new infrastructure services, cloud migration, introduction of a new service offering);\n2. Substantial updates to national or international laws, regulations, or sector-specific standards (e.g., NIS2, DORA, GDPR) that impact information security obligations;\n3. Reorganisation or merger/acquisition of organisational units that affect leadership, decision-making, or key responsibilities related to security;\n4. Significant changes in contractual requirements, risk assessments, operational processes, or threat landscape (e.g., new threat intelligence indicating emerging risks, supply chain incidents);\n5. Major security incidents or breaches requiring incident response revision;\n6. Launch or decommissioning of service components impacting customer data or trust boundaries; and\n7. Changes in the composition or responsibilities of top management or the information security steering committee.\n\nFor an efficient review the cloud service provider can document the nature of each significant change, the rationale for review, and the result of policy adjustments. Automated tracking of policy changes and manual verification of content can also be integrated into the review workflow.\n\nThe top level management is an appropriate level of management for approving the information security policy."}],"title":"SP-02 Basic 02B"}]},{"id":"sp-03","parts":[{"id":"sp-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they obtain information from the cloud service provider about exceptions to information security policies and procedures in order to assess and appropriately manage the associated risks to their own information security.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Exceptions from Existing Policies and Procedures","controls":[{"id":"sp-03-01b","class":"basic","parts":[{"id":"sp-03-01b_stmt","name":"statement","prose":"All exceptions to policies and procedures for information security are maintained in a list, including also the controls associated with the exceptions."},{"id":"sp-03-01b_guidance-1","name":"guidance","prose":"During an ISO 27001 certification audit, the controls to this criteria are most likely also tested. If it is a joint audit (C5 and ISO), efficiency of audit-once-certify-many may be gained here. If it is a separate audit, the auditor of the C5 attestation engagement can choose to inspect the ISO report instead of testing the control again, if the provided evidence is conclusive enough."},{"id":"sp-03-01b_guidance-2","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Basic 01B"},{"id":"sp-03-02b","class":"basic","parts":[{"id":"sp-03-02b_stmt","name":"statement","prose":"Exceptions to the policies and procedures for information security as well as respective controls go through risk management procedures in accordance with OIS-07, including approval of these exceptions and acceptance of the associated risks by the risk owners."},{"id":"sp-03-02b_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Basic 02B"},{"id":"sp-03-03b","class":"basic","parts":[{"id":"sp-03-03b_stmt","name":"statement","prose":"The risk management procedures in accordance with OIS-07, also take into account the aggregated risk from a combination of single exceptions."},{"id":"sp-03-03b_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Basic 03B"},{"id":"sp-03-04b","class":"basic","parts":[{"id":"sp-03-04b_stmt","name":"statement","prose":"The approvals of exceptions are documented, with a defined validity and reviewed for appropriateness at least annually by the risk owners or by the top management. This review also takes into account the aggregated risk from a combination of single exceptions."},{"id":"sp-03-04b_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Basic 04B"},{"id":"sp-03-05b","class":"basic","parts":[{"id":"sp-03-05b_stmt","name":"statement","prose":"Exceptions in information security policies and procedures that would result in a deviation (cf. 3.4.12) from any applicable C5 criterion within the scope of an assurance engagement (cf. 3.4.1) are not permitted."},{"id":"sp-03-05b_guidance-1","name":"guidance","prose":"This criterion addresses policies and procedures and demands that on this level, no codified deviations from applicable C5 criteria are permitted."},{"id":"sp-03-05b_guidance-2","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Basic 05B"},{"id":"sp-03-01ac","class":"additional-complement","parts":[{"id":"sp-03-01ac_stmt","name":"statement","prose":"The exceptions to policies or procedures are approved by the appropriate level of management."},{"id":"sp-03-01ac_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."},{"id":"sp-03-01ac_guidance-2","name":"guidance","prose":"Appropriate level of management for approval are in most cases either the level of management that approved the policies or procedures or the level of management to whom this task is delegated."}],"title":"SP-03 Additional Complement 01AC"},{"id":"sp-03-02ac","class":"additional-complement","parts":[{"id":"sp-03-02ac_stmt","name":"statement","prose":"The cloud service provider monitors the list of exceptions to prevent the expiration of approved exceptions and ensure the up-to-dateness of all reviews and approvals."},{"id":"sp-03-02ac_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Additional Complement 02AC"},{"id":"sp-03-03ac","class":"additional-complement","parts":[{"id":"sp-03-03ac_stmt","name":"statement","prose":"Any exceptions for which deviations were identified during monitoring are addressed through timely and appropriate remediation measures."},{"id":"sp-03-03ac_guidance-1","name":"guidance","prose":"Exceptions in the sense of the criterion can have organisational or technical causes, such as:\n\n1. An organisational unit should deviate from the intended processes and procedures in order to meet the requirements of a cloud service customer; and\n2. A system component lacks technical properties to configure it according to the applicable requirements."}],"title":"SP-03 Additional Complement 03AC"}]}]},{"id":"hr","title":"Personnel (HR)","controls":[{"id":"hr-01","title":"Verification of Qualification and Trustworthiness","controls":[{"id":"hr-01-01b","class":"basic","parts":[{"id":"hr-01-01b_stmt","name":"statement","prose":"The cloud service provider identifies for the production environment which roles within the organisation can access cloud service customer data, cloud service derived data, cloud service provider data, account data or system components under the cloud service provider's responsibility."},{"id":"hr-01-01b_guidance-1","name":"guidance","prose":"This criterion applies to both existing and newly hired personnel. Roles with access to these data types or system components can, depending on their access rights, include, but are not limited to:\n\n1. Cloud software engineers and developers;\n2. Cloud architects and cloud infrastructure engineers;\n3. Cloud platform engineers and DevOps engineers;\n4. System operations engineers and managers;\n5. Cloud operations engineers and managers;\n6. Cloud network engineers and architecture leads;\n7. Cloud security engineers, administrators and security architects;\n8. Cloud security operations specialists and analysts;\n9. Storage and database engineers;\n10. Technical account managers and customer account managers;\n11. Customer support engineers;\n12. IAM administrators and access management specialists;\n13. Cloud compliance managers and risk and compliance analysts; and\n14. Information security officers and data protection officers.\n\nPersonnel refers to both internal and external personnel."}],"title":"HR-01 Basic 01B"},{"id":"hr-01-02b","class":"basic","parts":[{"id":"hr-01-02b_stmt","name":"statement","prose":"The competency and integrity of all internal and external personnel to which these roles are assigned is verified prior to employment. The verification considers the following measures, to the extent permitted by local legislation and regulation and as considered appropriate by the cloud service provider to mitigate risks related to inappropriate access to the respective data type:\n\n1. Verification of the person's identity via identity card or passport;\n2. Verification of professional experience through the CV;\n3. Verification of academic titles and degrees;\n4. Request for a certificate of good conduct, police clearance or other national equivalents; and\n5. Evaluation of susceptibility to blackmail."},{"id":"hr-01-02b_guidance-1","name":"guidance","prose":"This criterion applies to both existing and newly hired personnel. External personnel in the sense of the criterion is that which performs activities in accordance with the processes and procedures of the cloud service provider and that has potential access to cloud service customer data or cloud service derived data. Personnel of service organisations that performs activities according to the service organisation's own processes and procedures is not covered by this criterion.\n\nPermissible verifications of competency and integrity are governed by applicable local laws and the roles of the personnel. In some jurisdictions, the collection, processing, or disclosure of such information is fundamentally restricted or even prohibited, meaning they may be unable to be obtained at all or only in a very limited form. Where permitted, explicit consent by the personnel may be required depending on the nature and scope of the checks. These legal constraints also apply to any analyses concerning blackmailing.\n\nThe verification of qualification and trustworthiness can be supported by specialised service providers or be based on voluntary self-disclosure of the personnel. Depending on national legislation, national equivalents of the German certificate of good conduct ('Führungszeugnis') may also be permitted. Assessing the vulnerability of potential personnel to blackmail can involve evaluating their creditworthiness. However, this assessment may only be legally permissible for positions with significant financial responsibility, depending on local regulations.\n\nRisks related to inappropriate access to cloud service customer data may be mitigated by the use of encryption or monitoring system access for suspicious events. Although such measures are not supposed to completely substitute the above-mentioned verification measures, the extent of such measures may be reduced."}],"title":"HR-01 Basic 02B"},{"id":"hr-01-03b","class":"basic","parts":[{"id":"hr-01-03b_stmt","name":"statement","prose":"The cloud service provider considers changes in personnel roles or employment status that may impact access rights, responsibilities, or risk exposure, and identifies and mitigates related risks."}],"title":"HR-01 Basic 03B"},{"id":"hr-01-04b","class":"basic","parts":[{"id":"hr-01-04b_stmt","name":"statement","prose":"The cloud service provider classifies security-sensitive positions according to their level of risk, including IT administration roles and any positions with access to cloud service customer data or to system components used to provide the cloud service in the production environment."}],"title":"HR-01 Basic 04B"},{"id":"hr-01-05b","class":"basic","parts":[{"id":"hr-01-05b_stmt","name":"statement","prose":"The cloud service provider assesses the competence and integrity of its personnel before transfer or promotion into a role with a higher risk classification."}],"title":"HR-01 Basic 05B"},{"id":"hr-01-06b","class":"basic","parts":[{"id":"hr-01-06b_stmt","name":"statement","prose":"The intensity of the assessment defined in this criterion is in proportion to the business context, the sensitivity of the information that the personnel will access, and the associated risks."}],"title":"HR-01 Basic 06B"},{"id":"hr-01-01ac","class":"additional-complement","parts":[{"id":"hr-01-01ac_stmt","name":"statement","prose":"The cloud service provider defines in the human resource policy positions with levels and risk classification that require regular assessment of competence and integrity. The cloud service provider annually reviews their assessment of competence and integrity for personnel belonging to the defined positions."},{"id":"hr-01-01ac_guidance-1","name":"guidance","prose":"Cloud service providers can implement various methods to assess competence and integrity of personnel in high risk positions, such as:\n\n1. Self-disclosure of significant financial interests to determine conflicts of interest and susceptibility to blackmail;\n2. Regular checking of certificates of good conduct, police clearance or other national equivalents;\n3. Regular self-declaration of commitment with applicable policies and obligations;\n4. Enforcing regular ethics and compliance trainings, including certification and testing of the personnel's understanding of applicable requirements and policies;\n5. Enforcing regular participation in assessment centers to evaluate personnel's competence and integrity; and\n6. Regular checks of personnel against national and international sanctions lists."}],"title":"HR-01 Additional Complement 01AC"}]},{"id":"hr-02","title":"Employment Terms and Conditions","controls":[{"id":"hr-02-01b","class":"basic","parts":[{"id":"hr-02-01b_stmt","name":"statement","prose":"The cloud service provider ensures that the employment terms and conditions reflect applicable legal and regulatory requirements in accordance with SP-01."}],"title":"HR-02 Basic 01B"},{"id":"hr-02-02b","class":"basic","parts":[{"id":"hr-02-02b_stmt","name":"statement","prose":"The cloud service provider's internal and external personnel are required by employment terms and conditions to comply with the code of ethics and the information security policy, as well as the policies, procedures and instructions based on it."}],"title":"HR-02 Basic 02B"},{"id":"hr-02-03b","class":"basic","parts":[{"id":"hr-02-03b_stmt","name":"statement","prose":"The cloud service provider ensures that a non-disclosure provision is included in the terms for all internal and external personnel. The non-disclosure provision covers any information, including anonymised and decontextualised information, that the personnel obtains or generates as part of the cloud service."},{"id":"hr-02-03b_guidance-1","name":"guidance","prose":"These agreements are prescribed in more detail in HR-06."}],"title":"HR-02 Basic 03B"},{"id":"hr-02-04b","class":"basic","parts":[{"id":"hr-02-04b_stmt","name":"statement","prose":"The cloud service provider instructs its personnel on the code of ethics and the information security policy, as well as the policies, procedures and instructions based on it, before access is granted to any cloud service customer data, cloud service derived data, cloud service provider data and account data or system components under the responsibility of the cloud service provider used to provide the cloud service in the production environment."}],"title":"HR-02 Basic 04B"},{"id":"hr-02-05b","class":"basic","parts":[{"id":"hr-02-05b_stmt","name":"statement","prose":"Additionally, the cloud service provider requires the code of ethics and the information security policy, as well as the policies, procedures and instructions based on it, to be acknowledged by the internal and external personnel in a documented form before access is granted to any of the aforementioned data or system components."}],"title":"HR-02 Basic 05B"}]},{"id":"hr-03","title":"Security Training and Awareness Programme","controls":[{"id":"hr-03-01b","class":"basic","parts":[{"id":"hr-03-01b_stmt","name":"statement","prose":"The cloud service provider operates a target group-oriented security awareness and training programme."},{"id":"hr-03-01b_guidance-1","name":"guidance","prose":"The target groups may be defined considering job function, job position and the associated risk classification. Target groups serve to simplify and systematise the security training and awareness programme."}],"title":"HR-03 Basic 01B"},{"id":"hr-03-02b","class":"basic","parts":[{"id":"hr-03-02b_stmt","name":"statement","prose":"All internal and external personnel of the cloud service provider undergoes a role-based training programme regularly and when changing job function, taking into consideration at least the risk classification and technical responsibilities of their position."}],"title":"HR-03 Basic 02B"},{"id":"hr-03-03b","class":"basic","parts":[{"id":"hr-03-03b_stmt","name":"statement","prose":"The programme is regularly updated based on changes to policies and procedures and the current threat situation and includes the following aspects insofar as they are applicable to each personnel's role:\n\n1. Handling system components used to provide the cloud service in the production environment in accordance with applicable policies and procedures;\n2. Handling cloud service customer data, cloud service derived data, cloud service provider data and account data in accordance with applicable policies and procedures and applicable legal and regulatory requirements;\n3. Information about the current threat situation;\n4. Correct behaviour in the event of security incidents;\n5. Security best practices; and\n6. Secure development."}],"title":"HR-03 Basic 03B"},{"id":"hr-03-04b","class":"basic","parts":[{"id":"hr-03-04b_stmt","name":"statement","prose":"The learning outcomes achieved through the awareness and training programme are measured and evaluated."}],"title":"HR-03 Basic 04B"},{"id":"hr-03-02as","class":"additional-sharpen","parts":[{"id":"hr-03-02as_stmt","name":"statement","prose":"All internal and external personnel of the cloud service provider undergoes a role-based training programme at least annually and when changing job function, taking into consideration at least the risk classification and technical responsibilities of their position."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"HR-03 Additional Sharpen 02AS"},{"id":"hr-03-01ac","class":"additional-complement","parts":[{"id":"hr-03-01ac_stmt","name":"statement","prose":"The cloud service provider monitors the completion of the security awareness and training programme."}],"title":"HR-03 Additional Complement 01AC"},{"id":"hr-03-02ac","class":"additional-complement","parts":[{"id":"hr-03-02ac_stmt","name":"statement","prose":"Timely and appropriate remediation measures address any deviations identified during monitoring."}],"title":"HR-03 Additional Complement 02AC"},{"id":"hr-03-03ac","class":"additional-complement","parts":[{"id":"hr-03-03ac_stmt","name":"statement","prose":"The learning outcomes achieved through the awareness and training programme are measured and evaluated in a target group-oriented manner."},{"id":"hr-03-03ac_guidance-1","name":"guidance","prose":"The measurement and evaluation of learning outcomes in a target group-oriented manner, as specified by the additional criterion, do not require assessing each member of the personnel individually. Instead, evaluations can be performed at an aggregated level, focusing on the overall effectiveness of the training program for specific target groups. This approach allows for the identification of trends and areas for improvement within the program while respecting the personnel's privacy requirements."}],"title":"HR-03 Additional Complement 03AC"},{"id":"hr-03-04ac","class":"additional-complement","parts":[{"id":"hr-03-04ac_stmt","name":"statement","prose":"The measurements cover quantitative and qualitative aspects."}],"title":"HR-03 Additional Complement 04AC"},{"id":"hr-03-05ac","class":"additional-complement","parts":[{"id":"hr-03-05ac_stmt","name":"statement","prose":"The results are used to improve the awareness and training programme."}],"title":"HR-03 Additional Complement 05AC"}]},{"id":"hr-04","title":"Disciplinary Measures","controls":[{"id":"hr-04-01b","class":"basic","parts":[{"id":"hr-04-01b_stmt","name":"statement","prose":"The cloud service provider ensures that the policies and procedures concerning disciplinary measures reflect applicable legal and regulatory requirements in accordance with SP-01."}],"title":"HR-04 Basic 01B"},{"id":"hr-04-02b","class":"basic","parts":[{"id":"hr-04-02b_stmt","name":"statement","prose":"In the event of violations of policies and procedures or applicable legal and regulatory requirements, actions are taken in accordance with a defined policy that includes the following aspects:\n\n1. Verifying whether a violation has occurred; and\n2. Consideration of the nature and severity of the violation and its impact."}],"title":"HR-04 Basic 02B"},{"id":"hr-04-03b","class":"basic","parts":[{"id":"hr-04-03b_stmt","name":"statement","prose":"The internal and external personnel of the cloud service provider is informed about possible disciplinary measures."}],"title":"HR-04 Basic 03B"},{"id":"hr-04-04b","class":"basic","parts":[{"id":"hr-04-04b_stmt","name":"statement","prose":"The use of disciplinary measures is appropriately documented."},{"id":"hr-04-04b_guidance-1","name":"guidance","prose":"With regards to the use of disciplinary measures, the submission of anonymised evidence is acceptable and does not imply that the basic criterion is not fully fulfilled."}],"title":"HR-04 Basic 04B"}]},{"id":"hr-05","title":"Responsibilities in the Event of Termination or Change of Employment","controls":[{"id":"hr-05-01b","class":"basic","parts":[{"id":"hr-05-01b_stmt","name":"statement","prose":"Internal and external personnel has been informed about which responsibilities, arising from employment terms and conditions relating to information security, will remain in place when the employment is terminated or changed and for how long."}],"title":"HR-05 Basic 01B"}]},{"id":"hr-06","title":"Non-disclosure Agreements","controls":[{"id":"hr-06-01b","class":"basic","parts":[{"id":"hr-06-01b_stmt","name":"statement","prose":"The non-disclosure or confidentiality agreements to be agreed with internal personnel and service organisations 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."},{"id":"hr-06-01b_guidance-1","name":"guidance","prose":"A non-disclosure agreement (NDA) is a legal document and has content required by both parties to protect confidential information. Processes and procedures around media handling can be managed separately outside of the NDA. An NDA should cover:\n\n1. Which information or data types must be kept confidential;\n2. The period for which this confidentiality agreement applies;\n3. What actions must be taken upon termination of this agreement, e.g. destruction or return of data medium;\n4. How the ownership of information is regulated;\n5. What rules apply to the use and disclosure of confidential information to other partners, if necessary; and\n6. The consequences of a breach of the agreement.\n\nThese agreements are described in general in HR-02."}],"title":"HR-06 Basic 01B"},{"id":"hr-06-02b","class":"basic","parts":[{"id":"hr-06-02b_stmt","name":"statement","prose":"The agreements are to be accepted by service organisations when the contract is agreed."},{"id":"hr-06-02b_guidance-1","name":"guidance","prose":"Confidentiality or non-disclosure agreements should be signed by means of an electronic signature, insofar as this is legally binding."}],"title":"HR-06 Basic 02B"},{"id":"hr-06-03b","class":"basic","parts":[{"id":"hr-06-03b_stmt","name":"statement","prose":"The agreements are to be accepted by internal personnel of the cloud service provider before authorisation to access cloud service customer data, cloud service derived data, cloud service provider data and account data is granted."},{"id":"hr-06-03b_guidance-1","name":"guidance","prose":"Confidentiality or non-disclosure agreements should be signed by means of an electronic signature, insofar as this is legally binding."}],"title":"HR-06 Basic 03B"},{"id":"hr-06-04b","class":"basic","parts":[{"id":"hr-06-04b_stmt","name":"statement","prose":"The requirements are documented and reviewed at regular intervals (at least annually), as well as in case of significant changes to the cloud service. If the review shows that the requirements need to be adapted, the non-disclosure or confidentiality agreements are updated."}],"title":"HR-06 Basic 04B"},{"id":"hr-06-05b","class":"basic","parts":[{"id":"hr-06-05b_stmt","name":"statement","prose":"The cloud service provider informs the internal personnel and service organisations and obtains confirmation of the updated confidentiality or non-disclosure agreement."},{"id":"hr-06-05b_guidance-1","name":"guidance","prose":"Confidentiality or non-disclosure agreements should be signed by means of an electronic signature, insofar as this is legally binding."}],"title":"HR-06 Basic 05B"},{"id":"hr-06-06b","class":"basic","parts":[{"id":"hr-06-06b_stmt","name":"statement","prose":"In instances where an agreement on the updates cannot be reached, the cloud service provider assesses the resulting risks to information security according to OIS-07."}],"title":"HR-06 Basic 06B"}]},{"id":"hr-07","title":"Remote Working - Policy","controls":[{"id":"hr-07-01b","class":"basic","parts":[{"id":"hr-07-01b_stmt","name":"statement","prose":"Policies and procedures for the protection of information when personnel works remotely are documented, communicated and provided in accordance with SP-01 and address the following aspects:\n\n1. Establishing guidelines for the personnel for the safe handling and storage of sensitive information and data types;\n2. Definition of remote access security requirements;\n3. Utilisation of secure communication methods and enforcement of secure network use (e.g., VPN usage, endpoint protection, multi-factor authentication, secure communication channels); and\n4. Provision of organisation-approved equipment and prohibition of unregulated personal devices."},{"id":"hr-07-01b_guidance-1","name":"guidance","prose":"Please note that this criterion refers to off-site working places whereas PS-08.01B addresses security requirements for on-site office workplaces.\n\nThe guidelines for the personnel for safe handling and storage of sensitive information and data types refer to organisational measures the personnel is obligated to follow. Remote access security requirements refer to technical measures like e.g. MFA and VPN and also rules for the particular work place that follow from general considerations about working e.g. in public places where the screen can be spied on."}],"title":"HR-07 Basic 01B"}]},{"id":"hr-08","title":"Remote Working - Implementation","controls":[{"id":"hr-08-01b","class":"basic","parts":[{"id":"hr-08-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains the technical and organisational measures required to enable its personnel to comply with the policies and procedures for remote work (cf. HR-07)."},{"id":"hr-08-01b_guidance-1","name":"guidance","prose":"Please note that this criterion refers to off-site working places whereas PS-08.01B addresses security requirements for on-site office workplaces."}],"title":"HR-08 Basic 01B"}]}]},{"id":"am","title":"Asset Management (AM)","controls":[{"id":"am-01","title":"Asset Management Framework","controls":[{"id":"am-01-01b","class":"basic","parts":[{"id":"am-01-01b_stmt","name":"statement","prose":"An asset management framework is documented, communicated and provided according to SP-01, in which the following aspects are described:\n\n1. Identification of assets which are used to provide the cloud service in the production environment;\n2. Definition of a scheme for identifying protection needs based on information processed, stored or transmitted on the asset;\n3. Definition of asset types, considering at a minimum the differentiation of hardware and software objects;\n4. Definition of asset lifecycles based on the asset type; and\n5. Definition of procedures for inventory of hardware and software assets."},{"id":"am-01-01b_guidance-1","name":"guidance","prose":"Assets within the meaning of this domain 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. \n\nHardware objects include, but are not limited to:\n\n1. Physical and virtual infrastructure resources (e.g. servers, storage systems, network components); and\n2. End user 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 include, but are not limited to, hypervisors, containers, operating systems, databases, microservices and application programming interfaces (APIs).\n\nThe lifecycle of an asset includes, depending on the asset type:\n\n1. Acquisition;\n2. Commissioning;\n3. Maintenance;\n4. Decommissioning; and\n5. Disposal."}],"title":"AM-01 Basic 01B"},{"id":"am-01-01ac","class":"additional-complement","parts":[{"id":"am-01-01ac_stmt","name":"statement","prose":"The information collected about assets is considered in logging and monitoring applications to:\n\n1. Identify the impact on cloud services and functions in case of events that could lead to a breach of protection objectives; and \n2. Support information provided to affected cloud service customers in accordance with contractual agreements."},{"id":"am-01-01ac_guidance-1","name":"guidance","prose":"Assets within the meaning of this domain 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. \n\nHardware objects include, but are not limited to:\n\n1. Physical and virtual infrastructure resources (e.g. servers, storage systems, network components); and\n2. End user 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 include, but are not limited to, hypervisors, containers, operating systems, databases, microservices and application programming interfaces (APIs).\n\nThe lifecycle of an asset includes, depending on the asset type:\n\n1. Acquisition;\n2. Commissioning;\n3. Maintenance;\n4. Decommissioning; and\n5. Disposal."}],"title":"AM-01 Additional Complement 01AC"},{"id":"am-01-02ac","class":"additional-complement","parts":[{"id":"am-01-02ac_stmt","name":"statement","prose":"The cloud service provider assures that the inventory of assets is up-to-date by implementing monitoring measures to the process that is maintaining it."},{"id":"am-01-02ac_guidance-1","name":"guidance","prose":"Assets within the meaning of this domain 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. \n\nHardware objects include, but are not limited to:\n\n1. Physical and virtual infrastructure resources (e.g. servers, storage systems, network components); and\n2. End user 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 include, but are not limited to, hypervisors, containers, operating systems, databases, microservices and application programming interfaces (APIs).\n\nThe lifecycle of an asset includes, depending on the asset type:\n\n1. Acquisition;\n2. Commissioning;\n3. Maintenance;\n4. Decommissioning; and\n5. Disposal."}],"title":"AM-01 Additional Complement 02AC"}]},{"id":"am-02","title":"Asset Inventory","controls":[{"id":"am-02-01b","class":"basic","parts":[{"id":"am-02-01b_stmt","name":"statement","prose":"The cloud service provider maintains an asset inventory of hardware and software assets in accordance with the asset management framework (cf. AM-01)."},{"id":"am-02-01b_guidance-1","name":"guidance","prose":"Cloud service providers who procure their cloud infrastructure as virtual infrastructure from service organisation (e.g. virtual machines or containers) may use tools provided by the service organisation to inventory those assets, insofar as the cloud service provider deems these suitable based on their asset management framework.\n\nIn practice, the implementation of the asset inventory can vary greatly depending on the number, size and complexity of provided cloud services."}],"title":"AM-02 Basic 01B"},{"id":"am-02-02b","class":"basic","parts":[{"id":"am-02-02b_stmt","name":"statement","prose":"The 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."},{"id":"am-02-02b_guidance-1","name":"guidance","prose":"Cloud service providers who procure their cloud infrastructure as virtual infrastructure from service organisation (e.g. virtual machines or containers) may use tools provided by the service organisation to inventory those assets, insofar as the cloud service provider deems these suitable based on their asset management framework.\n\nIn practice, the implementation of the asset inventory can vary greatly depending on the number, size and complexity of provided cloud services."}],"title":"AM-02 Basic 02B"},{"id":"am-02-03b","class":"basic","parts":[{"id":"am-02-03b_stmt","name":"statement","prose":"Assets 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."},{"id":"am-02-03b_guidance-1","name":"guidance","prose":"Cloud service providers who procure their cloud infrastructure as virtual infrastructure from service organisation (e.g. virtual machines or containers) may use tools provided by the service organisation to inventory those assets, insofar as the cloud service provider deems these suitable based on their asset management framework.\n\nIn practice, the implementation of the asset inventory can vary greatly depending on the number, size and complexity of provided cloud services."}],"title":"AM-02 Basic 03B"},{"id":"am-02-04b","class":"basic","parts":[{"id":"am-02-04b_stmt","name":"statement","prose":"Changes to the recorded information of an asset are logged."},{"id":"am-02-04b_guidance-1","name":"guidance","prose":"Cloud service providers who procure their cloud infrastructure as virtual infrastructure from service organisation (e.g. virtual machines or containers) may use tools provided by the service organisation to inventory those assets, insofar as the cloud service provider deems these suitable based on their asset management framework.\n\nIn practice, the implementation of the asset inventory can vary greatly depending on the number, size and complexity of provided cloud services."}],"title":"AM-02 Basic 04B"},{"id":"am-02-05b","class":"basic","parts":[{"id":"am-02-05b_stmt","name":"statement","prose":"The cloud service provider maintains lists of all users under its responsibility who have access to a specific resource, along with their respective access rights."},{"id":"am-02-05b_guidance-1","name":"guidance","prose":"Cloud service providers who procure their cloud infrastructure as virtual infrastructure from service organisation (e.g. virtual machines or containers) may use tools provided by the service organisation to inventory those assets, insofar as the cloud service provider deems these suitable based on their asset management framework.\n\nIn practice, the implementation of the asset inventory can vary greatly depending on the number, size and complexity of provided cloud services."},{"id":"am-02-05b_guidance-2","name":"guidance","prose":"These lists can be, but do not have to be, provided by the inventory system established through the criteria AM-02, AM-03 and AM-04."}],"title":"AM-02 Basic 05B"}]},{"id":"am-03","title":"Hardware Asset Inventory","controls":[{"id":"am-03-01b","class":"basic","parts":[{"id":"am-03-01b_stmt","name":"statement","prose":"The hardware asset inventory maintained by the cloud service provider (cf. AM-02) includes information for each entry that:\n\n1. Enables the identification of the hardware asset; \n2. Provides visibility into the lifecycle of the hardware asset; and\n3. Enables the cloud service provider to control the hardware asset, perform a risk assessment and protect its information security."},{"id":"am-03-01b_guidance-1","name":"guidance","prose":"This basic criterion can, but does not have to, be fulfilled by including the following details for each entry of the hardware asset inventory:\n\n1. Identification details (such as name, IP address, MAC address, etc.);\n2. The function of the asset;\n3. The model of the asset;\n4. The location of the asset;\n5. The owner of the asset; and\n6. Information security requirements for the asset.\n\nAn 'asset owner' is an individual or role assigned with the responsibility and accountability for managing and protecting an organisation's asset and does not imply legal ownership of the assets.\n\nIf cloud service customers operate virtual machines or containers with the cloud service, the cloud service provider inventories the containers and document their life cycle (cf. OPS-34)."}],"title":"AM-03 Basic 01B"}]},{"id":"am-04","title":"Software Asset Inventory","controls":[{"id":"am-04-01b","class":"basic","parts":[{"id":"am-04-01b_stmt","name":"statement","prose":"The cloud service provider maintains a comprehensive inventory of all software assets, including used software (cf. AM-02). This inventory includes information for each entry that: \n\n1. Enables the identification of the software asset;\n2. Provides visibility into which other assets use the software asset for the provision of the cloud service; and\n3. Enables the cloud service provider to control the software asset, perform a risk assessment and protect its information security."},{"id":"am-04-01b_guidance-1","name":"guidance","prose":"This basic criterion can, but does not have to, be fulfilled by including the following details for each entry of the software asset inventory:\n\n1. Identification details (such as name, IP address, MAC address, etc.);\n2. The version of the software; and\n3. The parent resource (hardware asset or software asset) on which the software is installed."}],"title":"AM-04 Basic 01B"},{"id":"am-04-01ac","class":"additional-complement","parts":[{"id":"am-04-01ac_stmt","name":"statement","prose":"The inventory also includes information for each entry that provides visibility into how long the software asset will receive security updates from its supplier, if such a time frame has been communicated by the supplier."},{"id":"am-04-01ac_guidance-1","name":"guidance","prose":"This additional criterion can, but does not have to, be fulfilled by including license information, including communicated end-of-support dates related to the licensed software, for each entry of the software asset inventory."}],"title":"AM-04 Additional Complement 01AC"}]},{"id":"am-05","title":"Policy for the Proper and Secure Use of Assets","controls":[{"id":"am-05-01b","class":"basic","parts":[{"id":"am-05-01b_stmt","name":"statement","prose":"Policies and procedures for the proper and secure use 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\n1. Approval procedures for acquisition, commissioning, maintenance, decommissioning, and disposal by authorised personnel or system components;\n2. Classification and labelling based on the protection need of the cloud service customer data, cloud service derived data, cloud service provider data and account data as well as measures for the level of protection identified;\n3. Secure configuration of mechanisms for error handling, logging, encryption, authentication and authorisation;\n4. Requirements for versions of software and images as well as application of patches;\n5. Handling of software for which support and security patches are not available anymore;\n6. Restriction of software installations or use of services;\n7. Protection against malware;\n8. Remote deactivation, deletion or blocking;\n9. Physical delivery and transport;\n10. Dealing with incidents and vulnerabilities;\n11. Deletion of cloud service customer data, cloud service derived data, cloud service provider data and account data; and\n12. Secure handling and usage of removable media, e.g. by specifying which devices are permitted to interact with removable media and what data can be stored on them or by banning the reuse of removable media."}],"title":"AM-05 Basic 01B"},{"id":"am-05-02b","class":"basic","parts":[{"id":"am-05-02b_stmt","name":"statement","prose":"The applicability of these aspects is defined based on the cloud service provider's asset management framework (cf. AM-01)."}],"title":"AM-05 Basic 02B"}]},{"id":"am-06","title":"Commissioning of Hardware","controls":[{"id":"am-06-01b","class":"basic","parts":[{"id":"am-06-01b_stmt","name":"statement","prose":"The cloud service provider has implemented an approval process for commissioning hardware used to provide the cloud service in the production environment. This process involves identifying, analysing, and mitigating any risks (cf. OIS-07) associated with the commissioning."},{"id":"am-06-01b_guidance-1","name":"guidance","prose":"The 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."}],"title":"AM-06 Basic 01B"},{"id":"am-06-02b","class":"basic","parts":[{"id":"am-06-02b_stmt","name":"statement","prose":"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."},{"id":"am-06-02b_guidance-1","name":"guidance","prose":"The 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."}],"title":"AM-06 Basic 02B"}]},{"id":"am-07","title":"Decommissioning of Hardware","controls":[{"id":"am-07-01b","class":"basic","parts":[{"id":"am-07-01b_stmt","name":"statement","prose":"The cloud service provider defines, documents and implements a procedure for the decommissioning of hardware used to operate system components supporting the cloud service production environment under the responsibility of the cloud service provider. As part of this procedure, approval by authorised personnel of the cloud service provider based on the applicable policies is required."},{"id":"am-07-01b_guidance-1","name":"guidance","prose":"The decommissioning procedure typically includes:\n\n1. Verification that the asset is no longer required for operational use;\n2. Assessment of associated risks and dependencies;\n3. Approval by authorised personnel based on internal policies;\n4. Execution of secure data deletion or sanitization processes;\n5. Updating the asset inventory to reflect decommissioning status; and\n6. Disposal or repurposing of the hardware in accordance with environmental and security guidelines."},{"id":"am-07-01b_guidance-2","name":"guidance","prose":"This criterion is not applicable for hardware components that do not store cloud service customer data, cloud service derived data, cloud service provider data or account data (e.g. monitors, routers or keyboards)."}],"title":"AM-07 Basic 01B"},{"id":"am-07-02b","class":"basic","parts":[{"id":"am-07-02b_stmt","name":"statement","prose":"The decommissioning includes either: \n\n1. The complete and permanent deletion of all cloud service customer data, cloud service derived data, cloud service provider data and account data; or \n2. The proper destruction of the media. \n\nAccount data needs to be deleted at least in cases where the data is located in the production environment for the operation of system components."},{"id":"am-07-02b_guidance-1","name":"guidance","prose":"The deletion of data or physical destruction of data mediums can take place, for example, according to DIN 66399 or BSI IT-Grundschutz module CON.6."},{"id":"am-07-02b_guidance-2","name":"guidance","prose":"This criterion is not applicable for hardware components that do not store cloud service customer data, cloud service derived data, cloud service provider data or account data (e.g. monitors, routers or keyboards)."}],"title":"AM-07 Basic 02B"},{"id":"am-07-01as","class":"additional-sharpen","parts":[{"id":"am-07-01as_stmt","name":"statement","prose":"The cloud service provider defines, documents and implements a procedure for the decommissioning of hardware used to operate system components supporting the cloud service production, development, test or staging environment under the responsibility of the cloud service provider. As part of this procedure, approval by authorised personnel of the cloud service provider based on the applicable policies is required."},{"id":"am-07-01as_guidance-1","name":"guidance","prose":"This criterion is not applicable for hardware components that do not store cloud service customer data, cloud service derived data, cloud service provider data or account data (e.g. monitors, routers or keyboards)."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"AM-07 Additional Sharpen 01AS"},{"id":"am-07-01ac","class":"additional-complement","parts":[{"id":"am-07-01ac_stmt","name":"statement","prose":"The destruction of data on hardware components is carried out in such a manner that data recovery can be reasonably considered to be impossible."},{"id":"am-07-01ac_guidance-1","name":"guidance","prose":"The deletion of data or physical destruction of data mediums can take place, for example, according to DIN 66399 or BSI IT-Grundschutz module CON.6."},{"id":"am-07-01ac_guidance-2","name":"guidance","prose":"This approval process ensures that disposal activities conducted offsite adhere to the organisation's security, compliance, and environmental policies. It typically includes:\n\n1. Verification of asset ownership and usage history;\n2. Assessment of data sanitisation requirements;\n3. Selection of approved disposal vendors or methods;\n4. Documentation of disposal actions and approvals; and\n5. Confirmation of secure data deletion or destruction."},{"id":"am-07-01ac_guidance-3","name":"guidance","prose":"This criterion is not applicable for hardware components that do not store cloud service customer data, cloud service derived data, cloud service provider data or account data (e.g. monitors, routers or keyboards)."}],"title":"AM-07 Additional Complement 01AC"}]},{"id":"am-08","title":"Commitment to Proper Use, Safe and Secure Handling and Return of Assets","controls":[{"id":"am-08-01b","class":"basic","parts":[{"id":"am-08-01b_stmt","name":"statement","prose":"The cloud service provider determines in a risk assessment (cf. OIS-07) if loss of or unauthorised access to assets could compromise the information security of the cloud service. If so, the cloud service provider's internal and external personnel is provably committed to the policies and procedures for proper use and safe and secure handling of assets before they can be used."},{"id":"am-08-01b_guidance-1","name":"guidance","prose":"The criterion essentially concerns mobile devices (e.g. notebooks, tablets, smartphones, FIDO2 security keys, etc.), especially if confidential information is stored on them that 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)."}],"title":"AM-08 Basic 01B"},{"id":"am-08-02b","class":"basic","parts":[{"id":"am-08-02b_stmt","name":"statement","prose":"Any assets handed over are provably returned upon termination of employment."},{"id":"am-08-02b_guidance-1","name":"guidance","prose":"The criterion essentially concerns mobile devices (e.g. notebooks, tablets, smartphones, FIDO2 security keys, etc.), especially if confidential information is stored on them that 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)."}],"title":"AM-08 Basic 02B"},{"id":"am-08-03b","class":"basic","parts":[{"id":"am-08-03b_stmt","name":"statement","prose":"If assets cannot be returned prior to or on the day of the termination, the cloud service provider removes the access rights of the personnel no later than the date of termination"},{"id":"am-08-03b_guidance-1","name":"guidance","prose":"The criterion essentially concerns mobile devices (e.g. notebooks, tablets, smartphones, FIDO2 security keys, etc.), especially if confidential information is stored on them that 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)."},{"id":"am-08-03b_guidance-2","name":"guidance","prose":"The removal of access rights of terminated personnel can be implemented by e.g. disabling their identity on the device."}],"title":"AM-08 Basic 03B"}]},{"id":"am-09","parts":[{"id":"am-09-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the protection need of the information that can be processed or stored with the cloud service is adequately determined.\n\nCloud service customers ensure with suitable controls 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Asset Classification and Labelling","controls":[{"id":"am-09-01b","class":"basic","parts":[{"id":"am-09-01b_stmt","name":"statement","prose":"Assets are classified and, if possible, labelled. Classification and labelling of an asset reflect the protection needs of the category of cloud service customer data, cloud service derived data, cloud service provider data and account data it processes, stores, or transmits."},{"id":"am-09-01b_guidance-1","name":"guidance","prose":"If the cloud service provider does not categorise the assets specifically, then all assets may be treated as requiring the highest level of protection needs."}],"title":"AM-09 Basic 01B"},{"id":"am-09-02b","class":"basic","parts":[{"id":"am-09-02b_stmt","name":"statement","prose":"Classification levels are reviewed at least annually and in case of significant changes to the cloud service. Based on the review, the classification levels are updated where appropriate."},{"id":"am-09-02b_guidance-1","name":"guidance","prose":"If the cloud service provider does not categorise the assets specifically, then all assets may be treated as requiring the highest level of protection needs."},{"id":"am-09-02b_guidance-2","name":"guidance","prose":"If a review is caused by significant changes to the cloud service, only the classification levels affected by the changes need to be included in the review."}],"title":"AM-09 Basic 02B"},{"id":"am-09-03b","class":"basic","parts":[{"id":"am-09-03b_stmt","name":"statement","prose":"The protection need is determined by the individuals or groups responsible for the assets of the cloud service provider according to a uniform and documented classification schema."},{"id":"am-09-03b_guidance-1","name":"guidance","prose":"If the cloud service provider does not categorise the assets specifically, then all assets may be treated as requiring the highest level of protection needs."}],"title":"AM-09 Basic 03B"},{"id":"am-09-04b","class":"basic","parts":[{"id":"am-09-04b_stmt","name":"statement","prose":"The classification schema provides levels of protection for the confidentiality, integrity, availability, and authenticity protection objectives. These protection objectives are aligned with delivery and recovery objectives set out in business and disaster recovery plans."},{"id":"am-09-04b_guidance-1","name":"guidance","prose":"If the cloud service provider does not categorise the assets specifically, then all assets may be treated as requiring the highest level of protection needs."}],"title":"AM-09 Basic 04B"},{"id":"am-09-01ac","class":"additional-complement","parts":[{"id":"am-09-01ac_stmt","name":"statement","prose":"The unique identification of physical devices serves as an additional method for connection authentication."},{"id":"am-09-01ac_guidance-1","name":"guidance","prose":"To ensure that all physical assets are uniquely identified, the cloud service provider may implement practices such as:\n\n1. Use of a centralised device management platform to monitor and control all devices;\n2. Assigning unique identifiers (e.g. MAC addresses, serial numbers) to all devices; and\n3. Use of automated mechanisms to register connecting devices."}],"title":"AM-09 Additional Complement 01AC"},{"id":"am-09-02ac","class":"additional-complement","parts":[{"id":"am-09-02ac_stmt","name":"statement","prose":"Device identification is integrated into the asset classification and labeling processes."},{"id":"am-09-02ac_guidance-1","name":"guidance","prose":"Integrating device identification ensures that each asset is uniquely recognised and appropriately classified based on its protection needs. This is particularly important for mobile and endpoint devices, which may carry sensitive data or serve as access points to cloud services. Proper labeling supports traceability, risk assessment, and enforcement of security controls throughout the asset lifecycle."}],"title":"AM-09 Additional Complement 02AC"},{"id":"am-09-03ac","class":"additional-complement","parts":[{"id":"am-09-03ac_stmt","name":"statement","prose":"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."}],"title":"AM-09 Additional Complement 03AC"},{"id":"am-09-04ac","class":"additional-complement","parts":[{"id":"am-09-04ac_stmt","name":"statement","prose":"Actions for events on assets with a higher level of protection take precedence over events on assets with a lower protection need."}],"title":"AM-09 Additional Complement 04AC"}]},{"id":"am-10","title":"Protection of Hardware on Hold","controls":[{"id":"am-10-01b","class":"basic","parts":[{"id":"am-10-01b_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider has documented and implemented a procedure for protecting hardware components of the cloud service's production environment that are temporarily not in use. The procedure supports the secure storage and protection against unauthorised access or damage of inactive hardware until it is needed again."}],"title":"AM-10 Basic 01B"},{"id":"am-10-01as","class":"additional-sharpen","parts":[{"id":"am-10-01as_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider has documented and implemented a procedure for protecting any hardware components that are temporarily not in use. The procedure supports the secure storage and protection against unauthorised access or damage of inactive hardware until it is needed again."}],"title":"AM-10 Additional Sharpen 01AS"}]},{"id":"am-11","title":"Transfer of Hardware","controls":[{"id":"am-11-01b","class":"basic","parts":[{"id":"am-11-01b_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider ensures the secure and controlled transfer of hardware objects used in the cloud service production environment to an offsite or alternate location."}],"title":"AM-11 Basic 01B"},{"id":"am-11-02b","class":"basic","parts":[{"id":"am-11-02b_stmt","name":"statement","prose":"The transfer of hardware is authorised by designated personnel."},{"id":"am-11-02b_guidance-1","name":"guidance","prose":"Authorisation ensures that hardware object transfers, whether internal or external, are controlled, traceable, and compliant with organisational policies. This is particularly important for assets containing sensitive data or used in production environments. The process typically includes:\n\n1. Verification of asset ownership and classification;\n2. Assessment of associated risks;\n3. Documentation of the transfer request and approval; and\n4. Confirmation of secure handling during transit."}],"title":"AM-11 Basic 02B"},{"id":"am-11-03b","class":"basic","parts":[{"id":"am-11-03b_stmt","name":"statement","prose":"The cloud service provider ensures that all transfers of hardware objects used in the cloud service production environment are conducted using secure, documented methods designed to prevent unauthorised access, tampering, data leakage, or loss during transit. These methods include physical protection, chain-of-custody tracking, and verification upon receipt."}],"title":"AM-11 Basic 03B"}]},{"id":"am-12","title":"Removable Media and Endpoint Devices","controls":[{"id":"am-12-01b","class":"basic","parts":[{"id":"am-12-01b_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider designs, implements and maintains controls for endpoint devices and removable storage media regarding the following aspects:\n\n1. Except for system administrative tasks for which no other method is available, the use of removable media is forbidden;\n2. Removable media is used for dedicated, specific purposes only;\n3. Storage encryption is enabled on managed endpoints and removable storage media (except those used for unavoidable system administration actions) to protect information from unauthorised disclosure;\n4. Managed endpoints are configured with anti-malware detection and prevention technology and services;\n5. Self-execution from removable storage is disabled and storage media is scanned before use on the cloud service provider's systems;\n6. Measures are to be taken by users to protect mobile endpoints and removable storage in transit and in storage;\n7. Protection in terms of confidentiality and integrity of any equipment containing cloud service customer data during the transfer off-site for disposal is equivalent to that on the site;\n8. Cloud service customer data and cloud service derived data stored on shareable equipment is encrypted in accordance with CRY-05 or destroyed using a secure deletion mechanism before the equipment is shared with a third party;\n9. Users are to use mobile endpoints and removable storage in a secure manner, this includes for example not leaving media openly accessible in public spaces, using screen locks and screen privacy films; and\n10. Measures for maintaining proper security of third party endpoints with access to organisational assets are to be defined."},{"id":"am-12-01b_guidance-1","name":"guidance","prose":"A removable medium is a portable data storage medium that can be added to or removed from a computing device or network. Examples include, but are not limited to, optical discs (e.g., CD, DVD, Blu-ray), external or removable hard drives or solid state disk drives, magnetic or optical tapes and flash memory devices (e.g., USB, eSATA, flash drive, thumb drive)."}],"title":"AM-12 Basic 01B"},{"id":"am-12-01ac","class":"additional-complement","parts":[{"id":"am-12-01ac_stmt","name":"statement","prose":"Policies and procedures for endpoint devices and removable storage media furthermore contain the following aspects:\n\n1. Managed endpoints are configured with appropriate software firewalls;\n2. Managed endpoints are configured with Data Loss Prevention (DLP) technologies and rules in accordance with a risk assessment (cf. OIS-07);\n3. Remote geo-location capabilities are enabled for all managed mobile endpoints; and\n4. Define, implement and evaluate processes, procedures and technical safeguards to enable the deletion of company data remotely on managed endpoint devices."},{"id":"am-12-01ac_guidance-1","name":"guidance","prose":"A removable medium is a portable data storage medium that can be added to or removed from a computing device or network. Examples include, but are not limited to, optical discs (e.g., CD, DVD, Blu-ray), external or removable hard drives or solid state disk drives, magnetic or optical tapes and flash memory devices (e.g., USB, eSATA, flash drive, thumb drive)."}],"title":"AM-12 Additional Complement 01AC"}]}]},{"id":"ps","title":"Physical Security (PS)","controls":[{"id":"ps-01","title":"Physical Security and Environmental Control Requirements","controls":[{"id":"ps-01-01b","class":"basic","parts":[{"id":"ps-01-01b_stmt","name":"statement","prose":"The cloud service provider defines and documents at least two security areas, with at least one sensitive area and one public area. A sensitive area covers the buildings and premises in which sensitive activities take place, such as hosting the system components used for providing the cloud service. A public area covers all buildings and premises not otherwise covered by a security area."},{"id":"ps-01-01b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Basic 01B"},{"id":"ps-01-02b","class":"basic","parts":[{"id":"ps-01-02b_stmt","name":"statement","prose":"Security requirements for premises and buildings related to the cloud service provided are based on the security objectives of the information security policy, protection needs identified for the cloud service and a risk assessment regarding physical and environmental security. The security requirements are documented, communicated and provided in a policy or framework according to SP-01."},{"id":"ps-01-02b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Basic 02B"},{"id":"ps-01-03b","class":"basic","parts":[{"id":"ps-01-03b_stmt","name":"statement","prose":"Security requirements for data centres are based on criteria in accordance with established rules of technology and the criteria PS-02 to PS-07. They are suitable for addressing the following risks in accordance with the applicable legal and contractual requirements:\n\n1. Faults in planning;\n2. Unauthorised access (including access to the premises by drones);\n3. Insufficient surveillance;\n4. Lightning and overvoltage (aligned with the internationally harmonised standards of IEC 62305);\n5. Fire and smoke;\n6. Unwanted water;\n7. Failures and/or unavailable telecommunications;\n8. Power failure; and\n9. Insufficient heating, ventilation, airconditioning (HVAC) and filtration."},{"id":"ps-01-03b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."},{"id":"ps-01-03b_guidance-2","name":"guidance","prose":"The recognised established rules of technology are defined in relevant standards, e.g. EN 50600 (facilities and infrastructures of data centres). Note for German readers: The German version of C5 uses the term *Stand der Technik* for established rules of technology although the German reader might expect the term *state of the art*. Without discussing the semantic, please note that *state of the art* defines a higher level than *Stand der Technik* and therefore *established rules of technology* is used here."}],"title":"PS-01 Basic 03B"},{"id":"ps-01-04b","class":"basic","parts":[{"id":"ps-01-04b_stmt","name":"statement","prose":"The maximum tolerable downtimes of utility facilities are suitable for meeting the availability requirements contained in the service level agreement."},{"id":"ps-01-04b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Basic 04B"},{"id":"ps-01-05b","class":"basic","parts":[{"id":"ps-01-05b_stmt","name":"statement","prose":"If the cloud service provider operates the cloud service in data centres operated by service organisations, the document describes:\n\n1. The complementary subservice organisation controls (CSOC) expected at the service organisations; and\n2. The measures for monitoring the design and operation of controls at the service organisations with respect to these CSOC (cf. SSO-05)."},{"id":"ps-01-05b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."},{"id":"ps-01-05b_guidance-2","name":"guidance","prose":"Premises and buildings operated by third parties are e.g. server housing, colocation, IaaS."}],"title":"PS-01 Basic 05B"},{"id":"ps-01-06b","class":"basic","parts":[{"id":"ps-01-06b_stmt","name":"statement","prose":"If the cloud service provider operates the cloud service in data centres operated by service organisations, the cloud service provider performs a verification of the implementation of suitable CSOC in accordance with the criteria for controlling and monitoring service organisations (cf. SSO-05)."},{"id":"ps-01-06b_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Basic 06B"},{"id":"ps-01-01ac","class":"additional-complement","parts":[{"id":"ps-01-01ac_stmt","name":"statement","prose":"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."},{"id":"ps-01-01ac_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."},{"id":"ps-01-01ac_guidance-2","name":"guidance","prose":"Time 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)."}],"title":"PS-01 Additional Complement 01AC"},{"id":"ps-01-02ac","class":"additional-complement","parts":[{"id":"ps-01-02ac_stmt","name":"statement","prose":"The security requirements include time limits in order to provide self-sufficient operation of a location for at least 72 hours in the event of a failure of the external power supply, or until all services are transferred to another location."},{"id":"ps-01-02ac_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."},{"id":"ps-01-02ac_guidance-2","name":"guidance","prose":"The 72-hour time frame for self-sufficient operation aligns with guidelines for government agencies, businesses and critical infrastructure operators (KRITIS) as per the Federal Office for Civil Protection and Disaster Assistance (BBK)."}],"title":"PS-01 Additional Complement 02AC"},{"id":"ps-01-03ac","class":"additional-complement","parts":[{"id":"ps-01-03ac_stmt","name":"statement","prose":"The security requirements for a self-sufficient operation during a heat period are based on the highest outside temperatures that can reasonably be estimated to occur at the locations of the premises and buildings within the lifespan of the cooling supply system. The cloud service provider determines these temparatures with an appropriate safety margin."},{"id":"ps-01-03ac_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."},{"id":"ps-01-03ac_guidance-2","name":"guidance","prose":"A reasonable estimation of the highest outside temperatures can be based on information supplied by official measurement station such as Deutscher Wetterdienst (DWD) or other reliable resources, such as e.g. American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE).\n\nThese estimations should take the effects of global warming into account.\n\nWhat constitutes an appropriate safety margin depends on the location of the premises and buildings. In Germany, 3 Kelvin can generally be considered appropriate."}],"title":"PS-01 Additional Complement 03AC"},{"id":"ps-01-04ac","class":"additional-complement","parts":[{"id":"ps-01-04ac_stmt","name":"statement","prose":"The security requirements stipulate that the permissible operating and environmental parameters of the cooling supply system shall also be maintained on at least five consecutive days with these outside temperatures including the safety margin (cf. PS-06)."},{"id":"ps-01-04ac_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Additional Complement 04AC"},{"id":"ps-01-05ac","class":"additional-complement","parts":[{"id":"ps-01-05ac_stmt","name":"statement","prose":"The security requirements take into account that if water is taken from a body of water (e.g., river or lake) for air conditioning, it is determined at which water levels and water temperatures the air conditioning can be maintained for how long."},{"id":"ps-01-05ac_guidance-1","name":"guidance","prose":"Incorrect 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\nPremises and buildings related to the cloud service provided include data centres and server rooms housing system components used to process cloud service customer data (including data centres for backup or redundancy purposes) and the technical utilities required to operate these system components (e.g. power supply, refrigeration, fire-fighting, telecommunications, security, etc.).\n\nPremises and buildings in which no data from cloud service customers is processed or stored (e.g. offices of the cloud service provider, server rooms with system components for internal development and test systems) adhere to requirements specifically covered under PS-08."}],"title":"PS-01 Additional Complement 05AC"}]},{"id":"ps-02","parts":[{"id":"ps-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the existing redundancy model of the cloud service provider and the evidence for the verification of the model comply with their own requirements for the availability and reliability of the cloud service.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Redundancy Model","controls":[{"id":"ps-02-01b","class":"basic","parts":[{"id":"ps-02-01b_stmt","name":"statement","prose":"The cloud service is provided from at least two locations. The locations meet the security requirements of the cloud service provider (cf. PS-01) and are located in an adequate distance to each other to achieve operational redundancy and resilience."},{"id":"ps-02-01b_guidance-1","name":"guidance","prose":"Operational redundancy of the sites to each other in the sense of this criterion 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\nThere are cloud service 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 3.4.12) of the criterion. The tests and exercises on functionality required in the criterion also apply analogously to resilient architectures."}],"title":"PS-02 Basic 01B"},{"id":"ps-02-02b","class":"basic","parts":[{"id":"ps-02-02b_stmt","name":"statement","prose":"Operational redundancy is designed in a way that ensures that the availability requirements specified in the service level agreement are met."},{"id":"ps-02-02b_guidance-1","name":"guidance","prose":"Operational redundancy of the sites to each other in the sense of this criterion 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\nThere are cloud service 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 3.4.12) of the criterion. The tests and exercises on functionality required in the criterion also apply analogously to resilient architectures."}],"title":"PS-02 Basic 02B"},{"id":"ps-02-03b","class":"basic","parts":[{"id":"ps-02-03b_stmt","name":"statement","prose":"The effectiveness of the redundancy is checked at least annually by suitable tests and exercises (cf. BCM-04)."}],"title":"PS-02 Basic 03B"},{"id":"ps-02-01as","class":"additional-sharpen","parts":[{"id":"ps-02-01as_stmt","name":"statement","prose":"The cloud service is provided from more than two locations. The locations meet the security requirements of the cloud service provider (cf. PS-01) and are located sufficiently far apart to achieve georedundancy and resilience. If two locations fail at the same time, at least one third location is still available to prevent a total service failure."},{"id":"ps-02-01as_guidance-1","name":"guidance","prose":"A georedundancy of the sites to each other in the sense of this criterion 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 von Rechenzentren' (German for: 'Criteria for selecting the location of data centres', document only available in German) provides recommendations in this regard."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"PS-02 Additional Sharpen 01AS"},{"id":"ps-02-02as","class":"additional-sharpen","parts":[{"id":"ps-02-02as_stmt","name":"statement","prose":"The georedundancy is designed in a way that ensures that the availability requirements specified in the service level agreement are met."},{"id":"ps-02-02as_guidance-1","name":"guidance","prose":"A georedundancy of the sites to each other in the sense of this criterion 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 von Rechenzentren' (German for: 'Criteria for selecting the location of data centres', document only available in German) provides recommendations in this regard."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"PS-02 Additional Sharpen 02AS"}]},{"id":"ps-03","title":"Perimeter Protection","controls":[{"id":"ps-03-01b","class":"basic","parts":[{"id":"ps-03-01b_stmt","name":"statement","prose":"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)."}],"title":"PS-03 Basic 01B"},{"id":"ps-03-02b","class":"basic","parts":[{"id":"ps-03-02b_stmt","name":"statement","prose":"The security measures are designed to detect and prevent unauthorised access so that the information security of the cloud service is not compromised."},{"id":"ps-03-02b_guidance-1","name":"guidance","prose":"Security measures for detecting unauthorised access can be security personnel, video surveillance or anti-burglary systems."}],"title":"PS-03 Basic 02B"},{"id":"ps-03-03b","class":"basic","parts":[{"id":"ps-03-03b_stmt","name":"statement","prose":"The outer doors, windows and other construction elements exhibit an appropriate security level so that their combined resistance time withstand a break-in attempt for at least ten minutes in total. This time period applies from the moment an external intruder is detected (e.g. by perimeter surveillance)."},{"id":"ps-03-03b_guidance-1","name":"guidance","prose":"The resistance class RC4 according to DIN EN 1627 stipulates that doors, windows and other components shall withstand a break-in attempt for at least ten minutes. The US standard SD-STD-01.01 Rev.G. is an international equivalent to this standard. However, fulfilling the objective of this criteria does not necessarily imply that those standards have to be fulfilled. \n\nAdditionally, the subcriterion demands that all construction elements as a whole lead to a resistance time to break-in attempts for at least ten minutes. Consequently, it does not necessarly demand that all individual construction elements have to fulfil this requirement on their own, provided the combined measures effectively delay an external attack for the required time."}],"title":"PS-03 Basic 03B"},{"id":"ps-03-04b","class":"basic","parts":[{"id":"ps-03-04b_stmt","name":"statement","prose":"The surrounding wall constructions as well as the locking mechanisms meet the associated requirements."},{"id":"ps-03-04b_guidance-1","name":"guidance","prose":"The resistance class RC4 according to DIN EN 1627 stipulates that doors, windows and other components shall withstand a break-in attempt for at least ten minutes. The US standard SD-STD-01.01 Rev.G. is an international equivalent to this standard. However, fulfilling the objective of this criteria does not necessarily imply that those standards have to be fulfilled. \n\nAdditionally, the subcriterion demands that all construction elements as a whole lead to a resistance time to break-in attempts for at least ten minutes. Consequently, it does not necessarly demand that all individual construction elements have to fulfil this requirement on their own, provided the combined measures effectively delay an external attack for the required time."}],"title":"PS-03 Basic 04B"},{"id":"ps-03-05b","class":"basic","parts":[{"id":"ps-03-05b_stmt","name":"statement","prose":"If the construction elements as a whole do not fully meet the associated requirements, compensating controls are implemented to restore the appropriate security level."},{"id":"ps-03-05b_guidance-1","name":"guidance","prose":"Compensating measures can include additional security layers (e.g. security areas) on the premise, an increased presence of security personnel, video surveillance and anti-burglary systems."}],"title":"PS-03 Basic 05B"},{"id":"ps-03-06b","class":"basic","parts":[{"id":"ps-03-06b_stmt","name":"statement","prose":"Data centre personnel are trained on how to respond effectively to unauthorised ingress or egress attempts."}],"title":"PS-03 Basic 06B"},{"id":"ps-03-01ac","class":"additional-complement","parts":[{"id":"ps-03-01ac_stmt","name":"statement","prose":"The security measures installed at the site include permanently present security personnel (at least two individuals), video surveillance and anti-burglary systems."}],"title":"PS-03 Additional Complement 01AC"}]},{"id":"ps-04","title":"Physical Site Access Control","controls":[{"id":"ps-04-01b","class":"basic","parts":[{"id":"ps-04-01b_stmt","name":"statement","prose":"Preventive and detective physical access controls in premises and buildings related to the cloud service provided are implemented. They are in accordance with the cloud service provider's security requirements (cf. PS-01) and based on the principles defined in IAM-01 to prevent unauthorised access. They are documented and communicated in a policy or framework in accordance with SP-01 and include the following aspects:\n\n1. Specified procedure for the granting and modifying of user accounts and access rights (cf. IAM-02) based on the 'least-privilege-principle' and the 'need-to-know-principle';\n2. Revocation of access authorisations if they have not been used for a period of two months. Exceptions are only made for well-founded individual cases and follow a defined exception process according to SP-03;\n3. Authentication with at least one factor for access to any non-public area;\n4. Multi-factor authentication for access to areas hosting system components that process cloud service customer data;\n5. 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;\n6. Physical access control exceptions applicable in case of emergency, including an analysis procedure following every use of these exceptions; and\n7. For visitors and external personnel, measures that ensure identification and tracking of every individual such that their activities are traceable and - in case of activities that infringe information security - stoppable in an appropriate reaction time. These measures are appropriate and proportional to the sensitivity of the zone the visitors or external personnel are in. The appropriate reaction time frame is determined based on a risk assessment (cf. OIS-07)."},{"id":"ps-04-01b_guidance-1","name":"guidance","prose":"For implementing access control based on the need-to-know-principle, a zoning framework can be deployed with each on-premises area having separate access permissions. If a zoning framework is implemented, each on-premises area should be physically separated with its own access control system. Examples for zoning on-premises can be:\n\n1. Green zone: Public area, contains no resources that are relevant to the provisioning of the cloud service;\n2. Yellow zone: Private area, contains means for supporting the cloud service such as development, administration and supervision; and\n3. Red zone: Sensitive area for production systems such as the server rooms.\n\nExamples for reasonable exceptions to the revocation of access authorisations after two months of inactivity are e.g. cases where personnel with specific roles, such as management positions or supervisors, requires only occasional but crucial entry. The rationale for the exceptions should be documented and during the review critically assessed if they are still necessary."}],"title":"PS-04 Basic 01B"},{"id":"ps-04-02b","class":"basic","parts":[{"id":"ps-04-02b_stmt","name":"statement","prose":"The cloud service provider displays a warning at the entrance of each applicable non-public area regarding its limits and access conditions."}],"title":"PS-04 Basic 02B"},{"id":"ps-04-03b","class":"basic","parts":[{"id":"ps-04-03b_stmt","name":"statement","prose":"Physical access control to the site is managed by an electronic access control system that supports authentication, authorisation, and logging of entry and exit events."}],"title":"PS-04 Basic 03B"}]},{"id":"ps-05","title":"Protection against Threats from Outside and from the Environment","controls":[{"id":"ps-05-01b","class":"basic","parts":[{"id":"ps-05-01b_stmt","name":"statement","prose":"Premises and buildings related to the cloud service provided are protected from fire, smoke, lightning and unwanted water by structural, technical and organisational measures that meet the security requirements of the cloud service provider (cf. PS-01)."}],"title":"PS-05 Basic 01B"},{"id":"ps-05-02b","class":"basic","parts":[{"id":"ps-05-02b_stmt","name":"statement","prose":"Structural Measures include the following aspects:\n\n1. Establishment of fire sections with a fire resistance duration of at least 90 minutes for all structural parts, or alternatively, equivalent organisational and technical measures that ensure the same level of protection standard as 90-minutes fire-resistant structural parts or establishment of compensating measures for containing fires and maintaining operational capability. If compensating measures are taken into account, the fire resistance of structural parts has to be at least 60 minutes;\n2. Effective implementation of measures to protect against lightning and overvoltage damage; and\n3. Effective implementation of measures to protect against flooding, unless critical facilities are located significantly above the highest flood level at the location of the cloud data centre. Additionally, appropriate measures to mitigate the effects of heavy rain are implemented, unless critical facilities are located significantly above the backwater level at the location of the cloud data centre."},{"id":"ps-05-02b_guidance-1","name":"guidance","prose":"Structural parts are walls, ceilings, floors, doors, windows and other breakthroughs like ventilation flaps, etc.\n\nCompensating measures can take into account aspects such as:\n\n1. Partitioning and layout of fire sections;\n2. Extinguishing systems within the fire sections;\n3. Early and very early fire detection mechanisms;\n4. Redundancy of systems and supply facilities within the premise; and\n5. Period of time the locations and premises can withstand a fire impairing a data hall without a second data hall catching fire.\n\nThe cloud service provider should describe the measures taken to protect its premises and buildings against fire as part of the system description.\n\nThe location of all critical facilities in relation to the highest historically recorded flood level at the cloud data centre site or the site's backwater level acts as the starting point for considering flood and heavy rain protection measures."}],"title":"PS-05 Basic 02B"},{"id":"ps-05-03b","class":"basic","parts":[{"id":"ps-05-03b_stmt","name":"statement","prose":"Technical Measures include the following aspects:\n\n1. 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;\n2. Extinguishing system or oxygen reduction; and\n3. Fire alarm system with reporting to the local fire department."},{"id":"ps-05-03b_guidance-1","name":"guidance","prose":"The monitoring of the environmental parameters is addressed in PS-07. When exceeding the allowed control range, alarm messages are generated and forwarded to the responsible cloud service provider."}],"title":"PS-05 Basic 03B"},{"id":"ps-05-04b","class":"basic","parts":[{"id":"ps-05-04b_stmt","name":"statement","prose":"Organisational Measures include the following aspects:\n\n1. Regular fire protection inspections to check compliance with fire protection requirements; and\n2. Regular fire protection exercises."}],"title":"PS-05 Basic 04B"}]},{"id":"ps-06","title":"Protection against Interruptions caused by Power Failures and similar Risks to Supply Facilities","controls":[{"id":"ps-06-01b","class":"basic","parts":[{"id":"ps-06-01b_stmt","name":"statement","prose":"Measures to prevent the failure of the technical supply facilities required for the operation of system components with which cloud service customer data is processed and to protect equipment containing cloud service customer data, are documented and set up in accordance with the security requirements of the cloud service provider (cf. PS-01) with respect to the following aspects:\n\n1. Operational redundancy (N+1) in power and cooling supply;\n2. Use of appropriately sized uninterruptible power supplies (UPSes) and emergency power supplies (EPSes), designed to ensure that all data remains undamaged in the event of a power failure. The functionality of UPSes and EPSes is checked at least annually by suitable tests and exercises (cf. BCM-04);\n3. Maintenance (servicing, inspection, repair) of the utilities in accordance with the manufacturer's recommendations; and\n4. Protection of power supply and telecommunications lines against interruption, interference, damage and eavesdropping."},{"id":"ps-06-01b_guidance-1","name":"guidance","prose":"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."}],"title":"PS-06 Basic 01B"},{"id":"ps-06-02b","class":"basic","parts":[{"id":"ps-06-02b_stmt","name":"statement","prose":"Uninterruptible Power Supplies (UPSes) and Emergency Power Supplies (EPSes) are implemented to comply with the availability requirements defined in the Service Level Agreement."}],"title":"PS-06 Basic 02B"},{"id":"ps-06-03b","class":"basic","parts":[{"id":"ps-06-03b_stmt","name":"statement","prose":"The protection of power supply and telecommunications lines 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\n1. Traces of violent attempts to open closed distributors;\n2. Up-to-dateness of the documentation within the distributor;\n3. Conformity of the actual wiring and patching with the documentation;\n4. The short-circuits and earthing of unneeded cables and wires are intact; and\n5. Impermissible installations and modifications."},{"id":"ps-06-03b_guidance-1","name":"guidance","prose":"The subcriterion requires the check to be performed at least every two years. If no check was performed during the specified period of a Type 2 engagement, the auditor shall note in the test result that there was 'no occurrence' provided that the previous check was performed within the two years required by the criterion. For the evaluation of the design of the control, the auditor may obtain evidence regarding the previous check, even if this check did not occur within the specified period of the engagement. If there was no check performed for two years, the auditor shall note a deviation."}],"title":"PS-06 Basic 03B"},{"id":"ps-06-01ac","class":"additional-complement","parts":[{"id":"ps-06-01ac_stmt","name":"statement","prose":"The cooling supply system 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 that can reasonably be estimated to occur at the locations of the premises and buildings within the lifespan of the cooling supply system, with an appropriate safety margin."},{"id":"ps-06-01ac_guidance-1","name":"guidance","prose":"This subcriterion demands the implementation of concrete measures to fulfil the policy required by PS-01.03AC. The cloud service provider also determines the highest outside temperatures that can reasonably be estimated to occur at the locations of the premises and buildings within the lifespan of the cooling supply system as part of PS-01.03AC."}],"title":"PS-06 Additional Complement 01AC"},{"id":"ps-06-02ac","class":"additional-complement","parts":[{"id":"ps-06-02ac_stmt","name":"statement","prose":"The 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."}],"title":"PS-06 Additional Complement 02AC"},{"id":"ps-06-03ac","class":"additional-complement","parts":[{"id":"ps-06-03ac_stmt","name":"statement","prose":"The cloud service provider implements measures to ensure the compatibility of the conditions for installation, maintenance and servicing of the related technical equipment (e.g., electrical power, air conditioning, fire protection) with the cloud service's availability and security requirements."}],"title":"PS-06 Additional Complement 03AC"},{"id":"ps-06-04ac","class":"additional-complement","parts":[{"id":"ps-06-04ac_stmt","name":"statement","prose":"The cloud service provider ensures that maintenance agreements for equipment used for the hosting of the cloud service enable the timely installation of security updates on this equipment."}],"title":"PS-06 Additional Complement 04AC"}]},{"id":"ps-07","title":"Surveillance of Operational and Environmental Parameters","controls":[{"id":"ps-07-01b","class":"basic","parts":[{"id":"ps-07-01b_stmt","name":"statement","prose":"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)."},{"id":"ps-07-01b_guidance-1","name":"guidance","prose":"These measures typically include but are not limited to:\n\n1. Environmental monitoring systems (e.g., temperature and humidity sensors);\n2. Fire suppression systems;\n3. Climate control (HVAC) systems; and\n4. Leak detection and alarms."}],"title":"PS-07 Basic 01B"},{"id":"ps-07-02b","class":"basic","parts":[{"id":"ps-07-02b_stmt","name":"statement","prose":"When the permitted control range is exceeded, the responsible departments at the cloud service provider are automatically informed in order to timely initiate the necessary measures for return to the control range."}],"title":"PS-07 Basic 02B"}]},{"id":"ps-08","title":"Workplace Security Requirements","controls":[{"id":"ps-08-01b","class":"basic","parts":[{"id":"ps-08-01b_stmt","name":"statement","prose":"Based on a risk assessment according to OIS-07, security requirements for office environments are documented, communicated and provided in accordance with SP-01. The security requirements for rented offices take into account proportionality and appropriateness, potentially being less extensive than those in own office environments. These security requirements encompass various aspects for a safe and secure working environment, including at least:\n\n1. Physical access controls, such as key cards and biometric scanners, for office buildings;\n2. Use of screen locks and privacy screens for workstations;\n3. No openly visible confidential data at temporarily unattended workstations;\n4. Disposal of all company documents that are no longer required within the company premise;\n5. Prohibition of the use of third party equipment; and\n6. Securing the entrances of office premises with alarm systems and surveillance cameras."},{"id":"ps-08-01b_guidance-1","name":"guidance","prose":"As a result of the risk assessment in accordance with OIS-07, not every aspect listed in the criterion may need to be addressed by corresponding security requirements. For example, if there are no assets related to the development or operation of the cloud service in an office building, alarm systems and surveillance cameras may not be required."}],"title":"PS-08 Basic 01B"}]}]},{"id":"ops","title":"Operations (OPS)","controls":[{"id":"ops-01","parts":[{"id":"ops-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls 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 are reviewed regularly and the adjustment of SLA demanded accordingly.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Capacity Management - Planning","controls":[{"id":"ops-01-01b","class":"basic","parts":[{"id":"ops-01-01b_stmt","name":"statement","prose":"The planning of capacities and resources (personnel and system components) follows an established procedure in order to avoid possible capacity restrictions."},{"id":"ops-01-01b_guidance-1","name":"guidance","prose":"For economic reasons, cloud service providers typically strive for a high utilisation of system components (CPU, RAM, storage space, network). In multi-tenant environments, existing resources should still be shared between cloud service customers (clients) in such a way that service level agreements are adhered to. In this respect, proper planning and monitoring of system components 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 should be able to explain the procedures at least orally within the scope of this audit."},{"id":"ops-01-01b_guidance-2","name":"guidance","prose":"Capacity restrictions are limitations in the cloud service provider's resources, resulting in disruptions of the cloud service or impacting compliance with contractual agreements and service levels."}],"title":"OPS-01 Basic 01B"},{"id":"ops-01-02b","class":"basic","parts":[{"id":"ops-01-02b_stmt","name":"statement","prose":"The procedures include forecasting future capacity requirements in order to identify usage trends and manage system overload."},{"id":"ops-01-02b_guidance-1","name":"guidance","prose":"For economic reasons, cloud service providers typically strive for a high utilisation of system components (CPU, RAM, storage space, network). In multi-tenant environments, existing resources should still be shared between cloud service customers (clients) in such a way that service level agreements are adhered to. In this respect, proper planning and monitoring of system components 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 should be able to explain the procedures at least orally within the scope of this audit."}],"title":"OPS-01 Basic 02B"},{"id":"ops-01-03b","class":"basic","parts":[{"id":"ops-01-03b_stmt","name":"statement","prose":"The cloud service provider takes appropriate measures to ensure that they continue to meet the requirements agreed with cloud service customers for the provision of the cloud service in the event of capacity restrictions or outages regarding personnel and system components. This applies in particular to those relating to the dedicated use of system components, in accordance with the respective agreements."},{"id":"ops-01-03b_guidance-1","name":"guidance","prose":"For economic reasons, cloud service providers typically strive for a high utilisation of system components (CPU, RAM, storage space, network). In multi-tenant environments, existing resources should still be shared between cloud service customers (clients) in such a way that service level agreements are adhered to. In this respect, proper planning and monitoring of system components 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 should be able to explain the procedures at least orally within the scope of this audit."}],"title":"OPS-01 Basic 03B"},{"id":"ops-01-01ac","class":"additional-complement","parts":[{"id":"ops-01-01ac_stmt","name":"statement","prose":"The forecasts are considered in accordance with the service level agreement for planning and preparing the provisioning."},{"id":"ops-01-01ac_guidance-1","name":"guidance","prose":"For economic reasons, cloud service providers typically strive for a high utilisation of system components (CPU, RAM, storage space, network). In multi-tenant environments, existing resources should still be shared between cloud service customers (clients) in such a way that service level agreements are adhered to. In this respect, proper planning and monitoring of system components 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 should be able to explain the procedures at least orally within the scope of this audit."}],"title":"OPS-01 Additional Complement 01AC"}]},{"id":"ops-02","parts":[{"id":"ops-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Capacity Management - Monitoring","controls":[{"id":"ops-02-01b","class":"basic","parts":[{"id":"ops-02-01b_stmt","name":"statement","prose":"Procedures and technical safeguards for the monitoring, provisioning and de-provisioning of cloud services are defined. The cloud service provider ensures that resources are delivered as contractually agreed with the customers. The cloud service provider ensures compliance with the service level agreements."},{"id":"ops-02-01b_guidance-1","name":"guidance","prose":"Technical and organisational measures typically include:\n\n1. Use of monitoring tools with alarm function when defined threshold values are exceeded;\n2. Process for correlating events and interface to incident management;\n3. Continuous monitoring of the systems by qualified personnel; and\n4. Redundancies in the IT systems."}],"title":"OPS-02 Basic 01B"},{"id":"ops-02-02b","class":"basic","parts":[{"id":"ops-02-02b_stmt","name":"statement","prose":"Capacity restrictions that result in breaches of contractual obligations are to be reported to cloud service customers in accordance with OPS-24."},{"id":"ops-02-02b_guidance-1","name":"guidance","prose":"Cloud service providers may provide a health dashboard to the cloud service customer. This subcriterion can be fulfilled by the provision of such a health dashboard if the health dashboard informs the cloud service customer about breaches of contractual obligations, such as SLAs."}],"title":"OPS-02 Basic 02B"},{"id":"ops-02-01ac","class":"additional-complement","parts":[{"id":"ops-02-01ac_stmt","name":"statement","prose":"To monitor capacity and availability managed by the cloud service customer, the relevant information is available to the cloud service customer in a self-service portal."}],"title":"OPS-02 Additional Complement 01AC"}]},{"id":"ops-03","parts":[{"id":"ops-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they manage and monitor the system resources in their area of responsibility.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Capacity Management - Controlling of Resources","controls":[{"id":"ops-03-01b","class":"basic","parts":[{"id":"ops-03-01b_stmt","name":"statement","prose":"Depending on the capabilities of the respective service model, the cloud service customer can control and monitor the allocation of the system components assigned to the customer for administration/use in order to avoid overcrowding of resources and to achieve sufficient performance."},{"id":"ops-03-01b_guidance-1","name":"guidance","prose":"System components to be allocated and managed by the cloud service customer can include, according to the possibilities of the service model:\n\n1. Computing capacity;\n2. Storage capacity;\n3. Configuration of network properties;\n4. Application Programming Interfaces (APIs); and\n5. Databases.\n\nSystem component allocation may need to take into account any container-based infrastructure used in the service models."}],"title":"OPS-03 Basic 01B"},{"id":"ops-03-02b","class":"basic","parts":[{"id":"ops-03-02b_stmt","name":"statement","prose":"If there are significant security changes, or planned significant security changes, in the system components provided as part of the cloud service and allocated by the cloud service customer, the cloud service provider informs the cloud service customer about them."},{"id":"ops-03-02b_guidance-1","name":"guidance","prose":"Significant security changes in this context can include the change of the security feature itself, such as when changing the service architecture. Non-significant changes can include the change of the implementation of a security feature in a way that does not alter its functionality or reduce its security level, such as when replacing a used cryptographic primitive with another, equivalent one."}],"title":"OPS-03 Basic 02B"}]},{"id":"ops-04","title":"Protection Against Malware - Policies and Procedures","controls":[{"id":"ops-04-01b","class":"basic","parts":[{"id":"ops-04-01b_stmt","name":"statement","prose":"Policies and procedures with specifications for protection against malware are documented, communicated, and provided in accordance with SP-01 with respect to the following aspects:\n\n1. Use of system-specific protection mechanisms;\n2. Operating protection programmes on system components under the responsibility of the cloud service provider;\n3. Operation of protection programmes for personnel's terminal equipment; and\n4. Operation of protection programmes on flows coming in over cloud service provider end-devices, as well as all other incoming flows."},{"id":"ops-04-01b_guidance-1","name":"guidance","prose":"Protection programmes for personnel devices can be, for example, server-based protection programmes that scan files in attachments on the server or filter network traffic."}],"title":"OPS-04 Basic 01B"}]},{"id":"ops-05","parts":[{"id":"ops-05-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the layers of the cloud service which they are responsible for have security products in place to detect and remove malware.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Protection Against Malware - Implementation","controls":[{"id":"ops-05-01b","class":"basic","parts":[{"id":"ops-05-01b_stmt","name":"statement","prose":"System components under the cloud service provider's responsibility that are used to operate the cloud service in the production environment are configured with malware protection according to the policies and procedures."},{"id":"ops-05-01b_guidance-1","name":"guidance","prose":"Protection against malicious programmes can be implemented by operating system-specific protection mechanisms or explicit protection programmes (e.g. for signature- and behaviour-based detection and removal of malicious programmes).\n\nIf the cloud service provider operates malware protected containers or virtual machines to provide the cloud service, the malware protection should include container-specific measures. This can include, for example, monitoring the container images and the container runtime, and due to the frequent start and stop of the containers, real-time scans and -monitoring processes."},{"id":"ops-05-01b_guidance-2","name":"guidance","prose":"For end-devices used by the personnel of the cloud service provider, the applicability of this subcriterion is determined based on the risk assessment performed according to AM-08."}],"title":"OPS-05 Basic 01B"},{"id":"ops-05-02b","class":"basic","parts":[{"id":"ops-05-02b_stmt","name":"statement","prose":"If protection programmes are set up with signature or behaviour-based malware detection and removal, these protection programmes are regularly updated with the latest malware definitions when they are available, at least on a daily basis."},{"id":"ops-05-02b_guidance-1","name":"guidance","prose":"Protection against malicious programmes can be implemented by operating system-specific protection mechanisms or explicit protection programmes (e.g. for signature- and behaviour-based detection and removal of malicious programmes).\n\nIf the cloud service provider operates malware protected containers or virtual machines to provide the cloud service, the malware protection should include container-specific measures. This can include, for example, monitoring the container images and the container runtime, and due to the frequent start and stop of the containers, real-time scans and -monitoring processes."}],"title":"OPS-05 Basic 02B"},{"id":"ops-05-03b","class":"basic","parts":[{"id":"ops-05-03b_stmt","name":"statement","prose":"The cloud service provider creates regular reports on the checks performed by the operated protection programmes, which are reviewed and analysed by authorised individuals, bodies or committees."}],"title":"OPS-05 Basic 03B"},{"id":"ops-05-02as","class":"additional-sharpen","parts":[{"id":"ops-05-02as_stmt","name":"statement","prose":"If protection programmes are set up with signature and behaviour-based malware detection and removal, these protection programmes are regularly updated with the latest malware definitions when they are available, at the highest frequency that the vendor(s) offer(s) where applicable."},{"id":"ops-05-02as_guidance-1","name":"guidance","prose":"Protection against malicious programmes can be implemented by operating system-specific protection mechanisms or explicit protection programmes (e.g. for signature- and behaviour-based detection and removal of malicious programmes).\n\nIf the cloud service provider operates malware protected containers or virtual machines to provide the cloud service, the malware protection should include container-specific measures. This can include, for example, monitoring the container images and the container runtime, and due to the frequent start and stop of the containers, real-time scans and -monitoring processes."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"OPS-05 Additional Sharpen 02AS"},{"id":"ops-05-01ac","class":"additional-complement","parts":[{"id":"ops-05-01ac_stmt","name":"statement","prose":"Policies and procedures 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."}],"title":"OPS-05 Additional Complement 01AC"},{"id":"ops-05-02ac","class":"additional-complement","parts":[{"id":"ops-05-02ac_stmt","name":"statement","prose":"The configuration of the protection mechanisms is monitored automatically."}],"title":"OPS-05 Additional Complement 02AC"},{"id":"ops-05-03ac","class":"additional-complement","parts":[{"id":"ops-05-03ac_stmt","name":"statement","prose":"Deviations from the specifications are automatically reported to the cloud service provider's subject matter experts so that they can be immediately assessed and the necessary measures taken."}],"title":"OPS-05 Additional Complement 03AC"}]},{"id":"ops-06","parts":[{"id":"ops-06-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Data Backup and Recovery - Policies and Procedures","controls":[{"id":"ops-06-01b","class":"basic","parts":[{"id":"ops-06-01b_stmt","name":"statement","prose":"Policies and procedures for regular backup or replication and regular restore of cloud service customer data, cloud service derived data and cloud service provider data according to the sensitivity of the data are documented, communicated and provided in accordance with SP-01 regarding the following aspects:\n\n1. The extent and frequency of data backups and the duration of data retention are consistent with the contractual agreements with the cloud service customers and the cloud service provider's operational continuity requirements for Recovery Time Objective (RTO) and Recovery Point Objective (RPO);\n2. Data is backed up in encrypted, state of the art form;\n3. Secure storage, transfer, management and disposal of backup data;\n4. Access to the backed-up data and the execution of restores is performed only by authorised persons;\n5. Tests of data restore procedures by the cloud service provider (cf. OPS-08); and\n6. If part of the contractual agreement: Execution of actual data restore requests or restore tests initiated by the cloud service customer.\n\nThe policies and procedures include conditions for those parts of cloud service provider data that do not require a backup. For those parts of cloud service provider data, this subcriterion is not applicable."},{"id":"ops-06-01b_guidance-1","name":"guidance","prose":"Particularly within IaaS and PaaS service models, responsibility for backup and recovery of cloud service customer data often remains with the customer and is therefore not part of the contractual agreements between cloud service provider and cloud service customer.\n\nIf the data backup of cloud service customer data is not part of the contract, this criterion is not applicable for cloud service customer data, but it is still applicable for cloud service derived data and cloud service provider data. The extent to which the criterion is applicable to the cloud service is presented in the system description. \n\nThe data backup policies and procedures specifiy which type of data backup is to be carried out (e.g. scope, frequency and duration) and specify which data shall also be backed up in special cases (e.g. pure use of compute nodes without data storage). When backing up data, one has to distinct 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-02) for development and operational processes of the cloud service. If different data backup and recovery procedures exist for cloud service customer data and cloud service provider data, both variants are in scope for tests of controls according to this criteria catalogue.\n\nExisting contractual agreements prior to a C5 attestation do not need to be updated to incorporate the requirements specified in this criterion. Instead, new contractual agreements should be designed to ensure that specified requirements are clearly defined and agreed upon with cloud service customers."},{"id":"ops-06-01b_guidance-2","name":"guidance","prose":"Parts of cloud service provider data that do not require a backup include, but are not limited to, parts of cloud service provider data than can be built from scratch without a backup."}],"title":"OPS-06 Basic 01B"},{"id":"ops-06-01as","class":"additional-sharpen","parts":[{"id":"ops-06-01as_stmt","name":"statement","prose":"Policies and procedures for at least daily backup or replication and at least daily restore of cloud service customer data, cloud service derived data and cloud service provider data according to the sensitivity of the data are documented, communicated and provided in accordance with SP-01 regarding the following aspects:\n\n1. The extent and frequency of data backups and the duration of data retention are consistent with the contractual agreements with the cloud service customers and the cloud service provider's operational continuity requirements for Recovery Time Objective (RTO) and Recovery Point Objective (RPO);\n2. Data is backed up in encrypted, state of the art form;\n3. Secure storage, transfer, management and disposal of backup data;\n4. Access to the backed-up data and the execution of restores is performed only by authorised persons;\n5. Tests of data restore procedures by the cloud service provider (cf. OPS-08); and\n6. If part of the contractual agreement: Execution of actual data restore requests or restore tests initiated by the cloud service customer.\n\nThe policies and procedures include conditions for those parts of cloud service provider data that do not require a backup. For those parts of cloud service provider data, this subcriterion is not applicable."},{"id":"ops-06-01as_guidance-1","name":"guidance","prose":"Particularly within IaaS and PaaS service models, responsibility for backup and recovery of cloud service customer data often remains with the customer and is therefore not part of the contractual agreements between cloud service provider and cloud service customer.\n\nIf the data backup of cloud service customer data is not part of the contract, this criterion is not applicable for cloud service customer data, but it is still applicable for cloud service derived data and cloud service provider data. The extent to which the criterion is applicable to the cloud service is presented in the system description. \n\nThe data backup policies and procedures specifiy which type of data backup is to be carried out (e.g. scope, frequency and duration) and specify which data shall also be backed up in special cases (e.g. pure use of compute nodes without data storage). When backing up data, one has to distinct 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-02) for development and operational processes of the cloud service. If different data backup and recovery procedures exist for cloud service customer data and cloud service provider data, both variants are in scope for tests of controls according to this criteria catalogue.\n\nExisting contractual agreements prior to a C5 attestation do not need to be updated to incorporate the requirements specified in this criterion. Instead, new contractual agreements should be designed to ensure that specified requirements are clearly defined and agreed upon with cloud service customers."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"OPS-06 Additional Sharpen 01AS"}]},{"id":"ops-07","parts":[{"id":"ops-07-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the backup of data within their area of responsibility is monitored by technical and organisational measures.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Data Backup and Recovery - Monitoring","controls":[{"id":"ops-07-01b","class":"basic","parts":[{"id":"ops-07-01b_stmt","name":"statement","prose":"The execution of backups of cloud service customer data, cloud service derived data and cloud service provider data is monitored by technical and organisational measures documented and implemented in accordance with the policies and procedures for data backup and recovery (cf. OPS-06)."},{"id":"ops-07-01b_guidance-1","name":"guidance","prose":"If the data backup of cloud service customer data is not part of the contract concluded between the cloud service provider and the cloud service customer, this criterion is not applicable for cloud service customer data, but it is still applicable for cloud service derived data and cloud service provider data. The extent to which the criterion is applicable to the cloud service is presented in the system description."}],"title":"OPS-07 Basic 01B"},{"id":"ops-07-02b","class":"basic","parts":[{"id":"ops-07-02b_stmt","name":"statement","prose":"Incidents are investigated by qualified personnel and rectified timely to ensure compliance with contractual obligations to cloud service customers or the cloud service provider's business requirements regarding the scope and frequency of data backup and the duration of storage."},{"id":"ops-07-02b_guidance-1","name":"guidance","prose":"If the data backup of cloud service customer data is not part of the contract concluded between the cloud service provider and the cloud service customer, this criterion is not applicable for cloud service customer data, but it is still applicable for cloud service derived data and cloud service provider data. The extent to which the criterion is applicable to the cloud service is presented in the system description."}],"title":"OPS-07 Basic 02B"},{"id":"ops-07-01ac","class":"additional-complement","parts":[{"id":"ops-07-01ac_stmt","name":"statement","prose":"The relevant logs or summarised results are available to the cloud service customer in a self-service portal for monitoring the data backup."},{"id":"ops-07-01ac_guidance-1","name":"guidance","prose":"If the data backup of cloud service customer data is not part of the contract concluded between the cloud service provider and the cloud service customer, this criterion is not applicable for cloud service customer data, but it is still applicable for cloud service derived data and cloud service provider data. The extent to which the criterion is applicable to the cloud service is presented in the system description."}],"title":"OPS-07 Additional Complement 01AC"}]},{"id":"ops-08","parts":[{"id":"ops-08-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they actively request information on the results of restore tests from the cloud service provider. Customers assess the effectiveness of applied data recovery strategies and integrate insights into their own emergency plans in alignment with their business needs and security standards.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Data Backup and Recovery - Regular Testing","controls":[{"id":"ops-08-01b","class":"basic","parts":[{"id":"ops-08-01b_stmt","name":"statement","prose":"Restore procedures are tested regularly, at least annually. The tests include cloud service provider data and, if contractually agreed upon, cloud service customer data and cloud service derived data."},{"id":"ops-08-01b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-08-01b_guidance-2","name":"guidance","prose":"The use of cloud service customer data in backup and restore procedures as described in the basic criterion is a carefully considered exception. This exception does not extend to general software development or other testing environments and the use of cloud service customer data for testing is restricted specifically to backup and restore procedures."}],"title":"OPS-08 Basic 01B"},{"id":"ops-08-02b","class":"basic","parts":[{"id":"ops-08-02b_stmt","name":"statement","prose":"The tests allow an assessment 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)."},{"id":"ops-08-02b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-08 Basic 02B"},{"id":"ops-08-03b","class":"basic","parts":[{"id":"ops-08-03b_stmt","name":"statement","prose":"Cloud service customer data is only restored in environments that are subject to the same access restrictions as the production environment."},{"id":"ops-08-03b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-08-03b_guidance-2","name":"guidance","prose":"If cloud service customer data is restored in an environment with differing access restrictions, the confidentiality of the data may be affected."}],"title":"OPS-08 Basic 03B"},{"id":"ops-08-04b","class":"basic","parts":[{"id":"ops-08-04b_stmt","name":"statement","prose":"Performed restore tests are thoroughly documented. This also includes the documentation of the safe disposal of the restored data."},{"id":"ops-08-04b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-08 Basic 04B"},{"id":"ops-08-05b","class":"basic","parts":[{"id":"ops-08-05b_stmt","name":"statement","prose":"Deviations from the specifications are reported to the responsible personnel or system components so that these can timely assess the deviations and initiate the necessary actions."},{"id":"ops-08-05b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-08 Basic 05B"},{"id":"ops-08-01ac","class":"additional-complement","parts":[{"id":"ops-08-01ac_stmt","name":"statement","prose":"At the customer's request, the cloud service provider informs the cloud service customer of the results of the restore tests."},{"id":"ops-08-01ac_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-08 Additional Complement 01AC"},{"id":"ops-08-02ac","class":"additional-complement","parts":[{"id":"ops-08-02ac_stmt","name":"statement","prose":"Restore tests are included in the cloud service provider's business continuity management."},{"id":"ops-08-02ac_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-08 Additional Complement 02AC"}]},{"id":"ops-09","title":"Data Backup and Recovery - Storage","controls":[{"id":"ops-09-01b","class":"basic","parts":[{"id":"ops-09-01b_stmt","name":"statement","prose":"The cloud service provider transfers cloud service provider data and, if contractually agreed upon, cloud service customer data and cloud service derived data to be backed up to a remote location or transports these on backup media to a remote location."},{"id":"ops-09-01b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-09-01b_guidance-2","name":"guidance","prose":"A remote location can be e.g. another data centre of the cloud service provider."}],"title":"OPS-09 Basic 01B"},{"id":"ops-09-02b","class":"basic","parts":[{"id":"ops-09-02b_stmt","name":"statement","prose":"The protection needs resulting from the data classification of the original data (e.g., encryption, access control) are also applied to backups."},{"id":"ops-09-02b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."}],"title":"OPS-09 Basic 02B"},{"id":"ops-09-03b","class":"basic","parts":[{"id":"ops-09-03b_stmt","name":"statement","prose":"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 (cf. CRY-04)."},{"id":"ops-09-03b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-09-03b_guidance-2","name":"guidance","prose":"A remote location can be e.g. another data centre of the cloud service provider."}],"title":"OPS-09 Basic 03B"},{"id":"ops-09-04b","class":"basic","parts":[{"id":"ops-09-04b_stmt","name":"statement","prose":"The distance to the main site is chosen after sufficient consideration of the factors recovery times and impact of disasters on both sites."},{"id":"ops-09-04b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-09-04b_guidance-2","name":"guidance","prose":"A remote location can be e.g. another data centre of the cloud service provider."}],"title":"OPS-09 Basic 04B"},{"id":"ops-09-05b","class":"basic","parts":[{"id":"ops-09-05b_stmt","name":"statement","prose":"The physical and environmental security measures at the remote site are equivalent to those at the main site."},{"id":"ops-09-05b_guidance-1","name":"guidance","prose":"If the data backup has not been contractually agreed between the cloud service provider and the cloud service customer, this criterion is not applicable. The cloud service provider transparently presents this situation in the system description."},{"id":"ops-09-05b_guidance-2","name":"guidance","prose":"A remote location can be e.g. another data centre of the cloud service provider."}],"title":"OPS-09 Basic 05B"}]},{"id":"ops-10","parts":[{"id":"ops-10-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Logging and Monitoring - Policies and Procedures","controls":[{"id":"ops-10-01b","class":"basic","parts":[{"id":"ops-10-01b_stmt","name":"statement","prose":"The cloud service provider has established policies and procedures that govern the logging and monitoring of events on system components within its area of responsibility. These policies and procedures are documented, communicated and provided according to SP-01 with respect to the following aspects:\n\n1. Definition of events that could lead to a violation of the protection goals;\n2. Specifications for activating, stopping and pausing the various logs;\n3. Information regarding the purpose and retention period of the logs;\n4. Definition of roles, responsibilities and authorities for setting up and monitoring logging;\n5. Definition of log data allowed for transfer to cloud service customers and technical requirements of such a transfer;\n6. Information regarding timestamps used in event creation;\n7. Time synchronisation of system components with at least one approved time source that the cloud service provider considers to be reliable based on defined criteria. If several time sources are used, they are consistent with each other. The time sources can also be synchronised to several external reliable sources, except when used for isolated networks; and\n8. Compliance with legal and regulatory frameworks."},{"id":"ops-10-01b_guidance-1","name":"guidance","prose":"Logs as referred to in the basic criterion include cloud service derived data and cloud service provider data.\nLegal and regulatory frameworks can define e.g. legal requirements for retention and deletion of data."}],"title":"OPS-10 Basic 01B"}]},{"id":"ops-11","parts":[{"id":"ops-11-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that their contracts with the cloud service provider clearly outline the permissible uses of cloud service derived data. Cloud service customers verify that such data processing complies with contractual or legal restrictions and understand that the provider is obligated to delete data when it is no longer necessary for its initial purposes, unless agreed otherwise.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Logging and Monitoring - Policies and Procedures for Handling Cloud Service Derived Data and Account Data","controls":[{"id":"ops-11-01b","class":"basic","parts":[{"id":"ops-11-01b_stmt","name":"statement","prose":"Policies and procedures for the secure handling of cloud service derived data and account data are documented, communicated and provided according to SP-01 with regard to at least the following aspects:\n\n1. Cloud service derived data and account data is collected and used solely to administer and operate the cloud service, including purposes related to the implementation of security controls;\n2. No commercial use beyond the aforementioned purpose to administer and operate the cloud service;\n3. Storage for a fixed period reasonably related to the purposes of the collection;\n4. The confidentiality and integrity of the logs is protected through appropriate security controls;\n5. As far as technically possible, anonymised cloud service derived data is used only in a way so that no conclusions can be drawn about the usage behaviour of individual users of the cloud service customer;\n6. Cloud service derived data that has been fully anonymised and cannot be traced back to individual cloud service customers may be further processed and retained, provided no contractual or legal restrictions exist, otherwise immediate deletion if the purposes of the collection are fulfilled and further storage is no longer necessary; and\n7. Provision to cloud service customers according to contractual agreements."},{"id":"ops-11-01b_guidance-1","name":"guidance","prose":"The collection and use of cloud service derived data and account data for the administration and operation of the cloud service also includes the analysis of the aforementioned data to the purpose of improving the provided cloud service, unless this improvement only serves the economic interests of the cloud service provider.\nIf the cloud service provider acts as a cloud service broker, the policies and procedures should give special consideration to the complexities of handling cloud service derived data and account data as part of this role."}],"title":"OPS-11 Basic 01B"},{"id":"ops-11-02b","class":"basic","parts":[{"id":"ops-11-02b_stmt","name":"statement","prose":"The cloud service provider specifies in the contractual agreements with cloud service customers all purposes for which cloud service derived data are collected and used, except for those purposes that are inherent to the general operation of all cloud services."},{"id":"ops-11-02b_guidance-1","name":"guidance","prose":"Purposes that are inherent to the general operation of many cloud services are:\n\n1. Capacity planning and resource management;\n2. Security monitoring and incident response;\n3. Compliance with regulatory requirements; and\n4. Service performance and reliability."}],"title":"OPS-11 Basic 02B"},{"id":"ops-11-01ac","class":"additional-complement","parts":[{"id":"ops-11-01ac_stmt","name":"statement","prose":"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."}],"title":"OPS-11 Additional Complement 01AC"},{"id":"ops-11-02ac","class":"additional-complement","parts":[{"id":"ops-11-02ac_stmt","name":"statement","prose":"Cloud service derived data, particularly log data, is included in regulatory compliance assessments."}],"title":"OPS-11 Additional Complement 02AC"}]},{"id":"ops-12","title":"Logging and Monitoring - Access, Retention and Deletion","controls":[{"id":"ops-12-01b","class":"basic","parts":[{"id":"ops-12-01b_stmt","name":"statement","prose":"The requirements for the logging and monitoring of events and for the secure handling of cloud service derived data and cloud service provider data (cf. OPS-10, OPS-11) are implemented by technically supported procedures with regard to the following restrictions:\n\n1. Access only for authorised users and systems;\n2. Retention for the specified period; and\n3. Deletion when further retention is no longer necessary for the purpose of collection."}],"title":"OPS-12 Basic 01B"}]},{"id":"ops-13","title":"Logging and Monitoring - Security Information and Event Management","controls":[{"id":"ops-13-01b","class":"basic","parts":[{"id":"ops-13-01b_stmt","name":"statement","prose":"The cloud service provider integrates relevant log data (cloud service derived data and cloud service provider data) into a Security Information and Event Management (SIEM) system to establish a seamless connection between logging, monitoring, and security incident management."}],"title":"OPS-13 Basic 01B"},{"id":"ops-13-02b","class":"basic","parts":[{"id":"ops-13-02b_stmt","name":"statement","prose":"The SIEM system is deployed within the cloud environment or externally and includes the following capabilities:\n\n1. Standardisation of log data;\n2. Automated analysis to identify and correlate potential security incidents;\n3. Capabilities to detect unusual behaviour and potential threats;\n4. Real-time alerting to inform the incident response team of critical events; \n5. Reporting to the incident response team in case new information relevant to an event becomes available; and\n6. Automated response mechanisms for addressing security incidents."}],"title":"OPS-13 Basic 02B"},{"id":"ops-13-01ac","class":"additional-complement","parts":[{"id":"ops-13-01ac_stmt","name":"statement","prose":"The cloud service provider validates the correct operation of event detection processes on appropriate assets. The appropriateness of the assets is identified in accordance with the asset classification schema (cf. AM-09)."}],"title":"OPS-13 Additional Complement 01AC"},{"id":"ops-13-02ac","class":"additional-complement","parts":[{"id":"ops-13-02ac_stmt","name":"statement","prose":"Timely and appropriate remediation measures address any deviations identified during validation."}],"title":"OPS-13 Additional Complement 02AC"},{"id":"ops-13-03ac","class":"additional-complement","parts":[{"id":"ops-13-03ac_stmt","name":"statement","prose":"If an event that can lead to security incidents is identified, incident handling activities by the cloud service provider are triggered without undue delay."}],"title":"OPS-13 Additional Complement 03AC"}]},{"id":"ops-14","parts":[{"id":"ops-14-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they determine whether they require access to the customer-specific portion of the cloud service derived data that consists of log data, and if so, actively request it.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Logging and Monitoring - Retention of the Logging Data","controls":[{"id":"ops-14-01b","class":"basic","parts":[{"id":"ops-14-01b_stmt","name":"statement","prose":"The cloud service provider retains the generated log data, including SIEM log data, and keeps it 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."}],"title":"OPS-14 Basic 01B"},{"id":"ops-14-02b","class":"basic","parts":[{"id":"ops-14-02b_stmt","name":"statement","prose":"Log data is deleted if it is no longer required for the purpose for which it was collected."}],"title":"OPS-14 Basic 02B"},{"id":"ops-14-03b","class":"basic","parts":[{"id":"ops-14-03b_stmt","name":"statement","prose":"Between logging servers and the assets to be logged, authentication measures are in place to protect the integrity and authenticity of the information transmitted and stored. The transfer uses state of the art encryption or a dedicated administration network (out-of-band management)."}],"title":"OPS-14 Basic 03B"}]},{"id":"ops-15","parts":[{"id":"ops-15-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that unique user IDs are assigned which allow a corresponding analysis in the event of an incident.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Logging and Monitoring - Accountability","controls":[{"id":"ops-15-01b","class":"basic","parts":[{"id":"ops-15-01b_stmt","name":"statement","prose":"The log data generated - compromising both cloud service derived data and cloud service provider data - enables unambiguous identification of user access at the tenant level, supporting effective forensic analysis in the event of a security incident."}],"title":"OPS-15 Basic 01B"},{"id":"ops-15-02b","class":"basic","parts":[{"id":"ops-15-02b_stmt","name":"statement","prose":"Each logged event includes a time/date stamp to ensure accurate and traceable records."}],"title":"OPS-15 Basic 02B"},{"id":"ops-15-03b","class":"basic","parts":[{"id":"ops-15-03b_stmt","name":"statement","prose":"The cloud service provider is able to support forensic analysis of incidents and to retain a chain of evidence. This implies that the cloud service provider capture the state of hardware objects and network communication during security events."}],"title":"OPS-15 Basic 03B"},{"id":"ops-15-01ac","class":"additional-complement","parts":[{"id":"ops-15-01ac_stmt","name":"statement","prose":"On request of the cloud service customer, the cloud service provider provides the logs relating to the cloud service customer in an appropriate form and in a timely manner so that the cloud service customer can investigate any incidents relating to them."},{"id":"ops-15-01ac_guidance-1","name":"guidance","prose":"The additional criterion also refers to logs of system components under the responsibility of the cloud service provider, to which the cloud service customer generally has no access, insofar as these logs are relevant for the analysis of security incidents and for identifying access to cloud service customer service data (cf. IAM-07 and INQ-03). For logging of system components under the responsibility of the cloud service provider cf. PSS-04."}],"title":"OPS-15 Additional Complement 01AC"},{"id":"ops-15-02ac","class":"additional-complement","parts":[{"id":"ops-15-02ac_stmt","name":"statement","prose":"The aforementioned logs are collected and maintained using controls and processes that preserve their integrity and reliability for security monitoring and incident investigation purposes. This implies, but is not limited to:\n\n1. Records are complete and have not been tampered with in any way;\n2. Logging systems are clock synchronised, logs include accurate timestamps;\n3. Copies of electronic evidence are provably identical to the originals; and\n4. Any information system from which evidence has been gathered was operating correctly at the time the evidence was recorded."}],"title":"OPS-15 Additional Complement 02AC"}]},{"id":"ops-16","title":"Logging and Monitoring - Configuration","controls":[{"id":"ops-16-01b","class":"basic","parts":[{"id":"ops-16-01b_stmt","name":"statement","prose":"Access to system components for logging and monitoring in the cloud service provider's area of responsibility is restricted to authorised users and requires authentication with two or more factors."}],"title":"OPS-16 Basic 01B"},{"id":"ops-16-02b","class":"basic","parts":[{"id":"ops-16-02b_stmt","name":"statement","prose":"Changes to the configuration are made in accordance with the applicable policies (cf. DEV-03)."}],"title":"OPS-16 Basic 02B"}]},{"id":"ops-17","title":"Logging and Monitoring - Availability of the Monitoring Software","controls":[{"id":"ops-17-01b","class":"basic","parts":[{"id":"ops-17-01b_stmt","name":"statement","prose":"The cloud service provider monitors the availability of the system components for logging and monitoring in its area of responsibility."}],"title":"OPS-17 Basic 01B"},{"id":"ops-17-02b","class":"basic","parts":[{"id":"ops-17-02b_stmt","name":"statement","prose":"Failures are automatically and timely reported to the cloud service provider's responsible departments so that these can assess the failures and take required action."}],"title":"OPS-17 Basic 02B"},{"id":"ops-17-01ac","class":"additional-complement","parts":[{"id":"ops-17-01ac_stmt","name":"statement","prose":"The cloud service provider provides resilience for the logs and the associated infrastructure by defining, documenting and implementing measures to protect their integrity, availability and confidentiality."}],"title":"OPS-17 Additional Complement 01AC"},{"id":"ops-17-02ac","class":"additional-complement","parts":[{"id":"ops-17-02ac_stmt","name":"statement","prose":"The system components for logging and monitoring are designed in such a way that the overall functionality is not restricted if individual components fail."},{"id":"ops-17-02ac_guidance-1","name":"guidance","prose":"Individual components that might restrict the overall functionality are single points of failure. Such restrictions can be avoided by identifying potential single points of failure and adressing them through redundancy or the design and implementation of a resilient architecture."}],"title":"OPS-17 Additional Complement 02AC"}]},{"id":"ops-18","parts":[{"id":"ops-18-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they check system components in their area of responsibility for vulnerabilities on a regular basis and mitigate these with appropriate measures.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Managing Vulnerabilities - Policies and Procedures","controls":[{"id":"ops-18-01b","class":"basic","parts":[{"id":"ops-18-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational measures are documented, communicated and provided in accordance with SP-01 to govern the timely identification and addressing of vulnerabilities in the system components used to provide the cloud service. These policies and procedures contain specifications regarding the following aspects:\n\n1. Regular (proactive) identification of vulnerabilities through suitable measures, including vulnerability scans and penetration tests, considering typical vulnerability classes and Common Weaknesses (CWEs);\n2. Assessing the severity of identified vulnerabilities using the Common Vulnerability Scoring System (CVSS);\n3. Prioritising and implementing measures considering existing standards for timely remediation and/or mitigation of identified vulnerabilities based on severity according to defined time frames and with reference to commonly used scoring systems like the Exploit Prediction Scoring System (EPSS) and the Stakeholder-Specific Vulnerability Categorisation (SSVC);\n4. Deployment of Security Patches;\n5. Handling system components for which no measures for timely remediation or mitigation of vulnerabilities are initiated based on a risk assessment;\n6. Interfaces to incident management in case vulnerabilites become incidents;\n7. If AI-based tools are used for performing vulnerability scans or penetration tests, requirements for the comprehensible (traceable, transparent) documentation on the use of such tools and that these tools shall be used to support the cloud service provider's subject matter experts, not to replace them; and\n8. Providing information on the configuration of system components and cloud services, the existing vulnerabilities, and the available patches and/or mitigation measures, using widely adopted, preferably automated, formats."},{"id":"ops-18-01b_guidance-1","name":"guidance","prose":"Suitable measures for the identification of vulnerabilities include implementing RFC 9116 in conjunction with a Coordinated Vulnerability Disclosure (CVD) Policy according to established guidelines like ISO/IEC TR 5895:2022 and ISO/IEC 29147:2018 and community standards like Google's Project Zero Vulnerability Disclosure Policy.\n\nThe Common Vulnerability Scoring System (CVSS) is a technical standard that can be used for assessing the severity of identified vulnerabilities. Scores are calculated based on a formula with several metrics that approximate ease and impact of an exploit. In CVSS version 4.0 the scores can be mapped to qualitative ratings as follows:\n\n1. Low: 0.1 - 3.9;\n2. Medium: 4.0 - 6.9;\n3. High: 7.0 - 8.9; and\n4. Critical: 9.0 - 10.0.\n\nWidely adopted formats on the configuration of system components and cloud services, the existing vulnerabilities, and the available patches and/or mitigation measures include, but are not limited to:\n\n1. Software Bill of Materials (SBOM),\n2. Common Vulnerabilities and Exposures (CVE) or European Vulnerability Database (EUVD),\n3. Vulnerability, Exploitability eXchange (VEX); and\n4. Common Security Advisory Frameworks (CSAF)."},{"id":"ops-18-01b_guidance-2","name":"guidance","prose":"ISO/IEC 30111:2019 provides requirements and recommendations for prioritising and implementing measures to ensure the timely remediation or mitigation of identified vulnerabilities."}],"title":"OPS-18 Basic 01B"},{"id":"ops-18-02b","class":"basic","parts":[{"id":"ops-18-02b_stmt","name":"statement","prose":"The policies and procedures for the timely identification and addressing of vulnerabilities define that for vulnerabilities assessed to be 'critical', engagement has to begin in a timely manner after identification, even if this occurs outside regular working hours. They also define how such a vulnerability is engaged with."},{"id":"ops-18-02b_guidance-1","name":"guidance","prose":"ISO/IEC 30111:2019 provides requirements and recommendations for prioritising and implementing measures to ensure the timely remediation or mitigation of identified vulnerabilities."}],"title":"OPS-18 Basic 02B"},{"id":"ops-18-03b","class":"basic","parts":[{"id":"ops-18-03b_stmt","name":"statement","prose":"The policies and procedures for the timely identification and addressing of vulnerabilities also define that for vulnerabilities assessed to be 'high', engagement has to begin within one working day after their identification. They also define how such a vulnerability is engaged with."},{"id":"ops-18-03b_guidance-1","name":"guidance","prose":"ISO/IEC 30111:2019 provides requirements and recommendations for prioritising and implementing measures to ensure the timely remediation or mitigation of identified vulnerabilities."}],"title":"OPS-18 Basic 03B"},{"id":"ops-18-04b","class":"basic","parts":[{"id":"ops-18-04b_stmt","name":"statement","prose":"The engagement with a vulnerability according to the policies and procedures for the timely identification and addressing of vulnerabilities includes regular follow-up of the vulnerability until its remediation."}],"title":"OPS-18 Basic 04B"},{"id":"ops-18-05b","class":"basic","parts":[{"id":"ops-18-05b_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider can decide not to remediate or mitigate identified vulnerabilities. Such a risk assessment and the compensating or mitigating measures are reviewed regularly and in case of significant changes to the cloud service."}],"title":"OPS-18 Basic 05B"}]},{"id":"ops-19","title":"Managing Incidents and Crashes - Policies and Procedures","controls":[{"id":"ops-19-01b","class":"basic","parts":[{"id":"ops-19-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational measures are documented, communicated, and provided in accordance with SP-01 to govern the timely identification and management of incidents and crashes in the system components used to provide the cloud service or of parts or the whole cloud service. These policies and procedures include specifications regarding the following aspects: \n\n1. Classification and prioritisation of incidents and crashes;\n2. Standardised incident-handling procedures for addressing known issues;\n3. Escalation rules and procedures, including criteria for triggering Security Incident Management (SIM) processes in accordance with SIM-02 or internal incident management procedures;\n4. Knowledge sources for incidents and crashes;\n5. Criteria for determining when crashes are classified as incidents and when they trigger incident management processes;\n6. Mechanisms ensuring that access to crash files is restricted to authorised personnel only;\n7. Safeguards to prevent exposure of sensitive, personal, or confidential data within crash files;\n8. Encryption of crash files for storage and during transmission;\n9. Access management, logging, and review processes for access logs of crash files; and\n10. Retention periods and secure deletion processes for crash files once no longer needed."},{"id":"ops-19-01b_guidance-1","name":"guidance","prose":"A crash is an incident that leads to a sudden and complete failure of a system or system component. It can be indicative of a larger problem, such as an attempted DDoS attack or an unmitigated vulnerability. \n\nA crash file is the dump of a system's execution state, usually including contents of its storage or registers at the time of the crash (e.g. memory dump).\n\nCriteria for determining when an incident or crash triggering Security Incident Management (SIM) processes can include, but are not limited to, the incident or crash resulting in one or more of the following:\n\n1. Failure to uphold internal security policies, contractual agreements or relevant legal and regulatory requirements; \n2. Unauthorised access to cloud service customer data or system components used to provide the cloud service in the production environment;\n3. Loss or exfiltration of cloud service customer data;\n4. Unauthorised changes to system components used to provide the cloud service in the production environment; and\n5. Failure to uphold the availability requirements contained in the service level agreement."}],"title":"OPS-19 Basic 01B"}]},{"id":"ops-20","title":"Managing Incidents - Implementation","controls":[{"id":"ops-20-01b","class":"basic","parts":[{"id":"ops-20-01b_stmt","name":"statement","prose":"The cloud service provider identifies, records, classifies, prioritises, and addresses incidents according to the policies and procedures for the identification and management of incidents and crashes (cf. OPS-19)."}],"title":"OPS-20 Basic 01B"}]},{"id":"ops-21","title":"Managing Crashes - Implementation","controls":[{"id":"ops-21-01b","class":"basic","parts":[{"id":"ops-21-01b_stmt","name":"statement","prose":"Crashes of system components, parts of or the whole cloud service under the responsibility of the cloud service provider are identified, recorded, and addressed according to the policies and procedures for the identification and management of incidents and crashes (cf. OPS-19)."}],"title":"OPS-21 Basic 01B"}]},{"id":"ops-22","title":"Managing Vulnerabilities, Incidents and Crashes - Penetration Tests","controls":[{"id":"ops-22-01b","class":"basic","parts":[{"id":"ops-22-01b_stmt","name":"statement","prose":"The cloud service provider performs penetration tests by qualified internal personnel or external penetration testers at least once a year and in case of significant changes to the cloud service in accordance with the policies for managing vulnerabilities (cf. OPS-18)."},{"id":"ops-22-01b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-01b_guidance-2","name":"guidance","prose":"The qualification and competence of personnel for penetration tests can be verified based on professional certifications, e.g. as BSI-certified IS penetration tester or CREST-certified Cyber Security Professional."}],"title":"OPS-22 Basic 01B"},{"id":"ops-22-02b","class":"basic","parts":[{"id":"ops-22-02b_stmt","name":"statement","prose":"Penetration tests are carried out in accordance with a documented framework for penetration tests that outlines the number and types of penetration tests to be performed and the requirements for the qualification and competence of the personnel to perform such tests. The number and types of penetration tests to be performed are determined based on a risk assessment (cf. OIS-07)."},{"id":"ops-22-02b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-02b_guidance-2","name":"guidance","prose":"How many penetration tests should be performed within a year depends on factors such as the size and complexity of the provided cloud service. If penetration tests follow multi-year test plans, these should be considered when determining the number and types of penetration tests to be performed within a year."}],"title":"OPS-22 Basic 02B"},{"id":"ops-22-03b","class":"basic","parts":[{"id":"ops-22-03b_stmt","name":"statement","prose":"Penetration tests target the system components relevant to the provision of the cloud service in the area of responsibility of the cloud service provider. System components to be targeted are identified in a risk assessment."},{"id":"ops-22-03b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-03b_guidance-2","name":"guidance","prose":"The risk assessment should be used to identify the system components that are most critical for the provision of the cloud service or most relevant for penetration testing."},{"id":"ops-22-03b_guidance-3","name":"guidance","prose":"System components relevant to the provision of the cloud service in the area of responsibility of the cloud service provider can comprise such system components that are exposed at the external perimeter of the network or components accessible only from inside the network."}],"title":"OPS-22 Basic 03B"},{"id":"ops-22-04b","class":"basic","parts":[{"id":"ops-22-04b_stmt","name":"statement","prose":"Penetration tests are carried out in accordance with test plans that cover all relevant system components and specify which system components are to be tested."},{"id":"ops-22-04b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Basic 04B"},{"id":"ops-22-05b","class":"basic","parts":[{"id":"ops-22-05b_stmt","name":"statement","prose":"If penetration tests follow multi-year test plans, each relevant system component is subjected to at least one penetration test within a maximum period of three years."},{"id":"ops-22-05b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-05b_guidance-2","name":"guidance","prose":"System components relevant to the provision of the cloud service in the area of responsibility of the cloud service provider can comprise such system components that are exposed at the external perimeter of the network or components accessible only from inside the network."}],"title":"OPS-22 Basic 05B"},{"id":"ops-22-06b","class":"basic","parts":[{"id":"ops-22-06b_stmt","name":"statement","prose":"The cloud service provider assesses the severity of identified vulnerabilities in accordance with the Common Vulnerability Scoring System (CVSS), in the latest version valid at the time of the assessment."},{"id":"ops-22-06b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Basic 06B"},{"id":"ops-22-07b","class":"basic","parts":[{"id":"ops-22-07b_stmt","name":"statement","prose":"Actions for remediation or mitigation are taken in accordance with the time frames as defined in the policies for managing vulnerabilities (cf. OPS-18)."},{"id":"ops-22-07b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Basic 07B"},{"id":"ops-22-08b","class":"basic","parts":[{"id":"ops-22-08b_stmt","name":"statement","prose":"The vulnerabilities discovered through penetration testing are subject to a root cause analysis. The root cause analysis enables an assessment of the extent to which similar vulnerabilities may be present in the cloud service."},{"id":"ops-22-08b_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Basic 08B"},{"id":"ops-22-01as","class":"additional-sharpen","parts":[{"id":"ops-22-01as_stmt","name":"statement","prose":"The cloud service provider performs penetration tests at least every six months and in case of significant changes to the cloud service by independent external penetration testers in accordance with the policies for managing vulnerabilities (cf. OPS-18). The external penetration testers are engaged only if the personnel supposed to perform the test verifiably meets the cloud service provider's qualification and competence requirements. Internal personnel for penetration tests may support the external personnel."},{"id":"ops-22-01as_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-01as_guidance-2","name":"guidance","prose":"The qualification and competence of personnel for penetration tests can be verified based on professional certifications, e.g. as BSI-certified IS penetration tester or CREST-certified Cyber Security Professional."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"OPS-22 Additional Sharpen 01AS"},{"id":"ops-22-02as","class":"additional-sharpen","parts":[{"id":"ops-22-02as_stmt","name":"statement","prose":"Pre-launch and post-launch penetration tests are performed in accordance with a documented framework for penetration tests that outlines the number and types of penetration tests to be performed and the requirements for the qualification and competence of the personnel to perform such tests. The number and types of penetration tests to be performed are determined based on a risk assessment (cf. OIS-07)."},{"id":"ops-22-02as_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-02as_guidance-2","name":"guidance","prose":"How many penetration tests should be performed within a year depends on factors such as the size and complexity of the provided cloud service. If penetration tests follow multi-year test plans, these should be considered when determining the number and types of penetration tests to be performed within a year."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"OPS-22 Additional Sharpen 02AS"},{"id":"ops-22-03as","class":"additional-sharpen","parts":[{"id":"ops-22-03as_stmt","name":"statement","prose":"Penetration tests target system components relevant to the provision of the cloud service in the area of responsibility of the cloud service provider. System components to be targeted are identified in a risk assessment incorporating, where applicable, threat modelling."},{"id":"ops-22-03as_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-03as_guidance-2","name":"guidance","prose":"The risk assessment should be used to identify the system components that are most critical for the provision of the cloud service or most relevant for penetration testing."}],"props":[{"name":"sharpened-basic-criterion","value":"03B"}],"title":"OPS-22 Additional Sharpen 03AS"},{"id":"ops-22-01ac","class":"additional-complement","parts":[{"id":"ops-22-01ac_stmt","name":"statement","prose":"Penetration tests are performed based on reviews of the architecture and configuration of the system components, and of the cloud service provider's source code."},{"id":"ops-22-01ac_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Additional Complement 01AC"},{"id":"ops-22-02ac","class":"additional-complement","parts":[{"id":"ops-22-02ac_stmt","name":"statement","prose":"The cloud service provider designs a multi-year test plan for its penetration testing activities."},{"id":"ops-22-02ac_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Additional Complement 02AC"},{"id":"ops-22-03ac","class":"additional-complement","parts":[{"id":"ops-22-03ac_stmt","name":"statement","prose":"The cloud service provider reviews the effectiveness of penetration tests on system components at least annually, and in case of significant changes to the cloud service."},{"id":"ops-22-03ac_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Additional Complement 03AC"},{"id":"ops-22-04ac","class":"additional-complement","parts":[{"id":"ops-22-04ac_stmt","name":"statement","prose":"The cloud service provider uses the threat modelling process to prioritise system components with the highest risk exposure for penetration testing by systematically analysing cloud components, services, data flows, trust boundaries and assets critical to the cloud service to enumerate potential threats, vulnerabilities, and attack vectors."},{"id":"ops-22-04ac_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."},{"id":"ops-22-04ac_guidance-2","name":"guidance","prose":"This subcriterion is only applicable if subcriterion OPS-22.03AS is applied as well.\n\nThe risk-based scoping ensures that penetration tests focus on the areas most susceptible to security threats, improves business alignment and collaboration, and provides clear technical insight into which components require testing beyond standard risk evaluation.\n\nFor the threat modelling process, a structured threat modelling approach such as STRIDE, DREAD, PASTA, or hybrid methodologies tailored for cloud environments can be used."}],"title":"OPS-22 Additional Complement 04AC"},{"id":"ops-22-05ac","class":"additional-complement","parts":[{"id":"ops-22-05ac_stmt","name":"statement","prose":"The cloud service provider correlates the possible exploits of discovered vulnerabilities with previous information security incidents to identify if the vulnerability may have been exploited before its discovery."},{"id":"ops-22-05ac_guidance-1","name":"guidance","prose":"See section '1.2 Definitions' for the terms 'penetration test' and 'significant change'.\n\nIn contrast to vulnerability scans, which analyse code, penetration tests as referred to in this criterion mainly aim at probing the live system to uncover real-world vulnerabilities or weaknesses that only show up in the actual operation of the cloud service, thus creating the connection to criterion OPS-18.\n\nThere are three types of penetration tests: \n\n1. Black-box testing: Testing performed without prior knowledge of the internal structure/design/implementation of the object being tested;\n2. Grey-box testing: Testing performed with partial knowledge of the internal structure/design/implementation of the object being tested; and\n3. White-box testing: Testing performed with knowledge of the internal structure/design/implementation of the object being tested.\n\nIt can further be distinguished between\n\n1. Pre-launch penetration testing: Testing already performed as part of the software development process during the test phase of the cloud service (cf. DEV-07); and\n2. Post-launch penetration testing: Testing carried out during the regular operations of the cloud service.\n\nSignificant changes may include, but are not limited to, the following events:\n\n1. Replacing core cloud infrastructure technologies or performing major version upgrades;\n2. Moving between service organisations, such as switching to a new IaaS or data centre provider;\n3. Material changes in the way cloud service customer data is processed and stored, such as new backup technologies or new regions from which the service is operated;\n4. Replacing or performing major upgrades on security technologies such as authentication workflows, network security mechanisms or monitoring mechanisms; and\n5. Material changes to the cloud service model or of functionality made available to the cloud service customer."}],"title":"OPS-22 Additional Complement 05AC"}]},{"id":"ops-23","title":"Managing Vulnerabilities, Incidents and Crashes - Measurements, Analyses and Assessments of Procedures","controls":[{"id":"ops-23-01b","class":"basic","parts":[{"id":"ops-23-01b_stmt","name":"statement","prose":"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."},{"id":"ops-23-01b_guidance-1","name":"guidance","prose":"The assessment of the suitability, appropriateness and effectiveness of procedures for managing vulnerabilities and incidents may be based on the following information:\n\n1. Regular reporting of KPIs (Key Performance Indicators) that are volume, time-based or resolution/quality-based;\n2. Customer complaints or the results of customer surveys about their satisfaction with the procedures; and\n3. Results of internal or external audits.\n\nKPIs for vulnerabilities include, for example:\n1. Mean Time to Detect (MTTD, average time it takes to discover a vulnerability from its disclosure or creation);\n2. Mean Time to Remediate (MTTR, average time it takes to fix or patch a vulnerability after it has been detected);\n3. Number of open vulnerabilities at each severity level; and\n4. Percentage of vulnerabilities that have been patched within a set period.\n\nKPIs for incidents include, for example:\n1. Number of incidents reported over a set period and how this evolved over the time;\n2. Average response and resolution time;\n3. Percentage of incidents resolved within the agreed-upon service level agreement; and\n4. Percentage of incidents resolved during the first attempt for resolution."}],"title":"OPS-23 Basic 01B"},{"id":"ops-23-02b","class":"basic","parts":[{"id":"ops-23-02b_stmt","name":"statement","prose":"Results are evaluated at least quarterly in a documented form by responsible individuals or groups of the cloud service provider to initiate continuous improvement actions and to verify their effectiveness."}],"title":"OPS-23 Basic 02B"}]},{"id":"ops-24","parts":[{"id":"ops-24-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Involvement of Cloud Service Customers in the Event of Incidents","controls":[{"id":"ops-24-01b","class":"basic","parts":[{"id":"ops-24-01b_stmt","name":"statement","prose":"The cloud service provider periodically informs the cloud service customer on the status of incidents affecting the cloud service customer, or, where appropriate and necessary, involve the customer in the resolution, in a manner consistent with the contractual agreements."}],"title":"OPS-24 Basic 01B"},{"id":"ops-24-02b","class":"basic","parts":[{"id":"ops-24-02b_stmt","name":"statement","prose":"As soon as an incident has been resolved from the cloud service provider's perspective, the cloud service customer is informed about the actions taken according to the contractual agreements."}],"title":"OPS-24 Basic 02B"},{"id":"ops-24-01ac","class":"additional-complement","parts":[{"id":"ops-24-01ac_stmt","name":"statement","prose":"The cloud service provider defines and documents procedures in contractual agreements with cloud service customers that specify the involvement of the customer in confirming, within a specified time period, that a resolution has effectively addressed the root cause of an incident."}],"title":"OPS-24 Additional Complement 01AC"}]},{"id":"ops-25","parts":[{"id":"ops-25-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that system components under their responsibility are regularly checked for vulnerabilities and to mitigate these by appropriate measures. If cloud service customers operate virtual machines or containers with the cloud service, this also includes performing vulnerability scans to ensure that secure images (so-called golden images) provided by either the cloud service provider or the cloud service customer themselves are used.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Managing Vulnerabilities, Incidents and Crashes - Vulnerability Scans","controls":[{"id":"ops-25-01b","class":"basic","parts":[{"id":"ops-25-01b_stmt","name":"statement","prose":"System components in the area of responsibility of the cloud service provider for the provision of the cloud service are subject to vulnerability scans at least once a month in accordance with the policies for handling vulnerabilities (cf. OPS-18). These vulnerability scans include a comparison of software component data against up-to-date vulnerability databases (e.g., CVE, EUVD, etc.) to identify known vulnerabilities."},{"id":"ops-25-01b_guidance-1","name":"guidance","prose":"In contrast to penetration tests (cf. OPS-22), which are carried out manually and according to an individual scheme, the check for open vulnerabilities is performed automatically, using so-called vulnerability scanners. \n\nDefinitions of the terms 'CVE' and 'EUVD', as well as other vulnerability-related terms, can be found in the supplementary information of criterion OPS-18.01B.\n\nThe software component data to be compared against up-to-date vulnerability databases can be, but does not have to be, obtained using a Software Bill of Materials (SBOM)."}],"title":"OPS-25 Basic 01B"},{"id":"ops-25-02b","class":"basic","parts":[{"id":"ops-25-02b_stmt","name":"statement","prose":"The cloud service provider assesses the severity of vulnerabilities in accordance with defined criteria."}],"title":"OPS-25 Basic 02B"},{"id":"ops-25-03b","class":"basic","parts":[{"id":"ops-25-03b_stmt","name":"statement","prose":"Measures for timely remediation or mitigation are initiated within defined time frame."}],"title":"OPS-25 Basic 03B"},{"id":"ops-25-04b","class":"basic","parts":[{"id":"ops-25-04b_stmt","name":"statement","prose":"The results of the vulnerability scans are used to update the cloud service provider's SIEM system (cf. OPS-13) rules, enabling the system to detect when known vulnerabilities are being actively exploited."}],"title":"OPS-25 Basic 04B"},{"id":"ops-25-01as","class":"additional-sharpen","parts":[{"id":"ops-25-01as_stmt","name":"statement","prose":"System components in the area of responsibility of the cloud service provider for the provision of the cloud service are subject to vulnerability scans at least once a day in accordance with the policies for handling vulnerabilities (cf. OPS-18). These vulnerability scans include a comparison of software component data against up-to-date vulnerability databases (e.g., CVE, EUVD, etc.) to identify known vulnerabilities."},{"id":"ops-25-01as_guidance-1","name":"guidance","prose":"In contrast to penetration tests (cf. OPS-22), which are carried out manually and according to an individual scheme, the check for open vulnerabilities is performed automatically, using so-called vulnerability scanners. \n\nDefinitions of the terms 'CVE' and 'EUVD', as well as other vulnerability-related terms, can be found in the supplementary information of criterion OPS-18.01B.\n\nThe software component data to be compared against up-to-date vulnerability databases can be, but does not have to be, obtained using a Software Bill of Materials (SBOM)."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"OPS-25 Additional Sharpen 01AS"},{"id":"ops-25-02as","class":"additional-sharpen","parts":[{"id":"ops-25-02as_stmt","name":"statement","prose":"The cloud service provider assesses the severity of vulnerabilities using the latest version of the Common Vulnerability Scoring System (CVSS) valid at the time of the assessment."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"OPS-25 Additional Sharpen 02AS"},{"id":"ops-25-01ac","class":"additional-complement","parts":[{"id":"ops-25-01ac_stmt","name":"statement","prose":"Time frames for the initiation of remediation or mitigation efforts after a vulnerability is identified are defined and monitored according to a risk-based classification framework. This framework incorporates, but is not limited to, the CVSS severity level of vulnerabilities."},{"id":"ops-25-01ac_guidance-1","name":"guidance","prose":"An example of a framework for risk-based classification and definition of time frames can be:\n\n1. Critical (CVSS = 9.0 - 10.0): 24 - 48 hours;\n2. High (CVSS = 7.0 - 8.9): 48 - 72 hours;\n3. Medium (CVSS = 4.0 - 6.9): 5 days; and\n4. Low (CVSS = 0.1 - 3.9): 1 month."}],"title":"OPS-25 Additional Complement 01AC"}]},{"id":"ops-26","parts":[{"id":"ops-26-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Managing Vulnerabilities, Incidents and Crashes - System Hardening","controls":[{"id":"ops-26-01b","class":"basic","parts":[{"id":"ops-26-01b_stmt","name":"statement","prose":"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."},{"id":"ops-26-01b_guidance-1","name":"guidance","prose":"System components in the sense of the 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."},{"id":"ops-26-01b_guidance-2","name":"guidance","prose":"Generally 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-Compendium."}],"title":"OPS-26 Basic 01B"},{"id":"ops-26-02b","class":"basic","parts":[{"id":"ops-26-02b_stmt","name":"statement","prose":"The hardening requirements for each system component are documented."}],"title":"OPS-26 Basic 02B"},{"id":"ops-26-03b","class":"basic","parts":[{"id":"ops-26-03b_stmt","name":"statement","prose":"If non-modifiable ('immutable') images are used, compliance with the hardening specifications, as defined in the hardening requirements, is checked upon creation of the images."}],"title":"OPS-26 Basic 03B"},{"id":"ops-26-04b","class":"basic","parts":[{"id":"ops-26-04b_stmt","name":"statement","prose":"Configurations and log files (cloud service provider data) regarding the continuous availability of the aforementioned immutable images are retained."},{"id":"ops-26-04b_guidance-1","name":"guidance","prose":"The configuration and log files for non-modifiable images include e.g.:\n\n1. Configuration of the images used with regards to implemented hardening; \n2. Specifications including version history; and\n3. Logs for file integrity monitoring of images in productive use."}],"title":"OPS-26 Basic 04B"},{"id":"ops-26-05b","class":"basic","parts":[{"id":"ops-26-05b_stmt","name":"statement","prose":"The cloud service provider implements monitoring measures to ensure system components comply with hardening specifications."},{"id":"ops-26-05b_guidance-1","name":"guidance","prose":"System components in the sense of the 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."},{"id":"ops-26-05b_guidance-2","name":"guidance","prose":"Compliance with hardening specifications can be monitored with e.g. file integrity monitoring."}],"title":"OPS-26 Basic 05B"},{"id":"ops-26-06b","class":"basic","parts":[{"id":"ops-26-06b_stmt","name":"statement","prose":"Identified deviations from these specifications are timely reported to the appropriate departments for immediate assessment and action."}],"title":"OPS-26 Basic 06B"},{"id":"ops-26-05as","class":"additional-sharpen","parts":[{"id":"ops-26-05as_stmt","name":"statement","prose":"System components in the cloud service provider's area of responsibility are automatically monitored for compliance with hardening specifications."},{"id":"ops-26-05as_guidance-1","name":"guidance","prose":"System components in the sense of the 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."},{"id":"ops-26-05as_guidance-2","name":"guidance","prose":"Compliance with hardening specifications can be monitored with e.g. file integrity monitoring."}],"props":[{"name":"sharpened-basic-criterion","value":"05B"}],"title":"OPS-26 Additional Sharpen 05AS"}]},{"id":"ops-27","title":"Managing Vulnerabilities - Patch Management Policies and Procedures","controls":[{"id":"ops-27-01b","class":"basic","parts":[{"id":"ops-27-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational measures are documented, communicated and provided in accordance with SP-01 to ensure system components under the responsibility of the cloud service provider are patched within a suitable time frame depending on contractual agreements and identified vulnerabilities or exploits. These policies and procedures contain specifications regarding the following aspects:\n\n1. Software is kept up-to-date, including timely deployment of security patches;\n2. Patches are scheduled within maintenance windows, where applicable, to minimise service disruption; and\n3. Patches are tested in non-production environments before they are rolled out into the production environment, provided testing was successful. Mechanisms are in place to revert to previous software versions in case of unexpected issues."},{"id":"ops-27-01b_guidance-1","name":"guidance","prose":"Patches are defined as software updates to systems components with the goal of increasing security by addressing issues, vulnerabilities or exploits."},{"id":"ops-27-01b_guidance-2","name":"guidance","prose":"What constitutes as timely in the sense of this subcriterion depends on the criticality of the patched issue, vulnerability or exploit."}],"title":"OPS-27 Basic 01B"},{"id":"ops-27-02b","class":"basic","parts":[{"id":"ops-27-02b_stmt","name":"statement","prose":"Patch management procedures are harmonised with the cloud service provider's overall software change management process (cf. DEV-03)."},{"id":"ops-27-02b_guidance-1","name":"guidance","prose":"Patches are defined as software updates to systems components with the goal of increasing security by addressing issues, vulnerabilities or exploits."}],"title":"OPS-27 Basic 02B"},{"id":"ops-27-03b","class":"basic","parts":[{"id":"ops-27-03b_stmt","name":"statement","prose":"According to the measures and procedures of the overall change management, patches provided by third parties are identified, tested and deployed."},{"id":"ops-27-03b_guidance-1","name":"guidance","prose":"Patches are defined as software updates to systems components with the goal of increasing security by addressing issues, vulnerabilities or exploits."}],"title":"OPS-27 Basic 03B"},{"id":"ops-27-04b","class":"basic","parts":[{"id":"ops-27-04b_stmt","name":"statement","prose":"Systems are scanned after application of patches to ensure vulnerabilities and exploits are remediated and no known or unmitigated vulnerabilities or exploits were deployed."},{"id":"ops-27-04b_guidance-1","name":"guidance","prose":"Patches are defined as software updates to systems components with the goal of increasing security by addressing issues, vulnerabilities or exploits."},{"id":"ops-27-04b_guidance-2","name":"guidance","prose":"The scans performed after the application of a patch can, but do not have to be, restricted to the system components to which the patch was applied."}],"title":"OPS-27 Basic 04B"},{"id":"ops-27-03as","class":"additional-sharpen","parts":[{"id":"ops-27-03as_stmt","name":"statement","prose":"According to the measures and procedures of the overall change management, patches provided by third parties are identified, tested and deployed in an automated manner. In case of patches where manual intervention is required, an exception handling process for manual patching is defined."},{"id":"ops-27-03as_guidance-1","name":"guidance","prose":"Patches are defined as software updates to systems components with the goal of increasing security by addressing issues, vulnerabilities or exploits."}],"props":[{"name":"sharpened-basic-criterion","value":"03B"}],"title":"OPS-27 Additional Sharpen 03AS"}]},{"id":"ops-28","title":"Managing Vulnerabilities - Patch Management Implementation","controls":[{"id":"ops-28-01b","class":"basic","parts":[{"id":"ops-28-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains technical and organisational measures for the deployment of patches on the systems and applications under its responsibility according to the patch management policies and procedures (cf. OPS-27)."}],"title":"OPS-28 Basic 01B"}]},{"id":"ops-29","title":"Managing Vulnerabilities, Incidents and Crashes - Externally Sourced Components","controls":[{"id":"ops-29-01b","class":"basic","parts":[{"id":"ops-29-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains technical and organisational measures to manage updates to system components used to provide the cloud service that incorporate third-party or open-source libraries. This includes:\n\n1. Regularly identifying available updates and known vulnerabilities in third-party or open-source libraries used within applications;\n2. Evaluating the potential impact of identified updates and vulnerabilities on the applications and the overall security posture;\n3. Implementing necessary updates and patches in a timely manner to address identified vulnerabilities; and\n4. Continuously monitoring applications to ensure updates are effectively applied and no known or unmitigated vulnerabilities are introduced."}],"title":"OPS-29 Basic 01B"}]},{"id":"ops-30","title":"Separation of Datasets - Policies and Procedures","controls":[{"id":"ops-30-01b","class":"basic","parts":[{"id":"ops-30-01b_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider established policies and procedures with technical and organisational measures to ensure separation of cloud service customer data between different customers and between customers and the cloud service provider. These policies and procedures are documented, communicated and provided in accordance with SP-01 and contain specifications regarding the client separation based on a documented cloud layer model and include the following:\n\n1. Illustration of which cloud layers are used for the particular cloud service. The used cloud layers should be appropriate to enable client separation;\n2. Measures used to separate cloud service customer data along the used cloud layers. Those measures are categorised according to the protection goals of confidentiality, integrity and availability and if they are preventive, detective or reactive measures;\n3. Monitoring and compliance with these measures; and\n4. Initiation of suitable measures in the event of deviations."},{"id":"ops-30-01b_guidance-1","name":"guidance","prose":"The policies and procedures of this criteria are meant to serve as an umbrella guideline for all cyber security measures against all threats that stem from sharing physical or virtual resources and that lead to a loss of separation of data sets. Ideally, the cloud service provider has already ensured the separation of data sets between different customers and between customers and cloud service provider via all other policies, procedures and the corresponding measures. The systematic approach of the policies and procedures addressed by this criterion ensures that no aspect of this separation is overlooked. It also provides a good basis to explain the cyber security of the cloud service to the customer in an appealing manner (cf. PSS-01).\n\nCloud layers in the sense of this criterion can be found in the *CISA Cloud Security Technical Reference Architecture*. The layers provided in version 2.0 of this document include identity, credential and access management, data, networking, applications, runtime, middleware, operating systems, virtualisation, servers, storage and physical security. The cloud service provider may use its own categorisation of cloud layers as appropriate for the provided cloud service. \n\nThere are nine combinations for confidentiality, integrity and availability with prevention, detection and reaction. Applying this to every cloud layer may lead to a large number of combinations. However, depending on the cloud service, it can be acceptable that it may not be possible to provide meaningful information in the policy for every possible combination of prevention, detection and reaction as well as confidentiality, integrity and availability. Those cases should be comprehensibly documented in the policies and procedures."}],"title":"OPS-30 Basic 01B"}]},{"id":"ops-31","parts":[{"id":"ops-31-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the functions provided by the cloud service for separating shared virtual and physical resources are used in such way that risks related to separation are adequately addressed according to the data's protection needs.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Separation of Datasets - Implementation","controls":[{"id":"ops-31-01b","class":"basic","parts":[{"id":"ops-31-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains measures and procedures against threats to the separation of data sets according to the policies and procedures of OPS-30. The measures address prevention against, detection of and reaction to any incidents infringing the separation."}],"title":"OPS-31 Basic 01B"},{"id":"ops-31-02b","class":"basic","parts":[{"id":"ops-31-02b_stmt","name":"statement","prose":"Cloud service 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 assessment and following policies on cryptography (cf. CRY-01) to ensure the confidentiality and integrity of this data."},{"id":"ops-31-02b_guidance-1","name":"guidance","prose":"Shared resources include CPU, RAM, storage space and networks. The separation of cloud service customer data on shared resources can take place, for example, in accordance with cloud layers described in the *CISA Cloud Security Technical Reference Architecture*. The separation on each shared resource is implemented as deemed appropriate based on the conducted risk assessment, which might also include not implementing a cryptographic separation for certain shared resources.\n\nWhere the adequacy and effectiveness of separation 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 policies and procedures).\n\nThe separation of transmitted data is subject to criterion COS-06."}],"title":"OPS-31 Basic 02B"},{"id":"ops-31-03b","class":"basic","parts":[{"id":"ops-31-03b_stmt","name":"statement","prose":"The risk assessment is reviewed as needed, especially in case of changes to the architecture of the cloud service, and at least annually. Measures are adjusted or improved as appropriate to ensure they remain commensurate with the risks."}],"title":"OPS-31 Basic 03B"}]},{"id":"ops-32","title":"Confidential Computing - Policies and Procedures","controls":[{"id":"ops-32-01b","class":"basic","parts":[{"id":"ops-32-01b_stmt","name":"statement","prose":"If the cloud service comprises capabilities for confidential computing, policies and procedures and technical safeguards are documented, communicated and provided according to SP-01, in which the following aspects are described:\n\n1. Purpose and scope, including which information security risks on the cloud service provider's side are to be mitigated through the use of confidential computing (cf. OIS-07) and how the cloud service customers can use the provided features to manage information security risks on their side;\n2. Available confidential computing technologies;\n3. Determination of which parts of the cloud stack are protected with each technology and where third-party access is possible;\n4. Listing of involved suppliers/service organisations; and\n5. Utilisation of Trusted Execution Environments (TEEs) or secure enclaves."},{"id":"ops-32-01b_guidance-1","name":"guidance","prose":"Confidential computing as defined by the Confidential Computing Consortium and within the meaning of this criterion is the protection of data 'in use' by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). \n\nA TEE represents an isolated part within a system that provides a specially protected runtime environment. The TEE can be part of the main processor (CPU) or part of the system-on-chip (SoC). Generally, a TEE enforces that only authorised code can execute within the TEE and data used by that code cannot be read or tampered with by code outside the TEE. The attestation of the TEE and the application running within the TEE serve to validate the trustworthiness of the processing.\n\nConfidential computing measures include the implementation and monitoring of technical and organisational controls to ensure the secure deployment and operation of confidential computing technologies. Such measures may include the validation of TEE configurations, continuous attestation processes, monitoring for unauthorised code changes, and lifecycle management of attested environments."}],"title":"OPS-32 Basic 01B"},{"id":"ops-32-02b","class":"basic","parts":[{"id":"ops-32-02b_stmt","name":"statement","prose":"The cloud service provider provides its customers with information on the aspects specified in OPS-32.01B according to PSS-01."},{"id":"ops-32-02b_guidance-1","name":"guidance","prose":"Confidential computing as defined by the Confidential Computing Consortium and within the meaning of this criterion is the protection of data 'in use' by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). \n\nA TEE represents an isolated part within a system that provides a specially protected runtime environment. The TEE can be part of the main processor (CPU) or part of the system-on-chip (SoC). Generally, a TEE enforces that only authorised code can execute within the TEE and data used by that code cannot be read or tampered with by code outside the TEE. The attestation of the TEE and the application running within the TEE serve to validate the trustworthiness of the processing.\n\nConfidential computing measures include the implementation and monitoring of technical and organisational controls to ensure the secure deployment and operation of confidential computing technologies. Such measures may include the validation of TEE configurations, continuous attestation processes, monitoring for unauthorised code changes, and lifecycle management of attested environments."}],"title":"OPS-32 Basic 02B"},{"id":"ops-32-03b","class":"basic","parts":[{"id":"ops-32-03b_stmt","name":"statement","prose":"Additional aspects addressed by the policies and procedures for confidential computing, not necessarily included in the information provided to the cloud service customers, include:\n\n1. Responsibilities for the implementation and monitoring of confidential computing measures;\n2. Security requirements to ensure the confidentiality, integrity, and authenticity of the data during processing; and\n3. Relevant legal and regulatory requirements applicable to confidential computing.\n\nThese security requirements to ensure the confidentiality, integrity, and authenticity of the data during processing include that:\n\n1. Neither the cloud service provider nor any other unauthorised entity shall be able to access the cloud service customer data or the keys used for protecting that data; and\n2. Cryptographic algorithms that comply with the cloud service provider's policy for the use of cryptographic mechanisms (cf. CRY-01) are used."},{"id":"ops-32-03b_guidance-1","name":"guidance","prose":"Confidential computing as defined by the Confidential Computing Consortium and within the meaning of this criterion is the protection of data 'in use' by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). \n\nA TEE represents an isolated part within a system that provides a specially protected runtime environment. The TEE can be part of the main processor (CPU) or part of the system-on-chip (SoC). Generally, a TEE enforces that only authorised code can execute within the TEE and data used by that code cannot be read or tampered with by code outside the TEE. The attestation of the TEE and the application running within the TEE serve to validate the trustworthiness of the processing.\n\nConfidential computing measures include the implementation and monitoring of technical and organisational controls to ensure the secure deployment and operation of confidential computing technologies. Such measures may include the validation of TEE configurations, continuous attestation processes, monitoring for unauthorised code changes, and lifecycle management of attested environments."}],"title":"OPS-32 Basic 03B"},{"id":"ops-32-01ac","class":"additional-complement","parts":[{"id":"ops-32-01ac_stmt","name":"statement","prose":"The cloud service provider documents and implements a technical framework for confidential computing, demonstrating how certain information security risks are mitigated (cf. OIS-07). The framework includes at least the following procedures and technical safeguards:\n\n1. Usage of Trusted Execution Environments (TEEs) or secure enclaves to process sensitive data (data in use) in a protected environment;\n2. Documentation of all associated interfaces;\n3. Consideration of available hardware attestations;\n4. Utilisation of encryption techniques to secure data during processing, including secure key management;\n5. Remote attestation to verify the identity and measured state of the TEE as well as code executed within the TEE;\n6. Implementation of monitoring and logging mechanisms to detect and respond to security incidents;\n7. Conducting security reviews and penetration tests (cf. OPS-22) regularly as well as on an event-driven basis to verify the effectiveness of confidential computing measures; and\n8. Performing regular updates on the Trusted Computing Base of the TEE."},{"id":"ops-32-01ac_guidance-1","name":"guidance","prose":"Confidential computing as defined by the Confidential Computing Consortium and within the meaning of this criterion is the protection of data 'in use' by performing computation in a hardware-based, attested Trusted Execution Environment (TEE). \n\nA TEE represents an isolated part within a system that provides a specially protected runtime environment. The TEE can be part of the main processor (CPU) or part of the system-on-chip (SoC). Generally, a TEE enforces that only authorised code can execute within the TEE and data used by that code cannot be read or tampered with by code outside the TEE. The attestation of the TEE and the application running within the TEE serve to validate the trustworthiness of the processing.\n\nConfidential computing measures include the implementation and monitoring of technical and organisational controls to ensure the secure deployment and operation of confidential computing technologies. Such measures may include the validation of TEE configurations, continuous attestation processes, monitoring for unauthorised code changes, and lifecycle management of attested environments."}],"title":"OPS-32 Additional Complement 01AC"}]},{"id":"ops-33","title":"Confidential Computing - Remote Attestation","controls":[{"id":"ops-33-01b","class":"basic","parts":[{"id":"ops-33-01b_stmt","name":"statement","prose":"If the cloud service comprises capabilities for confidential computing, the cloud service provider offers remote attestation functionalities for data in-use protection."}],"title":"OPS-33 Basic 01B"},{"id":"ops-33-02b","class":"basic","parts":[{"id":"ops-33-02b_stmt","name":"statement","prose":"Remote attestation functionalities are based on cryptographic means rooted in trusted hard- and software."}],"title":"OPS-33 Basic 02B"},{"id":"ops-33-03b","class":"basic","parts":[{"id":"ops-33-03b_stmt","name":"statement","prose":"Remote attestation functionalities comprise an interface that allows the customer to verify the integrity of the remote attestation."},{"id":"ops-33-03b_guidance-1","name":"guidance","prose":"The attestation interface allows customers to securely retrieve attestation evidence from the confidential computing environment. Verification of this evidence may be performed by the customer or by trusted third-party services."}],"title":"OPS-33 Basic 03B"},{"id":"ops-33-01ac","class":"additional-complement","parts":[{"id":"ops-33-01ac_stmt","name":"statement","prose":"The cloud service provider clearly defines, documents and communicates the available attestation levels."},{"id":"ops-33-01ac_guidance-1","name":"guidance","prose":"Remote attestation can be performed at different locations and with different trust levels:\n\n1. Cloud service customers retrieve evidence from TEEs and perform verification in an environment fully trusted by them. This scenario is generally assumed to provide a very strong attestation;\n2. Cloud service providers retrieve evidence from TEEs, perform verification in verification services they control and provide verification results and evidence to the cloud service customer. Cloud service customers verify the attestation evidence in an environment fully trusted by them. This scenario is generally assumed to provide a very strong attestation;\n3. Cloud service customers retrieve evidence from TEEs and send it to an evidence verification service they trust. This scenario is generally assumed to provide a strong attestation; and\n4. Cloud service providers retrieve evidence from TEEs, send it to a verification service in their control and only return verification result to cloud service customers. This scenario is generally assumed to provide a weak attestation."}],"title":"OPS-33 Additional Complement 01AC"},{"id":"ops-33-02ac","class":"additional-complement","parts":[{"id":"ops-33-02ac_stmt","name":"statement","prose":"The information is part of the guidelines and recommendations for the secure use of the cloud service provided (cf. PSS-01)."}],"title":"OPS-33 Additional Complement 02AC"}]},{"id":"ops-34","title":"Container Management - Policies and Procedures","controls":[{"id":"ops-34-01b","class":"basic","parts":[{"id":"ops-34-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational measures for the planning and management of containers are documented, communicated and provided in accordance with SP-01. These policies and procedures contain specifications for the entire container life cycle regarding at least the following aspects:\n\n1. Image creation, testing, and validation;\n2. Image storage and retrieval;\n3. Container deployment and management;\n4. Container operations; and\n5. Decommissioning of images and container."}],"title":"OPS-34 Basic 01B"},{"id":"ops-34-02b","class":"basic","parts":[{"id":"ops-34-02b_stmt","name":"statement","prose":"The policies and procedures describe measures along the life cycle of containers and address at least the following aspects:\n\n1. Containers are inventoried according to a documented process (cf. AM-02, AM-03, AM-09);\n2. The need for malware protection is assessed and, if necessary, ensured (cf. OPS-05);\n3. Logging and monitoring of events takes place along the container lifecycle and is executed according to a defined logging framework (cf. OPS-10, OPS-12);\n4. Cloud service customer data is separated based on a risk assessment (cf. OPS-30);\n5. Access to the container host should take place in accordance with a roles and rights framework and a policy for managing access and access authorisations (cf. IAM-01, IAM-06);\n6. Data stored on containers and data in transit should be encrypted as far as possible by the provider in accordance with the encryption policy (cf. CRY-01);\n7. Measures to ensure network security are established. This includes, for example, measures to detect network anomalies (cf. COS-01 and COS-03) such as unexpected data flows within the network or unwanted access attempts;\n8. Changes to containers and images follow a regulated process (cf. DEV-03); and\n9. Hardening processes are carried out according to general industry standards to ensure that no unnecessary system services are executed (cf. PSS-11)."}],"title":"OPS-34 Basic 02B"},{"id":"ops-34-01ac","class":"additional-complement","parts":[{"id":"ops-34-01ac_stmt","name":"statement","prose":"The policies and procedures additionally describe measures along the life cycle of containers that address at least the following aspects:\n\n1. Container images are cryptographically signed and the signing key securely stored (cf. CRY-10) to ensure their authenticity and integrity;\n2. Container behaviour is monitored and restricted using runtime security controls; and\n3. Software products used for the provision of container images are, where possible, regularly scanned for known vulnerabilities or malicious components in container images and dependencies."},{"id":"ops-34-01ac_guidance-1","name":"guidance","prose":"In case of third-party and open source software products used for the provision of container images, scanning procedures comply with the policies and procedures defined in DEV-14."}],"title":"OPS-34 Additional Complement 01AC"}]},{"id":"ops-35","title":"Container Management - Implementation","controls":[{"id":"ops-35-01b","class":"basic","parts":[{"id":"ops-35-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains technical and organisational measures for the planning and management of containers along their life cycle according to the container management policies and procedures (cf. OPS-34)."}],"title":"OPS-35 Basic 01B"}]}]},{"id":"iam","title":"Identity and Access Management (IAM)","controls":[{"id":"iam-01","title":"Policy for Identities and Access Rights","controls":[{"id":"iam-01-01b","class":"basic","parts":[{"id":"iam-01-01b_stmt","name":"statement","prose":"The cloud service provider documents, communicates and makes available according to SP-01:\n\n1. An authorisation framework based on role-based access control and the business and security requirements of the cloud service provider; and \n2. A policy for managing identities and access rights for internal and external personnel of the cloud service provider and system components that have a role in automated authorisation processes of the cloud service provider."},{"id":"iam-01-01b_guidance-1","name":"guidance","prose":"External personnel includes freelancers, temporary workers, suppliers and service providers with access to system components."},{"id":"iam-01-01b_guidance-2","name":"guidance","prose":"Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).\n\nIf the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:\n\n1. Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;\n2. Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;\n3. Logging of events related to the authentication process of a federated identity; and\n4. Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated."}],"title":"IAM-01 Basic 01B"},{"id":"iam-01-02b","class":"basic","parts":[{"id":"iam-01-02b_stmt","name":"statement","prose":"For the purpose of the business and security requirements these documents address at least the following aspects:\n\n1. Aspects that are relevant for making access control decisions;\n2. Assignment of unique usernames;\n3. Granting and modifying identities and access rights based on the 'least-privilege-principle' and the 'need-to-know-principle';\n4. Application of a role-based mechanism for assigning access rights;\n5. Definition of the supported identity and role-based access types, including an assignment of access control parameters and roles to be considered for each type;\n6. Segregation of duties between operational and monitoring functions ('Segregation of Duties');\n7. Assigning and monitoring privileged access rights;\n8. Approval by authorised individual(s) or system(s) for granting or modifying identities and access rights before cloud service customer data, cloud service derived data and cloud service provider data can be accessed;\n9. Regular review of assigned identities and access rights;\n10. Blocking and removing identities or limiting access in the event of inactivity;\n11. Specific measures for managing identities whose use is restriced to emergency recovery and similar scenarios;\n12. Time-based or event-driven removal or adjustment of access rights in the event of changes to job responsibility;\n13. Multi-factor authentication for users with privileged access;\n14. Remote access and access across geographic boundaries;\n15. Requirements for approving and documenting the management of identities and access rights; and\n16. Measures to be taken upon the detection of a potential identity compromise, such as disabling and removing the affected identities."},{"id":"iam-01-02b_guidance-1","name":"guidance","prose":"System components in the sense of the criterion are defined in OPS-26. 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 identities and access rights based on approved requests.\n\nFor containers, identities and access rights should be managed according to a regulated process, especially for automated authorisation processes in container environments.\n\nIf a cloud service provider uses alternative access methods for which it is not possible or feasible to block and remove identities (such as time-bounded access methods), limiting the access to an identity is an another solution for handling inactivity that fulfils this subcriterion."},{"id":"iam-01-02b_guidance-2","name":"guidance","prose":"Requirements for physical access control in accordance with the policy for identities and access rights are specified in more detail in the physical access control policy (cf. PS-04).\n\nIf the cloud service provider offers federated identity services, in particular if the cloud service provider offers these services as a cloud service broker, the documents defined in these subcriteria should recognise the complexity of the particular cloud service architecture. This can include, but is not limited to, the following aspects:\n\n1. Management of the trust boundaries between the different parties involved in the authentication process of a federated identity;\n2. Propagation of identity management-related events across all parties involved in the authentication process of a federated identity;\n3. Logging of events related to the authentication process of a federated identity; and\n4. Notification of cloud service customers in case of a federation credential being compromised or a trust boundary being violated."}],"title":"IAM-01 Basic 02B"},{"id":"iam-01-03b","class":"basic","parts":[{"id":"iam-01-03b_stmt","name":"statement","prose":"The cloud service provider is capable of producing a list of the currently granted cloud-based access rights for each identity under its responsibility."},{"id":"iam-01-03b_guidance-1","name":"guidance","prose":"Based on this list, the cloud service provider is able to review the cloud-based access rights of the given identity.\n\n'Cloud-based' in this case refers to all of the access rights that are within the scope of the cloud service provider's system of internal control."}],"title":"IAM-01 Basic 03B"},{"id":"iam-01-01ac","class":"additional-complement","parts":[{"id":"iam-01-01ac_stmt","name":"statement","prose":"Access logs are reviewed at least every month in order to detect attempts of unauthorised access or suspicious access patterns."},{"id":"iam-01-01ac_guidance-1","name":"guidance","prose":"A review can be carried out manually or via automated manners. In a monthly review, suspicious behaviours like e.g. access failures over a larger time frame (e.g. once a day) or consecutive logins from different countries may show up that a SIEM that only analyses real-time login attemps may overlook."}],"title":"IAM-01 Additional Complement 01AC"}]},{"id":"iam-02","title":"Granting and Change of Identities and Access Rights","controls":[{"id":"iam-02-01b","class":"basic","parts":[{"id":"iam-02-01b_stmt","name":"statement","prose":"Specified procedures for granting and modifying identities and access rights for internal and external personnel 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 policies and procedures as well as the policy for managing identities and access rights."},{"id":"iam-02-01b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-02 Basic 01B"},{"id":"iam-02-02b","class":"basic","parts":[{"id":"iam-02-02b_stmt","name":"statement","prose":"The aforementioned procedures include, but are not limited to:\n\n1. Processes and technical controls to restrict access to the cloud service provider's data and system functions to authorised personnel; and\n2. Processes and technical controls to manage and verify access permissions within the cloud service provider's systems."}],"title":"IAM-02 Basic 02B"},{"id":"iam-02-03b","class":"basic","parts":[{"id":"iam-02-03b_stmt","name":"statement","prose":"If the cloud service provider defines break glass accounts for use in case of a non-availability of the main procedure for authentication, specific requirements and procedures for the secure usage of those accounts are defined and implemented."}],"title":"IAM-02 Basic 03B"}]},{"id":"iam-03","title":"Risk-Based Procedure for Locking and Withdrawal of Identities","controls":[{"id":"iam-03-01b","class":"basic","parts":[{"id":"iam-03-01b_stmt","name":"statement","prose":"The cloud service provider has a risk-based procedure in place for managing identities (cf. IAM-01), taking into account the types of data accessible via the identities of the internal and external personnel."},{"id":"iam-03-01b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-03 Basic 01B"},{"id":"iam-03-02b","class":"basic","parts":[{"id":"iam-03-02b_stmt","name":"statement","prose":"As part of this procedure, specific parameters for automatically locking and withdrawing access due to inactivity or indications of brute force attacks are defined, with exceptions for the identities whose use is restriced to emergency recovery and similar scenarios."},{"id":"iam-03-02b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-03-02b_guidance-2","name":"guidance","prose":"Locking can result from a longer absence of the personnel, for example, due to illness, parental leave, or sabbatical. Multiple failed login attempts can be indications of brute force attacks."}],"title":"IAM-03 Basic 02B"},{"id":"iam-03-03b","class":"basic","parts":[{"id":"iam-03-03b_stmt","name":"statement","prose":"The cloud service provider documents and implements a process for monitoring stolen and compromised credentials, which also includes disabling any identity for which an issue is identified. This process is implemented on all identities under the responsibility of the cloud service provider that have privileged access rights."},{"id":"iam-03-03b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-03-03b_guidance-2","name":"guidance","prose":"This process can be performed automatically, or manually by authorised personnel."}],"title":"IAM-03 Basic 03B"},{"id":"iam-03-04b","class":"basic","parts":[{"id":"iam-03-04b_stmt","name":"statement","prose":"The aforementioned process includes an exception mechanism to be applied if all identities needed to manage the situation are potentially compromised."},{"id":"iam-03-04b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-03-04b_guidance-2","name":"guidance","prose":"This exception mechanism should be implemented as part of the business continuity and emergency management system (cf. BCM-01), as cases where all identities needed to manage the situation described in IAM-03.03B are potentially compromised constitute an emergency."}],"title":"IAM-03 Basic 04B"},{"id":"iam-03-03as","class":"additional-sharpen","parts":[{"id":"iam-03-03as_stmt","name":"statement","prose":"The cloud service provider documents and implements a process for monitoring stolen and compromised credentials, which also includes disabling any identity for which an issue is identified. This process is implemented on all identities under the responsibility of the cloud service provider."},{"id":"iam-03-03as_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-03-03as_guidance-2","name":"guidance","prose":"This process can be performed automatically, or manually by authorised personnel."}],"props":[{"name":"sharpened-basic-criterion","value":"03B"}],"title":"IAM-03 Additional Sharpen 03AS"},{"id":"iam-03-01ac","class":"additional-complement","parts":[{"id":"iam-03-01ac_stmt","name":"statement","prose":"The context of authentication attempts is monitored and suspicious events are, as relevant, flagged to authorised persons."},{"id":"iam-03-01ac_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-03-01ac_guidance-2","name":"guidance","prose":"The context of an authentication attempt can, but does not have to, include IP addresses, the date and time, or the device used."}],"title":"IAM-03 Additional Complement 01AC"},{"id":"iam-03-02ac","class":"additional-complement","parts":[{"id":"iam-03-02ac_stmt","name":"statement","prose":"The effectiveness of the procedures for locking and withdrawing identities is validated."},{"id":"iam-03-02ac_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-03 Additional Complement 02AC"},{"id":"iam-03-03ac","class":"additional-complement","parts":[{"id":"iam-03-03ac_stmt","name":"statement","prose":"Timely and appropriate remediation measures address any deviations identified during validation."},{"id":"iam-03-03ac_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-03 Additional Complement 03AC"}]},{"id":"iam-04","title":"Withdrawal or Adjustment of Access Rights as the Task Area Changes","controls":[{"id":"iam-04-01b","class":"basic","parts":[{"id":"iam-04-01b_stmt","name":"statement","prose":"Access rights are timely adjusted or revoked if the job responsibilities of the cloud service provider's internal or external personnel or the tasks of system components involved in the cloud service provider's automated authorisation processes change."},{"id":"iam-04-01b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-04-01b_guidance-2","name":"guidance","prose":"Changes in the task area of internal and external personnel can be triggered by changes in the employment relationship (e.g. termination, transfer) or in contracts and agreements."}],"title":"IAM-04 Basic 01B"},{"id":"iam-04-02b","class":"basic","parts":[{"id":"iam-04-02b_stmt","name":"statement","prose":"Privileged access rights are adjusted or revoked within 48 hours after the change taking effect."},{"id":"iam-04-02b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."},{"id":"iam-04-02b_guidance-2","name":"guidance","prose":"For privileged access rights the definition in IAM-06 applies."}],"title":"IAM-04 Basic 02B"},{"id":"iam-04-03b","class":"basic","parts":[{"id":"iam-04-03b_stmt","name":"statement","prose":"All other access rights are adjusted or revoked within 14 days."},{"id":"iam-04-03b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-04 Basic 03B"},{"id":"iam-04-04b","class":"basic","parts":[{"id":"iam-04-04b_stmt","name":"statement","prose":"After revocation, the procedure for granting identities and access rights (cf. IAM-02) is repeated."},{"id":"iam-04-04b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-04 Basic 04B"},{"id":"iam-04-05b","class":"basic","parts":[{"id":"iam-04-05b_stmt","name":"statement","prose":"In cases of role changes where temporary access may need to be granted, these access rights are approved, time-limited and documented."},{"id":"iam-04-05b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities."}],"title":"IAM-04 Basic 05B"}]},{"id":"iam-05","title":"Regular Review of Access Rights","controls":[{"id":"iam-05-01b","class":"basic","parts":[{"id":"iam-05-01b_stmt","name":"statement","prose":"Identities and the associated access rights of internal and external personnel 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 and in case of significant changes to the cloud service to ensure that they still correspond to the actual area of use."},{"id":"iam-05-01b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities.\nAs an alternative to the regular reviews of access rights, time-bound access rights that automatically expire may also be issued."},{"id":"iam-05-01b_guidance-2","name":"guidance","prose":"If a review is caused by significant changes to the cloud service, only the identities and access rights affected by the change need to be included in the review."}],"title":"IAM-05 Basic 01B"},{"id":"iam-05-02b","class":"basic","parts":[{"id":"iam-05-02b_stmt","name":"statement","prose":"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 personnel or system components."},{"id":"iam-05-02b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities.\nAs an alternative to the regular reviews of access rights, time-bound access rights that automatically expire may also be issued."}],"title":"IAM-05 Basic 02B"},{"id":"iam-05-03b","class":"basic","parts":[{"id":"iam-05-03b_stmt","name":"statement","prose":"Identified deviations are dealt with timely, but no later than seven days after their detection, through appropriate modification or withdrawal of the access rights."},{"id":"iam-05-03b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities.\nAs an alternative to the regular reviews of access rights, time-bound access rights that automatically expire may also be issued."}],"title":"IAM-05 Basic 03B"},{"id":"iam-05-04b","class":"basic","parts":[{"id":"iam-05-04b_stmt","name":"statement","prose":"When revoking identities, the system ensures that all production associated system components (e.g., virtual machines, storage, access rights) are identified, reassigned, or deleted to prevent the creation of orphaned resources. Clear processes and technical controls are established to identify and handle any orphaned resources that occur despite preventive measures, ensuring their timely reassignment or secure deletion."},{"id":"iam-05-04b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities.\nAs an alternative to the regular reviews of access rights, time-bound access rights that automatically expire may also be issued."}],"title":"IAM-05 Basic 04B"},{"id":"iam-05-05b","class":"basic","parts":[{"id":"iam-05-05b_stmt","name":"statement","prose":"For system components that are not production associated, the cloud service provider designs, implements and maintains appropriate controls for the prevention of orphan resources based on a risk assessment (cf. OIS-07)."},{"id":"iam-05-05b_guidance-1","name":"guidance","prose":"This criterion applies to identities that refer to single, multiple or non-human entities.\nAs an alternative to the regular reviews of access rights, time-bound access rights that automatically expire may also be issued."},{"id":"iam-05-05b_guidance-2","name":"guidance","prose":"The system components meant here are system components in development, test or any other non-productive environments. Orphan resources are system components that have no assigned owner."}],"title":"IAM-05 Basic 05B"},{"id":"iam-05-01ac","class":"additional-complement","parts":[{"id":"iam-05-01ac_stmt","name":"statement","prose":"Privileged access rights are reviewed at least every six months, and in case of significant changes to the cloud service."},{"id":"iam-05-01ac_guidance-1","name":"guidance","prose":"If a review is caused by significant changes to the cloud service, only the identities and access rights affected by the change need to be included in the review."}],"title":"IAM-05 Additional Complement 01AC"}]},{"id":"iam-06","title":"Privileged Access Rights","controls":[{"id":"iam-06-01b","class":"basic","parts":[{"id":"iam-06-01b_stmt","name":"statement","prose":"Privileged access rights for internal and external personnel as well as technical users of the cloud service provider are assigned and changed in accordance with the policy for managing identities and access rights (cf. IAM-01) or a separate specific policy."},{"id":"iam-06-01b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 01B"},{"id":"iam-06-02b","class":"basic","parts":[{"id":"iam-06-02b_stmt","name":"statement","prose":"Privileged 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')."},{"id":"iam-06-02b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 02B"},{"id":"iam-06-03b","class":"basic","parts":[{"id":"iam-06-03b_stmt","name":"statement","prose":"Anonymous technical users are only accessed through authentication with a personalised identitiy."},{"id":"iam-06-03b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 03B"},{"id":"iam-06-04b","class":"basic","parts":[{"id":"iam-06-04b_stmt","name":"statement","prose":"Activities of users with privileged access rights are logged in order to detect any misuse of privileged access in suspicious cases."},{"id":"iam-06-04b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 04B"},{"id":"iam-06-05b","class":"basic","parts":[{"id":"iam-06-05b_stmt","name":"statement","prose":"The logged information is automatically monitored for defined events that may indicate misuse."},{"id":"iam-06-05b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 05B"},{"id":"iam-06-06b","class":"basic","parts":[{"id":"iam-06-06b_stmt","name":"statement","prose":"When such an event is identified, the responsible personnel is automatically informed so that they can timely assess whether misuse has occurred and take corresponding action."},{"id":"iam-06-06b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."},{"id":"iam-06-06b_guidance-2","name":"guidance","prose":"Responsible personnel for events that may indicate misuse can be e.g. the personnel of the cloud service provider's security operations centre.\n\nMisused privileged access rights can be treated e.g. as a security incident, cf. SIM-01."}],"title":"IAM-06 Basic 06B"},{"id":"iam-06-07b","class":"basic","parts":[{"id":"iam-06-07b_stmt","name":"statement","prose":"In the event of proven misuse of privileged access rights, disciplinary measures are taken in accordance with HR-04."},{"id":"iam-06-07b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 07B"},{"id":"iam-06-08b","class":"basic","parts":[{"id":"iam-06-08b_stmt","name":"statement","prose":"For containers and images, activities of users with privileged access are logged according to OPS-10."},{"id":"iam-06-08b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 08B"},{"id":"iam-06-09b","class":"basic","parts":[{"id":"iam-06-09b_stmt","name":"statement","prose":"Access to the cloud service provider's administration interfaces requires the use of multi-factor authentication."},{"id":"iam-06-09b_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Basic 09B"},{"id":"iam-06-01ac","class":"additional-complement","parts":[{"id":"iam-06-01ac_stmt","name":"statement","prose":"The cloud service provider maintains an inventory of the identities with privileged access rights under its responsibility. This inventory is kept up-to-date."},{"id":"iam-06-01ac_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Additional Complement 01AC"},{"id":"iam-06-02ac","class":"additional-complement","parts":[{"id":"iam-06-02ac_stmt","name":"statement","prose":"The cloud service provider maintains a list of the personnel that is responsible for an identity assigned to a non-human entity within the cloud service provider's scope of responsibility. This list is reviewed every six months and in case of significant changes to the cloud service."},{"id":"iam-06-02ac_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."},{"id":"iam-06-02ac_guidance-2","name":"guidance","prose":"If a review is caused by significant changes to the cloud service, only the parts of the list that are affected by the change need to be included in the review."}],"title":"IAM-06 Additional Complement 02AC"},{"id":"iam-06-03ac","class":"additional-complement","parts":[{"id":"iam-06-03ac_stmt","name":"statement","prose":"For privileged users, phishing-resistant multi-factor authentication such as FIDO2 security keys or comparable mechanisms using public key cryptography and domain binding are implemented."},{"id":"iam-06-03ac_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Additional Complement 03AC"},{"id":"iam-06-04ac","class":"additional-complement","parts":[{"id":"iam-06-04ac_stmt","name":"statement","prose":"Privileged access rights are enforced through a privileged access management (PAM) solution with support for 'just-in-time' elevation and 'just-enough' access."},{"id":"iam-06-04ac_guidance-1","name":"guidance","prose":"Privileged access rights in the sense of the criterion are those that enable personnel of the cloud service provider to perform any of the following activities:\n\n1. Read or write access to the cloud service 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\n2. 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 cloud service customers data (also indirectly, e.g. by deactivating the logging and monitoring of security-relevant events)."}],"title":"IAM-06 Additional Complement 04AC"}]},{"id":"iam-07","parts":[{"id":"iam-07-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that their contracts with the cloud service provider include a comprehensive list of all instances where the provider might access customer data in an unencrypted form. Cloud service customers verify that these conditions are thoroughly documented before engaging the services, allowing them to make informed decisions about data security and compliance.\n\nCloud service customers ensure with suitable controls that they provide a response to data access requests by the cloud service provider within a specified time frame as agreed upon in the contractual agreements.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Access to Cloud Service Customer Data","controls":[{"id":"iam-07-01b","class":"basic","parts":[{"id":"iam-07-01b_stmt","name":"statement","prose":"The cloud service provider implements partitioning measures that are:\n\n1. Sufficient for separating the system components for providing the cloud service from the system components of the cloud service provider's other information systems; and\n2. Suitable for separating different cloud service customers from each other (cf. OPS-30 and OPS-31)."}],"title":"IAM-07 Basic 01B"},{"id":"iam-07-02b","class":"basic","parts":[{"id":"iam-07-02b_stmt","name":"statement","prose":"The partitioning measures of the cloud service provider ensure that security incidents, if they compromise the system components storing the cloud service customer data, do not also compromise the system components that manage the access to them."}],"title":"IAM-07 Basic 02B"},{"id":"iam-07-03b","class":"basic","parts":[{"id":"iam-07-03b_stmt","name":"statement","prose":"Unless prohibited by applicable law, the cloud service customer is informed by the cloud service provider whenever internal or external personnel of the cloud service provider reads or writes to the cloud service customer data processed, stored or transmitted in the cloud service or has accessed it without the prior consent of the cloud service customer. The information is provided whenever cloud service customer data is/was accessed in unencrypted form or the contractual agreements with customers do not explicitly exclude informing the customer of such access."},{"id":"iam-07-03b_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."}],"title":"IAM-07 Basic 03B"},{"id":"iam-07-04b","class":"basic","parts":[{"id":"iam-07-04b_stmt","name":"statement","prose":"Unless contractually agreed otherwise, the information provided about the access contains the cause, time, duration, geographic location, type and scope of the access, as well as the retention time of other data generated during access, such as logs or copies containing cloud service customer data. The information is sufficiently detailed to enable subject matter experts of the cloud service customer to assess the risks of the access."},{"id":"iam-07-04b_guidance-1","name":"guidance","prose":"Subject matter experts in the sense of this basic criterion are personnel from e.g. IT, Compliance or Internal Audit."},{"id":"iam-07-04b_guidance-2","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."},{"id":"iam-07-04b_guidance-3","name":"guidance","prose":"The geographic location of the access provided to the cloud service customer need not be a GPS location, but should at least be as precise as the country from which the access has been or is meant to be performed."}],"title":"IAM-07 Basic 04B"},{"id":"iam-07-05b","class":"basic","parts":[{"id":"iam-07-05b_stmt","name":"statement","prose":"The information is provided in accordance with the contractual agreements, but no later than 72 hours from the initiation of the access."},{"id":"iam-07-05b_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."}],"title":"IAM-07 Basic 05B"},{"id":"iam-07-06b","class":"basic","parts":[{"id":"iam-07-06b_stmt","name":"statement","prose":"The cloud service provider discloses, through contractual agreements and before offering its services, all instances where the cloud service provider may access cloud service customer data in unencrypted form while it is processed, stored or transmitted in the cloud service."},{"id":"iam-07-06b_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."}],"title":"IAM-07 Basic 06B"},{"id":"iam-07-03as","class":"additional-sharpen","parts":[{"id":"iam-07-03as_stmt","name":"statement","prose":"Access to cloud service customer data and cloud service derived data by internal or external personnel of the cloud service provider requires the prior consent of an authorised department of the cloud service customer, provided that the cloud service customer's data is accessible in unencrypted form or contractual agreements do not explicitly exclude such consent. Additionally, if encrypted data and its decryption key are stored separately within the same cloud environment, prior consent is required not only for accessing the decryption key but also for accessing the encrypted data itself (potentially together with the key)."},{"id":"iam-07-03as_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."}],"props":[{"name":"sharpened-basic-criterion","value":"03B"}],"title":"IAM-07 Additional Sharpen 03AS"},{"id":"iam-07-04as","class":"additional-sharpen","parts":[{"id":"iam-07-04as_stmt","name":"statement","prose":"Unless contractually agreed otherwise, the information provided for the consent contains the cause, time, duration, geographic location, type and scope of the access, as well as the retention time of other data generated during access, such as logs or copies containing cloud service customer data. The information is sufficiently detailed to enable subject matter experts of the cloud service customer to assess the risks of the access. In addition to the provided information, the cloud service provider specifies a time frame within which the cloud service customer shall respond to the access request."},{"id":"iam-07-04as_guidance-1","name":"guidance","prose":"Subject matter experts in the sense of this basic criterion are personnel from e.g. IT, Compliance or Internal Audit."},{"id":"iam-07-04as_guidance-2","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."},{"id":"iam-07-04as_guidance-3","name":"guidance","prose":"The geographic location of the access provided to the cloud service customer need not be a GPS location, but should at least be as precise as the country from which the access has been or is meant to be performed."}],"props":[{"name":"sharpened-basic-criterion","value":"04B"}],"title":"IAM-07 Additional Sharpen 04AS"},{"id":"iam-07-06as","class":"additional-sharpen","parts":[{"id":"iam-07-06as_stmt","name":"statement","prose":"The cloud service provider discloses, through contractual agreements and before offering its services, all instances where the cloud service provider may access cloud service customer data or cloud service derived data in unencrypted form while it is processed, stored or transmitted in the cloud service."}],"props":[{"name":"sharpened-basic-criterion","value":"06B"}],"title":"IAM-07 Additional Sharpen 06AS"},{"id":"iam-07-01ac","class":"additional-complement","parts":[{"id":"iam-07-01ac_stmt","name":"statement","prose":"If the cloud service provider might access the cloud service customer data transmitted, handled or stored in the cloud service in a non-encrypted way, the cloud service provider includes provisions through contractual agreements for cases in which seeking prior consent for such an access is not feasible."},{"id":"iam-07-01ac_guidance-1","name":"guidance","prose":"This subcriterion is only applicable if subcriterion IAM-07.03S is also applied.\n\nSeeking prior consent might, for example, not be feasible where the cloud service needs to be troubleshot to preserve the confidentiality, integrity and availability of cloud service customer data."},{"id":"iam-07-01ac_guidance-2","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."}],"title":"IAM-07 Additional Complement 01AC"},{"id":"iam-07-02ac","class":"additional-complement","parts":[{"id":"iam-07-02ac_stmt","name":"statement","prose":"In order to be able to directly or indirectly access cloud service customer data, any internal or external personnel of the cloud service provider has to pass an appropriate assessment, or has to instead be supervised by personnel who has passed an appropriate assessment (cf. HR-01). The cloud service provider verifies that one of these conditions is met before the access is granted. This applies to support operations as well."},{"id":"iam-07-02ac_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."},{"id":"iam-07-02ac_guidance-2","name":"guidance","prose":"The cloud service provider should make details about how the supervised access is performed accessible to cloud service customers."}],"title":"IAM-07 Additional Complement 02AC"},{"id":"iam-07-03ac","class":"additional-complement","parts":[{"id":"iam-07-03ac_stmt","name":"statement","prose":"If the performed access is supervised, the cloud service provider ensures that:\n\n1. The mechanisms used to perform the supervised access allow the supervising personnel to authorise or deny individual actions of the supervisee and ask for explanations in real time;\n2. Any access rights that are granted as part of the supervised access are revoked at the end of the operation;\n3. All operations that are performed as part of the supervised access are logged as administration actions;\n4. The supervisee and the device used to perform the supervised access are authenticated by the supervision solution;\n5. The operations that the supervisee proposes and the actions of the supervising personnel are logged by the supervision solution, including operations that were denied; and\n6. Information flows towards the device of the supervisee are prevented by the supervision solution."},{"id":"iam-07-03ac_guidance-1","name":"guidance","prose":"Access to cloud service customer data also entails disclosure of data as part of investigation requests according to INQ-03. These are to be communicated to cloud service customers as far as it is legally not forbidden.\n\nThe criterion aims at minimising the cloud service provider's capability to access cloud service customer data. Minimisation of the cloud service provider's possibility to access cloud service customer data is often a question related to the radius of the collusion circle. For example, if the four-eyes principle for access is applied and the access is being logged, then three people make up the collusion circle. In order to build trust into such access statements, the cloud service provider should describe in the system description the measures taken to enlargen the collusion circle."},{"id":"iam-07-03ac_guidance-2","name":"guidance","prose":"The cloud service provider should make details about how the supervised access is performed accessible to cloud service customers."}],"title":"IAM-07 Additional Complement 03AC"},{"id":"iam-07-04ac","class":"additional-complement","parts":[{"id":"iam-07-04ac_stmt","name":"statement","prose":"If the cloud service customer is given access to interfaces for administrators and for end users as part of the cloud service, the cloud service provider separates these interfaces from one another and ensures that access paths for customer administrators differ from those for end users."},{"id":"iam-07-04ac_guidance-1","name":"guidance","prose":"The separation should be designed and implemented such that customer administrators can access the cloud service even when the end user interfaces are unavailable."}],"title":"IAM-07 Additional Complement 04AC"}]},{"id":"iam-08","title":"Authentication Mechanisms","controls":[{"id":"iam-08-01b","class":"basic","parts":[{"id":"iam-08-01b_stmt","name":"statement","prose":"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 personnel as well as system components that are involved in the cloud service provider's automated authorisation processes."}],"title":"IAM-08 Basic 01B"},{"id":"iam-08-02b","class":"basic","parts":[{"id":"iam-08-02b_stmt","name":"statement","prose":"The cloud service provider enforces multi-factor authentication (MFA) for all access to the production environment. This requirement applies to both human users and automated processes, ensuring that only authorised entities can access systems and data in the production environment."},{"id":"iam-08-02b_guidance-1","name":"guidance","prose":"Multi-factor authentication implies that different sources for identity verification are used. This applies both to human users and automated processes. Human users may use different factors like a password and a hardware token. Multi-factor authentication for automated processes implies using independent sources for identity verification like e.g. cryptographic keys and a short term token from another source."}],"title":"IAM-08 Basic 02B"},{"id":"iam-08-03b","class":"basic","parts":[{"id":"iam-08-03b_stmt","name":"statement","prose":"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 policies and procedures for the use of cryptographic mechanisms (cf. CRY-01)."}],"title":"IAM-08 Basic 03B"},{"id":"iam-08-04b","class":"basic","parts":[{"id":"iam-08-04b_stmt","name":"statement","prose":"The authentication requirements are derived from a risk assessment and documented, communicated and provided in an authentication policy according to SP-01. Compliance with the requirements is enforced by the configuration of the system components, as far as technically possible. The authentication policy describes at least the following aspects:\n\n1. The selection of appropriate mechanisms for every level of risk and each identity type;\n2. The protection of credentials that the authentication mechanisms use, including the confidentiality of personal or shared authentication information and non-sharing of credentials;\n3. The generation and distribution of credentials for any new identity;\n4. The non-reuse of credentials;\n5. Rules on the storage of credentials;\n6. Rules for renewing credentials, including periodic renewals and renewals in case a credential is lost or compromised; and\n7. Rules on the required strength of credentials, including trade-offs between entropy and ability to memorise where applicable, as well as mechanisms for communicating and enforcing these rules."}],"title":"IAM-08 Basic 04B"},{"id":"iam-08-05b","class":"basic","parts":[{"id":"iam-08-05b_stmt","name":"statement","prose":"The cloud service provider determines by means of a risk assessment (cf. OIS-07) the risk that the authentication mechanisms integrated into the system components under its responsibility used to provide the cloud service become outdated. Based on the results of the risk assessment, the cloud service provider implements appropriate measures for exchanging outdated authentication mechanisms or the system components into which they are integrated."}],"title":"IAM-08 Basic 05B"},{"id":"iam-08-06b","class":"basic","parts":[{"id":"iam-08-06b_stmt","name":"statement","prose":"Any authentication mechanism integrated into the system components used to provide the cloud service has a mechanism for disabling an identity after a predefined number of unsuccessful authentication attempts."}],"title":"IAM-08 Basic 06B"},{"id":"iam-08-07b","class":"basic","parts":[{"id":"iam-08-07b_stmt","name":"statement","prose":"The cloud service provider implements measures which require that users can only access non-personal identities assigned to multiple persons after they have already been authenticated with their identity assigned to a single person."}],"title":"IAM-08 Basic 07B"},{"id":"iam-08-02as","class":"additional-sharpen","parts":[{"id":"iam-08-02as_stmt","name":"statement","prose":"The cloud service provider enforces multi-factor authentication (MFA) for all access to any environment. This requirement applies to both human users and automated processes, ensuring that only authorised entities can access systems and data in all of the environments."},{"id":"iam-08-02as_guidance-1","name":"guidance","prose":"These environments include production, development, test and staging environments."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"IAM-08 Additional Sharpen 02AS"},{"id":"iam-08-03as","class":"additional-sharpen","parts":[{"id":"iam-08-03as_stmt","name":"statement","prose":"Within an 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 policies and procedures for the use of cryptographic mechanisms (cf. CRY-01)."},{"id":"iam-08-03as_guidance-1","name":"guidance","prose":"These environments include production, development, test and staging environments."}],"props":[{"name":"sharpened-basic-criterion","value":"03B"}],"title":"IAM-08 Additional Sharpen 03AS"}]},{"id":"iam-09","title":"Confidentiality of Authentication Information","controls":[{"id":"iam-09-01b","class":"basic","parts":[{"id":"iam-09-01b_stmt","name":"statement","prose":"The allocation of authentication information to access system components used to provide the cloud service to internal and external users of the cloud service provider and system components that are involved in automated authorisation processes of the cloud service provider is done in an orderly manner that ensures the confidentiality of the information."},{"id":"iam-09-01b_guidance-1","name":"guidance","prose":"Authentication information as referred to in the basic criterion is cloud service provider data."}],"title":"IAM-09 Basic 01B"},{"id":"iam-09-02b","class":"basic","parts":[{"id":"iam-09-02b_stmt","name":"statement","prose":"Authentication credentials are managed with a security level that matches or exceeds the classification of the system component they protect."},{"id":"iam-09-02b_guidance-1","name":"guidance","prose":"Authentication information as referred to in the basic criterion is cloud service provider data."}],"title":"IAM-09 Basic 02B"},{"id":"iam-09-03b","class":"basic","parts":[{"id":"iam-09-03b_stmt","name":"statement","prose":"If passwords are used as authentication information, their confidentiality is ensured by the following procedures, as far as technically possible:\n\n1. Users can initially create the password themselves or shall 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;\n2. When creating passwords, compliance with the authentication policy (cf. IAM-08) is enforced as far as technically possible;\n3. The user is informed about changing or resetting the password; and\n4. The server-side storage takes place using state of the art cryptographic hash functions, with the exception of passwords that are stored in the plain text form for later use, for example in a password manager. In this case, state of the art cryptographic mechanisms are used to protect the passwords."},{"id":"iam-09-03b_guidance-1","name":"guidance","prose":"Authentication information as referred to in the basic criterion is cloud service provider data."}],"title":"IAM-09 Basic 03B"},{"id":"iam-09-04b","class":"basic","parts":[{"id":"iam-09-04b_stmt","name":"statement","prose":"Deviations are evaluated by means of a risk assessment according to OIS-07 and mitigating measures derived from this are implemented."}],"title":"IAM-09 Basic 04B"},{"id":"iam-09-05b","class":"basic","parts":[{"id":"iam-09-05b_stmt","name":"statement","prose":"Rules and recommendations for managing credentials in accordance with the authentication policy (cf. IAM-08) are documented, communicated and made available to all users under the responsibility of the cloud service provider. They include recommendations on password managers and recommendations to specifically address classical attacks such as phishing, social attacks, and whaling."}],"title":"IAM-09 Basic 05B"},{"id":"iam-09-06b","class":"basic","parts":[{"id":"iam-09-06b_stmt","name":"statement","prose":"Used cryptographic mechanisms comply with the policies and instructions for cryptographic mechanisms (cf. CRY-01)."}],"title":"IAM-09 Basic 06B"},{"id":"iam-09-07b","class":"basic","parts":[{"id":"iam-09-07b_stmt","name":"statement","prose":"Password reset procedures are valid for at most 24 hours. After the reset procedure has been used, the password is to be changed by the user."},{"id":"iam-09-07b_guidance-1","name":"guidance","prose":"This subcriterion is only applicable to password-based authentication schemes."}],"title":"IAM-09 Basic 07B"},{"id":"iam-09-01ac","class":"additional-complement","parts":[{"id":"iam-09-01ac_stmt","name":"statement","prose":"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)."},{"id":"iam-09-01ac_guidance-1","name":"guidance","prose":"Authentication information as referred to in the basic criterion is cloud service provider data."},{"id":"iam-09-01ac_guidance-2","name":"guidance","prose":"Insofar as this is legally binding, declarations can be signed using an electronic signature."}],"title":"IAM-09 Additional Complement 01AC"}]}]},{"id":"cry","title":"Cryptography and Key Management (CRY)","controls":[{"id":"cry-01","title":"Policy for the Use of Cryptographic Mechanisms","controls":[{"id":"cry-01-01b","class":"basic","parts":[{"id":"cry-01-01b_stmt","name":"statement","prose":"Policies and procedures with procedures and technical safeguards for cryptographic mechanisms are documented, communicated and provided according to SP-01, in which the following aspects are described:\n\n1. Usage of encryption procedures and secure network protocols that correspond to the state of the art;\n2. Usage of hash functions and salt values, that both correspond to the state of the art;\n3. Usage of signature schemes that correspond to the state of the art;\n4. Risk-based provisions for the use of encryption and authentication which are aligned with the information classification schemes (cf. AM-09) and consider the communication channel, type, strength and quality of the encryption;\n5. Requirements for the secure generation, storage, archiving, retrieval, distribution, withdrawal, backup, restoration and deletion of the keys;\n6. Requirements for the rotation of cryptographic keys that follow industry best practices and consider the potential risk of information exposure;\n7. Consideration of relevant legal and regulatory obligations and requirements;\n8. Documentation of a change management process for managing cryptographic, encryption, authentication and key management technology changes; and\n9. Consideration of crypto-agility to allow for efficient substitution of implemented cryptographic mechanisms during their intended lifetimes."},{"id":"cry-01-01b_guidance-1","name":"guidance","prose":"The following Technical Guidelines (valid at the given time) provide recommendations and key lengths for state of the art cryptographic mechanisms:\n\n1. BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths;\n2. BSI TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Transport Layer Security (TLS);\n3. BSI TR-02102-3 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Internet Protocol Security (IPSec) and Internet Key Exchange (IKEv2); and\n4. BSI TR-02102-4 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Secure Shell (SSH).\n\nA change management process in the sense of the basic criterion can either be covered by the standard change management process described in DEV-03 or can be implemented as a separate process."},{"id":"cry-01-01b_guidance-2","name":"guidance","prose":"Crypto-agility refers to the ability to change the used cryptographic mechanisms or implementation of such mechanisms, e.g. in such a way that a transition to larger key lengths and stronger cryptographic mechanisms is possible. For further information, please refer to BSI TR-02102-1."}],"title":"CRY-01 Basic 01B"},{"id":"cry-01-02b","class":"basic","parts":[{"id":"cry-01-02b_stmt","name":"statement","prose":"Reviews of policies and procedures regarding cryptographic mechanisms include checks that the policies and procedures are up to date and comply with the BSI technical guideline  (BSI TR-02102) or suitable NIST guidelines (e.g. FIPS 140 series and SP 800 series). Deviations are analysed and documented in a risk assessment for cryptographic mechanisms valid at the given time. Remediation measures are to be taken based on risk."},{"id":"cry-01-02b_guidance-1","name":"guidance","prose":"The following Technical Guidelines (valid at the given time) provide recommendations and key lengths for state of the art cryptographic mechanisms:\n\n1. BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths;\n2. BSI TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Transport Layer Security (TLS);\n3. BSI TR-02102-3 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Internet Protocol Security (IPSec) and Internet Key Exchange (IKEv2); and\n4. BSI TR-02102-4 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Secure Shell (SSH).\n\nA change management process in the sense of the basic criterion can either be covered by the standard change management process described in DEV-03 or can be implemented as a separate process."}],"title":"CRY-01 Basic 02B"},{"id":"cry-01-01ac","class":"additional-complement","parts":[{"id":"cry-01-01ac_stmt","name":"statement","prose":"The cloud service provider has defined and documented a Post-Quantum-Cryptography (PQC) strategy according to SP-01 to address threats posed by adversaries in possession of a quantum computer."},{"id":"cry-01-01ac_guidance-1","name":"guidance","prose":"The following Technical Guidelines (valid at the given time) provide recommendations and key lengths for state of the art cryptographic mechanisms:\n\n1. BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths;\n2. BSI TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Transport Layer Security (TLS);\n3. BSI TR-02102-3 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Internet Protocol Security (IPSec) and Internet Key Exchange (IKEv2); and\n4. BSI TR-02102-4 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Secure Shell (SSH).\n\nA change management process in the sense of the basic criterion can either be covered by the standard change management process described in DEV-03 or can be implemented as a separate process."},{"id":"cry-01-01ac_guidance-2","name":"guidance","prose":"Recommendations for the migration to PQC and future-proof use of cryptography are provided, for example, in:\n\n1. The BSI guideline 'Quantum-safe cryptography – fundamentals, current developments and recommendations'; \n2. The roadmap 'A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography' published by the European Commission; and\n3. The preliminary drafts for the NIST publication 'NIST SP 1800-38: Migration to Post-Quantum Cryptography: Preparation for Considering the Implementation and Adoption of Quantum Safe Cryptography'."}],"title":"CRY-01 Additional Complement 01AC"},{"id":"cry-01-02ac","class":"additional-complement","parts":[{"id":"cry-01-02ac_stmt","name":"statement","prose":"The cloud service provider's PQC strategy is aligned with cryptography policies and procedures and includes the following aspects: \n\n1. Maintenance of an inventory of cryptographic mechanisms in use, including priority levels to each inventory item based on the impact and probabilities of the risks posed by quantum computing attacks and the effort to remediate such risks; \n2. Staying informed about encryption measures that are deemed state of the art and secure against adversaries who possess a quantum computer; \n3. Usage of hybrid cryptography models to ensure security for both quantum and non-quantum computing based attacks; and\n4. Definition of trigger events, required resources, transition plans and success criteria for implementation of post-quantum cryptographic mechanisms."},{"id":"cry-01-02ac_guidance-1","name":"guidance","prose":"The following Technical Guidelines (valid at the given time) provide recommendations and key lengths for state of the art cryptographic mechanisms:\n\n1. BSI TR-02102-1 Cryptographic Mechanisms: Recommendations and Key Lengths;\n2. BSI TR-02102-2 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Transport Layer Security (TLS);\n3. BSI TR-02102-3 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Internet Protocol Security (IPSec) and Internet Key Exchange (IKEv2); and\n4. BSI TR-02102-4 Cryptographic Mechanisms: Recommendations and Key Lengths – Use of Secure Shell (SSH).\n\nA change management process in the sense of the basic criterion can either be covered by the standard change management process described in DEV-03 or can be implemented as a separate process."},{"id":"cry-01-02ac_guidance-2","name":"guidance","prose":"Recommendations for the migration to PQC and future-proof use of cryptography are provided, for example, in:\n\n1. The BSI guideline 'Quantum-safe cryptography – fundamentals, current developments and recommendations'; \n2. The roadmap 'A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography' published by the European Commission; and\n3. The preliminary drafts for the NIST publication 'NIST SP 1800-38: Migration to Post-Quantum Cryptography: Preparation for Considering the Implementation and Adoption of Quantum Safe Cryptography'."},{"id":"cry-01-02ac_guidance-3","name":"guidance","prose":"Hybrid cryptography models, as defined in the context of post-quantum cryptography (PQC), combine classical and quantum-safe mechanisms to ensure that the system remains secure even if one component is compromised. The purpose of such models is to provide long-term protection against threats such as 'store now, decrypt later' and other attacks based on classical or quantum computing."}],"title":"CRY-01 Additional Complement 02AC"},{"id":"cry-01-03ac","class":"additional-complement","parts":[{"id":"cry-01-03ac_stmt","name":"statement","prose":"The PQC strategy, including the inventory and risk assessment, is reviewed at least annually or in case of significant changes impacting the PQC strategy."},{"id":"cry-01-03ac_guidance-1","name":"guidance","prose":"Recommendations for the migration to PQC and future-proof use of cryptography are provided, for example, in:\n\n1. The BSI guideline 'Quantum-safe cryptography – fundamentals, current developments and recommendations'; \n2. The roadmap 'A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography' published by the European Commission; and\n3. The preliminary drafts for the NIST publication 'NIST SP 1800-38: Migration to Post-Quantum Cryptography: Preparation for Considering the Implementation and Adoption of Quantum Safe Cryptography'."},{"id":"cry-01-03ac_guidance-2","name":"guidance","prose":"The risk assessment as part of the Post-Quantum-Cryptography strategy should consider: \n\n1. The threat landscape posed by advancements in quantum computing; \n2. Advancements in cryptographic mechanisms that are deemed secure against attackers in possession of a quantum computer; \n3. Vulnerabilities inherent to the cryptographic mechanism; and \n4. Vulnerabilities resulting from how cryptographic mechanisms are deployed (e.g. keys which are in use for an extended period of time and the data protected by those keys could already be harvested today and decrypted at a later date)."}],"title":"CRY-01 Additional Complement 03AC"}]},{"id":"cry-02","parts":[{"id":"cry-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that, if notified about any changes to cryptographic systems by the cloud service provider, they engage actively in a thorough evaluation of potential impacts on their usage of the cloud service.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Cryptographic Change Management","controls":[{"id":"cry-02-01b","class":"basic","parts":[{"id":"cry-02-01b_stmt","name":"statement","prose":"When implementing changes to cryptographic systems, the cloud service provider performs an evaluation of their potential impact in accordance with DEV-06. This process includes an analysis of the cloud infrastructure of the cloud service, as well as an analysis of potential disruptions to cloud service customer-managed workloads and the evaluation of residual risks, cost implications, and integration benefits. The cloud service provider informs cloud service customers of these downstream effects to prevent unforeseen failures within the cloud service customer's specific cryptographic implementations."},{"id":"cry-02-01b_guidance-1","name":"guidance","prose":"When performing the evaluation of the potential impact of changes, the cloud service provider should consider the complexity of the distributed architecture of its cloud service."}],"title":"CRY-02 Basic 01B"},{"id":"cry-02-02b","class":"basic","parts":[{"id":"cry-02-02b_stmt","name":"statement","prose":"All changes and adjustments to cryptographic systems are documented and traceable."}],"title":"CRY-02 Basic 02B"},{"id":"cry-02-03b","class":"basic","parts":[{"id":"cry-02-03b_stmt","name":"statement","prose":"The personnel responsible for cryptographic systems is regularly trained and informed about respective changes."}],"title":"CRY-02 Basic 03B"}]},{"id":"cry-03","title":"Review of Cryptography Practices","controls":[{"id":"cry-03-01b","class":"basic","parts":[{"id":"cry-03-01b_stmt","name":"statement","prose":"The cloud service provider ensures that encryption, authentication and key management practices are regularly audited in accordance with COM-02 and COM-03 to identify and address potential vulnerabilities. At a minimum, reviews are performed annually and immediately following security incidents involving cryptographic components."},{"id":"cry-03-01b_guidance-1","name":"guidance","prose":"Further criteria for key management are found in criteria CRY-06, CRY-07, CRY-09 - CRY-19"}],"title":"CRY-03 Basic 01B"},{"id":"cry-03-02b","class":"basic","parts":[{"id":"cry-03-02b_stmt","name":"statement","prose":"As part of the reviews, the cloud service provider determines if the cryptographic practices align with the state of the art and updates them as needed."},{"id":"cry-03-02b_guidance-1","name":"guidance","prose":"The cloud service provider applies the cryptographic change management process (cf. CRY-02) when updating the cryptographic practices to align with the state of the art."}],"title":"CRY-03 Basic 02B"}]},{"id":"cry-04","parts":[{"id":"cry-04-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 needs.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Protection of Data for Transmission (Transport Protection)","controls":[{"id":"cry-04-01b","class":"basic","parts":[{"id":"cry-04-01b_stmt","name":"statement","prose":"The cloud service provider has established procedures and technical safeguards for state of the art encryption and authentication for the transmission of cloud service customer data and cloud service derived data over public networks."},{"id":"cry-04-01b_guidance-1","name":"guidance","prose":"When transmitting data with normal protection needs 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. Configuration of the TLS protocol 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)'. Cipher Suites should provide Perfect Forward Secrecy. Generally, wildcard certificates should not be used."}],"title":"CRY-04 Basic 01B"},{"id":"cry-04-02b","class":"basic","parts":[{"id":"cry-04-02b_stmt","name":"statement","prose":"During remote access to the production environment, the cloud service provider uses state of the art cryptographic mechanisms, including personnel authentication, to protect the communication."},{"id":"cry-04-02b_guidance-1","name":"guidance","prose":"When transmitting data with normal protection needs 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. Configuration of the TLS protocol 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)'. Cipher Suites should provide Perfect Forward Secrecy. Generally, wildcard certificates should not be used."}],"title":"CRY-04 Basic 02B"},{"id":"cry-04-01as","class":"additional-sharpen","parts":[{"id":"cry-04-01as_stmt","name":"statement","prose":"The cloud service provider has established procedures and technical safeguards for state of the art encryption and authentication for the transmission of all data."},{"id":"cry-04-01as_guidance-1","name":"guidance","prose":"When transmitting data with normal protection needs 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. Configuration of the TLS protocol 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)'. Cipher Suites should provide Perfect Forward Secrecy. Generally, wildcard certificates should not be used."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"CRY-04 Additional Sharpen 01AS"}]},{"id":"cry-05","parts":[{"id":"cry-05-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 needs.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Encryption of Sensitive Data at Rest","controls":[{"id":"cry-05-01b","class":"basic","parts":[{"id":"cry-05-01b_stmt","name":"statement","prose":"The cloud service provider has established procedures and technical safeguards to encrypt cloud service customer data during storage (i.e. at rest)."}],"title":"CRY-05 Basic 01B"},{"id":"cry-05-02b","class":"basic","parts":[{"id":"cry-05-02b_stmt","name":"statement","prose":"In general, the private keys (for asymmetric algorithms) or secret keys (for symmetric algorithms) used for encryption are accessible only by the cloud service customer in accordance with applicable legal and regulatory obligations and requirements. If due to the nature of the cloud service, the cloud service provider has to access the private or secret keys of the customer in order to provide the cloud service, this access is performed in accordance with IAM-07. Exceptions follow a specified procedure."},{"id":"cry-05-02b_guidance-1","name":"guidance","prose":"The requirement of 'accessible only by the cloud service customer' means that encryption keys remain solely within the knowledge and control of the owner. This can be addressed by implementing a secure key management system. If a key management system is used, the keys need to be protected from usage not explicitly authorised by the owner of the key and remain inaccessible in plaintext.\n\nThis criterion does not apply to data that cannot be encrypted for the provision of the cloud service for functional reasons."},{"id":"cry-05-02b_guidance-2","name":"guidance","prose":"Scenarios in which the cloud service provider has to access the secret or private keys of the customer include, but are not limited to, the use of provider-managed keys in a SaaS service."},{"id":"cry-05-02b_guidance-3","name":"guidance","prose":"The use of a master key by the cloud service provider may be an exception to the requirement that keys are accessible only by the cloud service customers."}],"title":"CRY-05 Basic 02B"},{"id":"cry-05-03b","class":"basic","parts":[{"id":"cry-05-03b_stmt","name":"statement","prose":"The procedures for the use of private keys, including any exceptions, are agreed with the cloud service customer."},{"id":"cry-05-03b_guidance-1","name":"guidance","prose":"The requirement of 'accessible only by the cloud service customer' means that encryption keys remain solely within the knowledge and control of the owner. This can be addressed by implementing a secure key management system. If a key management system is used, the keys need to be protected from usage not explicitly authorised by the owner of the key and remain inaccessible in plaintext.\n\nThis criterion does not apply to data that cannot be encrypted for the provision of the cloud service for functional reasons."}],"title":"CRY-05 Basic 03B"},{"id":"cry-05-04b","class":"basic","parts":[{"id":"cry-05-04b_stmt","name":"statement","prose":"If any changes of these procedures and technical safeguards may affect the confidentiality of the cloud service customer data, the cloud service provider communicates these changes to the cloud service customers."},{"id":"cry-05-04b_guidance-1","name":"guidance","prose":"The requirement of 'accessible only by the cloud service customer' means that encryption keys remain solely within the knowledge and control of the owner. This can be addressed by implementing a secure key management system. If a key management system is used, the keys need to be protected from usage not explicitly authorised by the owner of the key and remain inaccessible in plaintext.\n\nThis criterion does not apply to data that cannot be encrypted for the provision of the cloud service for functional reasons."}],"title":"CRY-05 Basic 04B"},{"id":"cry-05-05b","class":"basic","parts":[{"id":"cry-05-05b_stmt","name":"statement","prose":"If the cloud service provider uses a master key, the cloud service provider regularly tests the suitability of the design and operating effectiveness of the respective controls."},{"id":"cry-05-05b_guidance-1","name":"guidance","prose":"The use of a master key by the cloud service provider may be an exception to the requirement that keys are accessible only by the cloud service customers."}],"title":"CRY-05 Basic 05B"},{"id":"cry-05-01ac","class":"additional-complement","parts":[{"id":"cry-05-01ac_stmt","name":"statement","prose":"The cloud service provider ensures that secure encryption mechanisms are in place to prevent the recovery of cloud service customer data when resources are reallocated or physical media are recovered."},{"id":"cry-05-01ac_guidance-1","name":"guidance","prose":"The requirement of 'accessible only by the cloud service customer' means that encryption keys remain solely within the knowledge and control of the owner. This can be addressed by implementing a secure key management system. If a key management system is used, the keys need to be protected from usage not explicitly authorised by the owner of the key and remain inaccessible in plaintext.\n\nThis criterion does not apply to data that cannot be encrypted for the provision of the cloud service for functional reasons."}],"title":"CRY-05 Additional Complement 01AC"}]},{"id":"cry-06","title":"Secure Key Generation","controls":[{"id":"cry-06-01b","class":"basic","parts":[{"id":"cry-06-01b_stmt","name":"statement","prose":"Procedures and technical safeguards for the secure generation of keys for different cryptographic systems and applications are documented and implemented. These safeguards require the use of secure random bit generators or generation based on keys that were created in this fashion."},{"id":"cry-06-01b_guidance-1","name":"guidance","prose":"For the definition of secure random number generators, cloud service providers should refer to BSI TR-02102-1 (Chapter 8).\n\nThe cloud service provider protects the keys which are created and inserted into the cloud service by the cloud service customers according to the same criteria as the keys created by the cloud service provider."}],"title":"CRY-06 Basic 01B"}]},{"id":"cry-07","title":"Rotation of Cryptographic Keys","controls":[{"id":"cry-07-01b","class":"basic","parts":[{"id":"cry-07-01b_stmt","name":"statement","prose":"The cloud service provider has established a schedule for rotating cryptographic keys that aligns with the requirements for cryptographic key rotation established in CRY-01. If, based on the results of a risk assessment, the cloud service provider does not perform key rotation, this decision is transparently communicated to the customer."}],"title":"CRY-07 Basic 01B"}]},{"id":"cry-08","parts":[{"id":"cry-08-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that, where they use certificate authority services provided by the cloud service provider, identity verification procedures appropriate to the certificates being issued are implemented and the technical controls provided by the cloud service are configured to enable and enforce identity verification. Cloud service customers ensure with suitable controls that, where they obtain certificates from external Certificate Authorities for their own use, procedures are established for selecting trusted Certificate Authorities and validating the authenticity of obtained certificates.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Public-Key Certificate Issuance","controls":[{"id":"cry-08-01b","class":"basic","parts":[{"id":"cry-08-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures to securely issue and obtain public-key certificates, ensuring the integrity and authenticity of cryptographic keys. These procedures include:\n\n1. Verification of identity before issuing public-key certificates that are issued by or on behalf of the cloud service provider for its own system components or personnel to ensure they are granted to legitimate entities;\n2. Secure methods for issuing certificates that are issued by or on behalf of the cloud service provider for its own system components or personnel to prevent unauthorised access; and\n3. Procedures for obtaining public-key certificates from trusted Certificate Authorities to ensure the authenticity of the certificates used by the cloud service provider."},{"id":"cry-08-01b_guidance-1","name":"guidance","prose":"The first two bullet points apply to certificates issued by or on behalf of the cloud service provider for its own system components and personnel. If the cloud service provider offers certificate authority services for cloud service customers, the shared responsibility principle applies, i.e. the cloud service provider should ensure that the cloud service provides adequate technical measures to enable cloud service customers to perform adequate identity verification (cf. also the Complementary Customer Criteria).\nThe third bullet point applies to certificates that the cloud service provider obtains from external Certificate Authorities for use in its own cloud services and system components. The cloud service provider should ensure that certificates are obtained only from trusted Certificate Authorities and that the authenticity of received certificates is verified before use. This criterion does not necessarily extend to certificates that cloud service customers obtain from external Certificate Authorities for their own purposes; the selection and validation of external Certificate Authorities by customers falls under customer responsibility within the shared responsibility model."}],"title":"CRY-08 Basic 01B"}]},{"id":"cry-09","title":"Secure Key Provisioning","controls":[{"id":"cry-09-01b","class":"basic","parts":[{"id":"cry-09-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures and technical safeguards to ensure that cryptographic keys are provisioned and activated securely within its area of responsibility. These procedures include the verification of identity and authorisation before provisioning and activating keys to ensure they are granted to legitimate entities."}],"title":"CRY-09 Basic 01B"},{"id":"cry-09-02b","class":"basic","parts":[{"id":"cry-09-02b_stmt","name":"statement","prose":"Provisioned keys include activation and deactivation dates to ensure that their use is time limited."}],"title":"CRY-09 Basic 02B"}]},{"id":"cry-10","title":"Secure Storage of Keys","controls":[{"id":"cry-10-01b","class":"basic","parts":[{"id":"cry-10-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented technical safeguards for the secure storage of cryptographic keys. This includes ensuring separation of the key management system from the application and middleware layers, defining how authorised users gain access and addressing the geographic residency of keys to comply with contractual, legal, regulatory, and security requirements."}],"title":"CRY-10 Basic 01B"},{"id":"cry-10-01ac","class":"additional-complement","parts":[{"id":"cry-10-01ac_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07), the cloud service provider uses a suitable software or hardware security module for the secure storage of cryptographic keys."}],"title":"CRY-10 Additional Complement 01AC"}]},{"id":"cry-11","title":"Cryptographic Key Archival","controls":[{"id":"cry-11-01b","class":"basic","parts":[{"id":"cry-11-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures and technical safeguards for the secure archiving of cryptographic keys. These include:\n\n1. Storage of archived keys in a repository to prevent unauthorised access;\n2. Restriction of access to archived keys to authorised personnel based on the principle of least privilege;\n3. Support of later recovery of information through archived keys;\n4. Retention of archived keys only for as long as needed and secure destruction afterwards; and\n5. Logging of all activities related to the storage and recovery of archived keys."}],"title":"CRY-11 Basic 01B"}]},{"id":"cry-12","title":"Cryptographic Key Transition Management","controls":[{"id":"cry-12-01b","class":"basic","parts":[{"id":"cry-12-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures to oversee the transition of cryptographic keys, including their movement into and out of suspension. These procedures ensure that all key transitions are thoroughly monitored, reviewed, and approved to maintain security and comply with applicable laws and regulations."},{"id":"cry-12-01b_guidance-1","name":"guidance","prose":"Suspension of a cryptographic key refers to a temporary state in which the key is disabled and cannot be used for cryptographic operations but may later be reactivated. Deactivation of a cryptographic key, in contrast, represents a permanent state in which the key is withdrawn from use and cannot be reactivated."}],"title":"CRY-12 Basic 01B"}]},{"id":"cry-13","title":"Handling of Compromised Keys","controls":[{"id":"cry-13-01b","class":"basic","parts":[{"id":"cry-13-01b_stmt","name":"statement","prose":"The cloud service provider manages the use of compromised cryptographic keys to ensure they are only used in controlled circumstances and solely for decryption or verification (in case of signature keys), while complying with legal and regulatory requirements."}],"title":"CRY-13 Basic 01B"},{"id":"cry-13-02b","class":"basic","parts":[{"id":"cry-13-02b_stmt","name":"statement","prose":"The cloud service provider notifies affected cloud service customers without undue delay that their keys have been compromised and will no longer be used for encryption or signing."}],"title":"CRY-13 Basic 02B"}]},{"id":"cry-14","title":"Secure Deactivation of Cryptographic Keys","controls":[{"id":"cry-14-01b","class":"basic","parts":[{"id":"cry-14-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures to deactivate cryptographic keys. These procedures ensure that:\n\n1. Expired keys are no longer used for encryption purposes, but may still be used for decryption if necessary;\n2. Expired keys are no longer used for signature creation, but may still be used for signature verification;\n3. Deactivated keys are eventually destroyed when they are no longer required, with relevant metadata retained for auditing; and\n4. All actions related to key deactivation and destruction are recorded in the key management system to maintain a detailed audit log."}],"title":"CRY-14 Basic 01B"}]},{"id":"cry-15","title":"Requirements for Pre-Shared Keys","controls":[{"id":"cry-15-01b","class":"basic","parts":[{"id":"cry-15-01b_stmt","name":"statement","prose":"If pre-shared keys or wildcard certificates are used, the cloud service provider has documented and implemented dedicated procedures and technical safeguards to ensure their secure use and provisioning."}],"title":"CRY-15 Basic 01B"}]},{"id":"cry-16","title":"Operational Continuity for Key Management","controls":[{"id":"cry-16-01b","class":"basic","parts":[{"id":"cry-16-01b_stmt","name":"statement","prose":"The cloud service provider has assessed the balance between conducting backups of key material stored in a Hardware Security Module (HSM) for key restoration and building redundancy or comparable measures for securing keys to ensure operational continuity. This assessment includes evaluating the risk of key exposure if control over the key material is lost. Decisions regarding whether to use the backups of keys or to establish redundancy are documented, and the chosen measures are reviewed for their effectiveness and compliance with contractual, legal and regulatory requirements."},{"id":"cry-16-01b_guidance-1","name":"guidance","prose":"The cloud service provider should consider the following options for safeguarding key material:\n\n1. Backup of keys: Encrypted backups of keys are stored securely outside the HSM. The backup process should ensure that the keys are encrypted during storage and transit to prevent unauthorised access. Regular testing of backup and recovery procedures should be carried out to verify the effectiveness and integrity of the backups. Backups outside a HSM should only be considered after dilligent risk assessment.\n2. Redundant HSMs: Implementing multiple HSMs in geographically dispersed locations to create redundancy to ensure that keys remain available and secure even if one HSM fails. The HSMs should be synchronised to ensure consistency of key material across all devices. Regular health checks and failover tests are necessary to ensure that redundancy mechanisms function correctly. The particular manner this redundancy is built may depend on the details of the contractual agreements between provider and customer. E.g. when the customer choose a particular location, zone or region, this choice also applies to the redundancy mentioned in this criterion."}],"title":"CRY-16 Basic 01B"},{"id":"cry-16-02b","class":"basic","parts":[{"id":"cry-16-02b_stmt","name":"statement","prose":"Procedures for the recovery of lost or corrupted keys are in place."},{"id":"cry-16-02b_guidance-1","name":"guidance","prose":"The cloud service provider should consider the following options for safeguarding key material:\n\n1. Backup of keys: Encrypted backups of keys are stored securely outside the HSM. The backup process should ensure that the keys are encrypted during storage and transit to prevent unauthorised access. Regular testing of backup and recovery procedures should be carried out to verify the effectiveness and integrity of the backups. Backups outside a HSM should only be considered after dilligent risk assessment.\n2. Redundant HSMs: Implementing multiple HSMs in geographically dispersed locations to create redundancy to ensure that keys remain available and secure even if one HSM fails. The HSMs should be synchronised to ensure consistency of key material across all devices. Regular health checks and failover tests are necessary to ensure that redundancy mechanisms function correctly. The particular manner this redundancy is built may depend on the details of the contractual agreements between provider and customer. E.g. when the customer choose a particular location, zone or region, this choice also applies to the redundancy mentioned in this criterion."}],"title":"CRY-16 Basic 02B"}]},{"id":"cry-17","title":"Cryptographic Key Lifecycle Management","controls":[{"id":"cry-17-01b","class":"basic","parts":[{"id":"cry-17-01b_stmt","name":"statement","prose":"The cloud service provider has documented and implemented procedures and technical safeguards to monitor and document the lifecycle of cryptographic keys and materials."}],"title":"CRY-17 Basic 01B"},{"id":"cry-17-02b","class":"basic","parts":[{"id":"cry-17-02b_stmt","name":"statement","prose":"For all keys except for ephemeral keys, the aforementioned safeguards ensure detailed records of each key from creation to destruction, including any status changes."}],"title":"CRY-17 Basic 02B"}]},{"id":"cry-18","parts":[{"id":"cry-18-corresponding","name":"corresponding","prose":"Cloud service customers ensure that their own key management procedures are compatible with the requirements of the external KMS and that they implement appropriate controls to ensure the security of their keys.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Usage of External Key Management Systems","controls":[{"id":"cry-18-01b","class":"basic","parts":[{"id":"cry-18-01b_stmt","name":"statement","prose":"In the case that external key management systems (KMS) are integrated into the service, the cloud service provider ensures that the procedures and technical safeguards for the usage of external key management systems (KMS) are established. The following aspects are taken into account:\n\n1. The external KMS have recognised security certifications that reflect the state of the art to comply with legal, regulatory and contractual requirements;\n2. The integration of the external KMS into the cloud infrastructure is secure to ensure the confidentiality, integrity, and availability of the keys;\n3. Strict access control are implemented to ensure that only authorised users and systems can access the keys (cf. IAM-01); \n4. Procedures for the regular rotation and renewal of keys are defined and implemented to ensure the security of the keys (cf. CRY-07);\n5. All accesses and operations on the external KMS are logged and monitored to detect and respond to suspicious activities; and\n6. The cloud service provider ensures that the external KMS is regularly checked for vulnerabilities (cf. OPS-25) and updated (cf. OPS-28) to meet current threats and technological developments."}],"title":"CRY-18 Basic 01B"}]},{"id":"cry-19","parts":[{"id":"cry-19-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that their agreements with the cloud service provider include robust procedures and technical safeguards for the secure handling of customer-managed cryptographic keys. Cloud service customers ensure that these procedures address the secure integration of their keys into the cloud environment, comprehensive logging of all activities related to their keys, and clearly defined access control mechanisms to restrict access solely to authorised users.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Secure Handling of Customer Managed Keys","controls":[{"id":"cry-19-01b","class":"basic","parts":[{"id":"cry-19-01b_stmt","name":"statement","prose":"The cloud service provider implements procedures and technical safeguards to ensure the secure handling of cryptographic keys managed by cloud service customers. In these procedures, the following aspects are considered:\n\n1. Secure integration of customer-generated keys ('Bring-Your-Own-Key'; BYOK) into the cloud environment;\n2. Logging of all activities related to customer-managed keys; and\n3. Definition of access control mechanisms to enable that only authorised users can gain access to customer-managed keys."}],"title":"CRY-19 Basic 01B"}]}]},{"id":"cos","title":"Communication Security (COS)","controls":[{"id":"cos-01","parts":[{"id":"cos-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Technical Safeguards","controls":[{"id":"cos-01-01b","class":"basic","parts":[{"id":"cos-01-01b_stmt","name":"statement","prose":"Based on the results of a risk assessment carried out according to OIS-07, the cloud service provider has implemented technical safeguards which are suitable to timely detect and respond to attacks on the network of system components used for provisioning of the cloud service."}],"title":"COS-01 Basic 01B"},{"id":"cos-01-02b","class":"basic","parts":[{"id":"cos-01-02b_stmt","name":"statement","prose":"For these technical safeguards, preventive and protective measures are implemented at multiple tiers (defence in depth) within the cloud service to mitigate the risk of breaching the deployed defensive system. This includes network-based cyber attacks such as:\n\n1. Attacks on the basis of irregular incoming or outgoing traffic patterns;\n2. Distributed Denial-of-Service (DDoS) attacks;\n3. Spoofing attacks;\n4. Code injection attacks;\n5. DNS tunneling; and\n6. IoT attacks targeting devices within a network."},{"id":"cos-01-02b_guidance-1","name":"guidance","prose":"Technical safeguards that provide protection and prevention at multiple tiers are e.g. a special separation in Identity and Access Management, separate logging for protective systems and Web Application Firewalls (WAFs) for accessing protective systems.\n\nNetwork-based attacks can be conducted e.g. with MAC spoofing and ARP poisoning attacks. Technical safeguards 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."}],"title":"COS-01 Basic 02B"},{"id":"cos-01-03b","class":"basic","parts":[{"id":"cos-01-03b_stmt","name":"statement","prose":"Data from corresponding technical safeguards implemented (cloud service provider data) is fed into the organisation's SIEM system (cf. OPS-13), so that (counter-) measures regarding correlating events can be initiated. The safeguards are documented, communicated and provided in accordance with SP-01."}],"title":"COS-01 Basic 03B"},{"id":"cos-01-01ac","class":"additional-complement","parts":[{"id":"cos-01-01ac_stmt","name":"statement","prose":"Technical safeguards ensure that no unknown (physical or virtual) devices join the cloud service provider's (physical or virtual) network."},{"id":"cos-01-01ac_guidance-1","name":"guidance","prose":"Technical safeguards that provide protection and prevention at multiple tiers are e.g. a special separation in Identity and Access Management, separate logging for protective systems and Web Application Firewalls (WAFs) for accessing protective systems.\n\nNetwork-based attacks can be conducted e.g. with MAC spoofing and ARP poisoning attacks. Technical safeguards 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."}],"title":"COS-01 Additional Complement 01AC"}]},{"id":"cos-02","title":"Security Requirements for Connections in the Cloud Service Provider's Network","controls":[{"id":"cos-02-01b","class":"basic","parts":[{"id":"cos-02-01b_stmt","name":"statement","prose":"Specific security requirements are designed, documented 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\n1. In which cases the security zones are to be separated and in which cases cloud service customers are to be logically or physically separated;\n2. Which communication relationships and which network and application protocols are permitted in each case;\n3. How the data traffic for administration and monitoring is separated from each on network level;\n4. How office networks are secured with firewalls and secure WIFI configurations as well as VPN for remote access;\n5. Which internal, cross-partition communication is permitted; and\n6. Which cross-network communication is allowed."},{"id":"cos-02-01b_guidance-1","name":"guidance","prose":"Cross-partition communication can be realised for e.g. individual regions or locations via e.g. WAN, LAN, VPN, RAS."}],"title":"COS-02 Basic 01B"}]},{"id":"cos-03","parts":[{"id":"cos-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 service customer's organisational units).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Monitoring of Connections in the Cloud Service Provider's Network","controls":[{"id":"cos-03-01b","class":"basic","parts":[{"id":"cos-03-01b_stmt","name":"statement","prose":"The cloud service provider distinguishes between trusted and untrusted networks. Based on a risk assessment according to OIS-07, these are separated into different security zones for internal and external network areas (and DMZ, if applicable)."}],"title":"COS-03 Basic 01B"},{"id":"cos-03-02b","class":"basic","parts":[{"id":"cos-03-02b_stmt","name":"statement","prose":"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 (cf. COS-02)."}],"title":"COS-03 Basic 02B"},{"id":"cos-03-03b","class":"basic","parts":[{"id":"cos-03-03b_stmt","name":"statement","prose":"The cloud service provider ensures that the configuration of networks matches the security requirements (cf. COS-02). The cloud service provider reviews at least annually and in case of significant changes to the cloud service the design and implementation of the configuration of the connections with regard to the defined security requirements."},{"id":"cos-03-03b_guidance-1","name":"guidance","prose":"The review of the security requirements depends on the measures implemented to design the networks, e.g. monitoring and reviewing firewall rules or log files for abnormalities as well as visual inspections of physical network components for changes."},{"id":"cos-03-03b_guidance-2","name":"guidance","prose":"If the review is caused by significant changes to the cloud service, only the design and implementation of configuration of the connections affected by these changes need to be included in the review."}],"title":"COS-03 Basic 03B"},{"id":"cos-03-04b","class":"basic","parts":[{"id":"cos-03-04b_stmt","name":"statement","prose":"Identified vulnerabilities and deviations are subject to risk assessment in accordance with the risk management procedure (cf. OIS-07) and follow-up measures are defined and tracked (cf. OPS-18)."},{"id":"cos-03-04b_guidance-1","name":"guidance","prose":"The review of the security requirements depends on the measures implemented to design the networks, e.g. monitoring and reviewing firewall rules or log files for abnormalities as well as visual inspections of physical network components for changes."}],"title":"COS-03 Basic 04B"},{"id":"cos-03-05b","class":"basic","parts":[{"id":"cos-03-05b_stmt","name":"statement","prose":"At 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."},{"id":"cos-03-05b_guidance-1","name":"guidance","prose":"The review of the security requirements depends on the measures implemented to design the networks, e.g. monitoring and reviewing firewall rules or log files for abnormalities as well as visual inspections of physical network components for changes."}],"title":"COS-03 Basic 05B"}]},{"id":"cos-04","parts":[{"id":"cos-04-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Cross-Network Access","controls":[{"id":"cos-04-01b","class":"basic","parts":[{"id":"cos-04-01b_stmt","name":"statement","prose":"Each network perimeter is controlled by security gateways."}],"title":"COS-04 Basic 01B"},{"id":"cos-04-02b","class":"basic","parts":[{"id":"cos-04-02b_stmt","name":"statement","prose":"The system access authorisation for cross-network access is based on a security assessment based on the requirements of the cloud service customers."},{"id":"cos-04-02b_guidance-1","name":"guidance","prose":"A security gateway is a stack of chained filtering and firewall components that restrict communication to explicitly permitted traffic. Security gateways can, for example, employ a P-A-P structure, consisting of an outer packet filter, an application-level gateway acting as a deep-inspection proxy, and an inner packet filter. The stack may be further enriched with an intrusion detection system, intrusion prevention system, or antivirus scanner. However, this structure is not mandatory. It serves to keep filtering and inspection functionally independent of each other, so that a failure of one does not automatically lead to a failure of the other."},{"id":"cos-04-02b_guidance-2","name":"guidance","prose":"Cross-network access is access from one network to another network via a defined network perimeter."}],"title":"COS-04 Basic 02B"},{"id":"cos-04-01as","class":"additional-sharpen","parts":[{"id":"cos-04-01as_stmt","name":"statement","prose":"Each network perimeter is controlled by redundant and highly available security gateways."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"COS-04 Additional Sharpen 01AS"}]},{"id":"cos-05","title":"Networks for Administration","controls":[{"id":"cos-05-01b","class":"basic","parts":[{"id":"cos-05-01b_stmt","name":"statement","prose":"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 service customer's network and protected from unauthorised access by multi-factor authentication (cf. IAM-08)."},{"id":"cos-05-01b_guidance-1","name":"guidance","prose":"The separation can be physical or logical (e.g. VLAN, SDN, VRF)."}],"title":"COS-05 Basic 01B"},{"id":"cos-05-02b","class":"basic","parts":[{"id":"cos-05-02b_stmt","name":"statement","prose":"Networks used by the cloud service provider to create, migrate or orchestrate compute workloads (e.g. virtual machines, containers, functions) are physically or logically separated from tenant networks."}],"title":"COS-05 Basic 02B"},{"id":"cos-05-01ac","class":"additional-complement","parts":[{"id":"cos-05-01ac_stmt","name":"statement","prose":"If there is no physical separation between the administration networks and other networks, the administration network traffic uses state of the art encryption (cf. CRY-01)."}],"title":"COS-05 Additional Complement 01AC"}]},{"id":"cos-06","parts":[{"id":"cos-06-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 organisational units).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Separation of Data Traffic in Jointly Used Network Environments","controls":[{"id":"cos-06-01b","class":"basic","parts":[{"id":"cos-06-01b_stmt","name":"statement","prose":"Cloud service customer data traffic in jointly used network environments is separated on network level according to a documented framework to ensure the confidentiality and integrity of the data transmitted."},{"id":"cos-06-01b_guidance-1","name":"guidance","prose":"If the cloud service provider does not use shared network environments for cloud service customers and instead uses a physical separation, the basic criterion is not applicable.\n\nIf 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 framework). The separation of stored and processed data is subject of the criteria OPS-30 and OPS-31. After successful authentication via an insecure communication channel (HTTP), a secure communication channel (HTTPS) is to be used.\n\nWith IaaS/PaaS, secure separation is ensured by physically separated networks or encryption of the networks that corresponds to the state of the art. For the definition of state of the art encryption, the BSI Technical Guideline TR-02102 should be considered (cf. CRY-01)."}],"title":"COS-06 Basic 01B"},{"id":"cos-06-01ac","class":"additional-complement","parts":[{"id":"cos-06-01ac_stmt","name":"statement","prose":"In the case of IaaS/PaaS, the secure separation is ensured by physically separated networks or by means of state of the art encryption in combination with logical network separation or encapsulation."},{"id":"cos-06-01ac_guidance-1","name":"guidance","prose":"If the cloud service provider does not use shared network environments for cloud service customers and instead uses a physical separation, the basic criterion is not applicable.\n\nIf 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 framework). The separation of stored and processed data is subject of the criteria OPS-30 and OPS-31. After successful authentication via an insecure communication channel (HTTP), a secure communication channel (HTTPS) is to be used.\n\nWith IaaS/PaaS, secure separation is ensured by physically separated networks or encryption of the networks that corresponds to the state of the art. For the definition of state of the art encryption, the BSI Technical Guideline TR-02102 should be considered (cf. CRY-01)."}],"title":"COS-06 Additional Complement 01AC"}]},{"id":"cos-07","title":"Documentation of the Network Topology","controls":[{"id":"cos-07-01b","class":"basic","parts":[{"id":"cos-07-01b_stmt","name":"statement","prose":"The documentation of the logical structure of the network used to provide 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 incidents in accordance with contractual obligations. The documentation shows:\n\n1. How the subnets are allocated; \n2. How the network is zoned and segmented;\n3. How the network connects with third party and public networks; and\n4. How the data flows between different subnets and system components within the network to support the management, monitoring and analysis of the network."},{"id":"cos-07-01b_guidance-1","name":"guidance","prose":"The network documentation can follow a hierarchical or grouped approach based on the scale of operations."},{"id":"cos-07-01b_guidance-2","name":"guidance","prose":"Zoning is a segmentation of the subnets with a firewall implemented at the network perimeters."}],"title":"COS-07 Basic 01B"},{"id":"cos-07-02b","class":"basic","parts":[{"id":"cos-07-02b_stmt","name":"statement","prose":"The partitions, regions, zones or location in which the cloud service customer data is stored are indicated."},{"id":"cos-07-02b_guidance-1","name":"guidance","prose":"The network documentation can follow a hierarchical or grouped approach based on the scale of operations."}],"title":"COS-07 Basic 02B"},{"id":"cos-07-03b","class":"basic","parts":[{"id":"cos-07-03b_stmt","name":"statement","prose":"The cloud service provider establishes and maintains an accurate representation of the technical and logical structure of the cloud service provider's systems based on the network topology documentation and the asset inventory (cf. AM-02). The documentation includes the system components that provide security functions and the system components that host the corresponding cloud service customer data and cloud service derived data, or provide sensitive functions."},{"id":"cos-07-03b_guidance-1","name":"guidance","prose":"The network documentation can follow a hierarchical or grouped approach based on the scale of operations."}],"title":"COS-07 Basic 03B"},{"id":"cos-07-04b","class":"basic","parts":[{"id":"cos-07-04b_stmt","name":"statement","prose":"The network topology documentation is reviewed at least once a year. Timely and appropriate remediation measures address any deviations identified during the review."}],"title":"COS-07 Basic 04B"}]},{"id":"cos-08","parts":[{"id":"cos-08-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the data transmitted to the cloud service is protected against tampering, copying, modifying, redirecting or deleting in accordance with their protection needs.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Policies for Data Transmission","controls":[{"id":"cos-08-01b","class":"basic","parts":[{"id":"cos-08-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational safeguards in order to protect the transmission of cloud service customer data, cloud service derived data, cloud service provider data and account data against unauthorised interception, manipulation, copying, modification, redirection, destruction or malware intrusion are documented, communicated and provided according to SP-01. The policies and procedures establish a reference to the asset classification and labelling (cf. AM-09) and cryptographic mechanisms (cf. CRY-01)."},{"id":"cos-08-01b_guidance-1","name":"guidance","prose":"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-04."}],"title":"COS-08 Basic 01B"},{"id":"cos-08-02b","class":"basic","parts":[{"id":"cos-08-02b_stmt","name":"statement","prose":"Technical safeguards outlined in the documented policies and procedures to protect the transmission of data are implemented and reviewed regularly, as well as in case of significant changes to the cloud service."},{"id":"cos-08-02b_guidance-1","name":"guidance","prose":"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-04."},{"id":"cos-08-02b_guidance-2","name":"guidance","prose":"If a review is caused by significant changes to the cloud service, only the technical safeguards affected by these changes need to be included in the review."}],"title":"COS-08 Basic 02B"}]}]},{"id":"pi","title":"Portability and Interoperability (PI)","controls":[{"id":"pi-01","parts":[{"id":"pi-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the interfaces provided (and their security) are adequate for its protection needs by means of appropriate checks before the start of use of the cloud service and each time the interfaces are changed.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Safety of Input and Output Interfaces","controls":[{"id":"pi-01-01b","class":"basic","parts":[{"id":"pi-01-01b_stmt","name":"statement","prose":"For inbound and outbound interfaces through which the cloud service can be accessed by other cloud services or IT systems of cloud service customers, the cloud service provider designs, implements and maintains controls regarding the following aspects:\n\n1. The use of standardised communication protocols for interactions between different application interfaces to ensure the confidentiality and integrity of the transmitted information according to its protection needs, and the adequate authentication of the user;\n2. The use of encryption according to CRY-02 in case of communication over untrusted networks;\n3. The use of standardised data formats and common data processing standards to facilitate information processing interoperability;\n4. The implementation of mechanisms to validate data integrity and establish backup and recovery processes to ensure data security and reliability during exchange, usage and transfer; and\n5. The provision of up-to-date information about the available communication protocols, as well as applicable data formats and data processing standards."},{"id":"pi-01-01b_guidance-1","name":"guidance","prose":"In this context, an interface is a system access point or library function with a well-defined syntax. It comprises documented methods that allow cloud service customers to securely access and interact with the cloud service, enabling the exchange of data.\n\nThose interfaces and their documentation should include sufficient information on the cloud service to enable the development of software to communicate with it for the purposes of data portability and interoperability. However, the cloud service provider is not required to develop new technologies to this purpose or share information that is protected by intellectual property rights or that constitutes a trade secret.\n\nWhile these interfaces provide the means for communication with the cloud service, they do not imply that cloud service customers can directly connect their custom systems as if they are natively integrated. Instead, cloud service customers can configure their systems by using methods, such as API calls, and adhering to the specified protocols and data formats provided by the cloud service provider.\n\nTo ensure seamless and secure communication between interfaces, the cloud service provider uses industry-standard API protocols and implements state of the art transport layer security. The cloud service provider supports cross-platform information processing by employing containerisation technologies and cloud-neutral development frameworks. Infrastructre as Code practices are adopted to standardise infrastructre provisioning. Common data usage policies are defined and enforced to ensure consistent and secure access, utilisation and sharing of data. Upon contract termination, the cloud service provider assists customers in exporting and transferring their data, e.g. by providing technical documentation and data export tools."}],"title":"PI-01 Basic 01B"},{"id":"pi-01-02b","class":"basic","parts":[{"id":"pi-01-02b_stmt","name":"statement","prose":"The cloud service provider provides suitable technical means for extracting cloud service customer data in accordance with the aforementioned policies and procedures to the cloud service customer. Where data volume, format, or architecture make a customer-driven extraction infeasible, the cloud service provider provides appropriate extraction services to the cloud service customer."},{"id":"pi-01-02b_guidance-1","name":"guidance","prose":"In this context, an interface is a system access point or library function with a well-defined syntax. It comprises documented methods that allow cloud service customers to securely access and interact with the cloud service, enabling the exchange of data.\n\nThose interfaces and their documentation should include sufficient information on the cloud service to enable the development of software to communicate with it for the purposes of data portability and interoperability. However, the cloud service provider is not required to develop new technologies to this purpose or share information that is protected by intellectual property rights or that constitutes a trade secret.\n\nWhile these interfaces provide the means for communication with the cloud service, they do not imply that cloud service customers can directly connect their custom systems as if they are natively integrated. Instead, cloud service customers can configure their systems by using methods, such as API calls, and adhering to the specified protocols and data formats provided by the cloud service provider.\n\nTo ensure seamless and secure communication between interfaces, the cloud service provider uses industry-standard API protocols and implements state of the art transport layer security. The cloud service provider supports cross-platform information processing by employing containerisation technologies and cloud-neutral development frameworks. Infrastructre as Code practices are adopted to standardise infrastructre provisioning. Common data usage policies are defined and enforced to ensure consistent and secure access, utilisation and sharing of data. Upon contract termination, the cloud service provider assists customers in exporting and transferring their data, e.g. by providing technical documentation and data export tools."}],"title":"PI-01 Basic 02B"},{"id":"pi-01-01ac","class":"additional-complement","parts":[{"id":"pi-01-01ac_stmt","name":"statement","prose":"The cloud service provider sets up an application firewall to protect the administration interfaces for cloud service customers that are accessible over public networks."},{"id":"pi-01-01ac_guidance-1","name":"guidance","prose":"In this context, an interface is a system access point or library function with a well-defined syntax. It comprises documented methods that allow cloud service customers to securely access and interact with the cloud service, enabling the exchange of data.\n\nThose interfaces and their documentation should include sufficient information on the cloud service to enable the development of software to communicate with it for the purposes of data portability and interoperability. However, the cloud service provider is not required to develop new technologies to this purpose or share information that is protected by intellectual property rights or that constitutes a trade secret.\n\nWhile these interfaces provide the means for communication with the cloud service, they do not imply that cloud service customers can directly connect their custom systems as if they are natively integrated. Instead, cloud service customers can configure their systems by using methods, such as API calls, and adhering to the specified protocols and data formats provided by the cloud service provider.\n\nTo ensure seamless and secure communication between interfaces, the cloud service provider uses industry-standard API protocols and implements state of the art transport layer security. The cloud service provider supports cross-platform information processing by employing containerisation technologies and cloud-neutral development frameworks. Infrastructre as Code practices are adopted to standardise infrastructre provisioning. Common data usage policies are defined and enforced to ensure consistent and secure access, utilisation and sharing of data. Upon contract termination, the cloud service provider assists customers in exporting and transferring their data, e.g. by providing technical documentation and data export tools."}],"title":"PI-01 Additional Complement 01AC"},{"id":"pi-01-02ac","class":"additional-complement","parts":[{"id":"pi-01-02ac_stmt","name":"statement","prose":"The cloud service provides cloud service customers with interfaces for custom identity providers to manage the authentication information of users under the responsibility of the cloud service customer. These interfaces are accompanied by a standardised protocol to facilitate communication between the cloud service and the external identity provider."},{"id":"pi-01-02ac_guidance-1","name":"guidance","prose":"In this context, an interface is a system access point or library function with a well-defined syntax. It comprises documented methods that allow cloud service customers to securely access and interact with the cloud service, enabling the exchange of data.\n\nThose interfaces and their documentation should include sufficient information on the cloud service to enable the development of software to communicate with it for the purposes of data portability and interoperability. However, the cloud service provider is not required to develop new technologies to this purpose or share information that is protected by intellectual property rights or that constitutes a trade secret.\n\nWhile these interfaces provide the means for communication with the cloud service, they do not imply that cloud service customers can directly connect their custom systems as if they are natively integrated. Instead, cloud service customers can configure their systems by using methods, such as API calls, and adhering to the specified protocols and data formats provided by the cloud service provider.\n\nTo ensure seamless and secure communication between interfaces, the cloud service provider uses industry-standard API protocols and implements state of the art transport layer security. The cloud service provider supports cross-platform information processing by employing containerisation technologies and cloud-neutral development frameworks. Infrastructre as Code practices are adopted to standardise infrastructre provisioning. Common data usage policies are defined and enforced to ensure consistent and secure access, utilisation and sharing of data. Upon contract termination, the cloud service provider assists customers in exporting and transferring their data, e.g. by providing technical documentation and data export tools."}],"title":"PI-01 Additional Complement 02AC"},{"id":"pi-01-03ac","class":"additional-complement","parts":[{"id":"pi-01-03ac_stmt","name":"statement","prose":"The interfaces are clearly documented to enable subject matter experts of the cloud service customer to integrate their identity provider with the cloud service."},{"id":"pi-01-03ac_guidance-1","name":"guidance","prose":"In this context, an interface is a system access point or library function with a well-defined syntax. It comprises documented methods that allow cloud service customers to securely access and interact with the cloud service, enabling the exchange of data.\n\nThose interfaces and their documentation should include sufficient information on the cloud service to enable the development of software to communicate with it for the purposes of data portability and interoperability. However, the cloud service provider is not required to develop new technologies to this purpose or share information that is protected by intellectual property rights or that constitutes a trade secret.\n\nWhile these interfaces provide the means for communication with the cloud service, they do not imply that cloud service customers can directly connect their custom systems as if they are natively integrated. Instead, cloud service customers can configure their systems by using methods, such as API calls, and adhering to the specified protocols and data formats provided by the cloud service provider.\n\nTo ensure seamless and secure communication between interfaces, the cloud service provider uses industry-standard API protocols and implements state of the art transport layer security. The cloud service provider supports cross-platform information processing by employing containerisation technologies and cloud-neutral development frameworks. Infrastructre as Code practices are adopted to standardise infrastructre provisioning. Common data usage policies are defined and enforced to ensure consistent and secure access, utilisation and sharing of data. Upon contract termination, the cloud service provider assists customers in exporting and transferring their data, e.g. by providing technical documentation and data export tools."}],"title":"PI-01 Additional Complement 03AC"}]},{"id":"pi-02","parts":[{"id":"pi-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Contractual Agreements for the Provision of Data","controls":[{"id":"pi-02-01b","class":"basic","parts":[{"id":"pi-02-01b_stmt","name":"statement","prose":"In contractual agreements, the following aspects are defined for provisioning of cloud service customer data following termination of the contractual relationship, insofar as these are applicable to the cloud service:\n\n1. Type, scope and format of the cloud service customer data the cloud service provider provides to the cloud service customer;\n2. Methods for delivering the data to the cloud service customer;\n3. Conditions and time frames for cloud service customer data provisioning throughout the duration of the contractual relationship;\n4. Right of termination of the contract and definition of the time frame within which the cloud service provider makes the cloud service customer data available to the cloud service customer after termination of the contract;\n5. Definition of the point in time as of which the cloud service provider makes the cloud service customer data inaccessible to the cloud service customer and deletes these after termination of the contract;\n6. The cloud service customers' responsibilities and obligations to cooperate for the provision of the cloud service customer data; and\n7. Cloud service customer data remains the property of the cloud service customer throughout the entire contractual relationship. After its termination, the data is once again the sole property and possession of the cloud service customer.\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."},{"id":"pi-02-01b_guidance-1","name":"guidance","prose":"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-like services, the cloud service 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 service customer has set up within its environment (e.g. configuration of networks, images of virtual machines and containers).\n\nWith SaaS, the cloud service customer typically relies on export functions provided by the cloud service provider. Data created by the cloud service 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\nLegal requirements can, for example, include the EU Data Act. In Germany, legal requirements for retention in particular 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.\n\nIf contractual agreements do not include the aspects listed in the basic criterion, and these are applicable due to the service model, the criterion is not met and a deviation is to be noted by the auditor."},{"id":"pi-02-01b_guidance-2","name":"guidance","prose":"If the cloud service provider acts as a cloud service broker, special consideration should be given to contractual data-portability clauses that recognise the complexity of the particular cloud service broker scenario. This can include, but is not limited to, the definition of:\n\n1. Responsibility for the export of cloud service customer data; \n2. If there are multiple underlying cloud service providers, the export scope, the consolidated format, any completeness limits, and how cloud service broker generated artifacts such as aggregated logs are handled; \n3. Whether cloud service customers can access the cloud services of underlying cloud service providers directly via APIs or have to rely on the cloud service broker's export interface, and whether there are any timing or usage restrictions; and\n4. Time frames for the delivery of cloud service customer data exports to the cloud service customer."}],"title":"PI-02 Basic 01B"},{"id":"pi-02-01ac","class":"additional-complement","parts":[{"id":"pi-02-01ac_stmt","name":"statement","prose":"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."},{"id":"pi-02-01ac_guidance-1","name":"guidance","prose":"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-like services, the cloud service 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 service customer has set up within its environment (e.g. configuration of networks, images of virtual machines and containers).\n\nWith SaaS, the cloud service customer typically relies on export functions provided by the cloud service provider. Data created by the cloud service 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\nLegal requirements can, for example, include the EU Data Act. In Germany, legal requirements for retention in particular 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.\n\nIf contractual agreements do not include the aspects listed in the basic criterion, and these are applicable due to the service model, the criterion is not met and a deviation is to be noted by the auditor."}],"title":"PI-02 Additional Complement 01AC"},{"id":"pi-02-02ac","class":"additional-complement","parts":[{"id":"pi-02-02ac_stmt","name":"statement","prose":"The cloud service provider also provides cloud service derived data to the cloud service customer upon termination of the contractual relationship. The provision of this data is also defined in the contractual agreements and includes the aspects specified in the basic criterion."},{"id":"pi-02-02ac_guidance-1","name":"guidance","prose":"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-like services, the cloud service 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 service customer has set up within its environment (e.g. configuration of networks, images of virtual machines and containers).\n\nWith SaaS, the cloud service customer typically relies on export functions provided by the cloud service provider. Data created by the cloud service 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\nLegal requirements can, for example, include the EU Data Act. In Germany, legal requirements for retention in particular 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.\n\nIf contractual agreements do not include the aspects listed in the basic criterion, and these are applicable due to the service model, the criterion is not met and a deviation is to be noted by the auditor."}],"title":"PI-02 Additional Complement 02AC"}]},{"id":"pi-03","parts":[{"id":"pi-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Secure Deletion of Data","controls":[{"id":"pi-03-01b","class":"basic","parts":[{"id":"pi-03-01b_stmt","name":"statement","prose":"The cloud service provider's procedures for deleting cloud service customer data, cloud service derived data and account data upon termination of the contractual relationship ensure compliance with the contractual agreements (cf. PI-02). Exceptions are only made if they are required by a valid court order or needed for the fulfilment of known future financial and legal obligations."},{"id":"pi-03-01b_guidance-1","name":"guidance","prose":"Suitable methods for data deletion are e.g. multiple overwriting or deletion of the encryption key."}],"title":"PI-03 Basic 01B"},{"id":"pi-03-02b","class":"basic","parts":[{"id":"pi-03-02b_stmt","name":"statement","prose":"The deletion procedures prevent recovery by forensic means that comply with the established rules of technology."},{"id":"pi-03-02b_guidance-1","name":"guidance","prose":"Suitable methods for data deletion are e.g. multiple overwriting or deletion of the encryption key."}],"title":"PI-03 Basic 02B"},{"id":"pi-03-03b","class":"basic","parts":[{"id":"pi-03-03b_stmt","name":"statement","prose":"The deletion of the cloud service customer data, cloud service derived data and account data is documented in a manner that enables the cloud service customer to obtain proof of the deletion of its data."}],"title":"PI-03 Basic 03B"}]}]},{"id":"dev","title":"Procurement, Development and Modification of Information Systems (DEV)","controls":[{"id":"dev-01","title":"Policies for the Development/Procurement of System Components","controls":[{"id":"dev-01-01b","class":"basic","parts":[{"id":"dev-01-01b_stmt","name":"statement","prose":"Policies and procedures with technical and organisational measures for the secure development of system components of the cloud service are documented, communicated and provided in accordance with SP-01.\n\nThe policies and procedures 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\n1. Security and quality in software development (requirements, design, implementation, testing and verification), including the existence of a security by design principle, enforcing the consideration of information security requirements in the software development phase;\n2. Security and quality in software deployment (including continuous delivery);\n3. Security and quality in operation (reaction to identified faults and vulnerabilities); and\n4. Secure coding standards and practices (reduction of vulnerabilities being introduced to the code)."},{"id":"dev-01-01b_guidance-1","name":"guidance","prose":"The software provision can be carried out e.g. with Continuous Delivery methods.\n\nAccepted standards and methods for secure development are, for example:\n\n1. ISO/IEC 27034; and\n2. OWASP Secure Software Development Lifecycle (S-SDLC).\n\n\n\nMinimisation of customer data access during operation can be supported by following robust security models, such as Zero Trust, during cloud architecture development. Furthermore, aspects such as limiting data interfaces, API calls and access as well as ensuring end-to-end-encryption from transit to storage are relevant considerations.\n\nFor quality assurance in software development, the following can be considered to be relevant processes:\n\n1. Planning and definition of quality objectives: Definition of quality requirements based on customer needs and objectives, taking into account the requirements of the cloud system to be developed;\n2. Design phase: Carrying out design reviews and inspections of the cloud service to ensure that the design meets the quality requirements;\n3. Development phase: Use of code reviews and pair programming to ensure code quality. Use of static analysis tools to check the code for potential errors and violations of coding standards;\n4. Testing phase: Execution (automated where possible) of various types of tests (e.g. unit tests, integration tests, system tests, acceptance tests) to ensure the functionality and quality of the software;\n5. Integration and continuous integration (CI): Integration of the various software components and continuous checking of the integrations through automated builds and tests. Use of CI/CD pipelines to ensure that the code is regularly integrated and tested;\n6. Release and deployment: Preparation and implementation of the software release in accordance with defined quality standards; and\n7. Maintenance and continuous improvement: Monitoring the software in operation to ensure that it continues to meet the quality requirements. This includes post release activities such as bug fixing and performance optimisation processes. Additionally, post-mortem analyses should be performed to learn from incidents and optimise processes for future releases.\n\nAn accepted standard and a method for quality in development processes is, for example, Google Site Reliability Engineering (SRE).\n\nThe scope of the DEV criteria and the requirements within includes not only the development of software applications but also platforms, virtual infrastructure, and other system components."}],"title":"DEV-01 Basic 01B"},{"id":"dev-01-02b","class":"basic","parts":[{"id":"dev-01-02b_stmt","name":"statement","prose":"Guidelines for the secure development of the cloud service define principles to ensure the system architecture and software operated by the cloud service provider within the production environment are designed in such a way that access to cloud service customer data by the cloud service provider is minimised wherever possible."}],"title":"DEV-01 Basic 02B"},{"id":"dev-01-03b","class":"basic","parts":[{"id":"dev-01-03b_stmt","name":"statement","prose":"The cloud service provider defines measures to enforce the specified standards and guidelines as part of the policies and procedures for the secure development of system components of the cloud service."}],"title":"DEV-01 Basic 03B"},{"id":"dev-01-01ac","class":"additional-complement","parts":[{"id":"dev-01-01ac_stmt","name":"statement","prose":"In procurement, products are preferred which have been certified according to the 'Common Criteria for Information Technology Security Evaluation' (short: Common Criteria - CC) Evaluation Assurance Level EAL 4. If non-certified products are to be procured instead of available certified products, a risk assessment is carried out in accordance with OIS-07."},{"id":"dev-01-01ac_guidance-1","name":"guidance","prose":"The software provision can be carried out e.g. with Continuous Delivery methods.\n\nAccepted standards and methods for secure development are, for example:\n\n1. ISO/IEC 27034; and\n2. OWASP Secure Software Development Lifecycle (S-SDLC).\n\n\n\nMinimisation of customer data access during operation can be supported by following robust security models, such as Zero Trust, during cloud architecture development. Furthermore, aspects such as limiting data interfaces, API calls and access as well as ensuring end-to-end-encryption from transit to storage are relevant considerations.\n\nFor quality assurance in software development, the following can be considered to be relevant processes:\n\n1. Planning and definition of quality objectives: Definition of quality requirements based on customer needs and objectives, taking into account the requirements of the cloud system to be developed;\n2. Design phase: Carrying out design reviews and inspections of the cloud service to ensure that the design meets the quality requirements;\n3. Development phase: Use of code reviews and pair programming to ensure code quality. Use of static analysis tools to check the code for potential errors and violations of coding standards;\n4. Testing phase: Execution (automated where possible) of various types of tests (e.g. unit tests, integration tests, system tests, acceptance tests) to ensure the functionality and quality of the software;\n5. Integration and continuous integration (CI): Integration of the various software components and continuous checking of the integrations through automated builds and tests. Use of CI/CD pipelines to ensure that the code is regularly integrated and tested;\n6. Release and deployment: Preparation and implementation of the software release in accordance with defined quality standards; and\n7. Maintenance and continuous improvement: Monitoring the software in operation to ensure that it continues to meet the quality requirements. This includes post release activities such as bug fixing and performance optimisation processes. Additionally, post-mortem analyses should be performed to learn from incidents and optimise processes for future releases.\n\nAn accepted standard and a method for quality in development processes is, for example, Google Site Reliability Engineering (SRE).\n\nThe scope of the DEV criteria and the requirements within includes not only the development of software applications but also platforms, virtual infrastructure, and other system components."}],"title":"DEV-01 Additional Complement 01AC"}]},{"id":"dev-02","title":"Outsourcing of the Development","controls":[{"id":"dev-02-01b","class":"basic","parts":[{"id":"dev-02-01b_stmt","name":"statement","prose":"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 service organisation:\n\n1. Security in software development (requirements, design, implementation, tests and verifications) in accordance with recognised standards and methods, ensuring a security level equivalent to that of the cloud service provider's internal development;\n2. Acceptance testing of the quality of the services provided in accordance with the agreed functional and non-functional requirements; and\n3. Providing evidence that sufficient verifications have been carried out to rule out the existence of known vulnerabilities."},{"id":"dev-02-01b_guidance-1","name":"guidance","prose":"Outsourced development in the sense of the basic criterion refers to the development of system components used specifically for the cloud service, by a service organisation of the cloud service provider. The development takes place according to the processes of the service organisation.\n\nThe risks that may arise and should be taken into account can, but do not have to, include:\n\n1. Risks that may result from the service organisation managing source code without adequate controls, including unauthorised modifications, insufficient version control, or inadequate protection against loss or theft of intellectual property;\n2. Risks that may result from the service organisation granting access to source code to the cloud service provider or to third-party evaluators, including unauthorised disclosure, loss of confidentiality, or inadequate controls governing how such access is managed and restricted;\n3. Risks that may result from inadequate personnel screening, insufficient background checks, lack of security awareness training, or high staff turnover within the service organisation, including insider threats or uncontrolled loss of sensitive knowledge;\n4. Risks that may result from granting the service organisation access to internal development, test or preproduction environments, including excessive privileges, insufficient access controls, or inadequate logging and monitoring of such access; and\n5. Risks that may result from the service organisation subcontracting parts of the service without adequate security controls in place, including insufficient contractual security requirements imposed on subcontractors or lack of transparency regarding the composition of the supply chain.\n\nThe purchase of software available on the market as well as the integration of external personnel into the processes of the cloud service provider do not constitute outsourcing in the sense of this basic criterion."}],"title":"DEV-02 Basic 01B"},{"id":"dev-02-02b","class":"basic","parts":[{"id":"dev-02-02b_stmt","name":"statement","prose":"Before outsourcing the development of the cloud service or components thereof, the cloud service provider conducts a risk assessment according to SSO-02 that takes into account at least the following aspects:\n\n1. Management of source code by the service organisation;\n2. Accessability of source code to the cloud service provider;\n3. Human resource procedures implemented by the service organisation;\n4. Required access to the development, test and preproduction environments of the cloud service provider; and\n5. Management of subcontractors engaged by the service organisation."},{"id":"dev-02-02b_guidance-1","name":"guidance","prose":"Outsourced development in the sense of the basic criterion refers to the development of system components used specifically for the cloud service, by a service organisation of the cloud service provider. The development takes place according to the processes of the service organisation.\n\nThe risks that may arise and should be taken into account can, but do not have to, include:\n\n1. Risks that may result from the service organisation managing source code without adequate controls, including unauthorised modifications, insufficient version control, or inadequate protection against loss or theft of intellectual property;\n2. Risks that may result from the service organisation granting access to source code to the cloud service provider or to third-party evaluators, including unauthorised disclosure, loss of confidentiality, or inadequate controls governing how such access is managed and restricted;\n3. Risks that may result from inadequate personnel screening, insufficient background checks, lack of security awareness training, or high staff turnover within the service organisation, including insider threats or uncontrolled loss of sensitive knowledge;\n4. Risks that may result from granting the service organisation access to internal development, test or preproduction environments, including excessive privileges, insufficient access controls, or inadequate logging and monitoring of such access; and\n5. Risks that may result from the service organisation subcontracting parts of the service without adequate security controls in place, including insufficient contractual security requirements imposed on subcontractors or lack of transparency regarding the composition of the supply chain.\n\nThe purchase of software available on the market as well as the integration of external personnel into the processes of the cloud service provider do not constitute outsourcing in the sense of this basic criterion."}],"title":"DEV-02 Basic 02B"},{"id":"dev-02-01ac","class":"additional-complement","parts":[{"id":"dev-02-01ac_stmt","name":"statement","prose":"The cloud service provider documents and implements a procedure that enables the supervision and control of the outsourced development activity to ensure that it complies with the secure development policy of the cloud service provider, and that the security level achieved through it matches the security level achieved through internal development."}],"title":"DEV-02 Additional Complement 01AC"},{"id":"dev-02-02ac","class":"additional-complement","parts":[{"id":"dev-02-02ac_stmt","name":"statement","prose":"When a change contains work from outsourced development, the cloud service provider's personnel runs the tests needed to decide whether the change can be deployed."}],"title":"DEV-02 Additional Complement 02AC"}]},{"id":"dev-03","title":"Policies for Changes to System Components","controls":[{"id":"dev-03-01b","class":"basic","parts":[{"id":"dev-03-01b_stmt","name":"statement","prose":"Policies and procedures with procedures and technical safeguards for change management of system components of the cloud service are documented, communicated and provided according to SP-01 with regard to the following aspects:\n\n1. 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;\n2. Requirements for the performance and documentation of tests;\n3. Requirements for segregation of duties during development, testing and release of changes;\n4. Requirements for the proper information of cloud service customers about the type and scope of the change as well as the resulting obligations to cooperate in accordance with the contractual agreements;\n5. Requirements for the documentation of changes in system, operational and user documentation;\n6. Requirements for the implementation and documentation of emergency changes such that - as far as reasonably possible - they comply with the same level of security as normal changes;\n7. Requirements for the handling of unexpected effects of those changes, including corrective actions;\n8. Requirements for the increased testing for the development of security features that implement technical mechanisms and safeguards; and\n9. Requirements for managing exceptions, including emergency changes, to ensure related risks are appropriately mitigated."},{"id":"dev-03-01b_guidance-1","name":"guidance","prose":"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 also fall under this criterion and should also undergo a specified procedure, as they are necessary for effective separation of cloud service customers.\n\nChanges to the container environments, including the management of container images and versions, should also go through a regulated process.\n\nPersonnel and system components receive authorisation to approve changes in accordance with the requirements for access and access authorisations (cf. IAM-01) via a specified procedure (cf. IAM-02). Relevant information includes descriptions of e.g. new functions.\n\nThe cloud service customer's obligations to cooperate can define that, e.g. the cloud service customer has to carry out certain tests.\n\nA centralised change management process is not mandatory. The cloud service provider has the flexibility to adopt change management practices that best fit its operational needs, including agile methods, as long as they adhere to the procedures and technical safeguards."}],"title":"DEV-03 Basic 01B"}]},{"id":"dev-04","title":"Safety Training and Awareness Programme Regarding Continuous Software Delivery and Associated Systems, Components or Tools","controls":[{"id":"dev-04-01b","class":"basic","parts":[{"id":"dev-04-01b_stmt","name":"statement","prose":"The cloud service provider provides a training programme for regular, role-based security training and awareness for internal and external personnel on standards and methods for:\n\n1. Secure software development and provision as well as on how to use the tools used for this purpose; and\n2. Risks linked to malicious code and best practices to reduce the impact of an infection."},{"id":"dev-04-01b_guidance-1","name":"guidance","prose":"This is a specialised criteria for safety training and awareness programmes for a particular target group. In HR-03, general properties of such trainings and programmes are defined."}],"title":"DEV-04 Basic 01B"},{"id":"dev-04-02b","class":"basic","parts":[{"id":"dev-04-02b_stmt","name":"statement","prose":"The programme is regularly reviewed and updated with regard to the applicable policies and procedures, the assigned roles and responsibilities and the tools used."}],"title":"DEV-04 Basic 02B"}]},{"id":"dev-05","title":"Design Documentation for Security Features","controls":[{"id":"dev-05-01b","class":"basic","parts":[{"id":"dev-05-01b_stmt","name":"statement","prose":"Design documentation for security features is based on a security analysis of the adequacy and planned effectiveness of the features. A specification of expected inputs, outputs and possible errors is included in the documentation."},{"id":"dev-05-01b_guidance-1","name":"guidance","prose":"Security features are typically features that control confidentiality (e.g. via integrating cryptography), integrity (e.g. via introducing check-sums or validating input data), availability (e.g. via redundancy or resiliency), authentication (e.g. via MFA or secure session management) and authorisation (e.g. via different roles). They usually follow from threat modelling and risk assessment. Ideally, security features are an integral part of the software development process and not additions made only after new software features have been created."}],"title":"DEV-05 Basic 01B"}]},{"id":"dev-06","title":"Risk Assessment, Categorisation and Prioritisation of Changes","controls":[{"id":"dev-06-01b","class":"basic","parts":[{"id":"dev-06-01b_stmt","name":"statement","prose":"In accordance with the applicable policies, changes are subject to a risk assessment evaluating its potential impact on the overall cloud service in scope. In addition, when multiple changes are implemented concurrently, their mutual interactions and cumulative effects are also subject to the risk assessment in order to identify potential conflicts or dependencies. All identified risks and dependencies are categorised and prioritised accordingly."}],"title":"DEV-06 Basic 01B"},{"id":"dev-06-02b","class":"basic","parts":[{"id":"dev-06-02b_stmt","name":"statement","prose":"If the risk associated to a planned change is high, appropriate mitigation measures are taken before deploying the change in the cloud service's production environment."}],"title":"DEV-06 Basic 02B"},{"id":"dev-06-01ac","class":"additional-complement","parts":[{"id":"dev-06-01ac_stmt","name":"statement","prose":"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 service 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. This does not include changes without an effect on the service usage or security posture of the service."}],"title":"DEV-06 Additional Complement 01AC"}]},{"id":"dev-07","parts":[{"id":"dev-07-corresponding","name":"corresponding","prose":"Where changes are to be tested by the cloud service customers in accordance with the contractual agreements prior to deployment in the production environment, the cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Testing Changes","controls":[{"id":"dev-07-01b","class":"basic","parts":[{"id":"dev-07-01b_stmt","name":"statement","prose":"Changes to the cloud service are subject to appropriate testing according to documented test procedures during software development and deployment."},{"id":"dev-07-01b_guidance-1","name":"guidance","prose":"Tests should be used that contribute to the quality assurance of the software development as well as to the security of the cloud service.      \n\nThe errors and vulnerabilities identified in tests can be assessed, for example, according to the Common Vulnerability Scoring System (CVSS)."},{"id":"dev-07-01b_guidance-2","name":"guidance","prose":"Test procedures for software assets can be static (SAST), dynamic (DAST) or interactive (IAST)."}],"title":"DEV-07 Basic 01B"},{"id":"dev-07-02b","class":"basic","parts":[{"id":"dev-07-02b_stmt","name":"statement","prose":"The 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 established rules of technology. Cloud service customers are involved into the tests in accordance with the contractual requirements."}],"title":"DEV-07 Basic 02B"},{"id":"dev-07-03b","class":"basic","parts":[{"id":"dev-07-03b_stmt","name":"statement","prose":"Before using cloud service customer data for tests, the cloud service provider first obtains approval from that cloud service customer and anonymises the cloud service customer data. The cloud service provider ensures the confidentiality of the data during the whole process."}],"title":"DEV-07 Basic 03B"},{"id":"dev-07-04b","class":"basic","parts":[{"id":"dev-07-04b_stmt","name":"statement","prose":"The security features of the cloud service are subject to tests that fully cover the security features' specification (cf. DEV-05), including all specified error conditions. The documentation of these tests covers at least the following aspects:\n\n1. A description of the test;\n2. The initial conditions;\n3. The expected outcome; and\n4. Procedures for running the test."}],"title":"DEV-07 Basic 04B"},{"id":"dev-07-05b","class":"basic","parts":[{"id":"dev-07-05b_stmt","name":"statement","prose":"The 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."}],"title":"DEV-07 Basic 05B"},{"id":"dev-07-01ac","class":"additional-complement","parts":[{"id":"dev-07-01ac_stmt","name":"statement","prose":"Pre-launch penetration tests are carried out during the test phase of the cloud service in accordance with the penetration test framework (cf. OPS-22 additional criterion). The severity of identified vulnerabilities is assessed according to defined criteria and actions for timely remediation or mitigation are initiated."},{"id":"dev-07-01ac_guidance-1","name":"guidance","prose":"Tests should be used that contribute to the quality assurance of the software development as well as to the security of the cloud service.      \n\nThe errors and vulnerabilities identified in tests can be assessed, for example, according to the Common Vulnerability Scoring System (CVSS)."}],"title":"DEV-07 Additional Complement 01AC"}]},{"id":"dev-08","title":"Logging of Changes","controls":[{"id":"dev-08-01b","class":"basic","parts":[{"id":"dev-08-01b_stmt","name":"statement","prose":"System components for version control and software deployment that are used to manage changes to system components of the cloud service in the production environment are subject to a role and rights framework according to IAM-01 and authorisation mechanisms."}],"title":"DEV-08 Basic 01B"},{"id":"dev-08-02b","class":"basic","parts":[{"id":"dev-08-02b_stmt","name":"statement","prose":"The configuration of these system components ensures that all changes performed by the cloud service provider to system components in the production environment are recorded and can be traced back to the individuals or system components contributing to their development, deployment or implementation."},{"id":"dev-08-02b_guidance-1","name":"guidance","prose":"If the change has external contribution (e.g. use of third-party products, libraries), tracing back individual changes in the development is often not possible. In that case it is sufficient to record the external contribution in the software component list or Software Bill of Materials (SBOM, cf. DEV-13.01B). In addition to that, depending on the nature of the external contribution, the criterion for Outsourcing of the Development (cf. DEV-02) and the criteria for Control and Monitoring of Service Providers and Suppliers (SSO) may apply."}],"title":"DEV-08 Basic 02B"},{"id":"dev-08-01ac","class":"additional-complement","parts":[{"id":"dev-08-01ac_stmt","name":"statement","prose":"The cloud service provider enforces the role and rights framework by monitoring the changes made to system components of the cloud service in the production environment. Timely and appropriate remediation measures address any deviations identified during monitoring."}],"title":"DEV-08 Additional Complement 01AC"}]},{"id":"dev-09","title":"Version Control","controls":[{"id":"dev-09-01b","class":"basic","parts":[{"id":"dev-09-01b_stmt","name":"statement","prose":"The cloud service provider uses a version control system that adequately ensures the confidentiality, integrity and authenticity of the source code during all development stages."}],"title":"DEV-09 Basic 01B"},{"id":"dev-09-02b","class":"basic","parts":[{"id":"dev-09-02b_stmt","name":"statement","prose":"Version control procedures track dependencies of individual changes and attribute each change to individual contributors. The version control procedures are capable of restoring affected system components back to a previous state."}],"title":"DEV-09 Basic 02B"},{"id":"dev-09-03b","class":"basic","parts":[{"id":"dev-09-03b_stmt","name":"statement","prose":"Version control covers all internally and externally developed software, configurations and third party commercial products under the responsibility of the cloud service provider."}],"title":"DEV-09 Basic 03B"},{"id":"dev-09-01ac","class":"additional-complement","parts":[{"id":"dev-09-01ac_stmt","name":"statement","prose":"Version control procedures provide appropriate safeguards to ensure that the integrity and availability of cloud service customer data is not compromised when system components are restored back to their previous state."}],"title":"DEV-09 Additional Complement 01AC"},{"id":"dev-09-02ac","class":"additional-complement","parts":[{"id":"dev-09-02ac_stmt","name":"statement","prose":"The cloud service provider keeps a record of all deployed software versions and system configurations. This record enables the recreation of a previously implemented environment in a test environment.\n\nThe retention time for this history is risk-based (cf. OIS-07), defined in the policy for version control and aligned to the support life cycle of the cloud service."}],"title":"DEV-09 Additional Complement 02AC"}]},{"id":"dev-10","parts":[{"id":"dev-10-corresponding","name":"corresponding","prose":"Where changes are to be approved by the cloud service customers in accordance with the contractual agreements before they are made available in the production environment, the cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Approvals for Provision in the Production Environment","controls":[{"id":"dev-10-01b","class":"basic","parts":[{"id":"dev-10-01b_stmt","name":"statement","prose":"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 service customers in the production environment."},{"id":"dev-10-01b_guidance-1","name":"guidance","prose":"The definitions for criterion DEV-03 apply."}],"title":"DEV-10 Basic 01B"},{"id":"dev-10-02b","class":"basic","parts":[{"id":"dev-10-02b_stmt","name":"statement","prose":"Cloud service customers are involved in the release according to contractual agreements."},{"id":"dev-10-02b_guidance-1","name":"guidance","prose":"If the contractual agreements do not foresee customer involvement of the approval, this should be clearly stated in the contractual agreements in order to fulfil this criterion."}],"title":"DEV-10 Basic 02B"},{"id":"dev-10-01ac","class":"additional-complement","parts":[{"id":"dev-10-01ac_stmt","name":"statement","prose":"The approval process is monitored. Timely and appropriate remediation measures address any deviations identified during monitoring."}],"title":"DEV-10 Additional Complement 01AC"}]},{"id":"dev-11","title":"Protection of Development and Test Environments","controls":[{"id":"dev-11-01b","class":"basic","parts":[{"id":"dev-11-01b_stmt","name":"statement","prose":"Development and test environments under the responsibility of the cloud service provider undergo a risk assesssment (cf. OIS-07) and are protected with appropriate security measures against identified risks. This also includes extending the backup plan (cf. OPS-06) to the necessary parts of those environments."},{"id":"dev-11-01b_guidance-1","name":"guidance","prose":"Note that the backup policies and procedures (cf. OPS-06) are preceded by a risk assessment and does not need to include all elements of those environments, but only the ones considered necessary based on the risk assessment. Some parts can be build from scatch more easily than backing them up."}],"title":"DEV-11 Basic 01B"}]},{"id":"dev-12","title":"Separation of Environments","controls":[{"id":"dev-12-01b","class":"basic","parts":[{"id":"dev-12-01b_stmt","name":"statement","prose":"Production environments are physically or logically separated from test or development environments to prevent unauthorised access to cloud service customer data, the spread of malware, or unintended changes to system components. Cloud service customer data contained in the production environments is not used in test or development environments, unless explicitly approved by cloud service customers, in order not to compromise their confidentiality."}],"title":"DEV-12 Basic 01B"},{"id":"dev-12-02b","class":"basic","parts":[{"id":"dev-12-02b_stmt","name":"statement","prose":"Unless unavoidable, the cloud service provider does not reuse the cryptographic secret and private keys and other secrets used in production environments in other, non-production environments. Any unavoidable reuse of the cryptographic secret and private keys between production and non-production environments is documented and justified in accordance with the process for handling exceptions (cf. SP-03) and the risk management procedures (cf. OIS-07)."}],"title":"DEV-12 Basic 02B"}]},{"id":"dev-13","title":"Transparency about Software Components","controls":[{"id":"dev-13-01b","class":"basic","parts":[{"id":"dev-13-01b_stmt","name":"statement","prose":"The cloud service provider ensures that, as part of the software development process, a list of software components is created, maintained, and kept up-to-date for every developed or integrated software component."},{"id":"dev-13-01b_guidance-1","name":"guidance","prose":"This criteria can be fulfilled via a sufficiently detailed list of software components. Sufficient detail means that the list allows the cloud service provider to identify all cloud services affected by any given known vulnerability. This criteria can also be fulfilled via a Software Bill of Materials (SBOM). The established rules of technology regarding the creation, maintenance, and utilisation of SBOMs, including their components and formats, is described in the current version of the BSI Technical Guideline TR-03183-2. Automated tools for generating, maintaining, and validating software component lists or SBOMs are recommended to ensure accuracy and integration into security and vulnerability management processes. Please note that it may not be necessary to store every version of the SBOM - just like in the other development processes for components - as long as the cloud service provider is able to keep track of the changes."}],"title":"DEV-13 Basic 01B"},{"id":"dev-13-02b","class":"basic","parts":[{"id":"dev-13-02b_stmt","name":"statement","prose":"The cloud service provider maintains a list of software components for integrated software components as well, except where such information is not available and cannot be produced with reasonable effort. The risk from these exceptions is treated according to SP-03."},{"id":"dev-13-02b_guidance-1","name":"guidance","prose":"This subcriterion only applies to integrated software components. If integrated software components are e.g. open-source and if this criterion is fulfilled via SBOMs, there may be cases where a SBOM is not available and cannot be produced with reasonable effort. Reasonable implies that changing this component to one that has a SBOM is economically not feasible. However, the risks from these exceptions are treated within the exception process (cf. SP-03)."}],"title":"DEV-13 Basic 02B"}]},{"id":"dev-14","title":"Secure Use of Third Party Hardware and Software","controls":[{"id":"dev-14-01b","class":"basic","parts":[{"id":"dev-14-01b_stmt","name":"statement","prose":"Policies and procedures for the use of third party and open source software are documented, communicated and provided in accordance with SP-01."},{"id":"dev-14-01b_guidance-1","name":"guidance","prose":"The policy should consider, where applicable, the same aspects as the policy for the proper and secure use of assets (cf. AM-05)."}],"title":"DEV-14 Basic 01B"},{"id":"dev-14-02b","class":"basic","parts":[{"id":"dev-14-02b_stmt","name":"statement","prose":"For the hardware and software products (cf. DEV-13) used in the development of the cloud service, a list of dependencies to those products is maintained."}],"title":"DEV-14 Basic 02B"},{"id":"dev-14-03b","class":"basic","parts":[{"id":"dev-14-03b_stmt","name":"statement","prose":"Only trusted sources are used to retrieve third party software. Whenever possible, the authenticity of the software is verified."}],"title":"DEV-14 Basic 03B"},{"id":"dev-14-01ac","class":"additional-complement","parts":[{"id":"dev-14-01ac_stmt","name":"statement","prose":"In procurement for the development of the cloud service, the cloud service provider performs a risk assessment in accordance with OIS-07 for every hardware and software product."}],"title":"DEV-14 Additional Complement 01AC"}]},{"id":"dev-15","title":"Exceptions to the Change Management Process","controls":[{"id":"dev-15-01b","class":"basic","parts":[{"id":"dev-15-01b_stmt","name":"statement","prose":"The cloud service provider's change management process implements procedures for managing exceptions, including emergency changes, to ensure related risks are appropriately mitigated."},{"id":"dev-15-01b_guidance-1","name":"guidance","prose":"This criteria refers mainly to the exception process demanded in SP-03, although all exceptions from the standard procedure for changes are meant here."}],"title":"DEV-15 Basic 01B"}]}]},{"id":"sso","title":"Control and Monitoring of Service Providers and Suppliers (SSO)","controls":[{"id":"sso-01","title":"Policies and Procedures for Controlling and Monitoring Service Organisations","controls":[{"id":"sso-01-01b","class":"basic","parts":[{"id":"sso-01-01b_stmt","name":"statement","prose":"Policies and procedures for controlling and monitoring service organisations whose services contribute to the development or operation of the cloud service are documented, communicated and provided in accordance with SP-01 with respect to the following aspects:\n\n1. Requirements for the assessment of risks resulting from the procurement of third-party services;\n2. Requirements for the classification of service organisations based on the risk assessment by the cloud service provider and the determination of whether the service organisation is a subservice organisation;\n3. Information security requirements for the processing, storage or transmission of information by service organisations based on the established rules of technology, and under consideration of the criteria in this catalogue;\n4. Information security awareness and training requirements for personnel;\n5. Applicable legal and regulatory requirements;\n6. Requirements for dealing with vulnerabilities, security incidents and incidents;\n7. Specifications for the contractual agreement of these requirements;\n8. Specifications for the monitoring of these requirements; and\n9. Specifications for applying these requirements also to subservice organisations used by the service organisations, insofar as the services provided by these subservice organisations also contribute to the development or operation of the cloud service."},{"id":"sso-01-01b_guidance-1","name":"guidance","prose":"The basic criterion applies to all service organisations of the cloud service provider, regardless of applying the 'inclusive' or 'carve-out method'. The additional criterion applies only to those of the service organisations that are considered to be subservice organisations. See section 'Consideration of Subservice Organisations'.\n\nReports by independent auditors on the suitability of the design and operating effectiveness of their service-related system of internal control are, for example, attestation reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5.\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 subservice organisations, these regulations remain unaffected by the C5 criteria."}],"title":"SSO-01 Basic 01B"},{"id":"sso-01-01ac","class":"additional-complement","parts":[{"id":"sso-01-01ac_stmt","name":"statement","prose":"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 system of internal control system that allow the cloud service provider to determine whether the subservice organisation designed and operated controls that are commensurate with the expected complementary subservice organisation controls (CSOC)."},{"id":"sso-01-01ac_guidance-1","name":"guidance","prose":"The basic criterion applies to all service organisations of the cloud service provider, regardless of applying the 'inclusive' or 'carve-out method'. The additional criterion applies only to those of the service organisations that are considered to be subservice organisations. See section 'Consideration of Subservice Organisations'.\n\nReports by independent auditors on the suitability of the design and operating effectiveness of their service-related system of internal control are, for example, attestation reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5.\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 subservice organisations, these regulations remain unaffected by the C5 criteria."}],"title":"SSO-01 Additional Complement 01AC"},{"id":"sso-01-02ac","class":"additional-complement","parts":[{"id":"sso-01-02ac_stmt","name":"statement","prose":"In case no such reports can be provided, the cloud service provider agrees appropriate information and audit rights to assess the design and operations of the service-related system of internal control regarding the expected CSOC."}],"title":"SSO-01 Additional Complement 02AC"}]},{"id":"sso-02","title":"Risk Assessment of Service Organisations","controls":[{"id":"sso-02-01b","class":"basic","parts":[{"id":"sso-02-01b_stmt","name":"statement","prose":"Service organisations of the cloud service provider undergo a risk assessment in accordance with the policies and procedures for the control and monitoring of service organisations prior to contributing to the development or operation of the cloud service.\n\nThe risk assessment includes the identification, analysis, evaluation, treatment and documentation of risks with regard to the following aspects:\n\n1. Protection needs regarding the confidentiality, integrity, availability and authenticity of cloud service customer data, cloud service derived data, cloud service provider data and account data processed, stored or transmitted by the service organisation;\n2. Impact of a protection breach on the provision of the cloud service;\n3. The cloud service provider's dependence on the service organisation for the scope, complexity and uniqueness of the provided service, including the consideration of possible alternatives;\n4. Complementary subservice organisation controls (CSOCs) assumed in the design of cloud service provider's controls to meet the applicable C5 criteria;\n5. Deviations regarding the design and operation of CSOCs assumed at service organisations considered as subservice organisations and mitigating measures by the cloud service provider to address such deviations; \n6. The ability of the cloud service provider to diversify sources of supply and limit vendor lock-in;\n7. Whether service organisations used by the cloud service provider themselves use subcontracted service organisations (subcontractors) that contribute to the development and operation of the cloud service; and\n8. If service organisations used by the cloud service provider themselves use subcontractors, the types of data processed by the subcontractors."},{"id":"sso-02-01b_guidance-1","name":"guidance","prose":"For assessing risks with service organisations, the cloud service provider can perform coordinated security risk assessments of specific critical ICT services, ICT systems or ICT products provided by service organisations. Apart from the aspects listed in this subcriterion, such a risk assessment should take into account technical and, where relevant, non-technical risk factors.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations')."}],"title":"SSO-02 Basic 01B"},{"id":"sso-02-02b","class":"basic","parts":[{"id":"sso-02-02b_stmt","name":"statement","prose":"The adequacy of the risk assessment is reviewed regularly, at least annually, by qualified personnel of the cloud service provider during service usage."}],"title":"SSO-02 Basic 02B"}]},{"id":"sso-03","title":"Data Processing of Service Organisations","controls":[{"id":"sso-03-01b","class":"basic","parts":[{"id":"sso-03-01b_stmt","name":"statement","prose":"If the cloud service provider relies on assets from a supplier or on services from subservice organisations for the operation of the cloud service, it does not allow those suppliers or service organisations to access any cloud service customer data, cloud service derived data or account data. Exceptions are made only if the cloud service provider has performed a risk assessment according to OIS-07 on the possibility of cloud service customer data, cloud service derived data or account data being exposed."}],"title":"SSO-03 Basic 01B"},{"id":"sso-03-02b","class":"basic","parts":[{"id":"sso-03-02b_stmt","name":"statement","prose":"The cloud service provider obtains written authorisation of the customer prior to the processing of cloud service customer data, cloud service derived data or account data when engaging service organisations. This can be achieved by authorisation of the customer, per service organisation, or by way of a general pre-authorisation between the cloud service provider and the customer."},{"id":"sso-03-02b_guidance-1","name":"guidance","prose":"This subcriterion does not apply to cloud service derived data that does not contain any customer-owned data. Examples for such cloud service derived data include operational metrics or technical telemetry data."}],"title":"SSO-03 Basic 02B"},{"id":"sso-03-01as","class":"additional-sharpen","parts":[{"id":"sso-03-01as_stmt","name":"statement","prose":"If the cloud service provider relies on assets from a supplier or on services from subservice organisations for the operation of the cloud service, it does not allow those suppliers or service organisations to access any cloud service customer data, cloud service derived data or account data. Exceptions are made only if the cloud service provider has performed a risk assessment according to OIS-07 on the possibility of cloud service customer data, cloud service derived data or account data being exposed, and it is ensured that all operations requiring access to those data types are performed or supervised by authorised personnel (cf. HR-01)."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"SSO-03 Additional Sharpen 01AS"}]},{"id":"sso-04","title":"Directory of Service Organisations","controls":[{"id":"sso-04-01b","class":"basic","parts":[{"id":"sso-04-01b_stmt","name":"statement","prose":"The cloud service provider maintains a directory for controlling and monitoring the service organisations that contribute services to the delivery of the cloud service. The following information is maintained in the directory:\n\n1. Company name;\n2. Address of the head office;\n3. Applicable legal jurisdiction;\n4. Locations where cloud service customer data, cloud service derived data, cloud service provider data and account data is processed and stored;\n5. Responsible contact group/person at the service organisation;\n6. Responsible contact group/person at the cloud service provider;\n7. Description of the service;\n8. Classification based on the risk assessment;\n9. Beginning of service usage; and\n10. Proof of compliance with contractually agreed requirements."},{"id":"sso-04-01b_guidance-1","name":"guidance","prose":"It is not necessary to maintain a single central register in order to fulfil the basic criterion."}],"title":"SSO-04 Basic 01B"},{"id":"sso-04-02b","class":"basic","parts":[{"id":"sso-04-02b_stmt","name":"statement","prose":"The inventory is reviewed at least annually for completeness, accuracy and validity of the information."}],"title":"SSO-04 Basic 02B"}]},{"id":"sso-05","parts":[{"id":"sso-05-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 protection need of their data processed and stored in the cloud service whether further action should be taken to monitor and check these subservice organisations.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Monitoring of Compliance with Requirements","controls":[{"id":"sso-05-01b","class":"basic","parts":[{"id":"sso-05-01b_stmt","name":"statement","prose":"The cloud service provider monitors compliance with information security requirements and applicable legal and regulatory requirements in accordance with policies and procedures concerning controlling and monitoring of service organisation."},{"id":"sso-05-01b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 01B"},{"id":"sso-05-02b","class":"basic","parts":[{"id":"sso-05-02b_stmt","name":"statement","prose":"Monitoring includes a regular review of the following information to the extent that such information is to be provided by service organisations in accordance with the contractual agreements:\n\n1. Reports on the quality of the service provided;\n2. Certificates of the management systems' compliance with international standards;\n3. Records of the service organisations on the handling of vulnerabilities, security incidents and incidents;\n4. Independent third party reports on the design and operation of their service-related system of internal control; and\n5. If service organisations used by the cloud service provider themselves use subcontractors, the compliance of their subcontractors with relevant contractual, legal and regulatory requirements."},{"id":"sso-05-02b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."},{"id":"sso-05-02b_guidance-2","name":"guidance","prose":"When reviewing the information provided by the service organisation, the cloud service provider should distinguish between flawed information that was produced in good faith (such as reports about perceived security concerns that eventually turned out to be ill-founded), and deliberately false or malicious information.\n\nMonitoring of subcontractors can occur via audits, certifications and third party reports (cf. SSO-05) and may be performed by the service organisations of the cloud service provider. The cloud service provider remains responsible for reviewing the results of compliance monitoring and assessing the risk."}],"title":"SSO-05 Basic 02B"},{"id":"sso-05-03b","class":"basic","parts":[{"id":"sso-05-03b_stmt","name":"statement","prose":"The frequency of the monitoring corresponds to the classification of the service organisation based on the risk assessment conducted by the cloud service provider (cf. SSO-02)."},{"id":"sso-05-03b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 03B"},{"id":"sso-05-04b","class":"basic","parts":[{"id":"sso-05-04b_stmt","name":"statement","prose":"If a service organisation is considered to be a subservice organisation, the cloud service provider assesses this relationship and carries out appropriate procedures to ensure that the applicable C5 criteria are met. Appropriate procedures provide reasonable assurance: \n\n1. That the subservice organisation has designed and operated relevant controls; and\n2. That the subservice organisation's controls correspond to the expected complementary subservice organisation controls (CSOCs) assumed in the design of the cloud service providers controls."},{"id":"sso-05-04b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 04B"},{"id":"sso-05-05b","class":"basic","parts":[{"id":"sso-05-05b_stmt","name":"statement","prose":"Identified deviations are subjected to analysis, evaluation and treatment in accordance with the risk assessment of service organisations (cf. SSO-02)."},{"id":"sso-05-05b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 05B"},{"id":"sso-05-06b","class":"basic","parts":[{"id":"sso-05-06b_stmt","name":"statement","prose":"If a service organisation contributing to the provision of the cloud service undergoes a change that has a significant adverse effect on the cloud service provider's level of security, the cloud service provider communicates this to all of its cloud service customers without undue delay."},{"id":"sso-05-06b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 06B"},{"id":"sso-05-07b","class":"basic","parts":[{"id":"sso-05-07b_stmt","name":"statement","prose":"The cloud service provider establishes and documents a procedure to regularly review non-disclosure or confidentiality requirements for all service organisations involved in providing the cloud service. This procedure is implemented in practice, and the review is conducted at least once per year."},{"id":"sso-05-07b_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Basic 07B"},{"id":"sso-05-01ac","class":"additional-complement","parts":[{"id":"sso-05-01ac_stmt","name":"statement","prose":"The procedures for monitoring compliance with the requirements are supplemented by automatic procedures relating to the following aspects:\n\n1. Configuration of system components;\n2. Performance and availability of system components;\n3. Response time to incidents and security incidents; and\n4. Recovery time (time until completion of error handling)."},{"id":"sso-05-01ac_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Additional Complement 01AC"},{"id":"sso-05-02ac","class":"additional-complement","parts":[{"id":"sso-05-02ac_stmt","name":"statement","prose":"Identified violations and discrepancies are automatically reported to the responsible personnel or system components of the cloud service provider for prompt assessment and action."},{"id":"sso-05-02ac_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Additional Complement 02AC"},{"id":"sso-05-03ac","class":"additional-complement","parts":[{"id":"sso-05-03ac_stmt","name":"statement","prose":"The cloud service provider defines and implements a process for conducting periodic security assessments for all service organisations. The nature and scope of these security assessments correspond to the risk associated with each service organisation. These risk-based security assessments ensure that service organisations meet the required security standards and that any potential risks are identified and mitigated appropriately."},{"id":"sso-05-03ac_guidance-1","name":"guidance","prose":"Information obtained for monitoring of the design and operations of the service-related system of internal control typically includes reports in accordance with ISAE 3402, IDW PS 951, SOC 2 or BSI C5, ANSSI SecNumCloud or CSA CCM. Second party audits based on such frameworks may be useful here. For analysing BSI C5 reports in a structured manner, BSI has published an Excel-based evaluation guideline.\n\nIf such reports are provided by the service organisations, 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\n1. The scope and the validity respectively the period covered by the report;\n2. Modifications of the opinion, deviations/exceptions noted and management's response thereon;\n3. Complementary User Entity Controls (CUEC) to be designed and operated by the cloud service provider;\n4. Disclosed subservice organisations incl. any changes among those (e.g. additional subservice organisations); and\n5. Stated security incidents.\n\nInformation on CSOC has to be obtained for subservice organisations only. Not every service organisation is a subservice organisation, cf. section 'Consideration of Subservice Organisations'). Appropriate procedures may comprise the review of independent third party reports, or audit procedures performed by the cloud service provider at the subservice organisation.\n\nThe automated monitoring procedures outlined in the additional criterion are only applicable to service organisations for which monitoring automation is feasible based on the nature of the services provided to the cloud service provider."}],"title":"SSO-05 Additional Complement 03AC"}]},{"id":"sso-06","title":"Contract Termination Strategy for Service Organisations","controls":[{"id":"sso-06-01b","class":"basic","parts":[{"id":"sso-06-01b_stmt","name":"statement","prose":"The cloud service provider has defined and documented contract termination or exit strategies for the purchase of services where the risk assessment of the service organisations regarding the scope, complexity and uniqueness of the service provided resulted in a very high dependency (cf. Supplementary Information)."},{"id":"sso-06-01b_guidance-1","name":"guidance","prose":"A very high dependency can be assumed in particular if the purchased service is indispensable for the provision of the cloud service. This situation is the case if the cloud service provider:\n\n1. Provides the cloud service from data centres operated by service organisations; or\n2. Provides a SaaS service and uses the IaaS or PaaS of another cloud service provider.\n\nA very high dependency can also be assumed if the service cannot be obtained within one month from an alternative service organisation, as:\n\n1. It is unique on the market and no other service organisation can deliver it;\n2. It is strongly individualised by the service organisation and/or the cloud service provider;\n3. It cannot be supplied by any other service organisation in the required quality of service; or\n4. It requires specific knowledge that is only/mainly available to the current service organisation and not to the cloud service provider.\n\nExit strategies may vary in complexity based on the nature and degree of dependency of the cloud service on third party services and service organisations. Using a cloud service broker is an example of a complex scenario. Aspects listed in SSO-06.02B should be considered based on the results of the cloud service provider's risk assessment. Where a lower degree of dependency has been identified, exit strategies or individual aspects thereof are not mandatory in the sense of this criterion."}],"title":"SSO-06 Basic 01B"},{"id":"sso-06-02b","class":"basic","parts":[{"id":"sso-06-02b_stmt","name":"statement","prose":"Exit strategies are aligned with operational continuity plans and include the following aspects:\n\n1. Analysis of the potential costs, impacts, resources and timing of the transition of a purchased service to an alternative service organisation;\n2. Definition and allocation of roles, responsibilities and sufficient resources to perform the activities for a transition;\n3. Definition of success criteria for the transition; and\n4. Definition of indicators for monitoring the performance of services, which should initiate the withdrawal from the service if the results are unacceptable."},{"id":"sso-06-02b_guidance-1","name":"guidance","prose":"A very high dependency can be assumed in particular if the purchased service is indispensable for the provision of the cloud service. This situation is the case if the cloud service provider:\n\n1. Provides the cloud service from data centres operated by service organisations; or\n2. Provides a SaaS service and uses the IaaS or PaaS of another cloud service provider.\n\nA very high dependency can also be assumed if the service cannot be obtained within one month from an alternative service organisation, as:\n\n1. It is unique on the market and no other service organisation can deliver it;\n2. It is strongly individualised by the service organisation and/or the cloud service provider;\n3. It cannot be supplied by any other service organisation in the required quality of service; or\n4. It requires specific knowledge that is only/mainly available to the current service organisation and not to the cloud service provider.\n\nExit strategies may vary in complexity based on the nature and degree of dependency of the cloud service on third party services and service organisations. Using a cloud service broker is an example of a complex scenario. Aspects listed in SSO-06.02B should be considered based on the results of the cloud service provider's risk assessment. Where a lower degree of dependency has been identified, exit strategies or individual aspects thereof are not mandatory in the sense of this criterion."}],"title":"SSO-06 Basic 02B"}]},{"id":"sso-07","title":"Ensuring Transparency within Service Organisations","controls":[{"id":"sso-07-01b","class":"basic","parts":[{"id":"sso-07-01b_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains controls to ensure transparency within its service organisations with respect to the following aspects: \n\n1. Data flow and interfaces between the cloud service provider and service organisations used by the cloud service provider are documented, including measures regarding the secure transmission and access control for data shared with service organisations; and \n2. Cloud service customers are informed of service organisations used by the cloud service provider for development and operation of the cloud service and what type of data these service organisations and their subcontractors are processing.\n\nCloud service customers are informed which of the service organisations themselves use subcontractors to process cloud service customer data."},{"id":"sso-07-01b_guidance-1","name":"guidance","prose":"This criterion addresses the need for managing supply chain risks (e.g. service organisation vulnerabilities, data handling practices, compliance gaps or operational disruptions) and for those risks to be communicated to cloud service customers, enabling them to monitor and manage their own supply chain risks effectively."}],"title":"SSO-07 Basic 01B"},{"id":"sso-07-02b","class":"basic","parts":[{"id":"sso-07-02b_stmt","name":"statement","prose":"The cloud service provider documents this information and reviews its completeness, accuracy and validity at least annually."}],"title":"SSO-07 Basic 02B"},{"id":"sso-07-01as","class":"additional-sharpen","parts":[{"id":"sso-07-01as_stmt","name":"statement","prose":"The cloud service provider designs, implements and maintains controls to ensure transparency within its service organisations with respect to the following aspects: \n\n1. Data flow and interfaces between the cloud service provider and service organisations used by the cloud service provider are documented, including measures regarding the secure transmission and access control for data shared with service organisations; and \n2. Cloud service customers are informed of service organisations and their subcontractors used by the cloud service provider for development and operation of the cloud service and what type of data these service organisations and their subcontractors are processing.\n\nCloud service customers are informed which of the service organisations themselves use subcontractors to process cloud service customer data."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"SSO-07 Additional Sharpen 01AS"}]},{"id":"sso-08","title":"Controlling Exchanges with Suppliers of Functional Components","controls":[{"id":"sso-08-01b","class":"basic","parts":[{"id":"sso-08-01b_stmt","name":"statement","prose":"When functional components used for the provision of the cloud service may directly or indirectly access cloud service customer data, the cloud service provider defines and implements a policy according to SP-01 that does not allow a direct exchange between such components and their suppliers."},{"id":"sso-08-01b_guidance-1","name":"guidance","prose":"A supplier of a functional component is typically a service organisation of the cloud service provider. The authorisation for the transfer may be automated. Content provided by the supplier refers to updates of the functional components."}],"title":"SSO-08 Basic 01B"},{"id":"sso-08-02b","class":"basic","parts":[{"id":"sso-08-02b_stmt","name":"statement","prose":"In addition, procedures are defined and implemented according to SP-01 that require the cloud service provider to authorise any content provided by a supplier for its functional components or to be sent from a functional component to its supplier. The authorisation takes place before the content is transferred and for each transfer."},{"id":"sso-08-02b_guidance-1","name":"guidance","prose":"A supplier of a functional component is typically a service organisation of the cloud service provider. The authorisation for the transfer may be automated. Content provided by the supplier refers to updates of the functional components."}],"title":"SSO-08 Basic 02B"},{"id":"sso-08-03b","class":"basic","parts":[{"id":"sso-08-03b_stmt","name":"statement","prose":"When a procedure for authorising content before its transfer is automated, the cloud service provider implements it using a solution that maintains traces of: \n\n1. The operations that are proposed by the functional component's supplier;\n2. The verification that is performed to authorise the content before its transfer; and\n3. The transfers, both incoming and outgoing, that are effectively performed."},{"id":"sso-08-03b_guidance-1","name":"guidance","prose":"A supplier of a functional component is typically a service organisation of the cloud service provider. The authorisation for the transfer may be automated. Content provided by the supplier refers to updates of the functional components."}],"title":"SSO-08 Basic 03B"}]}]},{"id":"sim","title":"Security Incident Management (SIM)","controls":[{"id":"sim-01","parts":[{"id":"sim-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Policy for Security Incident Management","controls":[{"id":"sim-01-01b","class":"basic","parts":[{"id":"sim-01-01b_stmt","name":"statement","prose":"Policies, procedures and technical 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, escalation and root cause analysis of security incidents and creates interfaces to the incident management and business continuity management."}],"title":"SIM-01 Basic 01B"},{"id":"sim-01-02b","class":"basic","parts":[{"id":"sim-01-02b_stmt","name":"statement","prose":"The cloud service provider has set up a 'Computer Security Incident Response Team' (CSIRT), which contributes to the coordinated resolution of occurring security incidents."}],"title":"SIM-01 Basic 02B"},{"id":"sim-01-03b","class":"basic","parts":[{"id":"sim-01-03b_stmt","name":"statement","prose":"Communication channels with the cloud service customers are identified and defined and customers affected by security incidents are informed in a timely and appropriate manner."}],"title":"SIM-01 Basic 03B"},{"id":"sim-01-04b","class":"basic","parts":[{"id":"sim-01-04b_stmt","name":"statement","prose":"There are procedures as to how the data of a suspicious system can be collected in a conclusive manner in the event of a security incident."}],"title":"SIM-01 Basic 04B"}]},{"id":"sim-02","title":"Security Incident Response Plans","controls":[{"id":"sim-02-01b","class":"basic","parts":[{"id":"sim-02-01b_stmt","name":"statement","prose":"The cloud service provider has documented, approved and communicated one or more security incident response plans. The plans address all stages of incident response, including identification, containment, eradication, recovery, and lessons learned. They are approved by subject matter experts of the cloud service provider and communicated to all relevant stakeholders."},{"id":"sim-02-01b_guidance-1","name":"guidance","prose":"Relevant stakeholders in the sense of this criterion are those that need to know the incident response plan, for example due to their involvement in its execution or due to contractual or regulatory agreements."}],"title":"SIM-02 Basic 01B"},{"id":"sim-02-02b","class":"basic","parts":[{"id":"sim-02-02b_stmt","name":"statement","prose":"The plans are evaluated and updated at least annually or as necessary to reflect changes in the organisational structure or environment."}],"title":"SIM-02 Basic 02B"}]},{"id":"sim-03","title":"Processing of Security Incidents","controls":[{"id":"sim-03-01b","class":"basic","parts":[{"id":"sim-03-01b_stmt","name":"statement","prose":"Subject matter experts of the cloud service provider classify, prioritise and perform root-cause analyses for events that could constitute a security incident."}],"title":"SIM-03 Basic 01B"},{"id":"sim-03-02b","class":"basic","parts":[{"id":"sim-03-02b_stmt","name":"statement","prose":"The results of these root-cause analyses are documented, shared with relevant stakeholders, and used as part of evaluation and learning processes."}],"title":"SIM-03 Basic 02B"},{"id":"sim-03-03b","class":"basic","parts":[{"id":"sim-03-03b_stmt","name":"statement","prose":"If the cloud service provider determines that it requires external assistance for processing a security incident, it selects an incident response service based on their competence and trustworthiness or by following the recommendations of a national cybersecurity authority."}],"title":"SIM-03 Basic 03B"},{"id":"sim-03-04b","class":"basic","parts":[{"id":"sim-03-04b_stmt","name":"statement","prose":"A catalogue providing clear identification of information security incidents affecting cloud service customer data is maintained and used for the classification of information security incidents."}],"title":"SIM-03 Basic 04B"},{"id":"sim-03-05b","class":"basic","parts":[{"id":"sim-03-05b_stmt","name":"statement","prose":"The cloud service provider also uses the incident classification mechanism for the correlation of information security events, and assesses as well as classifies the correlated information security events according to their criticality."}],"title":"SIM-03 Basic 05B"},{"id":"sim-03-06b","class":"basic","parts":[{"id":"sim-03-06b_stmt","name":"statement","prose":"All documents and evidence that provide details on security incidents related to the cloud service are archived in a secure and tamper-proof manner, in line with criticality and regulatory requirements."},{"id":"sim-03-06b_guidance-1","name":"guidance","prose":"Regulatory requirements may necessitate maintaining a chain of custody to ensure that documents can be relied upon in legal proceedings."}],"title":"SIM-03 Basic 06B"},{"id":"sim-03-07b","class":"basic","parts":[{"id":"sim-03-07b_stmt","name":"statement","prose":"The analysis process provides sufficient traceability to understand root causes and attack progression, appropriate to the risk and impact of the security incident."}],"title":"SIM-03 Basic 07B"},{"id":"sim-03-01ac","class":"additional-complement","parts":[{"id":"sim-03-01ac_stmt","name":"statement","prose":"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)."}],"title":"SIM-03 Additional Complement 01AC"},{"id":"sim-03-02ac","class":"additional-complement","parts":[{"id":"sim-03-02ac_stmt","name":"statement","prose":"An integrated team of forensic/incident responder personnel, specifically qualified to preserve evidence and manage a chain of custody, is established or contracted for their services."}],"title":"SIM-03 Additional Complement 02AC"},{"id":"sim-03-03ac","class":"additional-complement","parts":[{"id":"sim-03-03ac_stmt","name":"statement","prose":"The cloud service provider verifies the application of incident management policies and procedures by monitoring the information security incident handling processes. Timely and appropriate remediation measures address any deviations identified during monitoring."}],"title":"SIM-03 Additional Complement 03AC"}]},{"id":"sim-04","parts":[{"id":"sim-04-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they receive notifications from the cloud service provider about security incidents that affect them and their resolution and that these notifications are timely forwarded to the entity responsible for handling them so that an appropriate response can be made.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Documentation and Reporting of Security Incidents","controls":[{"id":"sim-04-01b","class":"basic","parts":[{"id":"sim-04-01b_stmt","name":"statement","prose":"After a security incident has been processed, the solution is documented in accordance with the contractual agreements and the documentation is sent to the affected customers for final acknowledgement or, if applicable, as confirmation."}],"title":"SIM-04 Basic 01B"},{"id":"sim-04-02b","class":"basic","parts":[{"id":"sim-04-02b_stmt","name":"statement","prose":"Information on security incidents or confirmed security breaches is made available to all affected customers."},{"id":"sim-04-02b_guidance-1","name":"guidance","prose":"Security breaches in the sense of this criterion are security incidents caused by unauthorised access and compromise of cloud service customer data or service delivery as a result of violations of policies and procedures or applicable legal and regulatory requirements (cf. HR-04.02B)"}],"title":"SIM-04 Basic 02B"},{"id":"sim-04-01ac","class":"additional-complement","parts":[{"id":"sim-04-01ac_stmt","name":"statement","prose":"The customer can either actively approve solutions or the solution is automatically approved after a certain period."}],"title":"SIM-04 Additional Complement 01AC"},{"id":"sim-04-02ac","class":"additional-complement","parts":[{"id":"sim-04-02ac_stmt","name":"statement","prose":"The contract between the cloud service provider and the cloud service customer regulates which data is made available to the cloud service customer for his own analysis in the event of security incidents."}],"title":"SIM-04 Additional Complement 02AC"}]},{"id":"sim-05","parts":[{"id":"sim-05-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that identified security events, which the cloud service provider is required to process, are communicated timely to previously designated, responsible personnel.\n\nThe identification of such security events is supported by suitable controls (cf. complementary criterion for OPS-10).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Duty of the Personnel to Report Security Incidents to a Central Body","controls":[{"id":"sim-05-01b","class":"basic","parts":[{"id":"sim-05-01b_stmt","name":"statement","prose":"The cloud service provider informs personnel and external business partners of their obligations. If necessary, they agree to or are contractually obliged to timely 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."}],"title":"SIM-05 Basic 01B"},{"id":"sim-05-02b","class":"basic","parts":[{"id":"sim-05-02b_stmt","name":"statement","prose":"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."}],"title":"SIM-05 Basic 02B"},{"id":"sim-05-03b","class":"basic","parts":[{"id":"sim-05-03b_stmt","name":"statement","prose":"The information security incident reporting mechanisms are communicated to personnel, cloud service customers and service organisations of the cloud service provider."}],"title":"SIM-05 Basic 03B"}]},{"id":"sim-06","parts":[{"id":"sim-06-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 service customers evaluate whether and which supporting measures they might take on their side.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Evaluation and Learning Process","controls":[{"id":"sim-06-01b","class":"basic","parts":[{"id":"sim-06-01b_stmt","name":"statement","prose":"Mechanisms are in place to measure and monitor the type and scope of security incidents and to report them to supporting bodies."},{"id":"sim-06-01b_guidance-1","name":"guidance","prose":"Supporting bodies may be external service providers or government agencies such as the BSI."}],"title":"SIM-06 Basic 01B"},{"id":"sim-06-02b","class":"basic","parts":[{"id":"sim-06-02b_stmt","name":"statement","prose":"The cloud service provider defines, implements and maintains a knowledge repository containing:\n\n- Security incidents;\n- Measures taken for the solution of these security incidents; and\n- Information about the assets affected by these security incidents. \n\nThis information is used to supplement the classification catalogue of incidents (cf. SIM-03)."}],"title":"SIM-06 Basic 02B"},{"id":"sim-06-03b","class":"basic","parts":[{"id":"sim-06-03b_stmt","name":"statement","prose":"The information obtained from the security incident monitoring and the intelligence gathered in the knowledge repository is used to identify recurring security events or security incidents, or potential significant security incidents, to determine the need for advanced safeguards, and for implementing them."}],"title":"SIM-06 Basic 03B"},{"id":"sim-06-04b","class":"basic","parts":[{"id":"sim-06-04b_stmt","name":"statement","prose":"The evaluation and learning process includes the results of root-cause analyses conducted in accordance with SIM-03."}],"title":"SIM-06 Basic 04B"}]}]},{"id":"bcm","title":"Business Continuity Management (BCM)","controls":[{"id":"bcm-01","title":"Business Continuity and Emergency Management System","controls":[{"id":"bcm-01-01b","class":"basic","parts":[{"id":"bcm-01-01b_stmt","name":"statement","prose":"The cloud service provider operates a business continuity and emergency management system in accordance with ISO 22301 and/or BSI 200-4."},{"id":"bcm-01-01b_guidance-1","name":"guidance","prose":"The basic criterion can (but need not) be fulfilled with a certification of the BCM according to ISO/IEC 22301."}],"title":"BCM-01 Basic 01B"},{"id":"bcm-01-02b","class":"basic","parts":[{"id":"bcm-01-02b_stmt","name":"statement","prose":"Policies and procedures for the cloud service's business continuity management, including strategy and guidelines, business impact analyses, and business continuity plans, are documented, communicated, and made available in accordance with SP-01 regarding the following aspects:\n\n1. Goals of the BCM;\n2. Roles and responsibilities, management commitment;\n3. Scoping of the BCM, identifying relevant business processes;\n4. Interfaces, in particular to Incident Management;\n5. Communication with relevant entities and competent authorities;\n6. Methodology;\n7. Consideration of Risk;\n8. Business Impact Analysis (BIA);\n9. Business Continuity Plan (BCP);\n10. Resource Planning (usually part of the BCP);\n11. Testing of Business Continuity Plans and regular updates to BCM documentation; and\n12. Continuous improvement of the Business Continuity Management."},{"id":"bcm-01-02b_guidance-1","name":"guidance","prose":"Please note: BCM can be integrated into enterprise risk management (ERM) to gain more efficiency and overcome management silos."}],"title":"BCM-01 Basic 02B"},{"id":"bcm-01-03b","class":"basic","parts":[{"id":"bcm-01-03b_stmt","name":"statement","prose":"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 ensure that sufficient resources are made available for an effective process."},{"id":"bcm-01-03b_guidance-1","name":"guidance","prose":"The top management responsibility can be delegated from top management to another individual as long this individual has the scope, responsibilities and capabilities to influence the cloud-service-wide business continuity strategy and activities just as the top management could do."}],"title":"BCM-01 Basic 03B"},{"id":"bcm-01-04b","class":"basic","parts":[{"id":"bcm-01-04b_stmt","name":"statement","prose":"People in management and other relevant leadership positions demonstrate leadership and commitment to this issue by encouraging personnel to actively contribute to the effectiveness of continuity and emergency management."}],"title":"BCM-01 Basic 04B"}]},{"id":"bcm-02","parts":[{"id":"bcm-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Business Impact Analysis","controls":[{"id":"bcm-02-01b","class":"basic","parts":[{"id":"bcm-02-01b_stmt","name":"statement","prose":"The cloud service provider performs a Business Impact Analysis (BIA). In this BIA, the cloud service provider analyses the impact of disrupting activities to its organisation with respect the development and operations of the cloud service in accordance with applicable policies and procedures with at least the following aspects:\n\n1. Possible scenarios based on a risk assessment that includes cybersecurity risks;\n2. Identification of critical products and services;\n3. Identification of dependencies, including processes (including resources required), applications, business partners and third parties;\n4. Capturing threats to critical products and services;\n5. Identification of effects resulting from planned and unplanned outages, service degradations and changes over time;\n6. Determination of the maximum tolerable period of downtime and service degregation;\n7. Identification of restoration priorities;\n8. Determination of time targets for the resumption of critical products and services within the maximum acceptable time period (i.e. RTO);\n9. Determination of time targets for the maximum reasonable period during which cloud service derived data, cloud service provider data, account data and, if its processing is contractually agreed upon, cloud service customer data can be lost and not recovered (i.e. RPO); and\n10. Estimation of the resources needed for resumption."},{"id":"bcm-02-01b_guidance-1","name":"guidance","prose":"Scenarios to be considered according to the basic criterion are, for example, the loss of personnel, buildings, infrastructure and service providers."}],"title":"BCM-02 Basic 01B"},{"id":"bcm-02-02b","class":"basic","parts":[{"id":"bcm-02-02b_stmt","name":"statement","prose":"The business impact analysis adheres to the applicable policies and procedures and is reviewed at regular intervals, at least once a year, or after significant organisational or environment-related changes."}],"title":"BCM-02 Basic 02B"}]},{"id":"bcm-03","parts":[{"id":"bcm-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the results of their 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 service customers ensure with 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Business Continuity Plans","controls":[{"id":"bcm-03-01b","class":"basic","parts":[{"id":"bcm-03-01b_stmt","name":"statement","prose":"Based on the results of the business impact analysis, business continuity plans are documented in a consistent manner, and in accordance with applicable policies and procedures. \n\nBusiness continuity plans take the following aspects into account:\n\n1. Defined purpose and scope with consideration of the relevant dependencies;\n2. Accessibility and comprehensibility of the plans for persons who are to act accordingly;\n3. Ownership by at least one designated person responsible for review, updating and approval;\n4. Defined communication channels, roles and responsibilities including notification of the customer;\n5. Recovery procedures, manual interim solutions and reference information (taking into account prioritisation in the recovery of cloud hardware objects and services and alignment with customers);\n6. Methods for putting the plans into effect;\n7. Continuous process improvement; \n8. Consistency over all locations, zones, regions and partitions; and\n9. Interfaces to Security Incident Management."},{"id":"bcm-03-01b_guidance-1","name":"guidance","prose":"Although different partitions do not share a common IAM (and hence no common personnel for BCM), business continuity plans may be shared between different partitions since the same cloud services are provided."}],"title":"BCM-03 Basic 01B"},{"id":"bcm-03-02b","class":"basic","parts":[{"id":"bcm-03-02b_stmt","name":"statement","prose":"The business continuity plans are reviewed at regular intervals, at least once a year, or after significant organisational or environment-related changes."},{"id":"bcm-03-02b_guidance-1","name":"guidance","prose":"Although different partitions do not share a common IAM (and hence no common personnel for BCM), business continuity plans may be shared between different partitions since the same cloud services are provided."}],"title":"BCM-03 Basic 02B"}]},{"id":"bcm-04","parts":[{"id":"bcm-04-corresponding","name":"corresponding","prose":"Cloud service customers ensure with 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 service customers ensure with 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 service customers ensure that the appropriate measures for coping with the scenario are practiced and tested by means of suitable BCM controls.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Testing Business Continuity","controls":[{"id":"bcm-04-01b","class":"basic","parts":[{"id":"bcm-04-01b_stmt","name":"statement","prose":"Business continuity plans are tested on a regular basis (at least annually) or after significant organisational or environmental changes. Tests involve affected cloud service customers and relevant third parties (e.g. service organisations)."},{"id":"bcm-04-01b_guidance-1","name":"guidance","prose":"Tests are primarily conducted at the operational level and are aimed at operational target groups. Tests include e.g.:\n\n1. Test of technical precautionary safeguards;\n2. Functional tests; and\n3. Plan review.\n\nExercises also take place on a tactical and strategic level. These include e.g.:\n\n1. Plan meeting;\n2. Personnel exercise;\n3. Command post exercise;\n4. Communication and alerting exercise;\n5. Simulation of scenarios; and\n6. Emergency or full exercise.\n\nRelevant third parties are in particular service organisations of the cloud service provider who contribute to the development or operation of the cloud service (cf. basic criteria SSO-02 and SSO-06). A cloud service customer is affected (in the sense of this criterion) if the test or excercise leads to a service downgrade outside of the level defined in the SLA or if the effectiveness of the plans can only be tested if the cloud service customer has to take action."}],"title":"BCM-04 Basic 01B"},{"id":"bcm-04-02b","class":"basic","parts":[{"id":"bcm-04-02b_stmt","name":"statement","prose":"The tests are documented and results are taken into account to review the business continuity plans and for future business continuity measures."}],"title":"BCM-04 Basic 02B"},{"id":"bcm-04-01ac","class":"additional-complement","parts":[{"id":"bcm-04-01ac_stmt","name":"statement","prose":"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."},{"id":"bcm-04-01ac_guidance-1","name":"guidance","prose":"Tests are primarily conducted at the operational level and are aimed at operational target groups. Tests include e.g.:\n\n1. Test of technical precautionary safeguards;\n2. Functional tests; and\n3. Plan review.\n\nExercises also take place on a tactical and strategic level. These include e.g.:\n\n1. Plan meeting;\n2. Personnel exercise;\n3. Command post exercise;\n4. Communication and alerting exercise;\n5. Simulation of scenarios; and\n6. Emergency or full exercise.\n\nRelevant third parties are in particular service organisations of the cloud service provider who contribute to the development or operation of the cloud service (cf. basic criteria SSO-02 and SSO-06). A cloud service customer is affected (in the sense of this criterion) if the test or excercise leads to a service downgrade outside of the level defined in the SLA or if the effectiveness of the plans can only be tested if the cloud service customer has to take action."}],"title":"BCM-04 Additional Complement 01AC"},{"id":"bcm-04-02ac","class":"additional-complement","parts":[{"id":"bcm-04-02ac_stmt","name":"statement","prose":"The cloud service provider has procedures in place to ensure that cloud service customers are timely informed about planned activities related to business continuity tests and exercises that could affect the information security of the cloud service (e.g. regarding its availability). This information includes the scheduled time frame for the operations as well as a description of the work to be carried out."}],"title":"BCM-04 Additional Complement 02AC"},{"id":"bcm-04-03ac","class":"additional-complement","parts":[{"id":"bcm-04-03ac_stmt","name":"statement","prose":"The cloud service provider provides cloud service customers an assessment of the potential impacts of those tests and excercises concerning the information security of the cloud service and with details for contacting the cloud service provider."}],"title":"BCM-04 Additional Complement 03AC"},{"id":"bcm-04-04ac","class":"additional-complement","parts":[{"id":"bcm-04-04ac_stmt","name":"statement","prose":"After a completed exercise, the existing alarm and notification plan is reviewed and (if needed) adapted."},{"id":"bcm-04-04ac_guidance-1","name":"guidance","prose":"The term 'alarm and notification plan' refers to the documented procedure for alerting responsible personnel and stakeholders in case of incidents or disruptions."}],"title":"BCM-04 Additional Complement 04AC"}]}]},{"id":"com","title":"Compliance (COM)","controls":[{"id":"com-01","title":"Identification of Applicable Legal, Regulatory, Self-imposed or Contractual Requirements","controls":[{"id":"com-01-01b","class":"basic","parts":[{"id":"com-01-01b_stmt","name":"statement","prose":"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."},{"id":"com-01-01b_guidance-1","name":"guidance","prose":"The cloud service provider's documentation may refer to the following requirements, among others:\n\n1. Requirements for the protection of personal data (e.g. EU General Data Protection Regulation);\n2. Requirements regarding the information security posture of the cloud service provider (e.g. NIS 2 Directive, BSIG as applicable to KRITIS);\n3. Compliance requirements based on contractual obligations with cloud service customers (e.g. ISO/IEC 27001, SOC 2, PCI-DSS); and\n4. Requirements regarding exchange and use of data (e.g. EU Data Act).\n\nThe documentation of the identified requirements and the procedures for complying with these requirements may be spread across several documents and does not necessarily have to be recorded in a single register or directory."}],"title":"COM-01 Basic 01B"},{"id":"com-01-01ac","class":"additional-complement","parts":[{"id":"com-01-01ac_stmt","name":"statement","prose":"The cloud service provider provides an overview of the procedures described in the basic criterion upon request by the cloud service customer."}],"title":"COM-01 Additional Complement 01AC"}]},{"id":"com-02","parts":[{"id":"com-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that appropriate responses are made to outages or degradations of the cloud service through such audits.\n\nTo the extent that contractually agreed information and audit rights exist, the cloud service customers ensure with suitable controls that these rights are designed and executed in accordance with their own requirements.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Policy for Planning and Conducting Audits","controls":[{"id":"com-02-01b","class":"basic","parts":[{"id":"com-02-01b_stmt","name":"statement","prose":"The cloud service provider documents and implements an audit programme over multiple years that defines the scope and the frequency of the audits. The audit programme takes into consideration the management of change, policies, and the results of the risk assessment (cf. OIS-07)."},{"id":"com-02-01b_guidance-1","name":"guidance","prose":"An audit is a systematic, independent and documented process for obtaining objective evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled. Audits may be performed as internal audits, sometimes called first party audits, that are conducted by, or on behalf of, the organisation itself. They may also be performed as external audits, generally called second and third party audits. Second party audits are conducted by parties having an interest in the organisation, such as customers, or by other individuals on their behalf. Third party audits are conducted by independent auditing organisations.\n\nAn audit programme comprises arrangements for a set of one or more audits planned for a specific time frame and directed towards a specific purpose. The audit programme may, for example, comprise a time frame of three years, and may comprise internal and external audits.\n\nCOM-02 is fully applicable to virtual infrastructure and infrastructure as code. Audit activities might still impact operations in a virtual environment. Reviews of configurations might for example be performed as part of code reviews."}],"title":"COM-02 Basic 01B"},{"id":"com-02-02b","class":"basic","parts":[{"id":"com-02-02b_stmt","name":"statement","prose":"Risk-based policies and procedures for planning and conducting audits are documented, communicated and made available in accordance with SP-01 and address the following aspects in order to prevent adversal effects on the operation of the cloud service from the audit:\n\n1. Restriction to read-only access to system components in accordance with the agreed audit plan and as necessary to perform the activities;\n2. Activities that may result in outages, degradations of the cloud service or breaches of contractual requirements are performed during scheduled maintenance windows or outside peak periods;\n3. Logging and monitoring of activities;\n4. Review of server and network equipment configurations under the responsibility of the cloud service provider;\n5. Intrusion testing for external access points; and\n6. Source code reviews of internally developed security features."},{"id":"com-02-02b_guidance-1","name":"guidance","prose":"See DEV-05 for further explanation on security features."}],"title":"COM-02 Basic 02B"},{"id":"com-02-01as","class":"additional-sharpen","parts":[{"id":"com-02-01as_stmt","name":"statement","prose":"The cloud service provider documents and implements an audit programme over three years that defines the scope and the frequency of the audits. The audit programme takes into consideration the management of change, policies, and the results of the risk assessment (cf. OIS-07)."},{"id":"com-02-01as_guidance-1","name":"guidance","prose":"An audit is a systematic, independent and documented process for obtaining objective evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled. Audits may be performed as internal audits, sometimes called first party audits, that are conducted by, or on behalf of, the organisation itself. They may also be performed as external audits, generally called second and third party audits. Second party audits are conducted by parties having an interest in the organisation, such as customers, or by other individuals on their behalf. Third party audits are conducted by independent auditing organisations.\n\nAn audit programme comprises arrangements for a set of one or more audits planned for a specific time frame and directed towards a specific purpose. The audit programme may, for example, comprise a time frame of three years, and may comprise internal and external audits.\n\nCOM-02 is fully applicable to virtual infrastructure and infrastructure as code. Audit activities might still impact operations in a virtual environment. Reviews of configurations might for example be performed as part of code reviews."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"COM-02 Additional Sharpen 01AS"},{"id":"com-02-01ac","class":"additional-complement","parts":[{"id":"com-02-01ac_stmt","name":"statement","prose":"The cloud service provider grants its cloud service customers contractually agreed information and audit rights. These rights may be exercised individually or as part of group audits."}],"title":"COM-02 Additional Complement 01AC"}]},{"id":"com-03","title":"Internal Audits of the Information Security Management System","controls":[{"id":"com-03-01b","class":"basic","parts":[{"id":"com-03-01b_stmt","name":"statement","prose":"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) through internal audits. This includes checks regarding:\n\n1. Compliance with the policies and procedures (cf. SP-01) within their scope of responsibility (cf. OIS-01); and\n2. Effectiveness of organisational and operational measures to manage the risks posed to the security of network and information systems (cf. OIS-07)."},{"id":"com-03-01b_guidance-1","name":"guidance","prose":"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, cf. section 9.2 of ISO/IEC 27001, which outlines the requirements for conducting internal audits of an Information Security Management System (ISMS) and for establishing an internal audit programme. When establishing the internal audit programme(s), the cloud service provider should define the scope and criteria by considering the importance of the processes concerned and the results of previous audits. This approach allows cloud service providers to define the audit scope based on the criticality of complying with relevant legal, regulatory, or contractual requirements (cf. COM-01) and internal policies and procedures (cf. SP-01), without requiring a comprehensive review of all requirements during each audit cycle."}],"title":"COM-03 Basic 01B"},{"id":"com-03-02b","class":"basic","parts":[{"id":"com-03-02b_stmt","name":"statement","prose":"Subject matter experts conducting internal audits are not in the line of authority of the personnel of the area under review. If the size of the cloud service provider does not allow such separation of line of authority, alternative measures to guarantee the impartiality of compliance checks are put in place."}],"title":"COM-03 Basic 02B"},{"id":"com-03-03b","class":"basic","parts":[{"id":"com-03-03b_stmt","name":"statement","prose":"Identified vulnerabilities and deviations as well as non-conformities from the applicable legal, regulatory, self-imposed and contractual requirements relevant to the information security of the cloud service, are subjected to a risk assessment in accordance with the risk management procedure (cf. OIS-07). Follow-up measures are defined and tracked (cf. OPS-18)."}],"title":"COM-03 Basic 03B"},{"id":"com-03-01ac","class":"additional-complement","parts":[{"id":"com-03-01ac_stmt","name":"statement","prose":"Based on a risk assessment (cf. OIS-07) and technical feasibility, the cloud service provider decides to which extent internal audits are supplemented by procedures to automatically monitor applicable requirements of policies and procedures with regard to the following aspects:\n\n1. Configuration of system components to provide the cloud service within the cloud service provider's area of responsibility;\n2. Performance and availability of these system components;\n3. Response time to incidents and security incidents; and\n4. Recovery time (time to completion of error handling)."}],"title":"COM-03 Additional Complement 01AC"},{"id":"com-03-02ac","class":"additional-complement","parts":[{"id":"com-03-02ac_stmt","name":"statement","prose":"Identified vulnerabilities and deviations are automatically reported to the appropriate cloud service provider's subject matter experts for immediate assessment and action."}],"title":"COM-03 Additional Complement 02AC"},{"id":"com-03-03ac","class":"additional-complement","parts":[{"id":"com-03-03ac_stmt","name":"statement","prose":"The cloud service provider provides interfaces to cloud service customers so that they can check compliance with selected contractual agreements in real time."}],"title":"COM-03 Additional Complement 03AC"}]},{"id":"com-04","title":"Information on Information Security Performance and Management Assessment of the ISMS","controls":[{"id":"com-04-01b","class":"basic","parts":[{"id":"com-04-01b_stmt","name":"statement","prose":"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. This management review is performed at least once a year."},{"id":"com-04-01b_guidance-1","name":"guidance","prose":"The top management is a natural person or group of people who take final decisions for the institution and are accountable 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."}],"title":"COM-04 Basic 01B"},{"id":"com-04-01ac","class":"additional-complement","parts":[{"id":"com-04-01ac_stmt","name":"statement","prose":"The cloud service provider defines and implements technical and operational metrics that align with the organisation's business objectives, security requirements, and compliance obligations. These metrics are documented and included in the management review of the ISMS to ensure their continued suitability, adequacy, and effectiveness."}],"title":"COM-04 Additional Complement 01AC"},{"id":"com-04-02ac","class":"additional-complement","parts":[{"id":"com-04-02ac_stmt","name":"statement","prose":"The responsible business units of the cloud service provider report at least annually to the top management on the the status and effectiveness of the policies and procedures that are relevant to the top management review of the information security management system. This reporting includes at least:\n\n1. Implemented changes to address cybersecurity risks for the topic addressed in the policy or procedure;\n2. Information security incidents for the topic addressed in the policy or procedure and the follow-up;\n3. Performance of the internal controls regarding information security for the topic addressed in the policy or procedure; and\n4. Planned changes for the topic addressed in the policy or procedure to address cybersecurity risks and information security and cybersecurity."}],"title":"COM-04 Additional Complement 02AC"}]}]},{"id":"inq","title":"Dealing with Investigation Requests from Government Agencies (INQ)","controls":[{"id":"inq-01","parts":[{"id":"inq-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the type and scope of government agencies' 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 is only taken up or continued when this risk has been deemed acceptable.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Legal Assessment of Investigation Requests","controls":[{"id":"inq-01-01b","class":"basic","parts":[{"id":"inq-01-01b_stmt","name":"statement","prose":"Investigation requests from government agencies for cloud service customer data, cloud service derived data and account data are subject to a documented 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 for the given request."},{"id":"inq-01-01b_guidance-1","name":"guidance","prose":"For evidence purposes, all requests that were completely processed during the specified period shall form the population for testing the operating effectiveness of controls to meet the criteria in this domain. All requests are to be included in the population, irrespective of whether they resulted in cloud service customer data or cloud service derived data being disclosed."}],"title":"INQ-01 Basic 01B"},{"id":"inq-01-02b","class":"basic","parts":[{"id":"inq-01-02b_stmt","name":"statement","prose":"Access to or disclosure of cloud service customer data, cloud service derived data or account data in response to government investigation requests is only permitted if the cloud service provider has performed a legal assessment. This assessment has to confirm that there is an applicable and valid legal basis and that the request must be granted according to this basis."},{"id":"inq-01-02b_guidance-1","name":"guidance","prose":"Disclosure of cloud service customer data to government agencies may include handing over encryption keys. The disclosure of keys should also be scrutinised in accordance with the INQ criteria. In particular, with reference to INQ-03, care should be taken to ensure that no other cloud service customer data is compromised by handing over a key."}],"title":"INQ-01 Basic 02B"}]},{"id":"inq-02","parts":[{"id":"inq-02-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that such notifications are received and assessed from a legal perspective according to their own specifications and possibilities.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Informing Cloud Service Customers about Investigation Requests","controls":[{"id":"inq-02-01b","class":"basic","parts":[{"id":"inq-02-01b_stmt","name":"statement","prose":"The cloud service provider informs the affected cloud service customer(s) without undue delay, unless the applicable legal basis, on which the government agency's request is based, prohibits this or there are clear indications of illegal actions in connection with the use of the cloud service."},{"id":"inq-02-01b_guidance-1","name":"guidance","prose":"This does not affect other legal or regulatory requirements that requires earlier information for cloud service customers."}],"title":"INQ-02 Basic 01B"}]},{"id":"inq-03","title":"Limiting Access to or Disclosure of Data in Investigation Requests","controls":[{"id":"inq-03-01b","class":"basic","parts":[{"id":"inq-03-01b_stmt","name":"statement","prose":"The cloud service provider's procedures for granting access to or disclosing cloud service customer data and cloud service derived data in the context of investigation requests from government agencies ensure that the agencies only gain access to or insight into the data that is the subject of the investigation request."}],"title":"INQ-03 Basic 01B"},{"id":"inq-03-02b","class":"basic","parts":[{"id":"inq-03-02b_stmt","name":"statement","prose":"If no clear limitation of the cloud service customer data and cloud service derived data is possible, the cloud service provider anonymises or pseudonymises this data so that government agencies can only assign it to those cloud service customers who are subject of the investigation request."}],"title":"INQ-03 Basic 02B"},{"id":"inq-03-01ac","class":"additional-complement","parts":[{"id":"inq-03-01ac_stmt","name":"statement","prose":"The access and activities performed by or on behalf of investigators are monitored by the cloud service provider as determined by the process described in INQ-01."}],"title":"INQ-03 Additional Complement 01AC"},{"id":"inq-03-02ac","class":"additional-complement","parts":[{"id":"inq-03-02ac_stmt","name":"statement","prose":"Timely and appropriate remediation measures address any deviations identified during the monitoring of the activities performed by or on behalf of investigators."}],"title":"INQ-03 Additional Complement 02AC"}]},{"id":"inq-04","parts":[{"id":"inq-04-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they minimise potential disclosure of their customer data. According to the protection need of the cloud service customer data, the cloud service customers take the decision if the particular cloud service can be used or if the risk of disclosure is too high.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Communication of Technical Procedures for Data Disclosure in Investigation Requests","controls":[{"id":"inq-04-01b","class":"basic","parts":[{"id":"inq-04-01b_stmt","name":"statement","prose":"The cloud service provider documents the technical procedures per service and other technical information regarding the provision or disclosure of cloud service customer data in response to valid investigation requests and provides it to cloud service customers."},{"id":"inq-04-01b_guidance-1","name":"guidance","prose":"The criterion is limited to cloud service customer data. The cloud service provider typically has access to other data types such as cloud service derived data and account data such that extending the criterion to those other data types, may not lead to useful information for customers' risk management. Technical capabilities and limitations to access cloud service customer data include aspects such as:\n\n1. If the cloud service customers store their cloud service customer data in unencrypted form;\n2. If the cloud service provider encrypts cloud service customer data in storage and transit;\n3. Whether the cloud service provider has the ability to decrypt cloud service customer data in case of such requests and how this ability for access or disclosure is used;\n4. Retention periods for cloud service derived data relating to the cloud service customer and whether such data is stored in encrypted form;\n5. Possibilities for decrypting cloud service customer data or for extracting cloud service customer data during the decryption process;\n6. Disclosure of user identities and credentials; and\n7. Further measures that have been created or can be used for disclosing cloud service customer data."}],"title":"INQ-04 Basic 01B"},{"id":"inq-04-02b","class":"basic","parts":[{"id":"inq-04-02b_stmt","name":"statement","prose":"The type and scope of the information provided to the cloud service customers is based on the needs of their expert personnel to assess risks to the cloud service customer's data confidentiality. At a minimum, the following aspects are addressed:\n\n1. The process for the provision and disclosure of cloud service customer data in response to legitimate investigation requests;\n2. The technical capabilities and limitations of the cloud service provider regarding disclosure of cloud service customer data;\n3. Logging mechanisms implemented to records access for disclosure of cloud service customer data;\n4. Access possibilities for cloud service customers to review such logs;\n5. Methods and technical procedures per service for accessing and disclosing cloud service customer data; and\n6. Laws, regulations, or other legal means and their applicability concerning the cloud service provider's ability to inform its customers about the provision and disclosure of cloud service customer data."},{"id":"inq-04-02b_guidance-1","name":"guidance","prose":"The criterion is limited to cloud service customer data. The cloud service provider typically has access to other data types such as cloud service derived data and account data such that extending the criterion to those other data types, may not lead to useful information for customers' risk management. Technical capabilities and limitations to access cloud service customer data include aspects such as:\n\n1. If the cloud service customers store their cloud service customer data in unencrypted form;\n2. If the cloud service provider encrypts cloud service customer data in storage and transit;\n3. Whether the cloud service provider has the ability to decrypt cloud service customer data in case of such requests and how this ability for access or disclosure is used;\n4. Retention periods for cloud service derived data relating to the cloud service customer and whether such data is stored in encrypted form;\n5. Possibilities for decrypting cloud service customer data or for extracting cloud service customer data during the decryption process;\n6. Disclosure of user identities and credentials; and\n7. Further measures that have been created or can be used for disclosing cloud service customer data."}],"title":"INQ-04 Basic 02B"},{"id":"inq-04-03b","class":"basic","parts":[{"id":"inq-04-03b_stmt","name":"statement","prose":"The aforementioned document is maintained in accordance with SP-01 and aligned with the cloud service provider's guidelines on minimising access to cloud service customer data (cf. DEV-01) to ensure its relevance and accuracy for cloud service customers."},{"id":"inq-04-03b_guidance-1","name":"guidance","prose":"The criterion is limited to cloud service customer data. The cloud service provider typically has access to other data types such as cloud service derived data and account data such that extending the criterion to those other data types, may not lead to useful information for customers' risk management. Technical capabilities and limitations to access cloud service customer data include aspects such as:\n\n1. If the cloud service customers store their cloud service customer data in unencrypted form;\n2. If the cloud service provider encrypts cloud service customer data in storage and transit;\n3. Whether the cloud service provider has the ability to decrypt cloud service customer data in case of such requests and how this ability for access or disclosure is used;\n4. Retention periods for cloud service derived data relating to the cloud service customer and whether such data is stored in encrypted form;\n5. Possibilities for decrypting cloud service customer data or for extracting cloud service customer data during the decryption process;\n6. Disclosure of user identities and credentials; and\n7. Further measures that have been created or can be used for disclosing cloud service customer data."}],"title":"INQ-04 Basic 03B"}]}]},{"id":"pss","title":"Product Safety and Security (PSS)","controls":[{"id":"pss-01","parts":[{"id":"pss-01-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the cloud service provider's information is used to derive policies, frameworks and measures for the secure configuration and use (according to their own risk assessment) of the cloud service. Compliance with these policies, frameworks and measures is checked. Changes to the information are timely assessed for their impact on these documents and any necessary changes are implemented.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Guidelines and Recommendations for Cloud Service Customers","controls":[{"id":"pss-01-01b","class":"basic","parts":[{"id":"pss-01-01b_stmt","name":"statement","prose":"The cloud service provider publishes guidelines and recommendations for cloud service customers regarding the secure use of the cloud service provided. The information contained therein is intended to assist the cloud service customer in the secure configuration and use of the cloud service, as well as the implementation of complementary customer controls, to the extent applicable to the cloud service and the responsibility of the cloud service customer."},{"id":"pss-01-01b_guidance-1","name":"guidance","prose":"In a cloud environment, security responsibilities are shared between the cloud service provider and the customer, varying by service type — Infrastructure as a Service (IaaS), Platform as a Service (PaaS), or Software as a Service (SaaS). Guidance on the complementary customer controls helps cloud service customers understand their roles and responsibilities within the Shared Responsibility Model, also in terms of security and operational management (cf. OIS-03). By offering detailed guidance, cloud service customers are equipped to understand and implement the necessary controls that fall under their responsibility. The level of detail and length can vary according to the type of cloud service provided.\n\nExamples for defensive mechanisms include payload filtering, traffic shaping, load balancing, load shedding and DDoS defences.\n\nExamples for wide-area distributed architecture mechanisms include fault tolerance through replication, avoidance of localised outages and disasters through the use of multiple cloud regions, as well as the reduction of user-facing latency through the geo-dispersion of service endpoints."}],"title":"PSS-01 Basic 01B"},{"id":"pss-01-02b","class":"basic","parts":[{"id":"pss-01-02b_stmt","name":"statement","prose":"The type and scope of the information in the guidelines and recommendations for the secure use of the cloud service provided will be based on the needs of subject matter experts of the cloud service 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\n1. Procedures for secure configuration;\n2. Information sources on known vulnerabilities and update mechanisms;\n3. Malware protection for containers or virtual machines;\n4. Error handling and logging mechanisms;\n5. Authentication mechanisms;\n6. Roles and rights framework including combinations that result in an elevated risk;\n7. Services and functions for administration of the cloud service by privileged users;\n8. Complementary user entity controls;\n9. Encryption mechanisms and services;\n10. Data leakage prevention;\n11. Secure application development and operation on the cloud service;\n12. Instructions for using and configuring defensive mechanisms;\n13. Instructions for using and configuring wide-area distributed architecture mechanisms; \n14. Methods used for client data separation (cf. OPS-30 and OPS-31);\n15. How information security risks related to the use of the cloud service can be addressed through proper logging and monitoring mechanisms; and\n16. Inbound and outbound interfaces through which the cloud service can be accessed by other cloud services or IT systems of cloud service customers (cf. PI-01)."}],"title":"PSS-01 Basic 02B"},{"id":"pss-01-03b","class":"basic","parts":[{"id":"pss-01-03b_stmt","name":"statement","prose":"The cloud service provider describes in the user documentation all necessary complementary user entity controls (CUECs) and corresponding explanations of them, so that the cloud service customer has sufficient information for appropriate risk management on its side."}],"title":"PSS-01 Basic 03B"},{"id":"pss-01-04b","class":"basic","parts":[{"id":"pss-01-04b_stmt","name":"statement","prose":"The above-mentioned information is maintained so that it is applicable to the cloud service provided in the version intended for productive use."}],"title":"PSS-01 Basic 04B"},{"id":"pss-01-01ac","class":"additional-complement","parts":[{"id":"pss-01-01ac_stmt","name":"statement","prose":"The cloud service provider notifies cloud service customers in a timely manner about any planned modifications to the cloud service so that the affected cloud service customers can react appropriately with organisational and technical measures before the changes take effect."}],"title":"PSS-01 Additional Complement 01AC"}]},{"id":"pss-02","title":"Identification of Vulnerabilities of the Cloud Service","controls":[{"id":"pss-02-01b","class":"basic","parts":[{"id":"pss-02-01b_stmt","name":"statement","prose":"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."},{"id":"pss-02-01b_guidance-1","name":"guidance","prose":"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 criterion OPS-25 (Managing Vulnerabilities, Incidents and Errors - Vulnerability Scans)."}],"title":"PSS-02 Basic 01B"},{"id":"pss-02-02b","class":"basic","parts":[{"id":"pss-02-02b_stmt","name":"statement","prose":"The procedures for identifying such vulnerabilities are part of the software development process and, depending on a risk assessment, include the following activities:\n\n1. Static Application Security Testing;\n2. Dynamic Application Security Testing;\n3. Code reviews by the cloud service provider's subject matter experts;\n4. Conducting security checks based on a list of software components or Software Bill of Materials (SBOM); and\n5. Obtaining information about confirmed vulnerabilities in software libraries provided by third parties and used in their own cloud service."},{"id":"pss-02-02b_guidance-1","name":"guidance","prose":"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 criterion OPS-25 (Managing Vulnerabilities, Incidents and Errors - Vulnerability Scans)."}],"title":"PSS-02 Basic 02B"},{"id":"pss-02-03b","class":"basic","parts":[{"id":"pss-02-03b_stmt","name":"statement","prose":"The severity of identified vulnerabilities is assessed according to defined criteria and measures are taken to immediately eliminate or mitigate them."},{"id":"pss-02-03b_guidance-1","name":"guidance","prose":"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 criterion OPS-25 (Managing Vulnerabilities, Incidents and Errors - Vulnerability Scans)."}],"title":"PSS-02 Basic 03B"},{"id":"pss-02-01ac","class":"additional-complement","parts":[{"id":"pss-02-01ac_stmt","name":"statement","prose":"The procedures for identifying such vulnerabilities also include annual code reviews or security penetration tests by qualified external third parties."},{"id":"pss-02-01ac_guidance-1","name":"guidance","prose":"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 criterion OPS-25 (Managing Vulnerabilities, Incidents and Errors - Vulnerability Scans)."}],"title":"PSS-02 Additional Complement 01AC"}]},{"id":"pss-03","parts":[{"id":"pss-03-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the obtained vulnerability information is incorporated timely into their own risk management, evaluated and, if necessary, taken into account in their own area of responsibility.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Informing Customers about Known Vulnerabilities","controls":[{"id":"pss-03-01b","class":"basic","parts":[{"id":"pss-03-01b_stmt","name":"statement","prose":"The cloud service provider ensures through a coordinated process that cloud service customers have access to regularly updated information about known vulnerabilities associated with the cloud service that may impact the information security of the customer. This includes:\n\n1. Known-exploited vulnerabilities;\n2. Known vulnerabilities for which a patch and/or mitigating measures are provided by the cloud service provider (N-Day vulnerabilities), with appropriate references to the patch/measure; and\n3. Known vulnerabilities for which a patch and/or mitigating measures are unlikely to be provided by the cloud service provider (Forever-Day vulnerabilities), along with a justification for why they are not provided.\n\nThese pertain to the provided cloud service and assets provided by the cloud service provider that the cloud service customers have to install, provide or operate within their own responsibility."},{"id":"pss-03-01b_guidance-1","name":"guidance","prose":"This criterion supports transparency in vulnerability management. It requires the cloud service provider to proactively inform customers about vulnerabilities that may pose a residual risk due to the absence of remediation options. Such disclosures help customers assess their exposure and implement compensating controls where necessary.\n\nInformation about known-exploited vulnerabilities and known vulnerabilities can include, for example, the information about vulnerabilities in authorisation mechanisms obtained from the validation process carried out as part of PSS-09."}],"title":"PSS-03 Basic 01B"},{"id":"pss-03-02b","class":"basic","parts":[{"id":"pss-03-02b_stmt","name":"statement","prose":"The information provided to the cloud service customers includes, where available, a description of applicable and planned remediation or mitigation measures for the identified vulnerabilities."}],"title":"PSS-03 Basic 02B"},{"id":"pss-03-03b","class":"basic","parts":[{"id":"pss-03-03b_stmt","name":"statement","prose":"These vulnerabilities are also identified based on data from a list of software components or Software Bill of Materials (SBOM) data."},{"id":"pss-03-03b_guidance-1","name":"guidance","prose":"Although the cloud service provider has to identify the vulnerabilities based on SBOM data to fulfil this criterion, this SBOM data need not be handed over to the customer to fulfil the criterion."}],"title":"PSS-03 Basic 03B"},{"id":"pss-03-04b","class":"basic","parts":[{"id":"pss-03-04b_stmt","name":"statement","prose":"The vulnerabilities are presented with references to the Common Vulnerabilities and Exposures (CVE) and assessments are based on:\n\n1. The Common Vulnerability Scoring System (CVSS); and\n2. The Exploit Prediction Scoring System (EPSS), the Stakeholder-Specific Vulnerability Categorization (SSVC) or other similar scoring metrics\n\nin the latest version valid at the time of the assessment.\n\nThis information is accessible to all cloud customers and supports their risk assessment and follow-up actions, with references to vulnerability-specific measures where applicable."},{"id":"pss-03-04b_guidance-1","name":"guidance","prose":"Vulnerability-specific measures can for instance be found in the 'Vulnerability, Exploitability eXchange' (VEX) or the 'Common Security Advisory Frameworks' (CSAF).\n\nThe Common Vulnerability Scoring System (CVSS) assesses the severity of identified vulnerabilities (cf. OPS-18). The Exploit Prediction Scoring System (EPSS), the Stakeholder-Specific Vulnerability Categorization (SSVC) and other similar scoring metrics prioritise measures to be implemented for remediating or mitigating identified vulnerabilities. Both kinds of systems should be used in tandem."}],"title":"PSS-03 Basic 04B"},{"id":"pss-03-05b","class":"basic","parts":[{"id":"pss-03-05b_stmt","name":"statement","prose":"The cloud service provider consults the vulnerability information of its suppliers and service organisations at least daily. The published vulnerabilities are analysed in regards to their potential impact on the cloud service, and handled in accordance with the vulnerability handling process (cf. OPS-18). If the supplier or service organisation does not provide daily information, the related risk is managed according to OIS-07."},{"id":"pss-03-05b_guidance-1","name":"guidance","prose":"There can be various ways to obtain information about vulnerabilities from suppliers and service organisations. The criteria does not demand a particular way for obtaining this information but that the information is obtained at least daily."}],"title":"PSS-03 Basic 05B"},{"id":"pss-03-01ac","class":"additional-complement","parts":[{"id":"pss-03-01ac_stmt","name":"statement","prose":"Assets provided by the cloud service provider, which must be installed, provided or operated by cloud service customers within their area of responsibility, are equipped with automatic update mechanisms. After approval by the respective cloud service customer, software updates are rolled out by the cloud service provider."},{"id":"pss-03-01ac_guidance-1","name":"guidance","prose":"Assets provided by the cloud service provider that cloud service 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 information should incorporate or refer to the vulnerabilities of those other cloud services in order for this criterion to be met."}],"title":"PSS-03 Additional Complement 01AC"},{"id":"pss-03-02ac","class":"additional-complement","parts":[{"id":"pss-03-02ac_stmt","name":"statement","prose":"Vulnerabilities are disclosed in accordance with the Common Security Advisory Framework Version 2.0 or higher, and as specified in BSI's Technical Guideline TR-03191."},{"id":"pss-03-02ac_guidance-1","name":"guidance","prose":"Assets provided by the cloud service provider that cloud service 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 information should incorporate or refer to the vulnerabilities of those other cloud services in order for this criterion to be met."}],"title":"PSS-03 Additional Complement 02AC"}]},{"id":"pss-04","parts":[{"id":"pss-04-corresponding","name":"corresponding","prose":"If the cloud service is equipped with error handling and logging mechanisms, cloud service customers must activate these and configure them according to defined requirements. The cloud service customer must incorporate his own information security management for this purpose.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Error handling and Logging Mechanisms","controls":[{"id":"pss-04-01b","class":"basic","parts":[{"id":"pss-04-01b_stmt","name":"statement","prose":"The cloud service provided is equipped with error handling and logging mechanisms for system components under the responsibility of the cloud service customer. These enable cloud service customers to obtain security-related information about the security status of the cloud service as well as the data, services or functions it provides."},{"id":"pss-04-01b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Basic 01B"},{"id":"pss-04-02b","class":"basic","parts":[{"id":"pss-04-02b_stmt","name":"statement","prose":"These mechanisms are designed to address identified security risks related to the use of the cloud service. The cloud service provider identifies and documents these risks in advance, ensuring that the implemented logging mechanisms capture relevant events and activities."},{"id":"pss-04-02b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Basic 02B"},{"id":"pss-04-03b","class":"basic","parts":[{"id":"pss-04-03b_stmt","name":"statement","prose":"The information is detailed enough to allow cloud service customers to check the following aspects, insofar as they are applicable to the cloud service:\n\n1. Which cloud service customer data and cloud service derived data, services or functions available to the cloud service customer within the cloud service, have been accessed by whom, when and from where (Audit Logs);\n2. Malfunctions during processing of automatic or manual actions; and\n3. Changes to security-relevant configuration parameters, error handling and logging mechanisms, user authentication, action authorisation, cryptography, and communication security."},{"id":"pss-04-03b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Basic 03B"},{"id":"pss-04-04b","class":"basic","parts":[{"id":"pss-04-04b_stmt","name":"statement","prose":"The logged information is protected from unauthorised access and modification and can be deleted by the cloud service customer."},{"id":"pss-04-04b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."},{"id":"pss-04-04b_guidance-2","name":"guidance","prose":"The deletion of the logged information by the cloud service customer can, for example, be implemented by providing the cloud service customer with a process to request this deletion."}],"title":"PSS-04 Basic 04B"},{"id":"pss-04-05b","class":"basic","parts":[{"id":"pss-04-05b_stmt","name":"statement","prose":"Where applicable, the cloud service customer can activate or de-activate the logging and can control the scope and verbosity of the logging the cloud service provides."},{"id":"pss-04-05b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Basic 05B"},{"id":"pss-04-06b","class":"basic","parts":[{"id":"pss-04-06b_stmt","name":"statement","prose":"The logging of management plane actions by the cloud service customers covers all relevant systems and system components."},{"id":"pss-04-06b_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Basic 06B"},{"id":"pss-04-01ac","class":"additional-complement","parts":[{"id":"pss-04-01ac_stmt","name":"statement","prose":"Cloud service customers 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)."},{"id":"pss-04-01ac_guidance-1","name":"guidance","prose":"Unlike the additional criterion OPS-15, which covers both, system components under the responsibility of the cloud service provider, as well as system components under the responsibility of the cloud service customer, the scope of this criterion is limited strictly to system components under the responsibility of the cloud service customer only. \nThe extent of the logging depends on the cloud service. There may therefore be cloud services, such as SaaS services for which the amount of system components under the responsibility of the cloud service customer is very limited, to which this criterion is not applicable."}],"title":"PSS-04 Additional Complement 01AC"}]},{"id":"pss-05","parts":[{"id":"pss-05-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that the authentication mechanisms offered by the cloud service are used in accordance with the customer's identity and authorisation management requirements. If cloud service customers operate virtual machines or containers with the cloud service, they ensure with suitable controls that the authentication mechanisms cover container-specific scenarios, such as multi-factor authentication for container hosts and registry access.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Authentication Mechanisms","controls":[{"id":"pss-05-01b","class":"basic","parts":[{"id":"pss-05-01b_stmt","name":"statement","prose":"The cloud service provided is equipped with authentication mechanisms that can force multi-factor authentication for users, IT components or applications within the cloud service customers' area of responsibility. These authentication mechanisms are set up at all access points that allow users, IT components or applications to interact with the cloud service."},{"id":"pss-05-01b_guidance-1","name":"guidance","prose":"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 should be enforced and can e.g. be performed with cryptographic certificates, smart cards or tokens."}],"title":"PSS-05 Basic 01B"},{"id":"pss-05-02b","class":"basic","parts":[{"id":"pss-05-02b_stmt","name":"statement","prose":"For privileged users, IT components or applications under the responsibility of the cloud service customer, these authentication mechanisms can be enforced by the cloud service customer."},{"id":"pss-05-02b_guidance-1","name":"guidance","prose":"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 should be enforced and can e.g. be performed with cryptographic certificates, smart cards or tokens."}],"title":"PSS-05 Basic 02B"},{"id":"pss-05-01ac","class":"additional-complement","parts":[{"id":"pss-05-01ac_stmt","name":"statement","prose":"The cloud service offers out-of-band (OOB) authentication, in which the factors are transmitted via different channels (e.g. Internet and mobile network)."},{"id":"pss-05-01ac_guidance-1","name":"guidance","prose":"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 should be enforced and can e.g. be performed with cryptographic certificates, smart cards or tokens."}],"title":"PSS-05 Additional Complement 01AC"}]},{"id":"pss-06","parts":[{"id":"pss-06-corresponding","name":"corresponding","prose":"Cloud service 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Session Management","controls":[{"id":"pss-06-01b","class":"basic","parts":[{"id":"pss-06-01b_stmt","name":"statement","prose":"To protect confidentiality, availability, integrity and authenticity during interactions with the cloud service, a suitable session management system is used that corresponds to the established rules of technology and is protected against known attacks."},{"id":"pss-06-01b_guidance-1","name":"guidance","prose":"Known attacks include manipulation, forgery, session takeover, Denial of Service attacks, enveloping, replay and null cipher attacks."}],"title":"PSS-06 Basic 01B"},{"id":"pss-06-02b","class":"basic","parts":[{"id":"pss-06-02b_stmt","name":"statement","prose":"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 service customer."}],"title":"PSS-06 Basic 02B"}]},{"id":"pss-07","parts":[{"id":"pss-07-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they use sufficiently secure passwords (cf. IAM-08) and employ the procedures provided by the cloud service provider to protect the confidentiality of the passwords according to their own assessment, and that the risks of unauthorised access associated with their own choice are borne. If cloud service customers operate virtual machines or containers with the cloud service, they ensure with suitable controls that the confidentiality of the information is also ensured for the allocation of authentication information of the virtual machines or containers.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Confidentiality of Authentication Information","controls":[{"id":"pss-07-01b","class":"basic","parts":[{"id":"pss-07-01b_stmt","name":"statement","prose":"If passwords are used as authentication information for the cloud service, the cloud service provider provides the cloud service customers with the following procedures to protect the confidentiality of the passwords:\n\n1. 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;\n2. When creating passwords, compliance with the length and complexity requirements of the cloud service provider (cf. IAM-08) or the cloud service customer is technically enforced;\n3. The user is informed about changing or resetting the password. Password reset procedures are valid for at most 48 hours. After the reset procedure has been used, the password is to be changed by the user; and\n4. The server-side storage uses hash functions in combination with salt values, both corresponding to the state of the art."},{"id":"pss-07-01b_guidance-1","name":"guidance","prose":"The state of the art regarding cryptographic hash functions is described in the current version of the BSI Technical Guideline TR-02102-1 'Cryptographic Mechanisms: Recommendations and Key Lengths'."}],"title":"PSS-07 Basic 01B"},{"id":"pss-07-02b","class":"basic","parts":[{"id":"pss-07-02b_stmt","name":"statement","prose":"Rules and recommendations are shared with the cloud service customers as applicable to the users under their responsibility. The cloud service provider offers the cloud service customers tools for the management and enforcement of these rules."}],"title":"PSS-07 Basic 02B"},{"id":"pss-07-03b","class":"basic","parts":[{"id":"pss-07-03b_stmt","name":"statement","prose":"When distributing credentials, the cloud service provider verifies the recipient's identity, validates the request and protects the credentials by using additional security mechanisms such as multi-factor authentication."}],"title":"PSS-07 Basic 03B"}]},{"id":"pss-08","parts":[{"id":"pss-08-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that:\n\n1. They actively utilise the roles and rights framework and accompanying functionalities offered by the cloud service provider;\n2. The granting of permissions to users in their area of responsibility is subject to authorisation; and\n3. 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. personnel resignation).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Roles and Rights Framework","controls":[{"id":"pss-08-01b","class":"basic","parts":[{"id":"pss-08-01b_stmt","name":"statement","prose":"The cloud service provided comprises a roles and rights framework for users of the cloud service customer. This framework allows users to manage their own access rights. It describes access rights and roles for the functions provided by the cloud service. Cloud service customers can configure relevant access control parameters themselves."},{"id":"pss-08-01b_guidance-1","name":"guidance","prose":"In IaaS, a role and rights framework would describe, among other things, the access rights and roles for the following functions of the cloud service:\n\n1. Administration of the states of virtual machines (start, pause, stop) as well as for their migration or monitoring;\n2. Management of available images that can be used to create virtual machines; and\n3. Management of virtual networks (e.g. configuration of virtual routers and switches)."}],"title":"PSS-08 Basic 01B"},{"id":"pss-08-02b","class":"basic","parts":[{"id":"pss-08-02b_stmt","name":"statement","prose":"The access rights and roles are suitable for enabling users of the cloud service customer 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 ('segregation of duties')."}],"title":"PSS-08 Basic 02B"},{"id":"pss-08-03b","class":"basic","parts":[{"id":"pss-08-03b_stmt","name":"statement","prose":"The cloud service provided is equipped with a functionality to help cloud service customers review user access rights under their responsibility."},{"id":"pss-08-03b_guidance-1","name":"guidance","prose":"This functionality can e.g. include gaining a list of all roles and accesses the cloud service customer has activated and when they were changed the last time."}],"title":"PSS-08 Basic 03B"},{"id":"pss-08-04b","class":"basic","parts":[{"id":"pss-08-04b_stmt","name":"statement","prose":"In case the cloud service includes the management of customer identities, for a given customer identity, the cloud service provided is equipped with a functionality to provide the list of access rights currently granted to that identity according to the contractual terms."}],"title":"PSS-08 Basic 04B"}]},{"id":"pss-09","parts":[{"id":"pss-09-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that system components under their responsibility are regularly checked for vulnerabilities and to mitigate these by appropriate measures.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Authorisation Mechanisms","controls":[{"id":"pss-09-01b","class":"basic","parts":[{"id":"pss-09-01b_stmt","name":"statement","prose":"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."}],"title":"PSS-09 Basic 01B"},{"id":"pss-09-02b","class":"basic","parts":[{"id":"pss-09-02b_stmt","name":"statement","prose":"The cloud service provider validates the functionality of the authorisation mechanisms before new functions are made available to cloud service customers and in the event of changes to the authorisation mechanisms of existing functions (cf. DEV-07)."}],"title":"PSS-09 Basic 02B"},{"id":"pss-09-03b","class":"basic","parts":[{"id":"pss-09-03b_stmt","name":"statement","prose":"If validation activities reveal vulnerabilities, the procedures for identifying vulnerabilities (cf. PSS-02) are applied and measures for timely remediation or mitigation are initiated."}],"title":"PSS-09 Basic 03B"},{"id":"pss-09-01ac","class":"additional-complement","parts":[{"id":"pss-09-01ac_stmt","name":"statement","prose":"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)."}],"title":"PSS-09 Additional Complement 01AC"}]},{"id":"pss-10","parts":[{"id":"pss-10-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that they validate the functionality of SDN features for their individual use cases before using newly introduced capabilities or modifed existing ones.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Software Defined Networking","controls":[{"id":"pss-10-01b","class":"basic","parts":[{"id":"pss-10-01b_stmt","name":"statement","prose":"If the cloud service offers functions for software-defined networking (SDN), the confidentiality of cloud service customer data is ensured by suitable SDN procedures."},{"id":"pss-10-01b_guidance-1","name":"guidance","prose":"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."}],"title":"PSS-10 Basic 01B"},{"id":"pss-10-02b","class":"basic","parts":[{"id":"pss-10-02b_stmt","name":"statement","prose":"The cloud service provider validates the functionality of the SDN functions before providing new SDN features to cloud service customers or modifying existing SDN features. Identified defects are assessed and corrected in a risk-oriented manner."},{"id":"pss-10-02b_guidance-1","name":"guidance","prose":"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."}],"title":"PSS-10 Basic 02B"}]},{"id":"pss-11","parts":[{"id":"pss-11-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls 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.","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Images for Virtual Machines and Containers","controls":[{"id":"pss-11-01b","class":"basic","parts":[{"id":"pss-11-01b_stmt","name":"statement","prose":"If cloud service customers operate virtual machines or containers with the cloud service, the cloud service provided is equipped with functionalities that ensure the following aspects:\n\n1. Cloud service customers can restrict the selection of images of virtual machines or containers according to their specifications, so that users of the cloud service customer can only launch the images or containers released according to these restrictions;\n2. If the cloud service provider provides images of virtual machines or containers to the cloud service customer, the cloud service provider appropriately informs the cloud service customer of the changes made to the previous version;\n3. Images provided by the cloud service provider are labelled with information regarding their origin; and\n4. Images provided by the cloud service provider are hardened according to generally accepted industry standards."},{"id":"pss-11-01b_guidance-1","name":"guidance","prose":"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-Compendium."}],"title":"PSS-11 Basic 01B"},{"id":"pss-11-01ac","class":"additional-complement","parts":[{"id":"pss-11-01ac_stmt","name":"statement","prose":"The cloud service provider checks the integrity and authenticity of virtual machines or container images at startup and informs the cloud service customer accordingly about the results of those checks."},{"id":"pss-11-01ac_guidance-1","name":"guidance","prose":"Typical measures for checking virtual machines or container images against integrity and authenticity include cryptographical signing."}],"title":"PSS-11 Additional Complement 01AC"},{"id":"pss-11-02ac","class":"additional-complement","parts":[{"id":"pss-11-02ac_stmt","name":"statement","prose":"During runtime, the cloud service provider protects the virtual machines or container images against tampering and informs the cloud service customer accordingly about the status during runtime."}],"title":"PSS-11 Additional Complement 02AC"}]},{"id":"pss-12","parts":[{"id":"pss-12-corresponding","name":"corresponding","prose":"Cloud service customers ensure with suitable controls that, when selecting service providers and configuring the cloud service, they are informed about the available data processing and storage partitions and, if there is a choice between different partitions, 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 service customers take the laws of their own jurisdiction applicable to them into account when making their selection (e.g. when processing personal data; compliance with legal retention obligations for business documents, etc.).","title":"Corresponding Requirements for Cloud Service Customers"}],"title":"Region of Data Processing and Storage","controls":[{"id":"pss-12-01b","class":"basic","parts":[{"id":"pss-12-01b_stmt","name":"statement","prose":"The architecture of the cloud service, including the technical design of its infrastructure, ensures that cloud service customer data and eventual data backups thereof are processed and stored only in the region specified in the contractual agreements with the cloud service provider. If the cloud service customer is able to select from multiple regions, processing and storage of the aforementioned data is limited to the selected regions."},{"id":"pss-12-01b_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Basic 01B"},{"id":"pss-12-02b","class":"basic","parts":[{"id":"pss-12-02b_stmt","name":"statement","prose":"Processing and storage of cloud service customer data within the service organisations of the cloud service provider also adheres to the regions selected by the cloud service customer."},{"id":"pss-12-02b_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Basic 02B"},{"id":"pss-12-03b","class":"basic","parts":[{"id":"pss-12-03b_stmt","name":"statement","prose":"The contractual agreements specify the regions in which processing and storage of cloud service customer data, cloud service derived data and account data occurs and the circumstances under which changes may be applied."},{"id":"pss-12-03b_guidance-1","name":"guidance","prose":"This criterion refers to the architecture of the cloud service and does not put any constraints on the architecture the cloud service customer designs. \n\nIf a cloud service provider has several regions that provide the same service, the cloud service customer is free to use the service in different regions (e.g. for more resilience). \n\nThis subcriterion refers to contractual agreements which include the pledge for cloud service customer data, cloud service derived data, cloud service provider data and account data to reside in the chosen region. It also covers how contractual agreements are updated, ensuring transparent communication and continued residency for all four types of data in the agreed region(s)."},{"id":"pss-12-03b_guidance-2","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Basic 03B"},{"id":"pss-12-04b","class":"basic","parts":[{"id":"pss-12-04b_stmt","name":"statement","prose":"Customers are notified beforehand in case of any changes to the regions in which the aforementioned data is processed or stored. If the cloud service provider has not been granted prior general authorisation by the cloud service customer to do so, such authorisations are obtained in accordance with the requirements specified in the contractual agreements or let the cloud service customer exercise termination rights."},{"id":"pss-12-04b_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Basic 04B"},{"id":"pss-12-01as","class":"additional-sharpen","parts":[{"id":"pss-12-01as_stmt","name":"statement","prose":"The architecture of the cloud service, including the technical design of its infrastructure, ensures that the cloud service customer data, cloud service derived data and eventual data backups thereof are processed and stored only in the region specified in the contractual agreements with the cloud service provider. If the cloud service customer is able to select from multiple regions, processing and storage of the aforementioned data is limited to the selected regions."},{"id":"pss-12-01as_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"props":[{"name":"sharpened-basic-criterion","value":"01B"}],"title":"PSS-12 Additional Sharpen 01AS"},{"id":"pss-12-02as","class":"additional-sharpen","parts":[{"id":"pss-12-02as_stmt","name":"statement","prose":"Processing and storage of cloud service customer data and cloud service derived data within the service organisations of the cloud service provider also adheres to the regions selected by the cloud service customer."}],"props":[{"name":"sharpened-basic-criterion","value":"02B"}],"title":"PSS-12 Additional Sharpen 02AS"},{"id":"pss-12-01ac","class":"additional-complement","parts":[{"id":"pss-12-01ac_stmt","name":"statement","prose":"The cloud service provider offers partitions selectable by the cloud service customer where partition-specific identity management is enforced for both cloud service customers and all cloud service provider personnel. Identity verification and identity storage are confined to the geographical boundaries of the selected partition."},{"id":"pss-12-01ac_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Additional Complement 01AC"},{"id":"pss-12-02ac","class":"additional-complement","parts":[{"id":"pss-12-02ac_stmt","name":"statement","prose":"Within these partitions, the following operations by the cloud service provider are restricted to occur only within the geographical boundaries of the customer-selected partitions: \n\n1. Privileged access to the production environment by the cloud service provider, including potential access to cloud service customer data and cloud service derived data; \n2. System logging and event monitoring by the cloud service provider, except for processing event logs specifically for threat intelligence and handling IP addresses for routing purposes; and\n3. Cryptographic key management and storage practices to ensure keys are handled and stored within limits of the partition. \n\nThese restrictions considering partitions also apply to any service organisations involved in the operation of the cloud service."},{"id":"pss-12-02ac_guidance-1","name":"guidance","prose":"This criterion supplements the General Condition GC-01. It does not require the cloud service provider to offer multiple regions or partitions. If the cloud service provider offers only one partition for the cloud service(s) in scope, this does not comprise a deviation from the criterion.\n\nIf the additional complemental criterion is only applicable for selected partitions in scope of an assurance engagement in accordance with this catalogue, this should be presented in the cloud service provider's description of its system of internal control for the cloud service.\n\nThis criterion is a prerequisite for technical service sovereignty.\n\nMonitoring of threat intelligence data, which excludes any cloud service customer data and account data, and logging of required routing information such as IP addresses are not required to be geographically limited to a single partition."}],"title":"PSS-12 Additional Complement 02AC"}]}]},{"id":"gc","title":"GC (GC)","controls":[{"id":"gc-undefined","title":"Information on applicable law, jurisdiction, countries, partitions, regions, zones and locations"},{"id":"gc-undefined","title":"Information on availability and incident handling during regular operation"},{"id":"gc-undefined","title":"Information on recovery parameters in emergency operation"},{"id":"gc-undefined","title":"Information on the approach to ensuring service availability"},{"id":"gc-undefined","title":"Information on how investigation requests from government agencies are handled"},{"id":"gc-undefined","title":"Information on certifications or attestations"}]}]}}