Cloud Computing Compliance Criteria Catalogue - C5:2020

Cloud Computing
Compliance
Criteria Catalogue – C5:2020
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | PREFACE BY THE PRESIDENT
Preface by the President

In recent years, the BSI’s C5 requirements cat- When the BSI announced that it would be
alogue has developed into a leading force that revising the C5 at the beginning of 2019, it also
drives and supports cyber security in one of the inquired about the experience of Cloud Service
most important fields of digitisation: cloud com- Providers, customers and auditors. The response
puting. For digitisation to succeed, it is of great was incredibly positive. Many different groups,
importance that cloud services have a proven and associations and even competing vendors and
generally accepted level of security. auditors participated in joint workshops led by
BSI, sharing their experiences and making con-
When I was appointed to the BSI in 2016, I structive suggestions for improving the C5. I
was responsible for the adoption of the first C5 would like to take this opportunity to thank them
requirements catalogue. It was one of the first all!
things I did, and I noticed that the BSI was break-
ing new ground in this area. The BSI has defined The result is impressive. Besides countless updates
security objectives but has left open how they will and improvements, I would like to highlight the
be achieved. The BSI does not carry out C5 audits, following:
rather it is auditors who have added cloud secu-
rity aspects to their existing audit portfolio with 1. The new C5 implements the general require-
C5. It is difficult to standardise concrete individual ments of the EU Cybersecurity Act (EUCA).
measures in different cloud architectures, but it is This European regulation describes require-
possible to agree on common security objectives ments for IT products and services that are
which have found their way into the C5. Such certified according to an EUCA-compliant
audits cannot be carried out by a national author- procedure. These requirements have been
ity alone, or at least not easily. Since cloud services incorporated into the C5:2020 and are sum-
are usually provided globally, audits are carried marised in the new domain of product secu-
out by internationally reliable partners. rity.
The international success story of C5 shows that 2. The interfaces between Cloud Service Provid-
the decisions made at that time were correct. ers and cloud users plays an important role in
Many national and international Cloud Ser- the secure use of cloud services. The C5:2020
vice Providers, both small and large, have now introduces “corresponding criteria” that the
received a C5 audit certificate, and many cloud cloud customer must meet at the interfaces
customers outside the public sector are asking to the cloud service in order to play its part in
for the certificates to assess the security of the the shared responsibility for security.
cloud services used. Furthermore, C5 certificates
are used and accepted as verification in regulated This further extends the role of C5 as a founda-
areas such as banking and insurance. As a result, tion for cloud security for providers, customers
the BSI has earned itself an important role as a and auditors. As such, it will continue to serve as a
shaper of information security in digitisation in good example of how information security can be
the cloud area, which is accepted and appreciated shaped in the digital age.
worldwide.
1
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | TABLE OF CONTENTS
Table of Contents
Preface by the President 1
1 Introduction 9
1.1 Preliminary remarks 10
1.2 Definitions 11
2 Structure and Content of the Criteria 13
2.1 Structure 14
2.2 Content of the C5 Criteria 15
2.3 Underlying Standards and Publications 16
3 Providing Conformity through Independent Audits 18
3.1 Introduction 19
3.2 Audit Standards to be Applied 19
3.3 Connection to Other Audits 20
3.4 Supplementary Requirements of the BSI 20
3.4.1 Audit Engagement 20
3.4.2 Criteria to be Applied 21
3.4.3 Subject Matter and Objective of the Audit 21
3.4.4 Requirements for the Description

and the Written Statement 22
3.4.5 Consideration of Subservice Organisations 24
3.4.6 Assessing the Fulfilment of Criteria

at an Attestation Engagement 25
3.4.7 Deviation Handling 25
3.4.8 Reporting 26
3.4.9 Qualification of the Auditor 26
3.4.10 Information on Limitation of Liability 27
3.5 Dealing with Criteria Catalogue Updates 27
2
4 Information on the General Conditions of the Cloud Service 29
BC-01 Information on jurisdiction and locations 30
BC-02 Information on availability and

incident handling during regular operation 30
BC-03 Information on recovery parameters

in emergency operation 31
BC-04 Information on the availability of the data centre 31
BC-05 Information on how investigation enquiries

from government authorities are handled 32
BC-06 Information on certifications or attestations 33
5 Basic Criteria, Additional Criteria and Supplementary Information 34
5.1 Organisation of Information Security (OIS) 35
OIS-01 Information Security Management System

(ISMS)35
OIS-02 Information Security Policy 35
OIS-03 Interfaces and Dependencies 36
OIS-04 Segregation of Duties 37
OIS-05 Contact with Relevant Government Agencies

and Interest Groups 37
OIS-06 Risk Management Policy 38
OIS-07 Application of the Risk Management Policy 39
5.2 Security Policies and Instructions (SP) 39
SP-01 Documentation, communication and

provision of policies and instructions 39
SP-02 Review and Approval of Policies and Instructions 41
SP-03 Exceptions from Existing Policies and Instructions 41
5.3 Personnel (HR) 42
HR-01 Verification of qualification and trustworthiness 42
HR-02 Employment terms and conditions 43
HR-03 Security training and awareness programme 44
HR-04 Disciplinary measures 44
HR-05 Responsibilities in the event of termination

or change of employment 45
HR-06 Confidentiality agreements 46
3
5.4 Asset Management (AM) 46
AM-01 Asset Inventory 46
AM-02 Acceptable Use and Safe Handling of Assets Policy 48
AM-03 Commissioning of Hardware 48
AM-04 Decommissioning of Hardware 49
AM-05 Commitment to Permissible Use, Safe Handling

and Return of Assets 50
AM-06 Asset Classification and Labelling 50
5.5 Physical Security (PS) 51
PS-01 Physical Security and Environmental Control

Requirements51
PS-02 Redundancy model 53
PS-03 Perimeter Protection 54
PS-04 Physical site access control 54
PS-05 Protection from fire and smoke 55
PS-06 Protection against interruptions caused

by power failures and other such risks 56
PS-07 Surveillance of operational and

environmental parameters 57
5.6 Operations (OPS) 58
OPS-01 Capacity Management – Planning 58
OPS-02 Capacity Management – Monitoring 58
OPS-03 Capacity Management – Controlling

of Resources 59
OPS-04 Protection Against Malware – Concept 60
OPS-05 Protection Against Malware – Implementation 60
OPS-06 Data Backup and Recovery – Concept 61
OPS-07 Data Backup and Recovery – Monitoring 62
OPS-08 Data Backup and Recovery – Regular Testing 62
OPS-09 Data Backup and Recovery – Storage 63
OPS-10 Logging and Monitoring – Concept 63
OPS-11 Logging and Monitoring – Metadata

Management Concept 64
OPS-12 Logging and Monitoring – Access, Storage

and Deletion 65
4
OPS-13 Logging and Monitoring – Identification

of Events 65
OPS-14 Logging and Monitoring – Storage

of the Logging Data 66
OPS-15 Logging and Monitoring – Accountability 66
OPS-16 Logging and Monitoring – Configuration 67
OPS-17 Logging and Monitoring – Availability

of the Monitoring Software 67
OPS-18 Managing Vulnerabilities, Malfunctions

and Errors – Concept 68

and Errors – Penetration Tests 68

and Errors – Measurements, Analyses and Assessments
of Procedures 69
OPS-21 Involvement of Cloud Customers

in the Event of Incidents 69
OPS-22 Testing and Documentation of known

Vulnerabilities70

and Errors – System Hardening 71
OPS-24 Separation of Datasets in the Cloud

Infrastructure72
5.7 Identity and Access Management (IDM) 72
IDM-01 Policy for user accounts and access rights 72
IDM-02 Granting and change of user accounts

and access rights 74
IDM-03 Locking and withdrawal of user accounts

in the event of inactivity or multiple failed logins 74
IDM-04 Withdraw or adjust access rights

as the task area changes 75
IDM-05 Regular review of access rights 75
IDM-06 Privileged access rights 76
IDM-07 Access to cloud customer data 76
IDM-08 Confidentiality of authentication information 77
IDM-09 Authentication mechanisms 78
5
5.8 Cryptography and Key Management (CRY) 79
CRY-01 Policy for the use of encryption procedures

and key management 79
CRY-02 Encryption of data for transmission

(transport encryption) 79
CRY-03 Encryption of sensitive data for storage 80
CRY-04 Secure key management 81
5.9 Communication Security (COS) 82
COS-01 Technical safeguards 82
COS-02 Security requirements for connections

in the Cloud Service Provider’s network 82
COS-03 Monitoring of connections

in the Cloud Service Provider’s network 83
COS-04 Cross-network access 84
COS-05 Networks for administration 84
COS-06 Segregation of data traffic in jointly used

network environments 84
COS-07 Documentation of the network topology 85
COS-08 Policies for data transmission 86
5.10 Portability and Interoperability (PI) 86
PI-01 Documentation and safety of input

and output interfaces 86
PI-02 Contractual agreements for the provision of data 87
PI-03 Secure deletion of data 88
5.11 Procurement, Development and Modification

of Information Systems (DEV) 89
DEV-01 Policies for the development/procurement

of information systems 89
DEV-02 Outsourcing of the development 89
DEV-03 Policies for changes to information systems 90
DEV-04 Safety training and awareness programme

regarding continuous software delivery and associated
systems, components or tools. 91
DEV-05 Risk assessment, categorisation

and prioritisation of changes 91
DEV-06 Testing changes 92
6
DEV-07 Logging of changes 93
DEV-08 Version Control 93
DEV-09 Approvals for provision in the production

environment93
DEV-10 Separation of environments 94
5.12 Control and Monitoring of Service Providers and Suppliers

(SSO)95
SSO-01 Policies and instructions for controlling

and monitoring third parties 95
SSO-02 Risk assessment of service providers

and suppliers 96
SSO-03 Directory of service providers and suppliers 97
SSO-04 Monitoring of compliance with requirements 97
SSO-05 Exit strategy for the receipt of benefits 99
5.13 Security Incident Management (SIM) 100
SIM-01 Policy for security incident management 100
SIM-02 Processing of security incidents 101
SIM-03 Documentation and reporting

of security incidents 101
SIM-04 Duty of the users to report security incidents

to a central body 102
SIM-05 Evaluation and learning process 102
5.14 Business Continuity Management (BCM) 103
BCM-01 Top management responsibility 103
BCM-02 Business impact analysis policies

and instructions 103
BCM-03 Planning business continuity 104
BCM-04 Verification, updating and testing

of the business continuity 105
5.15 Compliance (COM) 106
COM-01 Identification of applicable legal, regulatory,

self-imposed or contractual requirements 106
COM-02 Policy for planning and conducting audits 107
COM-03 Internal audits of the information security

management system 107
7
COM-04 Information on information security

performance and management assessment
of the ISMS 108
5.16 Dealing with investigation requests from government

agencies (INQ) 109
INQ-01 Legal Assessment of Investigative Inquiries 109
INQ-02 Informing Cloud Customers about

Investigation Requests 109
INQ-03 Conditions for Access to or Disclosure

of Data in Investigation Requests 110
INQ-04 Limiting Access to or Disclosure

of Data in Investigation Requests 110
5.17 Product Safety and Security (PSS) 111
PSS-01 Guidelines and Recommendations

for Cloud Customers 111
PSS-02 Identification of Vulnerabilities

of the Cloud Service 112
PSS-03 Online Register of Known Vulnerabilities 113
PSS-04 Error handling and Logging Mechanisms 114
PSS-05 Authentication Mechanisms 114
PSS-06 Session Management 115
PSS-07 Confidentiality of Authentication Information 116
PSS-08 Roles and Rights Concept 116
PSS-09 Authorisation Mechanisms 117
PSS-10 Software Defined Networking 118
PSS-11 Images for Virtual Machines and Containers 118
PSS-12 Locations of Data Processing and Storage 119
Errata120
8
1 Introduction
9
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Introduction
1 Introduction
1.1 Preliminary remarks • Extension of the criteria for the provision of

cloud services to include product-specific
As the federal cyber security authority, the Fed- aspects of information security. These are
eral Office for Information Security (BSI) shapes derived from the European Cybersecurity Act;
information security in digitisation through pre-
vention, detection and reaction for government, • Extension of the criteria for the provision of
business and society. Digitisation can only be cloud services to include aspects relating to
successful if users can develop confidence in (new) the cloud provider’s handling of enquiries
technologies and use them safely and securely for from government agencies.
their benefit.
• Inclusion of corresponding criteria for cloud
The use of cloud computing has increased steadily customers. These show where cloud custom-
in recent years and has become an established ers need to develop their own measures to
standard for the service and delivery model of ensure the security of the cloud service.
IT services. Cloud computing is based on a high
degree of standardisation of hardware and soft- • Additional guidance and information to
ware, as well as the services based on it, the details better understand and continuously audit the
of which are usually not known to the customer. criteria; and,
As a result, the Cloud Service Providers must
establish a particularly high level of trust. • Extension of the existing audit engagement
type ‘attestation engagement’ with the option
In 2016, the BSI published this criteria catalogue for a ‘direct engagement’.
for assessing the information security of cloud
services in order to establish this trust. Established The name was changed from “Controls Cat-
standards for information security (e.g. ISO/ alogue” to “Criteria Catalogue”. This was in
IEC 27001 and the Cloud Controls Matrix of the response to the fact that Cloud Service Providers
Cloud Security Alliance) formed the basis for the rarely transferred the controls set out in the Con-
criteria and made it possible for auditors to carry trols Catalogue directly into their service-related
out audits in accordance with international audit internal control systems. Instead, the controls
standards. contained in the Cloud Service Providers’ ser-
vice-related internal control system were tested
With the first revision of the contents of the to see whether they provided the same level as
criteria catalogue, the BSI aims to take account of the level of the controls set out in the Controls
developments in this environment. The BSI has Catalogue. Hence, they already provided criteria
also initiated dialogue with providers of cloud for a control system, which is now reflected by the
computing services, customers, auditors and renaming. The English name was also changed to
regulators in order to take up their suggestions. “Cloud Computing Compliance Criteria Cat-
The following aspects represent the main changes alogue”; therefore, the abbreviation “C5” was
compared to the previous version of this criteria retained.
catalogue:
The structure and content of this criteria cata-
• Change or extension of the criteria regarding logue are presented in Section 2. Guidance on
new concepts, i.e. “DevOps” as the conver- demonstrating conformity with this criteria
gence of the development and operation of IT catalogue is provided in Section 3. The criteria for
systems;
10
independent audits can be found in Sections 4 vice Provider for the purpose of using the cloud
and 5. service.
The criteria in this criteria catalogue are appli- Hardware-objects: Physical and virtual infra-
cable to periods ending on or after February 15, structure resources (e.g. servers, storage systems,
2021. Cloud Service Providers can apply the crite- network components), as well as end point
ria earlier than this date. devices if the Cloud Service Provider has deter-
mined in a risk assessment that these could
endanger the information security of the cloud
service in the event of loss or unauthorised access
1.2 Definitions (e.g. mobile devices used as security tokens for
authentication).
For the purposes of this criteria catalogue, the
following definitions apply, derived from the BSI’s Information Security: Protection of the infor-
IT-Grundschutz-Kompendium and the interna- mation the Cloud Service Provider’s customers
tional standard ISO/IEC 17788:2014 (Information processed, stored or transmitted in the cloud
Technology – Cloud Computing – Overview and service with respect to the protection objectives of
Vocabulary): confidentiality, integrity, availability and authen-
ticity.
Assets: In this criteria catalogue, this term is used
synonymously with the term “system compo- Integrity: The ability of information to be com-
nents” (cf. below). plete, accurate (correct, undamaged) and pro-
tected from manipulation and unintentional or
Authenticity: Feature of information in which erroneous alteration.
changes can be uniquely assigned to an originator.
Protection needs: Sufficient and adequate level
Availability: The accessibility of information, of information security for the Cloud Service
services, and functions of an IT system, IT applica- Provider’s customers with respect to the informa-
tions or IT networks as intended. tion processed, stored or transmitted in the cloud
service.
Cloud Computing: Approach for the dynamic
provision, use and billing of IT services via a System components: The objects required for the
network, adapted to demand. These services are information security of the cloud service during
offered and used exclusively via defined technical the creation, processing, storage, transmission,
interfaces and protocols. deletion or destruction of information in the
Cloud Service Provider’s area of responsibility, e.g.
Cloud service: Information technology service firewalls, load balancers, web servers, application
offered as part of cloud computing. This includes servers and database servers.
infrastructure (e.g. computing power, storage
space), platforms and software. Furthermore, the following definitions apply,
based on the International Standard on Assurance
Cloud Service Provider: Natural or legal person Engagements (ISAE) 3000 (Revised) ”Assurance
providing a cloud service. Engagements Other than Audits or Reviews of
Historical Financial Information” and ISAE 3402
Confidentiality: The ability of information to be ”Assurance Reports on Controls at a Service
made available or disclosed only to authorised Organization”.
persons, entities and processes in a permissible
manner. Attestation engagement: An audit engagement
under which the auditor verifies that the written
Cloud customer: Natural or legal person who statement is free from material misstatement.
has a business relationship with the Cloud Ser-
11
C5 criteria: The criteria applied to assess the to assess the information security of the cloud
information security of the cloud service and service; or
defined in this catalogue of criteria (cf. Section 5).
• Information includes inappropriate gen-
Control: Process-integrated or process-independ- eralisations or unbalanced and distorting
ent measure to reduce the likelihood of events representations that may mislead the Cloud
occurring or to detect events that have occurred Service Provider’s customers.
in order to maintain the information security of
the cloud service. Service Organisation’s System: The principles,
procedures and measures applied by the legal rep-
Direct engagement: An audit engagement in resentatives (management) of the Cloud Service
which the practitioner (auditor) audits the cloud Provider towards the organisational and technical
service as the underlying subject matter against implementation of management decisions to
the C5 criteria and presents the resulting subject ensure the effectiveness and efficiency of busi-
matter information as part of its reporting. ness activities, the information security of the
Cloud Service and compliance with the legal and
Material misstatement: deficiencies in the state- other regulations applicable to the Cloud Service
ment, e.g.: Provider.
• Information does not indicate that controls Written statement: Assertions on the description
are not suitably designed, not implemented of the service organisation’s system for the provi-
or not operating effectively to meet the C5 sion of the Cloud Service and on the suitability of
criteria with reasonable assurance; the design and, where relevant, operating effec-
tiveness of the controls to meet the C5 criteria
• Information is false or missing that may be prepared by the legal representatives of the Cloud
individually or collectively relevant to the Service Provider.
Cloud Service Provider’s customers in order
12
2 Structure and Content
of the Criteria
13
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Structure and Content of the Criteria
2 Structure and Content of the Criteria
2.1 Structure • Complementary Customer Criteria:

Maintaining the information security of a
This criteria catalogue contains 17 objectives cloud service is not the sole responsibility of
regarding the information security of cloud the Cloud Service Provider. Customers must
services. Each objective is broken down into the also comply with the obligations to cooperate
criteria required to achieve the objective (cf. Sec- in their area of responsibility. In the case of
tion 2.2). cloud services for infrastructure, customers
are typically responsible for bringing in secu-
The criteria are divided into basic criteria and rity updates for the operating system they are
additional criteria (C5 criteria). using, whereas this responsibility typically lies
with the Cloud Service Provider when using a
According to the BSI, the basic criteria reflect the cloud service for software.
minimum level of information security that a Selected C5 criteria contain complementary
cloud service must offer when cloud customers customer criteria where potential cooper-
use it to process information that has a normal ation obligations exist. However, this is not
need for protection. The basic criteria define the an exhaustive list that is generally valid for
minimum scope of an audit according to this all cloud services. Rather, the complemen-
criteria catalogue. Nevertheless, it is up to the tary customer criteria provide the following
cloud customers to assess for their individual use support:
case to what extent the basic criteria adequately
reflect the protection needs of their information. – The criteria support Cloud Service Provid-
For cloud customers whose information has a ers with identifying those C5 criteria that
higher need for protection, the additional crite- typically require corresponding controls on
ria provide a starting point for conducting this the cloud customer’s side which must be set
assessment. Cloud Service Providers may include up together with the controls of the Cloud
the additional criteria in an audit in addition to Service Provider in order to meet the C5
the basic criteria to address customers with higher criteria (cf. Section 3.4.4.1);
protection needs.
– The criteria support auditors with assessing
Chapter 5 contains the following elements in the system description regarding the appro-
addition to the basic criteria, additional criteria priateness of the information provided
and supplementary information: about the complementary controls; and,
• Notes on Continuous Auditing: – The criteria support cloud customers in bet-

The C5 criteria include guidance on how ter understanding the information provided
Cloud Service Providers can take actions about the complementary controls in the
towards continuous monitoring, including system description and where to set up such
independent third-party audits, by automat- controls.
ing their procedures and measures. This guid-
ance should enable Cloud Service Providers to Providing details about the controls in place at
assess the general feasibility and effort impli- the Cloud Service Provider establishes confidence
cations of a continuous third-party audit. in the information security of a cloud service.
Potential customers should consider the informa
tion on the general conditions of the cloud service
(e.g. the Cloud Service Provider’s place of jurisdic-
14
tion or contractual agreements on availability and 2.2 Content of the C5 Criteria

troubleshooting) in addition to the transparency
regarding the C5 criteria (cf. Section 2.2). Accord- The C5 criteria are subdivided into 17 areas based
ing to the BSI, potential customers of a cloud on the description of the objectives of the meas-
service must know this information in order to ures in ISO/IEC 27001:2013 Annex A (cf. Table 1).
assess its suitability for their respective use case.
No. Area (identifier) Objective
1 Organisation of Information Plan, implement, maintain and continuously improve the

Security (OIS) information security framework within the organisation.
5.1 on page 35
2 Security Policies and Provide policies and instructions regarding security

Instructions (SP) requirements and to support business requirements.
5.2 on page 39
3 Personnel (HR) Ensure that employees understand their responsibilities, are

5.3 on page 42 aware of their responsibilities regarding information security,
and that the organisation’s assets are protected in the event of
changes in responsibilities or termination.
4 Asset Management (AM) Identify the organisation’s own assets and ensure an appropriate
5.4 on page 46 level of protection throughout their lifecycle.
5 Physical Security (PS) Prevent unauthorised physical access and protect against theft,
5.5 on page 51 damage, loss and outage of operations.
6 Operations (OPS) Ensure proper and regular operation, including appropriate

5.6 on page 58 measures for planning and monitoring capacity, protection
against malware, logging and monitoring events, and dealing
with vulnerabilities, malfunctions and failures.
7 Identity and Access Secure the authorisation and authentication of users of the
Management (IDM) Cloud Service Provider (typically privileged users) to prevent
5.7 on page 72 unauthorised access.
8 Cryptography and Key Ensure appropriate and effective use of cryptography to protect
Management (CRY) the confidentiality, authenticity or integrity of information.
5.8 on page 79
9 Communication Security Ensure the protection of information in networks and the

(COS) corresponding information processing systems.
5.9 on page 82
10 Portability and Enable the ability to access the cloud service via other cloud
Interoperability (PI) services or IT systems of the cloud customers, to obtain the
5.10 on page 86 stored data at the end of the contractual relationship and to
securely delete it from the Cloud Service Provider.
15
No. Area (identifier) Objective
11 Procurement, Development Ensure information security in the development cycle of cloud

and Modification of service system components.
Information Systems (DEV)
5.11 on page 89
12 Control and Monitoring Ensure the protection of information that service providers or
of Service Providers and suppliers of the Cloud Service Provider (subservice provider)
Suppliers (SSO) can access and monitor the agreed services and security
5.12 on page 95 requirements.
13 Security Incident Ensure a consistent and comprehensive approach to the

Management (SIM) capturing, evaluation, communication and handling of security
5.13 on page 100 incidents.
14 Business Continuity Plan, implement, maintain and test procedures and measures for
Management (BCM) business continuity and emergency management.
5.14 on page 103
15 Compliance (COM) Avoid non-compliance with legal, regulatory, self-imposed or

5.15 on page 106 contractual information security and compliance requirements.
16 Dealing with investigation Ensure appropriate handling of government investigation

requests from government requests for legal review, information to cloud customers, and
agencies (INQ) limitation of access to or disclosure of data.
5.16 on page 109
17 Product Safety and Security Provide up-to-date information on the secure configuration and
(PSS) known vulnerabilities of the cloud service for cloud customers,
5.17 on page 111 appropriate mechanisms for troubleshooting and logging,
as well as authentication and authorisation of users of cloud
customers.
Table 1: Areas of the criteria catalogue with assigned objectives
2.3 Underlying Standards and Publications • ISO/IEC 27001:2013 – Information security

management systems – Requirements
Requirements of nationally and internationally
established standards and publications form the • ISO/IEC 27002:2016 – IT security procedures –
foundation of the C5 criteria. The level of detail Guidelines for information security measures
usually goes beyond these standards and publica-
tions in order to achieve a high level of transpar- • ISO/IEC 27017:2015 – Security techniques
ency about the principles, procedures and meas- – Code of practice for information security
ures of the Cloud Service Providers. controls based on ISO/IEC 27002 for cloud
services
Requirements from the following standards and
publications have been taken into account during • BSI – IT-Grundschutz-Kompendium, 2nd
the development of this criteria catalogue: Edition 2019
16
• CSA (Cloud Security Alliance, a non-profit Cloud Service Providers who already base their
organisation for the dissemination of security policies, procedures and measures on one or more
standards in cloud computing) – Cloud Con- of these standards and publications can map them
trols Matrix 3.0.1 (CSA CCM) to the C5 criteria to assess compliance.
• AICPA (American Institute of Certified Public Reference tables of the BSI support the mapping
Accountants) – Trust Services Criteria 2017 and are available on its website (https://www.
(TSC) bsi.bund.de/EN/C5). Cloud Service Providers
should consider the tables as aids when assessing
• ANSSI (Agence nationale de la sécurité des compliance. Notwithstanding the information
systèmes d’information, National Cyberse- contained in the reference tables, Cloud Service
curity Agency of France) – Providers of cloud Providers must determine to what extent existing
computing services v. 3.1 (SecNumCloud) principles, procedures and measures meet the C5
criteria on a case-by-case basis (cf. Section 3.4.6).
• IDW (Institut der Wirtschaftsprüfer, the Ger-
man Institute of Certified Public Accountants)
RS FAIT 5 – Statement on Financial Reporting:
“Principles of Orderly Accounting for the
Outsourcing of Financial Reporting-Related
Services including Cloud Computing”, as at
November 4, 2015
17
3 Providing Conformity
through Independent Audits
18
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Providing Conformity through Independent Audits
3 Providing Conformity through

Independent Audits
3.1 Introduction The BSI is not involved in any part of the audit
or reporting. The auditor carries out the audit
Cloud Service Providers and cloud customers can independently of instructions from the BSI and
use the C5 criteria set out in this criteria cata- is engaged by the Cloud Service Provider, not the
logue. While Cloud Service Providers can align cloud customer.
their policies, procedures and measures with the
C5 criteria, cloud customers will have the objec-
tive to verify whether the Cloud Service Provider
meets these criteria. However, a self-assessment 3.2 Audit Standards to be Applied
for each individual customer would not be
efficient for Cloud Service Providers and would Nationally and internationally established stand-
not provide enough assurance for customers. In ards form the foundation for the design of the C5
addition, if a customer requests this information criteria and the requirements for proving con-
from several providers, a standard set of informa- formity.
tion will not be available making it difficult for a
customer to compare the information provided Specifically, the International Standard on
by the different providers. According to the BSI, Assurance Engagements (ISAE) 3000 (Revised)
an audit by an independent third party who issues “Assurance Engagements Other than Audits or
a report for the Cloud Service Provider according Reviews of Historical Financial Information”,
to international audit standards, made available to the German Audit Standard (PS) 860 “IT-Prüfung
existing and potential customers, is an appropri- außerhalb der Abschlussprüfung” of the Institut
ate and economic solution. der Wirtschaftsprüfer (IDW), which is in line with
ISAE 3000 (Revised), or other national equivalents
For this reason, the BSI sets out below its view to ISAE 3000 (Revised). Auditors should consider
of the requirements for proof of conformity and one of these standards or national equivalent as a
reporting to the Cloud Service Provider and its basis for audit planning, execution and reporting.
customers.
Auditors should consider further audit standards
The cloud customer should consider compliance for individual questions of audit execution and
with the criteria set out in this criteria catalogue reporting. These include ISAE 3402 “Assurance
as an integral part of engaging a Cloud Service Reports on Controls at a Service Organization”,
Provider. Further, the cloud customer should the German IDW PS 951 n.F. „Die Prüfung des
agree this in the contract with the Cloud Service internen Kontrollsystems bei Dienstleistungsun-
Provider. In particular, this applies if the Cloud ternehmen”, which is in line with ISAE 3402, or
Service Provider has to fulfil the additional cri- other national equivalents to ISAE 3402. Require-
teria. Furthermore, the potential cloud customer ments for the contents of the description of the
should not base its decision only on an existing, service organisation’s system, which is part of the
up-to-date reporting (regardless of whether it audit report, were derived from these standards
refers to the basic or additional criteria) according (cf. Section 3.4.4.1).
to this criteria catalogue but should request the
audit report regularly and evaluate it for their In addition, the audit standard AT-C section 105
individual use case. “Concepts Common to All Attestation Engage-
ments” and AT-C section 205 “Examination
19
Engagements” of AICPA, the American Institute In the reference tables, the C5 criteria are mapped
of Certified Public Accountants, have been taken to the criteria defined in other standards. It should
into account. These standards supplement ISAE be noted that a mapping initially only reflects
3402 and IDW PS 951 especially with require- the thematic relationship between the criteria.
ments for the consideration of subservice organ- In addition, it is indicated to what extent the C5
isations. criteria reflect the level of information security
articulated by the mapped criteria according to
the BSI.
3.3 Connection to Other Audits The tables are only an aid to understand the
extent to which the C5 criteria overlap with the
Nationally and internationally established stand- criteria defined in other standards. As such, it is
ards form the foundation for the design of the C5 not possible to conclude the actual coverage of
criteria (cf. Section 2.3). If the Cloud Service Pro- the C5 criteria by policies, procedures and meas-
vider uses the references to established standards ures implemented by a Cloud Service Provider
and publications, the provider has already consid- solely from the mapping given in the reference
ered the corresponding principles, procedures and tables. This applies even if the established poli-
measures in its operations. cies, procedures and measures have already been
audited against one or more of the standards
These principles, procedures and measures typ- contained in the reference table. According to the
ically also form the basis for additional audits, BSI, it must always be assessed individually and
which the Cloud Service Provider may already specifically to what extent the policies, procedures
have carried out by independent auditors. In this and measures set up by a Cloud Service Provider
context, especially audits according to ISAE 3402/ actually cover the C5 criteria.
SOC 1 or SOC 2 should be mentioned. In these
cases, it makes sense to combine these audits with The mere reference to the criteria defined in other
an audit according to this criteria catalogue in standards to which the C5 criteria are mapped in
terms of organisation and time. This enables audi- the reference tables is not enough.
tors and Cloud Service Providers to use records in
parallel for reporting according to ISAE 3402 and/ This does not affect further possibilities for the
or SOC 2, as well as for reporting according to this auditor to use the results of third parties within
criteria catalogue. the auditors responsibility.
In cases of the Cloud Service Provider obtaining

certificates (e.g. ISO/IEC 27001, ISO 22301), it is
also possible to combine the relevant audits as 3.4 Supplementary Requirements of the BSI
far as possible. The reference table defined in a
separate accompanying document to this criteria The following sections outline the application of
catalogue can be used for this purpose. the above-mentioned audit standards.
When assessing the coverage of C5 criteria by

results obtained during other audits, particular
consideration shall be given to the nature of the 3.4.1 Audit Engagement
audit and compared with the ‘reasonable assur-
ance’ required for an attestation engagement or Proof of conformity is always to be provided
a direct engagement (cf. Section 3.4.1). For exam- using the audit standard ISAE 3000 (Revised).
ple, results from ISO certification audits are to be
assessed differently from those obtained from an The ISAE 3000 (Revised) audit standard distin-
ISAE 3000 audit. guishes between audit engagements with “rea-
sonable assurance” and audit engagements with
“limited assurance”. According to the BSI, auditors
20
should perform reasonable assurance audits to Service Provider. Based on the information pro-
provide conformity with this criteria catalogue. vided by the Cloud Service Provider, the auditor
must assess to what extent the C5 criteria are not
A distinction is also made between “attestation applicable, and if applicable whether they are fully
engagements” and “direct engagements”. Both applicable or partially fulfilled. The Cloud Service
variants are suitable for proving conformity with Provider must explain in the description of the
this criteria catalogue. system if individual basic or additional criteria are
not applicable due to the nature and design of the
In addition, audits may be carried out regard- cloud service or the principles, procedures and
ing the suitability of the design or the operating measures of the Cloud Service Provider. Based on
effectiveness. According to the BSI, an operating the information provided by the Cloud Service
effectiveness audit is necessary in order to provide Provider, the auditor must assess to what extent
an appropriate opinion on the Cloud Service Pro- the C5 criteria are not applicable, and if applicable
vider’s controls to meet the C5 criteria defined in whether they are fully or partially fulfilled.
this criteria catalogue. Audit engagements on the
suitability of the design should only be carried out The applicable C5 criteria are to be presented in
in the case of an initial engagement according to the audit report’s section containing the C5 crite-
this criteria catalogue. As such, audit engagements ria, controls, test procedures and results.
on the suitability of the design only are not to be
recurring.
3.4.2.2 Further Criteria for Transparency

and Reporting
3.4.2 Criteria to be Applied
Further criteria define the information on the
3.4.2.1 Criteria for Information Security general conditions of the cloud service (cf. Sec-
of the Cloud Service tion 4) as well as the requirements concerning
the system description and written statement (cf.
According to the BSI, the basic criteria reflect the Section 3.4.4.1; this Section also provides guidance
minimum level of information security that a for the handling of the general conditions in a
cloud service must offer when cloud customers direct engagement). These further criteria serve to
use it to process information that has a normal inform customers about the information secu-
need for protection. The basic criteria define the rity of the cloud service supporting them with
minimum scope of an audit according to this assessing its suitability for their individual use
criteria catalogue. Nevertheless, it is up to the case. The further criteria also ensure the compa-
cloud customers to assess for their individual use rability of the reporting in order to make it easier
case to what extent the basic criteria adequately for customers to compare several Cloud Service
reflect the protection needs of their information. Providers or cloud services for which a C5 report
For cloud customers whose information has a has been issued.
higher need for protection, the additional criteria
can provide a starting point for conducting this
assessment. Cloud Service Providers may include
the additional criteria in an audit in addition to 3.4.3 Subject Matter and Objective of the Audit
the basic criteria to address customers with higher
protection needs. 3.4.3.1 Attestation Engagement
The Cloud Service Provider must explain in the The subject of an attestation engagement is
description of the system if individual basic or the description of the Cloud Service Provider’s
additional criteria are not applicable due to the service-related system of internal control to meet
nature and design of the cloud service or the the C5 criteria prepared by the Cloud Service
principles, procedures and measures of the Cloud Provider (“description”). The audit is based on a
21
written statement by the Cloud Service Provider’s Cloud Service Provider’s subject matter experts
management about the suitability of the design of and review relevant records and documents.
controls to meet the applicable C5 criteria as at a
specified date (type 1 report) and, if mandated, the The objective of the audit is to enable the auditor
operating effectiveness of the controls through- to provide an opinion with reasonable assurance
out a specified period (type 2 report). as to whether
The objective of the audit is to enable the auditor • the principles, procedures and measures
to provide an opinion with reasonable assurance applied by the Cloud Service Provider were
as to whether: suitable designed and implemented to meet
the applicable C5 criteria as at a specified date;
• the description fairly presents the Cloud and,
Service Provider’s service-related system of
internal control to meet the C5 criteria as at a • where mandated, the principles, procedures
specified date (type 1 report) or throughout a and measures applied operated effectively
specified period (type 2 report) and includes throughout a specified period.
the minimum content as set forth in Section
3.4.4.1 this criteria catalogue; According to the BSI, the direct engagement is
particularly suitable for Cloud Service Providers
• the controls stated in the description were who have not yet documented their service-re-
suitable designed and implemented to meet lated internal control system completely or in
the applicable C5 criteria as at a specified enough detail in a system description.
date (type 1 report) or throughout a specified
period (type 2 report); and
• where mandated (type 2 report), the controls 3.4.4 Requirements for the Description
stated in the description operated effectively and the Written Statement
throughout a specified period.
3.4.4.1 Description
According to the BSI, Cloud Service Providers
who already have a system description can reuse For an attestation engagement, the Cloud Ser-
it in audits according to this criteria catalogue. vice Provider’s service-related system of internal
However, an existing system description that control to meet the C5 criteria shall include the
meets the requirements of another standard must following minimum content in order to provide
be adapted to this criteria catalogue, as necessary. customers with sufficient transparency about the
information security of the cloud service:
• Name, type and scope of cloud services pro-

3.4.3.2 Direct Engagement vided;
In a direct engagement, the auditor takes stock of • Description of the system components for
the principles, procedures and measures applied providing the cloud service;
by the Cloud Service Provider for the cloud ser-
vice. • Information on the general conditions of the
cloud service in accordance with the criteria
In contrast to an attestation engagement, the in Section 5 this criteria catalogue, which ena-
Cloud Service Provider does not provide a ble potential customers of the Cloud Service
description. Identifying the relevant parts of the Provider to assess its suitability for their use
service-related internal control system takes place case;
during the execution of the engagement. This
typically requires the auditor to interview the • Applicable C5 criteria;
22
• Policies, procedures and measures, including – unauthorised third parties having gained
the controls implemented to provide (develop access to the data of cloud customers stored
and operate) the cloud services with respect to in the cloud service, or
the applicable C5 criteria;
– the integrity of the data stored in the cloud
• Dealing with significant events and conditions service was compromised and the protective
that represent exceptions to normal opera- measures put in place (e.g. data backup) were
tion, such as security incidents or the failure not effective,
of system components;
as well as the measures initiated by the Cloud
• Complementary customer controls assumed Service Provider to prevent such events and
in the design of the Cloud Service Provider’s conditions in the future.
controls; and
An incident is typically significant when it affects
• Functions and services with respect to the multiple cloud customers and the Cloud Ser-
applicable C5 criteria provided by subservice vice Provider informs the affected parties or the
organisations, including the type and scope public. The information about the incidents and
of such functions and services, the location of the protection measures put in place should be as
processing and storage of data, the complexity transparent as possible, without revealing vulner-
and uniqueness of the functions and services ability or potential points of attack. Furthermore,
as well as the resulting dependency of the the reporting must not jeopardise the confidenti-
Cloud Service Provider, (if carve-out method ality of information concerning individual cloud
is applied) complementary controls assumed customers and should therefore not contain a
in the design of the Cloud Service Provider’s detailed description of individual incidents.
controls, and the availability of audit reports
according to the criteria in this criteria cata- The description shall not omit or distort any
logue. information relevant to the fulfilment of the
applicable C5 criteria. This does not mean that
When auditing operating effectiveness (type 2 all aspects of the service-related internal control
reporting), the following minimum contents shall system that can be considered important from
be added to the system description: the point of view of individual customers of the
Cloud Service Provider should be presented. It
• Details on significant changes to the poli- should be noted that the description is intended
cies, procedures and measures, including the to achieve an appropriate level of transparency
controls, to govern the provisioning (devel- for a broad range of customers and that some of
opment and operation) of the Cloud Services the processes can be customised.
with respect to the applicable C5 Criteria, that
have been implemented during the period In the case of a direct engagement, the auditor
under review; shall present the above-mentioned minimum
content in all material aspects as part of the audit
• Details on significant events and conditions report so that the intended customers can obtain
that are exceptions to normal operation, that an appropriate understanding of the informa-
have occurred throughout the specified period tion security of the cloud service, including the
and have resulted in: principles, procedures and measures applied. This
includes sufficient information on the general
– contractual agreements regarding the conditions of the cloud service (cf. Section 4).
availability of the Cloud Service not being
fulfilled, or
23
3.4.4.2 Written Statement • Carve-out method: This method merely

describes the services provided by the sub-
In the written statement, management of the service organisation in accordance with the
Cloud Service Provider confirms that: minimum contents of the description (cf.
Section 3.4.4.1). The controls of the subcon-
• the description fairly presents the Cloud tractor are not presented. Instead, the service
Service Provider’s service-related system of provider’s description presents those controls
internal control to meet the C5 criteria as at a that are designed and implemented to moni-
specified date (type 1 report) or throughout a tor the operating effectiveness of the controls
specified period (type 2 report) and includes at the subservice organisation. This criteria
the minimum content as set forth in Section catalogue contains corresponding criteria in
3.4.4.1 this criteria catalogue; the area “Control and Monitoring of Service
Providers and Suppliers”.
• the controls stated in the description were
suitably designed and implemented to meet The Cloud Service Provider shall select the
the applicable C5 criteria as at a specified method to be used at its own discretion and state
date (type 1 report) or throughout a specified it accordingly in the description (cf. Section 3.4.4.1
period (type 2 report); and, on Minimum Contents of the System Descrip-
tion).
• where mandated (type 2 report), the controls
stated in the description operated effectively For the purposes of this criteria catalogue, a
throughout a specified period. service organisation is a subservice organisation if
the following two characteristics apply:
• The services provided by the service organi-

3.4.5 Consideration of Subservice Organisations sation are likely to be relevant to customers’
understanding of the applicable C5 criteria.
If necessary, the Cloud Service Provider will
outsource parts of its business processes for • Complementary controls at the service organ-
the provision of the cloud service to other ser- isation are required in combination with the
vice providers (use of subservice organisations). controls of the Cloud Service Provider, to
The Cloud Service Provider describes this in its meet the applicable C5 criteria with reasona-
description and the auditor takes this into con- ble assurance.
sideration as specified in the audit standards ISAE
3402. The standard distinguishes for an attestation If the Cloud Service Provider’s controls, including
engagement between the “inclusive method” and its controls to monitor the effectiveness of the
the “carve-out method”: service organisation’s controls, meet the applica-
ble C5 criteria with reasonable assurance, it is not
• Inclusive method: In the case of the inclusive a subservice organisation within the meaning of
method, the service-related internal con- this criteria catalogue.
trol system of the subservice organisations
is also included in the description and is in If the cloud service is provided in data centres
scope of the audit. Therefore, the auditor also operated by third parties, it is to be generally
assesses the subservice organisation’s controls assumed that the characteristics noted above
regarding the suitability of the design and, if apply and that a subservice organisation relation-
mandated, their operating effectiveness. In ship within the meaning of this criteria catalogue
this respect, the inclusive method provides exists, in particular regarding the area of “Physical
a report on the audit of the service-related Security”. The same applies, for example, to “Oper-
internal control system at the Cloud Service ations” if software is provided using the infra-
Provider and its subcontractors. structure or platform of another Cloud Service
Provider. The criterion of relevance for the user,
24
as well as the requirement of complementary • Inquiry of management of the Cloud Service

controls, typically does not apply, for example, Provider regarding their assessment of the
to business relationships of the Cloud Service cause of the identified deviation;
Provider with cleaning companies or advertising
agencies. • Assessment of the Cloud Service Provider’s
handling of the identified deviation;
In the case of a direct engagement, the above
remarks shall be applied mutatis mutandis. • Assessment whether comparable deviations
have been identified by the Cloud Service
Provider’s monitoring processes and what
measures have been taken as a result; and,
3.4.6 Assessing the Fulfilment of Criteria
at an Attestation Engagement • Verification whether compensating controls
are in place and effective to address the risks
If the Cloud Service Provider already performs arising from the deviation in such a way
audits in accordance with other standards and that the C5 criterion is met with reasonable
publications, it is possible that the controls assurance. This concerns, for example, the
presented in the description may be optimally assessment of alternative organisational and
aligned with the criteria of these standards and technical approaches of the Cloud Service
publications, but that their description does not Provider to meet the applicable C5 criteria,
fully meet all elements of the C5 criteria to which which have not been considered in the design
they are assigned. of the criteria set out in this criteria catalogue.
If the Cloud Service Provider can provide evi- Irrespective of the assessment as to whether a
dence of additional controls not previously stated deviation leads to a qualified opinion, further
in the description, but in place for non-covered information should be presented in the audit
elements of the C5 criteria, the Cloud Service Pro- report. This information is intended to enable
vider shall include these controls in the descrip- report recipients to assess whether the Cloud
tion or adjust the existing control descriptions Service Provider is taking appropriate actions to
and present these changes in an appropriate form. handle errors and optimise its policies, procedures
and actions. The following additional information
An adjustment of the description may be waived from the Cloud Service Provider shall be included
if the descriptions of the auditor’s test procedures in the audit report:
clearly state how the elements of the C5 crite-
ria not covered by the control description were • If the deviation was detected by the Cloud
audited. Such test procedures shall be marked in Service Provider itself, when and in the course
an appropriate form (e.g. “Further test procedure of which measures the deviation was detected.
for assessing full coverage of the C5 criterion”).
• If the deviation was already stated in a report
This applies mutatis mutandis to a direct engage- of a previous audit, an indication should be
ment. given of when and by what means the devi-
ation was detected, together with a separate
indication that the detection occurred in a
previous audit period. This requires that the
3.4.7 Deviation Handling auditor has access to prior reports from the
Cloud Service Provider. In case of doubt, the
Deviation handling is regulated in the audit auditor shall have the inspection of these
standards. In assessing whether applicable C5 reports separately assured in his engagement
criteria are not met due to identified deviations letter.
and whether the opinion needs to be qualified, the
auditor must consider the following procedures:
25
• The measures to be taken to remedy the devi- 3. Description of the Cloud Service Provider’s
ation in the future and when these measures service-related system of internal control to
are likely to be completed or effectively imple- meet the C5 criteria.
mented.
4. Presentation of the applicable C5 criteria, the
This additional information is not subject of associated controls (part of the description),
the audit, and, accordingly, the auditor does not test procedures performed and the individual
express an opinion thereon. For example, the test results of the auditor.
information may be provided in a separately
marked section of the Description or in the 5. Optional: Other information provided by the
optional section “5. Other Information Provided Cloud Service Provider (this information is
by the Cloud Service Provider” (cf. the following not subject of the audit, and, accordingly, the
section). auditor does not express an opinion thereon).
In case of a direct engagement, the components

2 ‘Written statement’ and 3 ‘Description’ are
3.4.8 Reporting omitted. Nevertheless, the minimum contents of
the description mentioned in Section 3.4.4.1 shall
The reporting on an attestation engagement is be presented in all material respects in the audit
based on the requirements of ISAE 3402. In the report so that the intended customers can obtain
case of a direct engagement, these are applied an appropriate understanding of the informa-
mutatis mutandis. Details are given in the follow- tion security of the cloud service, including the
ing section. principles, procedures and measures applied. This
includes sufficient information on the general
The report on an attestation engagement includes conditions of the cloud service (cf. Section 4).
the following elements: Such information shall be provided in a separate
section, e.g. “Description of the cloud service and
1. Independent auditor’s report the policies, procedures and measures applied by
the Cloud Service Provider”.
a. Scope and C5 version
The test procedures performed shall be described
b. Cloud Service Provider’s responsibility for both suitability of design (type 1 report) and
operating effectiveness (type 2 report) engage-
c. Independence and quality control of the ments.
auditor/auditing firm (including infor-
mation on compliance with qualification
requirements (cf. Section 3.4.9)
3.4.9 Qualification of the Auditor
d. Auditor‘s responsibility
According to ISAE 3000 (Revised), the auditor
e. Inherent limitations must determine before accepting an engagement
that the professional duties (for auditors in Ger-
f. Audit Opinion many § 43 WPO, German Law regulating the Pro-
fession of Wirtschaftsprüfer: Wirtschaftsprüfer-
g. Intended users and purpose ordnung), including the duty of independence, are
complied with. Based on the auditor’s knowledge
h. General terms of the engagement of the subject matter, the auditor shall assess
whether the members of the audit team entrusted
2. Written statement by the Cloud Service Pro- with the engagement have the necessary compe-
vider’s management responsible for the cloud tency and understanding of the industry as well
service(s). as capabilities to perform the audit and whether
26
sufficient experience with the relevant formal Compliance with the qualification requirements
requirements is available or can be obtained. shall be confirmed in the section “Independence
and quality control of the auditor/auditing firm”
According to the BSI, audits based on this crite- of the independent auditor’s report.
ria catalogue place special requirements on the
qualification of the auditor and the members of
the audit team. From the BSI’s point of view, the
following aspects on professional qualifications 3.4.10 Information on Limitation of Liability
and professional experience are suitable indica-
tions that these special requirements are met. According to the BSI, information on liability reg-
ulations is important information for the report
Therefore, the following aspects are to be fulfilled recipient.
by those members of the audit team who, accord-
ing to the International Standard on Quality The regulations on the auditor’s liability – in
Control (ISQC) 1 “Quality Control for Firms that the case of audits outside the scope of statutory
Perform Audits and Reviews of Financial State- reserved duties – are fundamentally based on civil
ments, and Other Assurance and Related Ser- law requirements and can be specified by contrac-
vices Engagements” or the German IDW quality tual agreement. A liability agreement can be made
assurance standard “Anforderungen an die Qual- individually or by using pre-formulated contrac-
itätssicherung in der Wirtschaftsprüferpraxis” tual conditions.
(IDW QS 1) or other national equivalents of
ISQC 1, supervision the execution and review the In this context, a reference to a liability agreement
results of the engagement (including evaluation must be made in the audit report.
of the work performed, review of the documenta-
tion and the planned reporting): The information on this can be found in the
section “General terms of the engagement” (with
• 3 years relevant professional experience with reference to other attachments if necessary).
IT audits in a public audit firm
or one of the following professional examina-

tions/certifications: 3.5 Dealing with Criteria Catalogue Updates
• Information Systems Audit and Control The BSI intends to update this criteria catalogue
Association (ISACA) – Certified Information regularly in line with general technical devel-
Systems Auditor (CISA), Certified Information opments and the ongoing development of the
Security Manager (CISM) or Certified in Risk underlying standards.
and Information Systems Control (CRISC)
In this context, Cloud Service Providers and audi-
• ISO/IEC 27001 Lead Auditor or BSI certified tors shall have sufficient time to make the nec-
ISO 27001 Auditor for audits based on BSI essary adjustments to the systems and processes
IT-Grundschutz and to the execution of the audit associated with
the updating of this criteria catalogue.
• Cloud Security Alliance (CSA) – Certificate of
Cloud Security Knowledge (CCSK) The criteria in this criteria catalogue shall be
applied for periods being assessed ending on or
• (ISC)² – Certified Cloud Security Professional after February 15, 2021. Earlier application of
(CCSP) these criteria is permitted.
At the client’s request, the auditor shall provide In the course of a specified period, it may hap-
appropriate evidence that the audit team meets pen that the assessment of the effectiveness of
the qualification requirements. the policies, procedures and measures applied
27
by the Cloud Service Provider relates both to the Cloud Service Provider shall provide additional
status before and after the implementation of information in the system description regarding
such adjustments. The system description should the necessary changes to its service-related inter-
include the adjustments made (cf. Section 3.4.4.1). nal control system which have not been com-
In the case of a direct engagement, the auditor pleted. The details should include what measures
must obtain and disclose this information. are to be completed or effectively implemented.
In the case of a direct engagement, the auditor
If the specified period ends in a period which is shall obtain and disclose this information.
up to three months before February 15, 2021, the
28
4 Information on the
General Conditions of
the Cloud Service
29
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Information on the General Conditions of the Cloud Service
4 Information on the General

Conditions of the Cloud Service
The information on the general conditions of the Supplementary Information – Notes
cloud service, serves to provide customers with on the General Conditions
additional information on the level of informa-
tion security offered by the cloud service. The If the processing, backup and storage of customer
information enables cloud customers to assess the data takes place in different locations, this is to be
suitability of the cloud service for their individual described comprehensibly and transparently in
use case. They are also intended to ensure a com- the system description.
parable reporting to make it easier for customers
to compare several cloud providers or cloud ser-
vices for which a C5 report has been issued.
BC-02 Information on availability and incident
Since in the case of a direct engagement, the audit handling during regular operation
is not based on a system description provided
by the Cloud Service Provider, the auditor must Information on the General
document details of the general conditions in Conditions of the cloud service
accordance with the information provided by the
Cloud Service Provider. In contractual agreements (e.g. service descrip-
tion), the Cloud Service Provider provides com-
prehensible, binding and transparent information
on:
BC-01 Information on jurisdiction and locations
• Availability of the cloud service;
Information on the General
Conditions of the cloud service • Categorisation and Prioritisation of incidents;
In the system description and the contractual • Response times for disruptions of regular
agreements (e.g. service description), the Cloud operation according to the categorisation
Service Provider clearly provides comprehensible (time elapsed between the reporting and the
and transparent information on: resolution of the disruption by the Cloud
Service Provider);
• Its jurisdiction; and
• Recovery time (time elapsed until the incident
• System component locations, including its has been resolved); and
subcontractors, where the cloud customer’s
data is processed, stored and backed up. • Legal consequences of non-compliance.
The scope of information is based on the require- The details are based on definitions that allow
ments of subject matter experts of the cloud subject matter experts of the cloud customers
customers who define information security to assess the cloud service against their business
requirements, implement them or check their requirements.
effectiveness and assess the suitability of the
cloud service from a legal and regulatory perspec- The system description describes where this
tive (e.g. IT, compliance, internal audit). information can be found.
30
If information on availability and remediation of Supplementary Information – Notes

disruptions represent average values that are not on the General Conditions
binding in individual cases, this is highlighted
separately. In addition to the reference in the system descrip-
tion where this information can be found, the
information itself may also be an optional part
Supplementary Information – Notes of the report, e.g. in a section “Other information
on the General Conditions provided by the legal representatives of the Cloud
Service Provider”. The auditor does not provide an
In addition to the reference in the system descrip- opinion on the information.
tion where this information can be found, the
information itself may also be an optional part
of the report, e.g. in a section “Other information
provided by the legal representatives of the Cloud BC-04 Information on the availability
Service Provider”. The auditor does not provide an of the data centre
opinion on the information.
Conditions of the cloud service
BC-03 Information on recovery parameters The cloud provider provides subject matter
in emergency operation experts of cloud customers with comprehensible
and transparent information on the availability of
Information on the General the data centres used to provide the cloud service
Conditions of the cloud service (including data centres operated by subcontrac-
tors), as needed. The information shows avail-
The Cloud Service Provider provides subject ability and downtime over one year according
matter experts of the cloud customers with to industry standard classification schemes. The
comprehensible and transparent information on information enables cloud customers to assess
the following recovery parameters of the cloud the cloud service as part of their business impact
service, if required: analysis.
• Maximum tolerable downtime/Recovery

Time Objective (RTO) Supplementary Information – Notes
on the General Conditions
• Maximum allowable data loss/Recovery Point
Objective (RPO) The Uptime Institute’s Tier classification system
is a classification customary in the industry. It
• Recovery time to start emergency operation defines the following levels (Tiers) for availability
and downtime in relation to one year:
• Recovery level (capacity related to regular
operation) • Tier I: 99.671 %; up to 28.8 hours cumulative
downtime per year
• Restore time until normal operation
• Tier II: 99.741 %; up to 22.7 hours cumulative
The information enables cloud customers to downtime per year
evaluate the cloud service as part of their own
business impact analysis. • Tier III: 99.982 %; up to 1.6 hours cumulative
downtime per year
• Tier IV: 99.995 %; up to 25 minutes cumulative

downtime per year
31
If there are requirements towards high availability • the ability of the affected cloud customers to
of a data centre, the BSI HV benchmark, which object; and
provides the following availability classes (AC), is
suitable: • whether the Cloud Service Provider has the
ability to decrypt encrypted data of the cloud
• AC 0: without availability requirements customers in case of such requests and how
(~ 95 %); up to 438 hours cumulative down- this ability for access or disclosure is used.
time per year
The scope of the information corresponds to the
• AC 1: normal availability (99 %); up to 88 needs of the subject matter experts of the cloud
hours cumulative downtime per year customers who define specifications on informa-
tion security, implement these or validate their
• AC 2: high availability (99.9 %); up to 9 hours implementation and assess the suitability of the
cumulative downtime per year cloud service from a legal and regulatory point of
view (e.g. IT, compliance, internal audit).
• AC 3: very high availability (99.99 %); up to 53
minutes cumulative downtime per year
Supplementary Information – Notes
• AC 4: highest availability (99.999 %); up to 6 on the General Conditions
minutes cumulative downtime per year
The legal foundation on which these govern-
• AC 5: Disaster-tolerant mental services are based (e.g. law enforcement
agencies, intelligence services) vary from region
This information may be an optional part of to region. In particular, the applicable jurisdiction
the report, e.g. in a section “Other information at the locations where data of cloud customers is
provided by the legal representatives of the cloud processed, stored, backed up and stored must be
provider”. The practitioner themselves do not considered.
provide an opinion on the information.
In Germany, such powers are governed by the
laws of the German Federal Criminal Police Office
(or the laws of the respective state offices), various
BC-05 Information on how investigation procedural codes for courts and the laws for intel-
enquiries from government authorities are handled ligence services (BNDG, BVerfSchG, respective
laws on the constitutional protection offices of
Information on the General the federal states, MADG) and the G10 Act.
Conditions of the cloud service
In other countries, other laws are relevant, and
In the system description, the Cloud Service Pro- the cloud customer may only occasionally be
vider provides comprehensible and transparent aware of them from the media, e.g. the CLOUD
information on how investigation enquiries by Act (“Clarifying Lawful Overseas Use of Data Act”)
government agencies for access to or disclosure from the United States of America or the Cyber
of cloud customer data are handled. The informa- Security Law of the People’s Republic of China. In
tion includes the following aspects: conjunction with the other information on the
cloud service, the cloud customer should be able
• Procedures to verify the legal basis of such to use this information to carry out a risk assess-
enquiries; ment assessing if and how these are relevant.
• Procedures for informing and involving the

affected cloud customers upon receipt of such
enquiries;
32
BC-06 Information on certifications To the extent applicable for the certification or

or attestations attestation, the following information are pro-
vided:
Conditions of the cloud service • date of issuance;
In the system description, the Cloud Service Pro- • issuing organisation; and
vider provides comprehensible and transparent
information on existing and valid certifications or • date or period of validity or coverage.
attestations by independent third parties relating
to the following aspects of the cloud service: The scope of the information corresponds to the
needs of the subject matter experts of the cloud
• compliance of the management systems for customers who define specifications on informa-
information security, business continuity and tion security, implement these or validate their
quality with applicable international stand- implementation and assess the suitability of the
ards; cloud service from a legal and regulatory point of
view (e.g. IT, compliance, internal audit).
• compliance with the European General Data
Protection Regulation (GDPR);
Supplementary Information – Notes
• the suitability and effectiveness of the internal on the General Conditions
control system in relation to the applicable
criteria; and Transparency can be additionally increased by
disclosing SLAs based on ISO/IEC 19086 or com-
• certifications or attestations according to parable standards.
industry-specific requirements of cloud cus-
tomers. Fulfilment of the General Condition does not
require the Cloud Service Provider to hold a certi-
fication or attestation for all listed aspects.
33
5 Basic Criteria, Additional
Criteria and Supplementary
Information
34
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Basic Criteria, Additional Criteria and Supplementary Information
5 Basic Criteria, Additional Criteria

and Supplementary Information
5.1 Organisation of Information Security (OIS) Supplementary Information
Objective: Plan, implement, maintain and About the Criterion

continuously improve the information security
framework within the organisation. The basic criterion can also be fulfilled without
valid certification of the ISMS according to ISO/
IEC 27001 or ISO 27001 based on IT-Grund-
schutz, if the submitted documentation meets the
OIS-01 Information Security Management requirements of ISO/IEC 27001.
System (ISMS)
Complementary Customer Criterion
Basic Criterion
–
The Cloud Service Provider operates an infor-
mation security management system (ISMS) in Notes on Continuous Auditing
accordance with ISO/IEC 27001. The scope of
the ISMS covers the Cloud Service Provider’s Feasibility: partially
organisational units, locations and procedures for
providing the cloud service. A continuous audit of the ISO 27001 certificate
is partially feasible because the existence of a
The measures for setting up, implementing, main- certificate can be continuously verified through
taining and continuously improving the ISMS are the creation date of the certificate and passing
documented. The documentation includes: an authenticity check. However, the certificate is
usually issued for three years and there will be no
• Scope of the ISMS (Section 4.3 of ISO/IEC dynamic changes as a rule.
27001);
• Declaration of applicability (Section 6.1.3), and

OIS-02 Information Security Policy
• Results of the last management review (Sec-
tion 9.3). Basic Criterion
The top management of the Cloud Service Pro-

Additional Criterion vider has adopted an information security policy
and communicated it to internal and external
The Information Security Management System employees as well as cloud customers.
(ISMS) has a valid certification according to ISO/
IEC 27001 or ISO 27001 based on IT-Grundschutz. The policy describes:
• the importance of information security, based

on the requirements of cloud customers in
relation to information security;
35
• the security objectives and the desired secu- parties are documented and communicated. This
rity level, based on the business goals and includes dealing with the following events:
tasks of the Cloud Service Provider;
• Vulnerabilities;
• the most important aspects of the security
strategy to achieve the security objectives set; • Security incidents; and
and
• Malfunctions.
• the organisational structure for information
security in the ISMS application area. The type and scope of the documentation is
geared towards the information requirements of
the subject matter experts of the affected organi-
Additional Criterion sations in order to carry out the activities appro-
priately (e.g. definition of roles and responsibilities
– in guidelines, description of cooperation obliga-
tions in service descriptions and contracts).
Supplementary Information The communication of changes to the interfaces

and dependencies takes place in a timely manner
About the Criterion so that the affected organisations and third parties
can react appropriately with organisational and
The top management is a natural person or group technical measures before the changes take effect.
of persons who make the final decision for the
institution and is responsible for that decision.
Additional Criterion
–
–
Notes on Continuous Auditing Supplementary Information
Feasibility: partially About the Criterion
A policy can change ad-hoc. However, the contin- The Cloud Service Provider can define and docu-
uous audit of policies is only partially feasible as ment the interfaces and dependencies described
the only attributes that can be tested are the last in the basic criterion in guidelines and instruc-
change date and the status of review or approval, tions. For example, cloud customers’ obligations
as far as this information is stored in a system. The to cooperate should be described in service
content of a policy can hardly be tested automat- descriptions and contracts.
ically.
Third parties in the sense of this basic criterion
are, e.g. cloud customers and sub-service provid-
ers.
OIS-03 Interfaces and Dependencies
Basic Criterion
Cloud customers ensure through suitable con-
Interfaces and dependencies between cloud trols, that the guidelines and requirements for
service delivery activities performed by the Cloud compliance with the contractual agreements with
Service Provider and activities performed by third the Cloud Service Provider (i.e., responsibilities,
cooperation obligations and interfaces for report-
36
ing security incidents) are adequately defined, Supplementary Information

documented and set up.
About the Criterion
Notes on Continuous Auditing
Identified events that may constitute unauthor-
Feasibility: no ised or unintentional changes to or misuse of
cloud customer data may, for example, be treated
An automated continuous audit for critical as a security incident, cf. SIM-01.
dependencies and interfaces is currently only pos-
sible at a high cost to the Cloud Service Provider. Complementary Customer Criterion
OIS-04 Segregation of Duties Notes on Continuous Auditing
Basic Criterion Feasibility: yes
Conflicting tasks and responsibilities are sep- A continuous audit is possible, especially in the
arated based on an OIS-06 risk assessment to case of changes to role profiles and responsibil-
reduce the risk of unauthorised or unintended ities. This would require an initial check of the
changes or misuse of cloud customer data pro- defined roles and responsibilities by the Cloud
cessed, stored or transmitted in the cloud service. Service Provider. The roles that are added or
changed on a monthly basis could then be auto-
The risk assessment covers the following areas, mated and continuously checked.
insofar as these are applicable to the provision of
the Cloud Service and are in the area of responsi-
bility of the Cloud Service Provider:
OIS-05 Contact with Relevant Government
• Administration of rights profiles, approval Agencies and Interest Groups
and assignment of access and access authori-
sations (cf. IDM-01); Basic Criterion
• Development, testing and release of changes The Cloud Service Provider leverages relevant
(cf. DEV-01); and authorities and interest groups in order to stay
informed about current threats and vulnerabil-
• Operation of the system components. ities. The information flows into the procedures
for handling risks (cf. OIS-06) and vulnerabilities
If separation cannot be established for organisa- (cf. OPS-19).
tional or technical reasons, measures are in place
to monitor the activities in order to detect unau-
thorised or unintended changes as well as misuse Additional Criterion
and to take appropriate actions.
If the cloud service is used by public sector organ-
isations in Germany, the Cloud Service Provider
Additional Criterion leverages contacts with the National IT Situation
Centre and the CERT Association of the BSI.
–
37
Supplementary Information authenticity of information within the scope

of the ISMS and assigning risk owners;
About the Criterion
• Analysis of the probability and impact of
Relevant contacts are for example: occurrence and determination of the level of
risk;
• Federal Office for Information Security (BSI);
• Evaluation of the risk analysis based on
• OWASP Foundation; and defined criteria for risk acceptance and priori-
tisation of handling;
• CERT networks DFN-CERT, TF-CSIRT etc.
• Handling of risks through measures, includ-
Public sector organisations in Germany are e.g. ing approval of authorisation and acceptance
authorities and ministries. of residual risks by risk owners; and
Complementary Customer Criterion • Documentation of the activities implemented

to enable consistent, valid and comparable
– results.

Feasibility: yes
–
A continuous audit of the Cloud Service Provid-
er’s contacts with relevant authorities and stake-
holders can be achieved by continuously storing Supplementary Information
relevant information on a monthly basis, such as
a list of contacted entities and evidence of receipt About the Criterion
of a response. A continuous flow of information
demonstrates a constant connection to relevant The risk level can be determined by qualitative,
authorities and interest groups. Furthermore, the semi-quantitative and quantitative methods (cf.
distribution of the information and, if necessary, ISO 31010) based on the likelihood and impacts.
the documentation of the handling of identified
risks and vulnerabilities could be continuously Complementary Customer Criterion
audited for the coverage of this criterion.
–

OIS-06 Risk Management Policy
Feasibility: partially
Basic Criterion
A policy can change ad-hoc. However, the contin-
Policies and instructions for risk management uous audit of policies is only partially feasible as
procedures are documented, communicated and the only attributes that can be tested are the last
provided in accordance with SP-01 for the follow- change date and the status of review or approval,
ing aspects: as far as this information is stored in a system. The
content of a policy can hardly be tested automat-
• Identification of risks associated with the loss ically.
of confidentiality, integrity, availability and
38
OIS-07 Application of the Risk Management for the provision of cloud services to subservice
Policy organisations, the responsibility for these risks
remains with the Cloud Service Provider. Require-
Basic Criterion ments for measures to manage these risks can be
found in the criteria area “Control and Monitor-
The Cloud Service Provider executes the process ing of Service Providers and Suppliers (SSO)”.
for handling risks as needed or at least once a
year. The following aspects are taken into account Shared resources are e.g. networks, RAM or stor-
when identifying risks, insofar as they are appli- age.
cable to the cloud service provided and are within
the area of responsibility of the Cloud Service Complementary Customer Criterion
Provider:
–
• Processing, storage or transmission of data
of cloud customers with different protection Notes on Continuous Auditing
needs;
• Occurrence of vulnerabilities and malfunc-
tions in technical protective measures for The procedure for handling risks must be tested
separating shared resources; at least once a year and is therefore part of the
standard audit cycle. However, the continuous
• Attacks via access points, including interfaces audit of handling risk is only partially feasible as
accessible from public networks; the only attributes that can be tested are the last
review date and the status of review or approval,
• Conflicting tasks and areas of responsibility as far as this information is stored in a system. The
that cannot be separated for organisational or content of the risks can hardly be tested automat-
technical reasons; and ically.
• Dependencies on subservice organisations.
The analysis, evaluation and treatment of risks, 5.2 Security Policies and Instructions (SP)
including the approval of actions and acceptance
of residual risks, is reviewed for adequacy at least Objective: Provide policies and instructions
annually by the risk owners. regarding security requirements and to support
business requirements.
– SP-01 Documentation, communication and

provision of policies and instructions
Supplementary Information Basic Criterion
About the Criterion Policies and instructions (incl. concepts and

guidelines) are derived from the information
This criterion applies only to risks that reside security policy and are documented according
within the area of responsibility of the cloud to a uniform structure. They are communicated
service provider. Risks that arise for the cloud cus- and made available to all internal and external
tomer when using the cloud service are not cov- employees of the Cloud Service Provider in an
ered by this criterion. When outsourcing activities appropriate manner.
39
The policies and instructions are version con- Policies and instructions are required for the
trolled and approved by the top management of following basic criteria in which the content is
the Cloud Service Provider or an authorised body. specified in more detail:
The policies and instructions describe at least the • Risk management policy (OIS-06)
following aspects:
• Acceptable use and handling of assets policy
• Objectives; (AM-02)
• Scope; • Security requirements for premises and build-

ings (PS-01)
• Roles and responsibilities, including staff
qualification requirements and the establish- • Physical site access control (PS-04)
ment of substitution rules;
• Concept for protection against malware
• Roles and dependencies on other organisa- (OPS-04)
tions (especially cloud customers and subser-
vice organisations); • Concept for data protection and recovery
(OPS-06)
• Steps for the execution of the security strat-
egy; and • Concept for logging and monitoring (OPS-10)
• Applicable legal and regulatory requirements. • Concept for meta data handling (OPS-11)
• Concept for handling of vulnerabilities, mal-

Additional Criterion functions and errors (OPS-18)
– • Policy for system and data access authorisa-

tions (IDM-01)
Supplementary Information • Policy for the use of encryption procedures

and key management (CRY-01)
About the Criterion
• Policies for data transmission (COS-08)
The appropriateness of the demand-oriented
communication and provision must be assessed • Policies for the development/procurement of
against the size and complexity of the Cloud Ser- information systems (DEV-01)
vice Provider’s organisation and the type of cloud
service offered. Possible criteria are: • Policies for changes to information systems
(DEV-03)
• Integration of guidelines and instructions in
the onboarding of new employees • Policies and instructions for controlling and
monitoring third parties (SSO-01)
• Training and information campaigns when
adopting new or revising existing policies and • Policy for security incident management
instructions (SIM-01)
• Form of provision • Business impact analysis policies and proce-

dures (BCM-02)
40
• Policy for planning and conducting audits Revised policies and instructions are approved
(COM-02) before they become effective.

–
–
Feasibility: partially Supplementary Information
Regarding the uniformity and content of the pol- About the Criterion
icies and instructions, there is a need for manual
testing, so continuous testing cannot be fully –
achieved.
The communication/provision of policies and
instructions can be queried via various registers. –
Registries for all approved policies and instruc-
tions can serve as a basis for reviewing the pol- Notes on Continuous Auditing
icies/rejections provided in the usual channels
and may be combined with a conditional access Feasibility: partially
check. These requirements must first be met by
the Cloud Service Provider. A continuous, automated audit of the content
changes to policies and instructions is only par-
Versioning after approval by authorised person- tially practicable at the current state-of-the-art.
nel can be automatically audited and is therefore
suitable for continuous audit. A continuous audit of the reviewers’ authorisa-
tion and expertise does not appear to be effective
either, as this cannot be linked to specified param-
eters of an automated evaluation. A continuous
SP-02 Review and Approval of Policies examination of this criterion could therefore only
and Instructions consist of returning the date of the last examina-
tion.
Basic Criterion
Information security policies and instructions are

reviewed at least annually for adequacy by the SP-03 Exceptions from Existing Policies
Cloud Service Provider’s subject matter experts. and Instructions
The review shall consider at least the following Basic Criterion

aspects:
Exceptions to the policies and instructions for
• Organisational and technical changes in the information security as well as respective controls
procedures for providing the cloud service; go through the OIS-06 risk management pro-
and cess, including approval of these exceptions and
acceptance of the associated risks by the risk own-
• Legal and regulatory changes in the Cloud ers. The approvals of exceptions are documented,
Service Provider’s environment. limited in time and are reviewed for appropriate-
ness at least annually by the risk owners.
41
Additional Criterion 5.3 Personnel (HR)
– Objective: Ensure that employees understand

their responsibilities, are aware of their
responsibilities with regard to information
Supplementary Information security, and that the organisation’s assets
are protected in the event of changes in
About the Criterion responsibilities or termination.
Exceptions in the sense of the basic criterion can

have organisational or technical causes, such as
HR-01 Verification of qualification
• An organisational unit should deviate from and trustworthiness
the intended processes and procedures in
order to meet the requirements of a cloud Basic Criterion
customer; and
The competency and integrity of all internal and
• A system component lacks technical proper- external employees of the Cloud Service Provider
ties to configure it according to the applicable with access to cloud customer data or system
requirements. components under the Cloud Service Provider’s
responsibility who are responsible to provide the
Cloud customers can use appropriate controls cloud service in the production environment shall
to ensure that they obtain information from the be verified prior to commencement of employ-
Cloud Service Provider about deviations from ment in accordance with local legislation and
information security policies and instructions regulation by the Cloud Service Provider.
in order to assess and appropriately manage the
associated risks to their own information security. To the extent permitted by law, the review will
cover the following areas:
• Verification of the person through identity
– card;
Notes on Continuous Auditing • Verification of the CV;
Feasibility: partially • Verification of academic titles and degrees;
Exceptions to policies and instructions are to be • Request of a police clearance certificate for
reviewed annually. However, the continuous audit applicants;
of these exceptions is only partially feasible as
the only attributes that can be tested are the last • Certificate of good conduct or national equiv-
change date and the status or review or approval, alent; and
as far as this information is stored in a system.
The content of an exception can hardly be tested • Evaluation of the risk to be blackmailed.
automatically.
42
Supplementary Information HR-02 Employment terms and conditions
About the Criterion Basic Criterion
External employees in the sense of the criteria are The Cloud Service Provider’s internal and exter-
those who perform activities in accordance with nal employees are required by the employment
the processes and procedures of the Cloud Service terms and conditions to comply with applicable
Provider. Employees of sub-service providers who policies and instructions relating to information
perform activities according to the sub-service security.
own processes and procedures are not covered by
this criterion. The information security policy, and the policies
and instructions based on it, are to be acknowl-
The verification of qualification and trustworthi- edged by the internal and external personnel in
ness can be supported by a specialised service pro- a documented form before access is granted to
vider. Depending on national legislation, national any cloud customer data or system components
equivalents of the German certificate of good under the responsibility of the Cloud Service
conduct may also be permitted. The assessment Provider used to provide the cloud service in the
of the extent to which a potential employee can production environment.
be blackmailed can be carried out, for example, by
checking his creditworthiness.
–
–
A continuous audit is only partially achievable The Cloud Service Provider ensures that the
due to the complications between local deviations policies and instructions reflect applicable legal
in laws and regulations. and regulatory requirements in accordance with
SP-01.
It would be conceivable to continuously query the
process steps stored in the system for each new Complementary Customer Criterion
hire in relation to the specified areas based on a
list of employees maintained in the HR system in –
which new hires are registered.
To do this, the Cloud Service Provider would have
to go through and document these steps applying Feasibility: yes
a system-based approach. The auditor could then
use an agent or a connected monitoring system to Due to the obligation of employees to comply
detect any deviations from the standard process. with certain requirements, a continuous audit is
not practical as compliance with the requirements
can be verified as part of a standard audit cycle
A continuous audit of the granting of access only

after acknowledgement of the instructions is
achievable as far as the Cloud Service Provider
designs the approval system to document the
43
appropriate data (e.g., date of acknowledgement, Supplementary Information

which data the employee had access to and when).
A clear definition and differentiation of customer About the Criterion
data as well as data in the productive environ-
ment is essential. –
With the help of this data, the auditor can per- Complementary Customer Criterion
form a comparison and detect deviations accord-
ingly. The data could be monitored using an agent –
on a monitoring system.
Feasibility: yes
HR-03 Security training and awareness
programme The concept behind the security awareness and
training program does not require continuous
Basic Criterion assessment and is sufficiently covered by the
recurring audit.
The Cloud Service Provider operates a target
group-oriented security awareness and training However, the completion of the training can
program, which is completed by all internal and be traced via training portals. For a continuous
external employees of the Cloud Service Pro- audit that each employee has completed and, if
vider on a regular basis. The program is regu- necessary, repeated the relevant training courses
larly updated based on changes to policies and for his role description, a clear system-based
instructions and the current threat situation and definition of the necessary training courses for
includes the following aspects: each role description must be carried out at the
Cloud Service Provider. The expected dates which
• Handling system components used to provide the respective training course is to be completed
the cloud service in the production environ- must also be recorded. The documentation that
ment in accordance with applicable policies the training has been completed by the employee
and procedures; and, if necessary, successfully completed with an
examination, should take place in the same portal.
• Handling cloud customer data in accordance
with applicable policies and instructions and The auditor then has the option of examining
applicable legal and regulatory requirements; the results of the training courses for employees
of the Cloud Service Provider for deviations by
• Information about the current threat situa- automatically and continuously comparing the
tion; and expected training dates with the actual date on
which the employees completed the training.
• Correct behaviour in the event of security
incidents.
HR-04 Disciplinary measures

Basic Criterion
The learning outcomes achieved through the
awareness and training programme are measured In the event of violations of policies and instruc-
and evaluated in a target group-oriented manner. tions or applicable legal and regulatory require-
The measurements cover quantitative and quali- ments, actions are taken in accordance with a
tative aspects. The results are used to improve the defined policy that includes the following aspects:
awareness and training programme.
44
• Verifying whether a violation has occurred; HR-05 Responsibilities in the event

and of termination or change of employment
• Consideration of the nature and severity of Basic Criterion

the violation and its impact.
Internal and external employees have been
The internal and external employees of the Cloud informed about which responsibilities, arising
Service Provider are informed about possible from employment terms and conditions relating
disciplinary measures. to information security, will remain in place when
their employment is terminated or changed and
The use of disciplinary measures is appropriately for how long.
documented.
–
–
Supplementary Information
About the Criterion
About the Criterion
The Cloud Service Provider ensures that the
The Cloud Service Provider ensures that the policies and instructions reflect applicable legal
policies and instructions reflect applicable legal and regulatory requirements in accordance with
and regulatory requirements in accordance with SP-01.
SP-01.
–
–
Feasibility: yes
Feasibility: no
As part of a comprehensive, system-based docu-
Continuous audit not practical, as the associated mentation of HR data, it is conceivable that the
processes and steps can be tested once within a employee will receive confirmation that he or
recurring audit. she has been informed about the required topics.
This should be requested again at the end of the
A system-based definition of the violations as well employment relationship.
as the corresponding regulations does not appear
practical, since in this context individual case If such documentation was available in standard-
decisions are often necessary which cannot be ised and digital form, the auditor would be able to
covered by predefined algorithms. check each termination for this confirmation and
identify any deviations. This makes continuous
verification possible.
45
HR-06 Confidentiality agreements • How the ownership of information is regu-

lated;
Basic Criterion
• What rules apply to the use and disclosure of
The non-disclosure or confidentiality agreements confidential information to other partners, if
to be agreed with internal employees, external necessary; and
service providers and suppliers of the Cloud
Service Provider are based on the requirements • The consequences of a breach of the agree-
identified by the Cloud Service Provider for the ment.
protection of confidential information and opera-
tional details. Confidentiality or non-disclosure agreements can
be signed by means of an electronic signature,
The agreements are to be accepted by external insofar as this is legally binding.
service providers and suppliers when the contract
is agreed. The agreements must be accepted by Complementary Customer Criterion
internal employees of the Cloud Service Provider
before authorisation to access data of cloud cus- –
tomers is granted.
The requirements must be documented and
reviewed at regular intervals (at least annually). If Feasibility: yes
the review shows that the requirements need to
be adapted, the non-disclosure or confidentiality The signing of confidentiality agreements with
agreements are updated. internal employees, external service providers and
suppliers can be standardised and stored digitally.
The Cloud Service Provider must inform the
internal employees, external service providers and An automated continuous evaluation can then
suppliers and obtain confirmation of the updated be carried out to check whether all parties have
confidentiality or non-disclosure agreement. signed such a confidentiality agreement and
whether the agreement is up to date.
– 5.4 Asset Management (AM)
Objective: Identify the organisation’s own

Supplementary Information assets and ensure an appropriate level of
protection throughout their lifecycle.
About the Criterion
In a confidentiality agreement it should be

described: AM-01 Asset Inventory
• Which information must be kept confidential; Basic Criterion
• The period for which this confidentiality The Cloud Service Provider has established proce-
agreement applies; dures for inventorying assets.
• What actions must be taken upon termination The inventory is performed automatically and/or
of this agreement, e.g. destruction or return of by the people or teams responsible for the assets
data medium;
46
to ensure complete, accurate, valid and consistent Software objects are e.g. hypervisors, containers,
inventory throughout the asset lifecycle. operating systems, databases, microservices and
programming interfaces (APIs).
Assets are recorded with the information needed
to apply the Risk Management Procedure (cf. The lifecycle of an asset includes:
OIS-07), including the measures taken to manage
these risks throughout the asset lifecycle. Changes • Acquisition;
to this information are logged.
• Commissioning;
Additional Criterion • Maintenance;
Logging and monitoring applications take into • Decommissioning; and

account the information collected on the assets
in order to identify the impact on cloud services • Disposal.
and functions in case of events that could lead to
a breach of protection objectives, and to support Complementary Customer Criterion
information provided to affected cloud customers
in accordance with contractual agreements. –

Feasibility: yes
About the Criterion
The Cloud Service Provider must ensure that
Assets within the meaning of this criteria area are assets are automatically captured (in a database).
the objects required for the information security The automatic capture of physical assets must
of the cloud service during the creation, process- also be ensured. However, it would be conceiv-
ing, storage, transmission, deletion or destruction able to automatically capture these assets when
of information in the Cloud Service Provider’s logging on to a network for the first time. The
area of responsibility, e.g. firewalls, load balanc- creation of virtual assets can be directly linked to
ers, web servers, application servers and database the entry into the database.
servers.
If all assets are recorded automatically, changes to
These objects consist of hardware and software the database can be documented (logs) and these
objects: logs can then be continuously evaluated. It is
important to ensure that the information con-
Hardware objects are tained in the inventory and logs is complete.
• Physical and virtual infrastructure resources If automated processes are available, the auditor
(e.g. servers, storage systems, network compo- can create an evaluation of the changes in the
nents); and inventory based on the logs.
• As well as end devices if the Cloud Service In order to check the completeness, the first step
Provider has determined in a risk assessment would be to query all current assets at the Cloud
that these could endanger the information Service Provider. This asset list could then be
security of the cloud service in the event compared with the entries in the asset manage-
of loss or unauthorised access (e.g. mobile ment database.
devices used as security tokens for authenti-
cation).
47
AM-02 Acceptable Use and Safe Handling Additional Criterion

of Assets Policy
–
Basic Criterion
Policies and instructions for acceptable use and Supplementary Information

safe handling of assets are documented, commu-
nicated and provided in accordance with SP-01 About the Criterion
and address the following aspects of the asset
lifecycle as applicable to the asset: –
• Approval procedures for acquisition, commis- Complementary Customer Criterion

sioning, maintenance, decommissioning, and
disposal by authorised personnel or system –
components;
• Inventory;
• Classification and labelling based on the need
for protection of the information and meas- A policy can change ad-hoc. However, the contin-
ures for the level of protection identified; uous audit of policies is only partially feasible as
the only attributes that can be tested are the last
• Secure configuration of mechanisms for error change date and the status of review or approval,
handling, logging, encryption, authentication as far as this information is stored in a system. The
and authorisation; content of a policy can hardly be tested automat-
ically.
• Requirements for versions of software and
images as well as application of patches;
• Handling of software for which support and AM-03 Commissioning of Hardware

security patches are not available anymore;
Basic Criterion
• Restriction of software installations or use of
services; The Cloud Service Provider has an approval
process for the use of hardware to be commis-
• Protection against malware; sioned, which is used to provide the cloud service
in the production environment, in which the risks
• Remote deactivation, deletion or blocking; arising from the commissioning are identified,
analysed and mitigated. Approval is granted after
• Physical delivery and transport; verification of the secure configuration of the
mechanisms for error handling, logging, encryp-
• dealing with incidents and vulnerabilities; and tion, authentication and authorisation according
to the intended use and based on the applicable
• Complete and irrevocable deletion of the data policies.
upon decommissioning.
48
Supplementary Information AM-04 Decommissioning of Hardware
The basic criterion applies only to physical hard- The decommissioning of hardware used to oper-
ware objects, such as servers, storage systems, and ate system components supporting the cloud ser-
network components. vice production environment under the respon-
sibility of the Cloud Service Provider requires
Virtual hardware and software objects are consid- approval based on the applicable policies.
ered in the criteria areas (OPS) and (DEV).
The decommissioning includes the complete and
The approval process typically considers both the permanent deletion of the data or proper destruc-
basic approval to use the hardware and the final tion of the media.
approval of the configured assets.
Complementary Customer Criterion Additional Criterion
– –

Feasibility: yes
About the Criterion
The approval of the commissioning of hardware
by authorised personnel or system components The deletion of data or physical destruction of
must be digitally documented to allow contin- data mediums can take place, for example, accord-
uous testing. A ticketing system, for example, is ing to DIN 66399 or BSI IT-Grundschutz module
suitable for this purpose. CON.6.
Both the instance and the verification of the con- Complementary Customer Criterion
figuration must be stored in the respective ticket.
–
This makes it possible for the auditor to check the
tickets in an automated procedure. This requires Notes on Continuous Auditing
an automated comparison of the authorised
instance against a database containing all poten- Feasibility: yes
tial approvers. In addition, the verification of
the configuration in the ticket must be audited The approval of the decommissioning of hard-
automatically. ware by authorised personnel or system com-
ponents must be digitally documented to allow
The compliant use of the assets can then be continuous testing. A ticketing system, for exam-
ensured via an agent system which checks active ple, is suitable for this purpose.
assets. The status of this system can then be que-
ried by the auditor for a continuous audit. Both the instance and the verification of the com-
plete deletion of the data must be stored in the
respective ticket.
This enables the auditor to check the tickets in an

automated procedure. This requires an automated
comparison of the authorised instance against a
database containing all potential approvers. In
49
addition, the deletion of the data documented in Complementary Customer Criterion

the ticket must be audited automatically.
–
The compliant use of the assets can be ensured via
an agent system which checks active assets. The Notes on Continuous Auditing
status of this system can then be queried by the
auditor for a continuous audit. Feasibility: yes
The obligation of the employees to follow the pol-

icies and instructions can be made in digital form.
AM-05 Commitment to Permissible Use, This can be used to create a monitoring system
Safe Handling and Return of Assets that documents the non-obligation to employee
guidelines in the form of logs.
Basic Criterion
In this case, the auditor can check the exceptions
The Cloud Service Provider’s internal and exter- in the form of logs and request evidence of what
nal employees are provably committed to the additional steps the Cloud Service Provider has
policies and instructions for acceptable use and taken in these cases to minimise the risk.
safe handling of assets before they can be used if
the Cloud Service Provider has determined in a The compliant use of the assets can then be
risk assessment that loss or unauthorised access ensured via an agent system which checks active
could compromise the information security of the assets. The status of this system can then be que-
Cloud Service. ried by the auditor for a continuous audit.
Any assets handed over are provably returned

upon termination of employment.
AM-06 Asset Classification and Labelling
Additional Criterion Basic Criterion
Physical assets of internal and external employees Assets are classified and, if possible, labelled.
are managed centrally. Classification and labelling of an asset reflect the
protection needs of the information it processes,
Central management enables software, data, and stores, or transmits.
policy distribution, as well as remote deactivation,
deletion, or locking. The need for protection is determined by the indi-
viduals or groups responsible for the assets of the
Cloud Service Provider according to a uniform
Supplementary Information schema. The schema provides levels of protection
for the confidentiality, integrity, availability, and
About the Criterion authenticity protection objectives.
The basic criterion essentially concerns mobile

devices (e.g. notebooks, tablets, smartphones, etc.), Additional Criterion
where confidential information is stored on them
which can be used in the event of unauthorised Logging and monitoring applications take the
access to obtain privileged access to the cloud asset protection needs into account in order to
service (e.g. if these are used as security tokens for inform the responsible stakeholder of events that
authentication). could lead to a violation of the protection goals,
so that the necessary measures are taken with an
appropriate priority. Actions for events on assets
50
with a higher level of protection take precedence 5.5 Physical Security (PS)
over events on assets with a lower need for pro-
tection. Objective: Prevent unauthorised physical
access and protect against theft, damage, loss
and outage of operations.
About the Criterion

PS-01 Physical Security and Environmental
If the Cloud Service Provider does not make a Control Requirements
differentiated classification of the assets, all assets
are to be assigned to the highest defined protec- Basic Criterion
tion requirement.
Security requirements for premises and buildings
Complementary Customer Criterion related to the cloud service provided, are based on
the security objectives of the information secu-
Cloud customers can use appropriate controls to rity policy, identified protection requirements for
ensure that the need for protection of the infor- the cloud service and the assessment of risks to
mation that can be processed or stored with the physical and environmental security. The security
cloud service is adequately determined. requirements are documented, communicated
and provided in a policy or concept according to
Cloud customers can also use appropriate con- SP-01.
trols to ensure that the information processed or
stored with the cloud service is protected against The security requirements for data centres are
tampering, copying, modifying, redirecting or based on criteria which comply with established
deleting in accordance with its protection needs. rules of technology. They are suitable for address-
ing the following risks in accordance with the
Notes on Continuous Auditing applicable legal and contractual requirements:
Feasibility: yes • Faults in planning;
The classification of the assets and the determina- • Unauthorised access;

tion of the need for protection should take place
during the initial acquisition of the assets. Thus, • Insufficient surveillance;
the classification should also be documented in an
asset management tool. The determination of the • Insufficient air-conditioning;
protection requirement can also be carried out in
a standardised form and stored digitally. If there • Fire and smoke;
are changes in the classification, these should also
be recorded in logs. • Water;
The auditor can then automatically test whether • Power failure; and
all assets in the platform are classified and
whether the classification was determined using • Air ventilation and filtration.
a standardised format. For changes in the clas-
sification, it can be automatically reconstructed If the Cloud Service Provider uses premises or
whether these were also carried out based on buildings operated by third parties to provide
the uniform schema. For this purpose, the logs the Cloud Service, the document describes which
produced can be evaluated as part of a continuous security requirements the Cloud Service Provider
audit. places on these third parties.
51
The appropriate and effective verification of rooms housing system components used to
implementation is carried out in accordance with process cloud customer data and the technical
the criteria for controlling and monitoring sub- utilities required to operate these system compo-
contractors (cf. SSO-01, SSO-02). nents (e.g. power supply, refrigeration, fire-fight-
ing, telecommunications, security, etc.). Backup or
redundancy computer centres.
Premises and buildings operated by third parties
The security requirements include time con- are e.g. server housing, colocation, IaaS.
straints for self-sufficient operation in the event
of exceptional events (e.g. prolonged power Premises and buildings in which no data from
outage, heat waves, low water in cold river water cloud customers is processed or stored (e.g. offices
supply) and maximum tolerable utility downtime. of the Cloud Service Provider, server rooms with
system components for internal development and
The time limits for self-sufficient operation pro- test systems) are not subject to this criteria area.
vide for at least 48 hours in the event of a failure
of the external power supply. The recognised rules of technology are defined
in relevant standards, e.g. EN 50600 (facilities and
For a self-sufficient operation during a heat infrastructures of data centres).
period, the highest outside temperatures meas-
ured to date within a radius of at least 50 km Incorrect planning can endanger the operational
around the locations of the premises and build- safety and availability of the premises or build-
ings have been determined with a safety margin ings. This can result from an incorrect assessment
of 3 K. The security requirements stipulate that of elementary hazards at the site (e.g. air traffic,
the permissible operating and environmental earthquakes, floods, hazardous substances) as well
parameters of the cooling supply must also be as an incorrect conception of the bandwidth or
observed on at least five consecutive days with energy supply.
these outside temperatures including the safety
margin (cf. PS-06 Protection against failure of the Time specifications for self-sustaining operation
supply facilities). as well as maximum tolerable downtimes of
utility facilities are typically collected during the
If water is taken from a river for air conditioning, business impact analysis (cf. BCM-02, BCM-03).
it is determined at which water levels and water
temperatures the air conditioning can be main- Complementary Customer Criterion
tained for how long.
–
The maximum tolerable downtimes of utility
facilities are suitable for meeting the availabil- Notes on Continuous Auditing
ity requirements contained in the service level
agreement. Feasibility: partially

Supplementary Information uous audit of policies is only partially feasible as
About the Criterion change date and the status of review or approval,
as far as this information is stored in a system. The
Premises and buildings related to the cloud content of a policy can hardly be tested automat-
service provided include data centres and server ically.
52
PS-02 Redundancy model A georedundancy of the sites to each other in the

sense of the optional, more far-reaching require-
Basic Criterion ment is given if a very extensive event at a site
under no circumstances affects several sites of
The cloud service is provided from two locations the same redundancy group simultaneously or
that are redundant to each other. The locations promptly. The BSI publication “Kriterien für die
meet the security requirements of the Cloud Standortwahl höchstverfügbarer und georedun-
Service Provider (cf. PS-01 Security Concept) and danter Rechenzentren” provides assistance in this
are located in an adequate distance to each other regard.
to achieve operational redundancy. Operational
redundancy is designed in a way that ensures There are cloud providers who no longer address
that the availability requirements specified in the the issue of reliability of the cloud service on a
service level agreement are met. The functionality physical level through redundancy from two
of the redundancy is checked at least annually by independent locations, but through resilience. The
suitable tests and exercises (cf. BCM-04 – Verifica- cloud service is provided simultaneously from
tion, updating and testing of business continuity). more than two locations. The underlying distrib-
uted data centre architecture ensures that the fail-
ure of a location or components of a location does
Additional Criterion not violate the defined availability criteria of the
cloud service. Such an architecture can represent
The cloud service is provided from more than two an alternative fulfilment (cf. Chapter 3.4.7) of the
locations that provide each other with redun- criterion. The tests and exercises on functionality
dancy. The locations are sufficiently far apart to required in the criterion also apply analogously to
achieve georedundancy. If two locations fail at resilient architectures.
the same time, at least one third location is still
available to prevent a total service failure. The Complementary Customer Criterion
georedundancy is designed in a way that ensures
that the availability requirements specified in the By means of suitable controls, cloud customers
service level agreement are met. The functionality ensure that the existing redundancy model of the
of the redundancy is checked at least annually by cloud provider and the evidence for the verifica-
suitable tests and exercises (cf. BCM-04 – Verifica- tion of the model comply with their own require-
tion, updating and testing of business continuity). ments for the availability and reliability of the
cloud service.
Supplementary Information Notes on Continuous Auditing
About the Criterion Feasibility: partially
Operational redundancy of the sites to each other An annual audit of the effectiveness of the
in the sense of the basic requirement is given, if redundancy is only partially suitable for a con-
based on the assessment of elementary risks at tinuous audit. A continuous audit could return
the site corresponding distances of the premises the date of the last transaction to bring about
and buildings to these risks are maintained. Very redundancy. In addition, it would be possible
extensive events which, due to their extent, could to document every transaction that contributes
affect several sites of the same redundancy group to redundancy by means of logs and to evaluate
simultaneously or in a timely manner (e.g. floods, these logs automatically and continuously. In
earthquakes) are not considered. addition, the status of the redundancy could be
continuously queried.
53
PS-03 Perimeter Protection Complementary Customer Criterion
Basic Criterion –
The structural shell of premises and buildings Notes on Continuous Auditing

related to the cloud service provided are phys-
ically solid and protected by adequate security Feasibility: partially
measures that meet the security requirements
of the Cloud Service Provider (cf. PS-01 Security A continuous inspection of the structural shell of
Concept). buildings is only partially feasible. Only the pro-
tection against unauthorised access can provide
The security measures are designed to detect and evaluable data in the form of access logs that are
prevent unauthorised access so that the informa- stored.
tion security of the cloud service is not compro-
mised.
The outer doors, windows and other construction PS-04 Physical site access control
elements exhibit an appropriate security level
and withstand a burglary attempt for at least 10 Basic Criterion
minutes.
At access points to premises and buildings related
The surrounding wall constructions as well as the to the cloud service provided, physical access
locking mechanisms meet the associated require- controls are set up in accordance with the Cloud
ments. Service Provider’s security requirements (cf. PS-01
Security Concept) to prevent unauthorised access.
Additional Criterion Access controls are supported by an access control

system.
The security measures installed at the site include
permanently present security personnel (at least 2 The requirements for the access control system
individuals), video surveillance and anti-burglary are documented, communicated and provided in
systems. a policy or concept in accordance with SP-01 and
include the following aspects:
Supplementary Information • Specified procedure for the granting and

revoking of access authorisations (cf. IDM-02)
About the Criterion based on the principle of least authorisation
(“least-privilege-principle”) and as necessary
Security measures for detecting unauthorised for the performance of tasks (“need-to-know-
access can be security personnel, video surveil- principle”);
lance or burglar alarm systems.
• Automatic revocation of access authorisations
The resistance class RC4 according to DIN if they have not been used for a period of 2
EN 1627 stipulates that doors, windows and month;
other components must withstand a break-in
attempt for at least 10 minutes. The US standard • Automatic withdrawal of access authorisa-
SD-STD-01.01 Rev.G. is an international equiva- tions if they have not been used for a period of
lent to this standard. 6 months;
54
• Two-factor authentication for access to areas PS-05 Protection from fire and smoke
hosting system components that process
cloud customer information; Basic Criterion
• Visitors and external personnel are tracked Premises and buildings related to the cloud
individually by the access control during their service provided are protected from fire and
work in the premises and buildings, identified smoke by structural, technical and organisational
as such (e.g. by visible wearing of a visitor pass) measures that meet the security requirements
and supervised during their stay; and of the Cloud Service Provider (cf. PS-01 Security
Concept) and include the following aspects:
• Existence and nature of access logging that
enables the Cloud Service Provider, in the a) Structural Measures:
sense of an effectiveness audit, to check
whether only defined personnel have entered Establishment of fire sections with a fire resist-
the premises and buildings related to the ance duration of at least 90 minutes for all struc-
cloud service provided. tural parts.
b) Technical Measures:

• 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
Supplementary Information to the maintenance of the availability of the
cloud service provided;
About the Criterion
• Extinguishing system or oxygen reduction;
– and
Complementary Customer Criterion • Fire alarm system with reporting to the local
fire department.
–
c) Organisational Measures
• Regular fire protection inspections to check
Feasibility: yes compliance with fire protection requirements;
and
Access control via an access card system can be
documented by the Cloud Service Provider in the • Regular fire protection exercises.
form of logs. These logs can be evaluated auto-
matically. In addition, unauthorised access can
also be traced through these logs. This can also be Additional Criterion
evaluated automatically.
The environmental parameters are monitored.
Therefore, a continuous audit is possible. When the permitted control range is exceeded,
alarm messages are generated and forwarded
Insofar as the withdrawal of access authorisations to the Cloud Service Provider’s subject matter
is standardised and documented in the same way, experts.
an automated evaluation is also possible here and
thus a continuous audit can be carried out.
55
Supplementary Information b) Use of appropriately sized uninterruptible

power supplies (UPS) and emergency power
About the Criterion systems (NEA), designed to ensure that all data
remains undamaged in the event of a power fail-
The monitoring of the environmental parame- ure. The functionality of UPS and NEA is checked
ters is addressed in PS-01. When exceeding the at least annually by suitable tests and exercises (cf.
allowed control range, alarm messages are gen- BCM-04 – Verification, updating and testing of
erated and forwarded to the responsible Cloud business continuity).
Service Provider.
c) Maintenance (servicing, inspection, repair) of
Structural parts are walls, ceilings, floors, doors, the utilities in accordance with the manufactur-
ventilation flaps, etc. er’s recommendations.
Complementary Customer Criterion d) Protection of power supply and telecommu-

nications lines against interruption, interference,
– damage and eavesdropping. The protection is
checked regularly, but at least every two years, as
Notes on Continuous Auditing well as in case of suspected manipulation by qual-
ified personnel regarding the following aspects:
Feasibility: yes
• Traces of violent attempts to open closed
Continuous testing is possible insofar as the distributors;
built-in technology for testing the protective
measures produces evaluable data and these are • Up-to-datedness of the documentation in the
stored in a standardised form. This would allow distribution list;
the security measures to be continuously evalu-
ated by the auditor. • Conformity of the actual wiring and patching
with the documentation;
If this technology is not fully available and an
inspection of the data centre is necessary, the pos- • The short-circuits and earthing of unneeded
sibility of continuous auditing is achievable only cables are intact; and
to a limited extent.
• Impermissible installations and modifications.
PS-06 Protection against interruptions caused Additional Criterion

by power failures and other such risks
Uninterruptible Power Supplies (UPS) and Emer-
Basic Criterion gency Power Supplies (NPS) are designed to meet
the availability requirements defined in the Ser-
Measures to prevent the failure of the technical vice Level Agreement.
supply facilities required for the operation of
system components with which information The cooling supply is designed in such a way that
from cloud customers is processed, are docu- the permissible operating and environmental
mented and set up in accordance with the secu- parameters are also ensured on at least five con-
rity requirements of the Cloud Service Provider secutive days with the highest outside tempera-
(cf. PS-01 Security Concept) with respect to the tures measured to date within a radius of at least
following aspects: 50 km around the locations of the premises and
buildings, with a safety margin of 3 K (in relation
a) Operational redundancy (N+1) in power and to the outside temperature). The Cloud Service
cooling supply Provider has previously determined the highest
56
outdoor temperatures measured to date (cf. PS-01 PS-07 Surveillance of operational

Security Concept). and environmental parameters
The connection to the telecommunications net- Basic Criterion

work is designed with sufficient redundancy so
that the failure of a telecommunications network The operating parameters of the technical utilities
does not impair the security or performance of (cf. PS-06) and the environmental parameters of
the Cloud Service Provider. the premises and buildings related to the cloud
service provided are monitored and controlled
in accordance with the security requirements
Supplementary Information of the Cloud Service Provider (cf. PS-01 Security
Concept). When the permitted control range is
About the Criterion exceeded, the responsible departments of the
Cloud-Provider are automatically informed in
Measures to prevent the failure of the technical order to promptly initiate the necessary measures
supply facilities are e.g. power supply, cooling, for return to the control range.
fire-fighting technology, telecommunications,
security technology, etc.
Cloud Service Providers can ensure that all data
remains undamaged in the event of a power fail- –
ure by shutting down servers following a defined
procedure.
Power supply and telecommunications lines can
be protected against interruption, interference, About the Criterion
damage and eavesdropping by e.g. underground
supply via different supply routes. Operating parameters and environmental param-
eters of the premises and buildings are, e.g. air
Complementary Customer Criterion temperature and humidity, leakage.
– Complementary Customer Criterion
Notes on Continuous Auditing –
Feasibility: partially Notes on Continuous Auditing
The physical security of premises, as well as fail- Feasibility: yes

ure precautions of the technical supply facilities
should be ensured on site by an inspection of the The monitoring and control of the operating
data centre. Therefore, a continuous examina- parameters of the technical supply facilities is
tion is achievable only to a limited extent. If the carried out automatically and documented in a
built-in technology for failure prevention pro- standardised manner, for example in logs.
duces evaluable log data, this requirement can
partly be audited continuously. However, this These logs are then automated by the inspector
does not replace an inspection. and can be continuously evaluated.
Otherwise, a continuous inspection can be carried

out at least partially by indicating the last inspec-
tion date.
57
5.6 Operations (OPS) availability and competitiveness of the cloud

service. If the procedures are not documented or
Objective: Ensure proper and regular operation, are subject to a higher degree of confidentiality as
including appropriate measures for planning a trade secret of the Cloud Service Provider, the
and monitoring capacity, protection against Cloud Service Provider must be able to explain
malware, logging and monitoring events, and the procedures at least orally within the scope of
dealing with vulnerabilities, malfunctions and this audit.
failures.
Cloud customers must use appropriate controls
to ensure that the capacity and resource require-
ments to be covered by the Cloud Service Pro-
OPS-01 Capacity Management – Planning vider are planned and reflected in the SLA with
the Cloud Service Provider. The requirements can
Basic Criterion also be reviewed regularly through appropriate
controls and the SLA can be adjusted accordingly.
The planning of capacities and resources (per-
sonnel and IT resources) follows an established Complementary Customer Criterion
procedure in order to avoid possible capacity
bottlenecks. The procedures include forecasting –
future capacity requirements in order to identify
usage trends and manage system overload. Notes on Continuous Auditing
Cloud Service Providers take appropriate meas- Feasibility: no

ures to ensure that they continue to meet the
requirements agreed with cloud customers for An audit of the planning of capacities and
the provision of the cloud service in the event of resources requires an assessment of the plausibil-
capacity bottlenecks or outages regarding person- ity or meaningfulness of the content. At present,
nel and IT resources, in particular those relating this can hardly be audited automatically and
to the dedicated use of system components, in continuously.
accordance with the respective agreements.
Additional Criterion OPS-02 Capacity Management – Monitoring
The forecasts are considered in accordance with Basic Criterion

the service level agreement for planning and pre-
paring the provisioning. Technical and organisational safeguards for the
monitoring and provisioning and de-provisioning
of cloud services are defined. Thus, the Cloud Ser-
Supplementary Information vice Provider ensures that resources are provided
and/or services are rendered according to the
About the Criterion contractual agreements and that compliance with
the service level agreements is ensured.
For economic reasons, Cloud Service Provid-
ers typically strive for a high utilisation of IT
resources (CPU, RAM, storage space, network). In Additional Criterion
multi-tenant environments, existing resources
must still be shared between cloud users (cli- To monitor capacity and availability, the relevant
ents) in such a way that service level agreements information is available to the cloud customer in
are adhered to. In this respect, proper planning a self-service portal.
and monitoring of IT resources is critical to the
58
Supplementary Information trol and monitor the allocation of the system

resources assigned to the customer for admin-
About the Criterion istration/use in order to avoid overcrowding of
resources and to achieve sufficient performance.
Technical and organisational measures typically
include:
• Use of monitoring tools with alarm function
when defined threshold values are exceeded; –
• Process for correlating events and interface to

incident management; Supplementary Information
• Continuous monitoring of the systems by About the Criterion

qualified personnel; and
Resources according to the possibilities of the
• Redundancies in the IT systems. service model are for example
Complementary Customer Criterion • Computing capacity;
Cloud customers ensure through suitable con- • Storage capacity;

trols, that the contractual agreements made with
the Cloud Service Provider for the provision of • Configuration of network properties;
resources or services can be monitored. In case
of deviations, appropriate controls ensure that • Application Programming Interfaces (APIs);
the Cloud Service Provider is informed so that and
the Cloud Service Provider can take appropriate
action. • Databases.
Notes on Continuous Auditing Complementary Customer Criterion
Feasibility: yes Cloud customers ensure through suitable con-

trols, that they manage and monitor the system
The part of resource monitoring can be contin- resources in their area of responsibility.
uously audited by checking capacity forecasts
and monitoring the resource management tool. Notes on Continuous Auditing
Furthermore, the logs of provisioning and de-pro-
visioning and their impact on resource manage- Feasibility: partially
ment can be continuously audited by the changes
in resource management. The existence of tools for controlling resources
by the cloud customers themselves is, in itself, a
continuous process, which can be continuously
checked provided that the Cloud Service Pro-
OPS-03 Capacity Management – Controlling vider can prove the functionality of these tools by
of Resources means of logs. However, continuously checking
this only generates a limited value. The function-
Basic Criterion ality of the tools provided can be continuously
audited, if they are documented and can be evalu-
Depending on the capabilities of the respective ated by the Cloud Service Provider.
service model, the cloud customer can con-
59
OPS-04 Protection Against Malware – Concept Notes on Continuous Auditing
Basic Criterion Feasibility: partially
Policies and instructions with specifications for A policy can change ad-hoc. However, the contin-
protection against malware are documented, uous audit of policies is only partially feasible as
communicated, and provided in accordance with the only attributes that can be tested are the last
SP-01 with respect to the following aspects: change date and the status of review or approval,
• Use of system-specific protection mecha- content of a policy can hardly be tested automat-
nisms; ically.
• Operating protection programs on system

components under the responsibility of
the Cloud Service Provider that are used to OPS-05 Protection Against Malware –
provide the cloud service in the production Implementation
environment; and
Basic Criterion
• Operation of protection programs for
employees’ terminal equipment. System components under the Cloud Service
Provider’s responsibility that are used to deploy
the cloud service in the production environment
Additional Criterion are configured with malware protection accord-
ing to the policies and instructions. If protection
The Cloud Service Provider creates regular reports programs are set up with signature and behav-
on the checks performed, which are reviewed iour-based malware detection and removal, these
and analysed by authorised bodies or com- protection programs are updated at least daily.
mittees. Policies and instructions describe the
technical measures taken to securely configure
and monitor the management console (both the Additional Criterion
customer’s self-service and the service provider’s
cloud administration) to protect it from malware. The configuration of the protection mechanisms
Updates are applied at the highest frequency that is monitored automatically. Deviations from the
the vendor(s) contractually offer(s). specifications are automatically reported to the
subject matter experts so that the deviations are
immediately assessed and the necessary measures
Supplementary Information taken.
About the Criterion

Protection programs for employee devices can be,
for example, server-based protection programs About the Criterion
that scan files in attachments on the server or
filter network traffic. Protection against malicious programs can
be implemented by operating system-specific
Complementary Customer Criterion protection mechanisms or explicit protection
programs (e.g. for signature- and behaviour-based
– detection and removal of malicious programs).
60
Cloud customers ensure through suitable con- –

trols, that the layers of the cloud service which
they are responsible for, have security products in
place to detect and remove malware. Supplementary Information
Notes on Continuous Auditing About the Criterion
Feasibility: yes The data backup concept specifies which type of

data backup is to be carried out (e.g. type, manner,
The first step should be to check whether all duration) and specifies which data must also be
systems are covered. This should be monitored backed up in special cases (e.g. pure use of com-
by continuously checking a tool including the pute nodes without data storage). When backing
additions and deletions of entries. up data, a distinction must be made between
backups and snapshots of virtual machines.
In the second step, the log files for the updates Snapshots do not replace backups, but can be part
of the individual servers and the regular scans of the backup strategy to achieve Recovery Point
should be audited continuously. Identified Objectives (RPO) if they are additionally stored
malware or irregularities should be marked and outside the original data location. The business
tracked as part of the continuous scan. requirements of the Cloud Service Provider for
the scope, frequency and duration of the data
backup result from the business impact analysis
(cf. BCM-03) for development and operational
OPS-06 Data Backup and Recovery – Concept processes of the cloud service. If different data
backup and recovery procedures exist for data
Basic Criterion under the responsibility of the cloud customer
and the Cloud Service Provider, both variants
Policies and instructions for data backup and must be included in a test according to this cri-
recovery are documented, communicated and teria catalogue. For procedures to secure the data
provided in accordance with SP-01 regarding the of the Cloud Service Provider, only the adequacy
following aspects. and implementation of the controls must be
proven, but not their effectiveness. For procedures
• The extent and frequency of data backups to secure the data of cloud customers, proof of
and the duration of data retention are con- effectiveness must also be provided.
sistent with the contractual agreements with
the cloud customers and the Cloud Service Complementary Customer Criterion
Provider’s operational continuity require-
ments for Recovery Time Objective (RTO) and Cloud customers ensure through suitable con-
Recovery Point Objective (RPO); trols, that the contractual agreements made with
the Cloud Service Provider regarding the scope,
• Data is backed up in encrypted, state-of-the- frequency and duration of data retention meet
art form; business requirements. The business requirements
are assessed as part of the Business Impact Analy-
• Access to the backed-up data and the execu- sis (cf. BCM-02).
tion of restores is performed only by author-
ised persons; and Notes on Continuous Auditing
• Tests of recovery procedures (cf. OPS-08). Feasibility: partially
61
A policy can change ad-hoc. However, the contin- Notes on Continuous Auditing
uous audit of policies is only partially feasible as
the only attributes that can be tested are the last Feasibility: yes
change date and the status of review or approval,
as far as this information is stored in a system. The The execution of different data backups can be
content of a policy can hardly be tested automat- performed by continuously auditing the log files
ically. and the associated results of the data backup. Any
errors in the data backup would be continuously
detected and could be explained by appropriate
measures and documentation in the audit.
OPS-07 Data Backup and Recovery –
Monitoring
Basic Criterion OPS-08 Data Backup and Recovery –

Regular Testing
The execution of data backups is monitored by
technical and organisational measures. Mal- Basic Criterion
functions are investigated by qualified staff and
rectified promptly to ensure compliance with Restore procedures are tested regularly, at least
contractual obligations to cloud customers or the annually. The tests allow an assessment to be
Cloud Service Provider’s business requirements made as to whether the contractual agreements
regarding the scope and frequency of data backup as well as the specifications for the maximum tol-
and the duration of storage. erable downtime (Recovery Time Objective, RTO)
and the maximum permissible data loss (Recovery
Point Objective, RPO) are adhered to (cf. BCM-02).
Deviations from the specifications are reported to
The relevant logs or summarised results are avail- the responsible personnel or system components
able to the cloud customer in a self-service portal so that these can promptly assess the deviations
for monitoring the data backup. and initiate the necessary actions.
Supplementary Information Additional Criterion
About the Criterion At the customer’s request, the Cloud Service Pro-
vider inform the cloud customer of the results of
If the data backup is not part of the contract con- the recovery tests. Recovery tests are embedded in
cluded between the Cloud Service Provider and the Cloud Service Provider’s emergency manage-
the cloud customer, this criterion is not applica- ment.
ble. The Cloud Service Provider must present this
situation transparently in the system description.
About the Criterion
trols, that the backup of data within their area If the data backup is not part of the contract con-
of responsibility is monitored by technical and cluded between the Cloud Service Provider and
organisational measures. the cloud customer, this criterion is not applica-
ble. The Cloud Service Provider must present this
situation transparently in the system description.
62
Complementary Customer Criterion A remote location can be e.g. another data centre
of the Cloud Service Provider.
–
–
If the tests on the restoration procedures are
performed at regular intervals, the time of exe- Feasibility: yes
cution and results can be audited automatically.
However, the effort of a continuous audit of this If the data is transported physically, a continuous
criterion is high and the added value limited if the audit of this criterion means that the successful
tests are carried out in an annual cycle storage has been confirmed. In the case of elec-
tronic transmission, the log files of the transmis-
sion can be continuously evaluated, and the result
of this audit can be transmitted.
OPS-09 Data Backup and Recovery – Storage
Basic Criterion
OPS-10 Logging and Monitoring – Concept
The Cloud Service Provider transfers data to be
backed up to a remote location or transports these Basic Criterion
on backup media to a remote location. If the data
backup is transmitted to the remote location via The Cloud Service Provider has established
a network, the data backup or the transmission policies and instructions that govern the logging
of the data takes place in an encrypted form that and monitoring of events on system components
corresponds to the state-of-the-art. The distance within its area of responsibility. These policies and
to the main site is chosen after sufficient consid- instructions are documented, communicated and
eration of the factors recovery times and impact provided according to SP-01 with respect to the
of disasters on both sites. The physical and envi- following aspects:
ronmental security measures at the remote site
are at the same level as at the main site. • Definition of events that could lead to a viola-
tion of the protection goals;
Additional Criterion • Specifications for activating, stopping and

pausing the various logs;
–
• Information regarding the purpose and reten-
tion period of the logs;
• Define roles and responsibilities for setting up
About the Criterion and monitoring logging;
If the data backup is not part of the contract con- • Time synchronisation of system components;
cluded between the Cloud Service Provider and and
the cloud customer, this criterion is not applica-
ble. The Cloud Service Provider must present this • Compliance with legal and regulatory frame-
situation transparently in the system description. works.
63
Additional Criterion • Exclusively anonymous metadata to deploy

and enhance the cloud service so that no
– conclusions can be drawn about the cloud
customer or user;
Supplementary Information • No commercial use;
About the Criterion • Storage for a fixed period reasonably related

to the purposes of the collection;
Legal and regulatory frameworks can define e.g.
legal requirements for retention and deletion of • Immediate deletion if the purposes of the
data. collection are fulfilled and further storage is
no longer necessary; and
• Provision to cloud customers according to
Cloud customers ensure through suitable con- contractual agreements.
trols, that appropriate logging and monitoring of
events that may affect the security and availability
of the cloud service (e.g. administrator activities, Additional Criterion
system failures, authentication checks, data dele-
tions, etc.) takes place for those layers of the cloud Personal data is automatically removed from the
service under their responsibility. log data before the Cloud Service Provider pro-
cesses it as far as technically possible. The removal
Notes on Continuous Auditing is done in a way that allows the Cloud Service
Provider to continue to use the log data for the
Feasibility: partially purpose for which it was collected.

uous audit of policies is only partially feasible as Supplementary Information
change date and the status of review or approval, About the Criterion
content of a policy can hardly be tested automat- Metadata is all data that is generated by the Cloud
ically. Service Provider through the use of its service
by the cloud customer and is not content-re-
lated data. This includes login/logout times,
IP addresses, customer’s GPS location, which
OPS-11 Logging and Monitoring – Metadata resources (network, storage, computer) were used,
Management Concept which data was accessed when, with whom data
was shared, with whom it was communicated, etc.
Basic Criterion This data is partly used for billing purposes and
for (security) incident management. However, it
Policies and instructions for the secure handling can also be used to analyse customer behaviour
of metadata (usage data) are documented, com- (depending on the cloud service) and to make
municated and provided according to SP-01 with the decision making and work processes visible
regard to the following aspects: to the Cloud Service Provider. The criteria aim
to provide a transparent and clear definition of
• Metadata is collected and used solely for the collection and use of metadata. In addition,
billing, incident management and security metadata refers to data that is generated when the
incident management purposes; Cloud Service Provider accesses customer data
(e.g. for indexing).
64
Complementary Customer Criterion Notes on Continuous Auditing
– Feasibility: no
Notes on Continuous Auditing A continuous check is only of limited use here,

since the primary purpose of checking the
Feasibility: partially handling of metadata is to check the guidelines
and the associated configurations of the tools
A policy can change ad-hoc. However, the contin- for securing, processing and deleting metadata.
uous audit of policies is only partially feasible as In addition, the contractual basis for the use of
the only attributes that can be tested are the last metadata may also need to be considered.
as far as this information is stored in a system. The A continuous audit could include the configura-
content of a policy can hardly be tested automat- tion for deleting or anonymising the metadata
ically. and automatically recording whether the config-
uration still exists and is implemented correctly.
In this case, there would be a partial possibility for
continuous auditing.
OPS-12 Logging and Monitoring – Access,
Storage and Deletion
Basic Criterion OPS-13 Logging and Monitoring –

Identification of Events
The requirements for the logging and monitoring
of events and for the secure handling of metadata Basic Criterion
are implemented by technically supported proce-
dures with regard to the following restrictions: The logging data is automatically monitored for
events that may violate the protection goals in
• Access only for authorised users and systems; accordance with the logging and monitoring
requirements. This also includes the detection of
• Retention for the specified period; and relationships between events (event correlation).
• Deletion when further retention is no longer Identified events are automatically reported to the
necessary for the purpose of collection. appropriate departments for prompt evaluation
and action.
–
–
About the Criterion
About the Criterion
–
–
–
–
65
Notes on Continuous Auditing Complementary Customer Criterion
Feasibility: yes –
The Cloud Service Provider can automatically test Notes on Continuous Auditing
the list of assets critical for monitoring and record
this test in logs. Feasibility: yes
The auditor can audit the log files for irregulari- The storage of logging data at a central location
ties automatically and continuously. can be documented by logs when the data is
saved. The deletion of this data can also be auto-
mated and documented by logs.
OPS-14 Logging and Monitoring – Storage The auditor can then perform an automated and
of the Logging Data continuous evaluation of these logs.
Basic Criterion
The Cloud Service Provider retains the gener- OPS-15 Logging and Monitoring –
ated log data and keeps these in an appropriate, Accountability
unchangeable and aggregated form, regardless of
the source of such data, so that a central, author- Basic Criterion
ised evaluation of the data is possible. Log data is
deleted if it is no longer required for the purpose The log data generated allows an unambiguous
for which they were collected. identification of user accesses at tenant level to
support (forensic) analysis in the event of a secu-
Between logging servers and the assets to be rity incident.
logged, authentication takes place to protect the
integrity and authenticity of the information Interfaces are available to conduct forensic analy-
transmitted and stored. The transfer takes place ses and perform backups of infrastructure com-
using state-of-the-art encryption or a dedicated ponents and their network communication.
administration network (out-of-band manage-
ment).
Additional Criterion On request of the cloud customer, the Cloud

Service Provider provides the logs relating to the
The Cloud Service Provider provides a custom- cloud customer in an appropriate form and in a
er-specific logging (in terms of scope and duration timely manner so that the cloud customer can
of retention period) upon request of the Cloud investigate any incidents relating to them.
Customer. Depending on the protection require-
ments of the Cloud Service Provider and the tech-
nical feasibility, a logical or physical separation of Supplementary Information
log and customer data is carried out.
About the Criterion
Supplementary Information Infrastructure components in the sense of this

criterion are e.g. fabric controllers, network com-
About the Criterion ponents and virtualisation servers.
66
Complementary Customer Criterion Notes on Continuous Auditing
Cloud customers ensure through suitable con- Feasibility: yes

trols, that unique user IDs are assigned which
allow a corresponding analysis in the event of a The continuous audit of this access restriction
security incident. can be tested by log files of all changes to access
rights for the system components for logging and
Notes on Continuous Auditing monitoring. Changes can be automatically and
continuously audited according to the person’s
Feasibility: no sense and need for access.
For the generated logging data to allow unambig-

uous identification of user accesses at the tenant
level, the creation of this data must be configured OPS-17 Logging and Monitoring – Availability
accordingly. This configuration does not have to of the Monitoring Software
be audited continuously, but only if it is changed.
Basic Criterion
The interfaces can also be audited initially and
then tested again if changes are made. The Cloud Service Provider monitors the system
components for logging and monitoring in its
area of responsibility. Failures are automatically
and promptly reported to the Cloud Service Pro-
OPS-16 Logging and Monitoring – vider’s responsible departments so that these can
Configuration assess the failures and take required action.
Basic Criterion
Access to system components for logging and
monitoring in the Cloud Service Provider’s area The system components for logging and moni-
of responsibility is restricted to authorised users. toring are designed in such a way that the overall
Changes to the configuration are made in accord- functionality is not restricted if individual com-
ance with the applicable policies (cf. DEV-03). ponents fail.
Additional Criterion Supplementary Information
Access to system components for logging and About the Criterion

monitoring in the Cloud Service Provider’s area of
responsibility requires two-factor authentication. –

–
About the Criterion
–
Feasibility: yes
Automatically communicated failures can be
– tracked in logs.
67
A continuous and automated audit of these fail- ment. If necessary, risk-compensating measures
ures can be carried out by evaluating these logs. must be taken.
OPS-18 Managing Vulnerabilities, Malfunctions Cloud customers ensure through suitable con-
and Errors – Concept trols, that they check system components in their
area of responsibility for vulnerabilities on a
Basic Criterion regular basis and mitigate these with appropriate
measures.
Guidelines and instructions with technical and
organisational measures are documented, com- Notes on Continuous Auditing
municated and provided in accordance with
SP-01 to ensure the timely identification and Feasibility: no
addressing of vulnerabilities in the system com-
ponents used to provide the cloud service. These A policy can change ad-hoc. However, the contin-
guidelines and instructions contain specifications uous audit of policies is only partially feasible as
regarding the following aspects: the only attributes that can be tested are the last
• Regular identification of vulnerabilities; as far as this information is stored in a system. The
content of a policy can hardly be tested automat-
• Assessment of the severity of identified vul- ically.
nerabilities;
• Prioritisation and implementation of actions

to promptly remediate or mitigate identified OPS-19 Managing Vulnerabilities, Malfunctions
vulnerabilities based on severity and accord- and Errors – Penetration Tests
ing to defined timelines; and
Basic Criterion
• Handling of system components for which no
measures are initiated for the timely remedia- The Cloud Service Provider has penetration tests
tion or mitigation of vulnerabilities. carried out by qualified internal personnel or
external service providers at least once a year.
The penetration tests are carried out according
Additional Criterion to a documented test methodology and include
the system components relevant to the provision
– of the cloud service in the area of responsibility
of the Cloud Service Provider, which have been
identified as such in a risk analysis.
The Cloud Service Provider assess the severity of
About the Criterion the findings made in penetration tests according
to defined criteria.
Identified vulnerabilities can be classified accord-
ing to established metrics such as CVSS or For findings with medium or high criticality
OWASP. The decision not to remediate or mitigate regarding the confidentiality, integrity or availa-
identified vulnerabilities must be made by the bility of the cloud service, actions must be taken
Cloud Service Provider based on a risk assess- within defined time windows for prompt remedi-
ation or mitigation.
68
Additional Criterion their continued suitability, appropriateness and

effectiveness.
The tests are carried out every six months. They
must always be performed by independent exter- Results are evaluated at least quarterly by
nal auditors. Internal personnel for penetration accountable departments at the Cloud Service
tests may support the external service providers. Provider to initiate continuous improvement
actions and to verify their effectiveness.
About the Criterion
–
Vulnerabilities should be classified according to
damage potential and a period of time should be
specified for the required response. The following Supplementary Information
classification according to the BSI publication
“Ein Praxis-Leitfaden für IS-Penetrationstests” About the Criterion
can serve as an orientation:
Common Vulnerabilities and Exposures (CVE) or
• High: Immediate reaction; similar methods are a suitable way of document-
ing vulnerabilities and incidents.
• Medium: Short-term response;
• Low: Medium-term response; and
–
• Information: Long-term response.
Feasibility: yes
–
The measurements, analyses and evaluations are
Notes on Continuous Auditing based on data that could be continuously queried
in order to verify the plausibility of the results
Feasibility: partially derived from them.
Since penetration tests are carried out annually, a The initiation and review of measures for contin-
continuous audit is not practical, since the effort uous improvement require a manual audit.
required to automate the execution of the test is
probably greater than the benefit.
OPS-21 Involvement of Cloud Customers

in the Event of Incidents
OPS-20 Managing Vulnerabilities,
Malfunctions and Errors – Measurements, Analyses Basic Criterion
and Assessments of Procedures
The Cloud Service Provider periodically informs
Basic Criterion the cloud customer on the status of incidents
affecting the cloud customer, or, where appro-
The Cloud Service Provider regularly measures, priate and necessary, involve the customer in
analyses and assesses the procedures with which the resolution, in a manner consistent with the
vulnerabilities and incidents are handled to verify contractual agreements.
69
As soon as an incident has been resolved from the informed on a regular basis about all incidents
Cloud Service Provider’s perspective, the cloud affecting them, but not beyond.
customer is informed according to the contrac-
tual agreements, about the actions taken.
OPS-22 Testing and Documentation of known

Additional Criterion Vulnerabilities
– Basic Criterion
System components in the area of responsibility

Supplementary Information of the Cloud Service Provider for the provision of
the cloud service are automatically checked for
About the Criterion known vulnerabilities at least once a month in
accordance with the policies for handling vul-
– nerabilities (cf. OPS-18), the severity is assessed
in accordance with defined criteria and measures
Complementary Customer Criterion for timely remediation or mitigation are initiated
within defined time windows.
Cloud customers ensure through suitable controls
that they receive notifications from the Cloud
Service Provider regarding incidents that affect Additional Criterion
them, and that these notifications are forwarded
in a timely manner to the department responsible Available security patches are applied depending
for processing them so that appropriate action on the severity of the vulnerabilities, as deter-
can be taken. mined based on the latest version of the Common
Vulnerability Scoring System (CVSS):
• Critical (CVSS = 9.0 – 10.0), 3 hours;
Feasibility: yes
• High (CVSS = 7.0 – 8.9), 3 days;
A continuous audit is possible if customers are
informed about incidents via a standardised • Average (CVSS = 4.0 – 6.9), 1 month; and
communication channel and this is documented
(e-mails, logs). • Low (CVSS = 0.1 – 3.9), 3 months.
The auditor can then evaluate the compiled docu-

mentation automatically and continuously. Supplementary Information
However, it seems more effective to combine the About the Criterion

evaluation of the communication of incidents to
cloud customers with the evaluation of the elim- In contrast to penetration tests (cf. OPS-20), which
ination of the incidents. As soon as the incidents are carried out manually and according to an
have been resolved automatically in the best case, individual scheme, the check for open vulnerabil-
an automatic message is generated and sent to ities is performed automatically, using so-called
the cloud customer. This message is to be docu- vulnerability scanners.
mented.
This makes it possible for the auditor to evaluate
whether the cloud customer has been properly Cloud customers ensure through suitable con-
trols, that system components under their
70
responsibility are regularly checked for vulner- Supplementary Information

abilities and to mitigate these by appropriate
measures. About the Criterion
Notes on Continuous Auditing System components in the sense of the basic cri-
terion are the objects required for the information
Feasibility: yes security of the cloud service during the creation,
processing, storage, transmission, deletion or
The periodic check for vulnerabilities and the destruction of information in the Cloud Service
corresponding results as well as the analysis and Provider’s area of responsibility, e.g. firewalls,
remediation of identified vulnerabilities are docu- load balancers, web servers, application servers
mented by the Cloud Service Provider. and database servers. These system components
in turn consist of hardware and software objects.
An automated and continuous audit of this proce- This criterion is limited to software objects such
dure can be implemented by the auditor by auto- as hypervisors, operating systems, databases, pro-
matically evaluating the documented results. gramming interfaces (APIs), images (e.g. for virtual
machines and containers) and applications for
logging and monitoring security events.
OPS-23 Managing Vulnerabilities, Malfunctions The configuration and log files for non-modifiable
and Errors – System Hardening mages include e.g.:
Basic Criterion • Configuration of the images used with regards

to implemented hardening specifications
System components in the production environ- including version history; and
ment used to provide the cloud service under the
Cloud Service Provider’s responsibility are hard- • Logs for file integrity monitoring of images in
ened according to generally accepted industry productive use.
standards. The hardening requirements for each
system component are documented. Generally accepted industry standards are, for
example, the Security Configuration Benchmark
If non-modifiable (“immutable”) images are used, of the “Centre for Internet Security” (CIS) or the
compliance with the hardening specifications as corresponding modules in the BSI IT-Grund-
defined in the hardening requirements is checked schutz-Kompendium.
upon creation of the images. Configuration and
log files regarding the continuous availability of Compliance with hardening specifications can be
the images are retained. monitored with e.g. file integrity monitoring.

System components in the Cloud Service Pro- trols that layers of the cloud service which are
vider’s area of responsibility are automatically under their responsibility are hardened according
monitored for compliance with hardening spec- to generally established and accepted industry
ifications. Deviations from the specifications are standards. The hardening specifications applied
automatically reported to the appropriate depart- are derived from a risk assessment of the planned
ments of the Cloud Service Provider for immedi- usage of the cloud service.
ate assessment and action.
Feasibility: yes
71
The verification of compliance with the specifi- Complementary Customer Criterion

cations for the hardening of system components
can be automatically tested and subsequently Cloud customers ensure through suitable con-
documented (logs). trols that the functions provided by the cloud
service for segregating shared virtual and physical
The auditor can evaluate these logs automatically resources are used in such way that risks related
and continuously and thus carry out a continuous to segregation are adequately addressed according
audit. to the data’s protection requirements.
OPS-24 Separation of Datasets in the Cloud Feasibility: partially

Infrastructure
The segregation according to a documented
Basic Criterion concept is implemented by means of a configura-
tion which does not change with high frequency.
Cloud customer data stored and processed on A continuous audit of this configuration could
shared virtual and physical resources is securely check whether the configuration and thus the
and strictly separated according to a documented segregation of the data is implemented correctly.
approach based on OIS-07 risk analysis to ensure However, the effort for a continuous audit would
the confidentiality and integrity of this data. be high and the benefit limited due to the low
change rate of the configuration. Thus, a contin-
uous audit would only be of limited use here. If
Additional Criterion compliance with the measures taken is moni-
tored, this criterion can be audited automatically.
Resources in the storage network are segmented
by secure zoning (LUN binding and LUN mask- It would also be conceivable to continuously
ing). audit the actual data segregation. For this purpose,
the Cloud Service Provider would have to set
up appropriate agents to monitor the data flow
Supplementary Information between the customer instances (or its absence)
on a permanent and documented basis (logs).
About the Criterion
Shared resources include memory, cores and

storage networks. Technical segregation (sepa- 5.7 Identity and Access Management (IDM)
ration) of the stored and processed data of cloud
customers into shared resources can be achieved Objective: Secure the authorisation and
through firewalls, access lists, tagging, VLANs, authentication of users of the Cloud Service
virtualisation and measures in the storage net- Provider (typically privileged users) to prevent
work (e.g. LUN binding and LUN masking). Where unauthorised access.
the adequacy and effectiveness of segregation
cannot be assessed with reasonable assurance
(e.g. due to complex implementation), evidence
may also be provided through expert third party IDM-01 Policy for user accounts and
review results (e.g. penetration tests to validate the access rights
concept). The segregation of transmitted data is
subject to control COS-06. Basic Criterion
A role and rights concept based on the business

and security requirements of the Cloud Service
72
Provider as well as a policy for managing user Supplementary Information

accounts and access rights for internal and exter-
nal employees of the Cloud Service Provider and About the Criterion
system components that have a role in automated
authorisation processes of the Cloud Service Pro- System components in the sense of the basic
vider are documented, communicated and made criterion cf. definition in OPS-23. Automated
available according to SP-01: authorisation processes in the sense of this basic
criterion concern procedures for automated soft-
• Assignment of unique usernames; ware provisioning (continuous delivery) as well
as for automated provisioning and deprovision-
• Granting and modifying user accounts ing of user accounts and access rights based on
and access rights based on the “least-priv- approved requests.
ilege-principle” and the “need-to-know”
principle; Complementary Customer Criterion
• Segregation of duties between operational –

and monitoring functions (“Segregation of
Duties”); Notes on Continuous Auditing
• Segregation of duties between managing, Feasibility: partially

approving and assigning user accounts and
access rights; A policy can change ad-hoc. However, the contin-
• Approval by authorised individual(s) or the only attributes that can be tested are the last
system(s) for granting or modifying user change date and the status of review or approval,
accounts and access rights before data of the as far as this information is stored in a system. The
cloud customer or system components used content of a policy can hardly be tested automat-
to provision the cloud service can be accessed; ically.
• Regular review of assigned user accounts and The aspects mentioned in the policy can be con-
access rights; verted into individual criteria and embedded in a
continuous audit. Individual aspects of the policy
• Blocking and removing access accounts in the which can be examined on an ongoing basis:
event of inactivity;
• Unique user name;
• Time-based or event-driven removal or
adjustment of access rights in the event of • Segregation of duties;
changes to job responsibility;
• Rights profile management (approvals);
• Two-factor or multi-factor authentication for
users with privileged access; and • Authorised bodies or individuals;
• Requirements for the approval and documen- • Regular review;

tation of the management of user accounts
and access rights. • Deactivation due to inactivity; and
• Multi-factor authentication.
Approval and documentation Individual aspects
– of the policy which cannot be continuously
examined in a practicable manner:
73
• Implementation of least-privilege/need-to- IDM-03 Locking and withdrawal of user

know principles; and accounts in the event of inactivity or multiple
failed logins
• Withdrawal or adjustment of access rights as
the task area changes. Basic Criterion
User accounts of internal and external employees

of the Cloud Service Provider as well as for system
IDM-02 Granting and change of user accounts components involved in automated authorisation
and access rights processes of the Cloud Service Provider are auto-
matically locked if they have not been used for a
Basic Criterion period of two months. Approval from authorised
personnel or system components are required to
Specified procedures for granting and modifying unlock these accounts.
user accounts and access rights for internal and
external employees of the Cloud Service Provider Locked user accounts are automatically revoked
as well as for system components involved in after six months. After revocation, the procedure
automated authorisation processes of the Cloud for granting user accounts and access rights (cf.
Service Provider ensure compliance with the role IDM-02) must be repeated.
and rights concept as well as the policy for man-
aging user accounts and access rights.
Additional Criterion –
The Cloud Service Provider offers cloud cus-

tomers a self-service with which they can inde- Supplementary Information
pendently assign and change user accounts and
access rights. About the Criterion
Locking can result from a longer absence of the

Supplementary Information employee, for example, due to illness, parental
leave, or sabbatical.
About the Criterion
–
–
–
Feasibility: yes
Automated processes can easily be included in
Feasibility: no the continuous audit. Appropriate evaluation and
reporting mechanisms must be used by the Cloud
A continuous audit of procedures is strongly Service Provider. The auditor must use data analy-
dependent on the underlying systematics and ses to detect deviations.
automation of the Cloud Service Provider’s pro-
cedures. This may vary in individual cases, but in
general a continuous audit does not appear to be
effective.
74
IDM-04 Withdraw or adjust access rights IDM-05 Regular review of access rights
as the task area changes
Basic Criterion
Basic Criterion
Access rights of internal and external employees
Access rights are promptly revoked if the job of the Cloud Service Provider as well as of system
responsibilities of the Cloud Service Provider’s components that play a role in automated author-
internal or external staff or the tasks of system isation processes of the Cloud Service Provider
components involved in the Cloud Service Pro- are reviewed at least once a year to ensure that
vider’s automated authorisation processes change. they still correspond to the actual area of use.
Privileged access rights are adjusted or revoked The review is carried out by authorised persons
within 48 hours after the change taking effect. All from the Cloud Service Provider’s organisational
other access rights are adjusted or revoked within units, who can assess the appropriateness of the
14 days. After revocation, the procedure for grant- assigned access rights based on their knowledge
ing user accounts and access rights (cf. IDM-02) of the task areas of the employees or system
must be repeated. components. Identified deviations will be dealt
with promptly, but no later than 7 days after their
detection, by appropriate modification or with-
Additional Criterion drawal of the access rights.
–
Supplementary Information Privileged access rights are reviewed at least every

six months.
About the Criterion
Changes in the task area of internal and external Supplementary Information

employees can be triggered by changes in the
employment relationship (e.g. termination, trans- About the Criterion
fer) or in contracts and agreements. For privileged
access rights the definition in IDM-06 applies. –
Complementary Customer Criterion Complementary Customer Criterion
– –
Notes on Continuous Auditing Notes on Continuous Auditing
Feasibility: yes Feasibility: yes
It is necessary to record the changes to the task The review audit cannot be recorded automati-
area in terms of content together with the date of cally. A registration of documents used for doc-
entry into force in order to compare these with umentary purposes could take place (e.g. confir-
the adjustments made to the access rights. A con- mation that the assignment of the access rights
tinuous audit seems possible but requires a great has been reviewed). A continuous audit could
deal of effort to implement. indicate when this review was last carried out. The
Cloud Service Provider must automate the review
process (in particular the confirmation that the
review has been performed) so that the auditor
75
can audit the steps to be performed in case devia- • Read or write access to the cloud customers’
tions are detected. 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
IDM-06 Privileged access rights
• Changes to the operational and/or security
Basic Criterion configuration of the system components in
the production environment, in particular the
Privileged access rights for internal and exter- starting, stopping, deleting or deactivating of
nal employees as well as technical users of the system components, if this can affect the con-
Cloud Service Provider are assigned and changed fidentiality, integrity or availability of the data
in accordance to the policy for managing user of the cloud customers (also indirectly, e.g. by
accounts and access rights (cf. IDM-01) or a sepa- deactivating the logging and monitoring of
rate specific policy. security-relevant events).
Privileged access rights are personalised, lim- Misused privileged access rights can be treated e.g.
ited in time according to a risk assessment and as a security incident, cf. SIM-01.
assigned as necessary for the execution of tasks
(“need-to-know principle”). Technical users are Complementary Customer Criterion
assigned to internal or external employees of the
Cloud Service Provider. –
Activities of users with privileged access rights are Notes on Continuous Auditing
logged in order to detect any misuse of privileged
access in suspicious cases. The logged information Feasibility: partially
is automatically monitored for defined events
that may indicate misuse. When such an event is The assignment of audit authorisations must be
identified, the responsible personnel are automat- audited manually. This includes the classification
ically informed so that they can promptly assess as privileged, personalisation, and evaluation of
whether misuse has occurred and take corre- the need-to-know principle. The time limit could
sponding action. In the event of proven misuse of be read, but the implementation effort would be
privileged access rights, disciplinary measures are very high. A continuous audit does not appear
taken in accordance with HR-04. to be sensible here. Only the system status could
be audited continuously. The automatic trigger-
ing of a notification in suspicious cases could be
Additional Criterion compared with documented measures to handle
these cases. However, this entire process must be
– digitised for this purpose, and the effort involved
currently appears to be very high. However, a
continuous audit could show the time of the last
Supplementary Information manual audit.
About the Criterion
Privileged access rights in the sense of the Basic IDM-07 Access to cloud customer data
Criterion are those that enable employees of the
Cloud Service Provider to perform any of the Basic Criterion
following activities:
The cloud customer is informed by the Cloud
Service Provider whenever internal or external
76
employees of the Cloud Service Provider read A continuous audit of the notifications carried out
or write to the cloud customer’s data processed, only appears practical if the accesses mentioned
stored or transmitted in the cloud service or have are also logged and classified automatically. The
accessed it without the prior consent of the cloud content of the notifications can only be audited
customer. The Information is provided whenever if the content is specified by the Cloud Service
data of the cloud customer is/was not encrypted, Provider according to a specific scheme. Then, a
the encryption is/was disabled for access or the comparison and plausibility check can take place.
contractual agreements do not explicitly exclude A continuous audit would test all notifications
such information. The information contains the after they have been received and thus check
cause, time, duration, type and scope of the access. whether the process has been executed correctly
The information is sufficiently detailed to enable in all cases.
subject matter experts of the cloud customer to
assess the risks of the access. The information
is provided in accordance with the contractual
agreements, or within 72 hours after the access. IDM-08 Confidentiality of authentication
information
Access to the data processed, stored or transmit- The allocation of authentication information to
ted in the cloud service by internal or external access system components used to provide the
employees of the Cloud Service Provider requires cloud service to internal and external users of the
the prior consent of an authorised department of cloud provider and system components that are
the cloud customer, provided that the cloud cus- involved in automated authorisation processes of
tomer’s data is not encrypted, encryption is disa- the cloud provider is done in an orderly manner
bled for access, or contractual agreements do not that ensures the confidentiality of the informa-
explicitly exclude such consent. For the consent, tion. If passwords are used as authentication
the cloud customer’s department is provided with information, their confidentiality is ensured by
meaningful information about the cause, time, the following procedures, as far as technically
duration, type and scope of the access supporting possible:
assessing the risks associated with the access.
• Users can initially create the password them-
selves or must change an initial password
Supplementary Information when logging on to the system component
for the first time. An initial password loses its
About the Criterion validity after a maximum of 14 days.
Subject matter experts in the sense of this basic • When creating passwords, compliance with
criterion is personnel from e.g. IT, Compliance or the password specifications (cf. IDM-09) is
Internal Audit. enforced as far as technically possible.
Complementary Customer Criterion • The user is informed about changing or reset-

ting the password.
–
• The server-side storage takes place using cryp-
Notes on Continuous Auditing tographically strong hash functions.
Feasibility: yes Deviations are evaluated by means of a risk analy-

sis and mitigating measures derived from this are
implemented.
77
Additional Criterion multi-factor authentication. Within the produc-

tion environment, user authentication takes place
The users sign a declaration in which they assure through passwords, digitally signed certificates
that they treat personal (or shared) authentication or procedures that achieve at least an equivalent
information confidentially and keep it exclusively level of security. If digitally signed certificates
for themselves (within the members of the group). are used, administration is carried out in accord-
ance with the Guideline for Key Management (cf.
CRY-01). The password requirements are derived
Supplementary Information from a risk assessment and documented, commu-
nicated and provided in a password policy accord-
About the Criterion ing to SP-01. Compliance with the requirements
is enforced by the configuration of the system
Argon2i, for example, is suitable for using a pass- components, as far as technically possible.
word hash function.
Insofar as this is legally binding, declarations can Additional Criterion

be signed using an electronic signature.
Access to the non-production environment
Complementary Customer Criterion requires two-factor or multi-factor authentica-
tion. Within the non-production environment,
– users are authenticated using passwords, digitally
signed certificates, or procedures that provide at
Notes on Continuous Auditing least an equivalent level of security.
Feasibility: yes
If the implementation is enforced by appropriate
system configuration (automated control), the About the Criterion
status or the last change of the configuration can
be checked regularly. –
IDM-09 Authentication mechanisms –
Basic Criterion Notes on Continuous Auditing
System components in the Cloud Service Pro- Feasibility: yes

vider’s area of responsibility that are used to
provide the cloud service, authenticate users of If the implementation is enforced by appropriate
the Cloud Service Provider’s internal and exter- system configuration (automated control), the
nal employees as well as system components status of the configuration or its last change can
that are involved in the Cloud Service Provider’s be checked regularly.
automated authorisation processes. Access to the
production environment requires two-factor or
78
5.8 Cryptography and Key Management (CRY) • BSI TR-02102-1 Cryptographic Mechanisms:
Recommendations and Key Lengths;
Objective: Ensure appropriate and effective use
of cryptography to protect the confidentiality, • BSI TR-02102-2 Cryptographic Mechanisms:
authenticity or integrity of information. Use of Transport Layer Security (TLS);
• BSI TR-02102-3 Cryptographic Mechanisms:

Use of Internet Protocol Security (IPSec) and
CRY-01 Policy for the use of encryption Internet Key Exchange (IKEv2); and
procedures and key management
• BSI TR-02102-4 Cryptographic Mechanisms:
Basic Criterion Use of Secure Shell (SSH).
Policies and instructions with technical and Complementary Customer Criterion

organisational safeguards for encryption pro-
cedures and key management are documented, –
communicated and provided according to SP-01,
in which the following aspects are described: Notes on Continuous Auditing
• Usage of strong encryption procedures and Feasibility: partially

secure network protocols that correspond to
the state-of-the-art; A policy can change ad-hoc. However, the contin-
• Risk-based provisions for the use of encryp- the only attributes that can be tested are the last
tion which are aligned with the informa- change date and the status of review or approval,
tion classification schemes (cf. AM-06) and as far as this information is stored in a system. The
consider the communication channel, type, content of a policy can hardly be tested automat-
strength and quality of the encryption; ically.
• Requirements for the secure generation, stor-

age, archiving, retrieval, distribution, with-
drawal and deletion of the keys; and CRY-02 Encryption of data for transmission
(transport encryption)
• Consideration of relevant legal and regulatory
obligations and requirements. Basic Criterion
The Cloud Service Provider has established proce-

Additional Criterion dures and technical measures for strong encryp-
tion and authentication for the transmission of
– data of cloud customers over public networks.
About the Criterion The Cloud Service Provider has established proce-
dures and technical measures for strong encryp-
The state-of-the-art of strong encryption proce- tion and authentication for the transmission of all
dures and secure network protocols is specified in data.
the following BSI Technical Guidelines valid at the
given time:
79
Supplementary Information CRY-03 Encryption of sensitive data for storage
When transmitting data with normal protection The Cloud Service Provider has established pro-
requirements within the Cloud Service Provid- cedures and technical safeguards to encrypt cloud
er’s infrastructure, encryption is not mandatory customers’ data during storage. The private keys
provided that the data is not transmitted via used for encryption are known only to the cloud
public networks. In this case, the non-public customer in accordance with applicable legal and
environment of the Cloud Service Provider can regulatory obligations and requirements. Excep-
generally be deemed trusted. The protocols TLS tions follow a specified procedure. The procedures
1.2 and TLS 1.3 are currently regarded as strong, for the use of private keys, including any excep-
state-of-the-art transport encryptions, in each tions, must be contractually agreed with the cloud
case in combination with Perfect Forward Secrecy. customer.
The specific configuration should comply with
the recommendations of the (current) version of
the BSI Technical Guideline TR-02102-2 “Cryp- Additional Criterion
tographic Procedures: Recommendations and key
lengths. Part 2 – Use of Transport Layer Security The private keys used for encryption are known
(TLS)”. Generally, the use of wildcard certificates is to the customer exclusively and without excep-
not considered a secure procedure. tion in accordance with applicable legal and
regulatory obligations and requirements.
The basic criterion for the transmission cloud
customers’ data, relates to e.g. the sending of elec-
tronic messages via public networks. Supplementary Information
Complementary Customer Criterion About the Criterion
Cloud customers ensure through suitable controls An exception to the requirement that keys are
for those parts of the cloud service under their known only to the cloud customers may be the
responsibility, that their data is transmitted over use of a master key by the Cloud Service Pro-
encrypted connections in accordance with the vider. If the Cloud Service Provider established a
respective protection requirements. procedure to use a master key, the Cloud Service
Provider must perform sample-based checks
Notes on Continuous Auditing regarding the suitability and effectiveness of the
procedure, on a regular basis. This criterion does
Feasibility: partially not apply to data that cannot be encrypted for
the provision of the cloud service for functional
The procedures and technical measures for reasons.
encrypting data during transmission are config-
ured centrally. This configuration rarely changes. Complementary Customer Criterion
Therefore, a continuous audit would not be sen-
sible, as only changes to this configuration would Through suitable controls, cloud customers
have to be checked. However, the system status ensure for parts of the cloud service under their
can be audited continuously. This also applies to responsibility (e. g. virtual machines within an
the additional criterion. IaaS solution), that their data is encrypted during
storage in accordance with the respective protec-
tion requirements.
80
Notes on Continuous Auditing • Handling of compromised keys;
Feasibility: partially • Withdrawal and deletion of keys; and
The encryption of data of cloud customers is • If pre-shared keys are used, the specific provi-
configured centrally; therefore, it is only suita- sions relating to the safe use of this procedure
ble for continuous auditing to a limited extent. are specified separately.
Exceptions to the encryption of data according to
a specified procedure and the coordination of this
with cloud customers should be documented and Additional Criterion
approved. This, too, is only suitable to a limited
extent for continuous auditing, as these excep- –
tions are decided on a case-by-case basis and do
not occur at a high enough frequency. In a con-
tinuous audit, the system status can be queried Supplementary Information
to determine whether the encryption is active
and whether the approved exceptions are being About the Criterion
adhered to.
Keys should be withdrawn or deleted e.g. in the
event of compromise or employee changes. The
Cloud Service Provider protects the keys which
CRY-04 Secure key management are created and inserted into the cloud service
by the cloud customers according to the same
Basic Criterion criteria as the keys created by the Cloud Service
Provider.
Procedures and technical safeguards for secure
key management in the area of responsibility of Complementary Customer Criterion
the Cloud Service Provider include at least the
following aspects: –
• Generation of keys for different cryptographic Notes on Continuous Auditing

systems and applications;
• Issuing and obtaining public-key certificates;
For procedures and technical measures for key
• Provisioning and activation of the keys; management to take into account the required
aspects, these aspects must be implemented in
• Secure storage of keys (separation of key the corresponding configuration. These configu-
management system from application and rations are rarely changed and only these changes
middleware level) including description of would have to be audited continuously. However,
how authorised users get access; the system status could be reviewed and, in the
event of irregularities, indicated and documented.
• Changing or updating cryptographic keys
including policies defining under which
conditions and in which manner the changes
and/or updates are to be realised;
81
5.9 Communication Security (COS) responsibility (e.g. virtual machines within an IaaS
solution), that they detect and respond to net-
Objective: Ensure the protection of work-based attacks based on anomalous inbound
information in networks and the corresponding and outbound traffic patterns (e.g. MAC spoofing
information processing systems and ARP poisoning attacks) and/or Distributed
Denial of Service (DDoS), in a timely manner.

COS-01 Technical safeguards
Feasibility: yes
Basic Criterion
The technical protective measures are suitable
Based on the results of a risk analysis carried out for continuous auditing, but are rarely changed.
according to OIS-06, the Cloud Service Provider However, the data fed into the overall SIEM
has implemented technical safeguards which system and the detection of correlating events are
are suitable to promptly detect and respond to suitable for continuous auditing. This data can be
network-based attacks on the basis of irregu- evaluated automatically and continuously, as can
lar incoming or outgoing traffic patterns and/ the monitoring of correlating events.
or Distributed Denial of Service (DDoS) attacks.
Data from corresponding technical protection
measures implemented is fed into a compre-
hensive SIEM (Security Information and Event COS-02 Security requirements for connections
Management) system, so that (counter) measures in the Cloud Service Provider’s network
regarding correlating events can be initiated. The
safeguards are documented, communicated and Basic Criterion
provided in accordance with SP-01.
Specific security requirements are designed, pub-
lished and provided for establishing connections
Additional Criterion within the Cloud Service Provider’s network. The
security requirements define for the Cloud Service
Technical measures ensure that no unknown Provider’s area of responsibility:
(physical or virtual) devices join the Cloud Ser-
vice Provider’s (physical or virtual) network (e.g. • in which cases the security zones are to be
MACSec according to IEEE 802.1X:2010). separated and in which cases cloud customers
are to be logically or physically segregated;
Supplementary Information • which communication relationships and

which network and application protocols are
About the Criterion permitted in each case;
Network-based attacks can be conducted e.g. with • how the data traffic for administration and
MAC spoofing and ARP poisoning attacks. Tech- monitoring is segregated from each on net-
nical measures to prevent unknown physical or work level;
virtual devices from joining a physical or virtual
network can be based on e.g. MACSec according • which internal, cross-location communica-
to IEEE 802.1X:2010. tion is permitted; and
Complementary Customer Criterion • which cross-network communication is

allowed.
trols for parts of the cloud service under their
82
Additional Criterion management procedure (cf. OIS-06) and follow-up

measures are defined and tracked (cf. OPS-18).
–
At specified intervals, the business justification for
using all services, protocols, and ports is reviewed.
Supplementary Information The review also includes the justifications for
compensatory measures for the use of protocols
About the Criterion that are considered insecure.
Cross-location communication can be realised

for e.g. individual regions or data centres via e.g. Additional Criterion
WAN, LAN, VPN, RAS.
–
– Supplementary Information
Notes on Continuous Auditing About the Criterion
Feasibility: no The review of the security requirements depends

on the measures implemented to design the
The required security requirements are centrally networks. For example, monitoring and reviewing
documented and rarely changed. Continuous firewall rules or log files for abnormalities, as well
auditing is not practical. as visual inspections of physical network compo-
nents for changes.

COS-03 Monitoring of connections in the Cloud
Service Provider’s network Cloud customers ensure through suitable controls
that the virtual networks within the cloud ser-
Basic Criterion vice for which they are responsible are designed,
configured and documented in accordance with
A distinction is made between trusted and their network security requirements (e.g. logical
untrusted networks. Based on a risk assessment, segmentation of the cloud customer’s organisa-
these are separated into different security zones tional units).
for internal and external network areas (and DMZ,
if applicable). Physical and virtualised network Notes on Continuous Auditing
environments are designed and configured to
restrict and monitor the established connection Feasibility: yes
to trusted or untrusted networks according to the
defined security requirements. If the business justification and the regular review
of the monitoring concept are documented in a
The entirety of the conception and configuration standardised way, these processes can be evalu-
undertaken to monitor the connections men- ated automatically. Thus, a continuous audit can
tioned is assessed in a risk-oriented manner, at be conducted. The separation of the networks
least annually, with regard to the resulting secu- is suitable for continuous auditing as well, since
rity requirements. the status of the separation can be continuously
audited here.
Identified vulnerabilities and deviations are sub-
ject to risk assessment in accordance with the risk
83
COS-04 Cross-network access COS-05 Networks for administration
Basic Criterion Basic Criterion
Each network perimeter is controlled by security There are separate networks for the administra-
gateways. The system access authorisation for tive management of the infrastructure and for
cross-network access is based on a security assess- the operation of management consoles. These
ment based on the requirements of the cloud networks are logically or physically separated
customers. from the cloud customer’s network and protected
from unauthorised access by multi-factor authen-
tication (cf. IDM-09). Networks used by the Cloud
Additional Criterion Service Provider to migrate or create virtual
machines are also physically or logically separated
Each network perimeter is controlled by redun- from other networks.
dant and highly-available security gateways.
–
About the Criterion
Cross-network access is access from one network Supplementary Information

to another network via a defined network perim-
eter. About the Criterion
Complementary Customer Criterion –
Cloud customers ensure through suitable controls Complementary Customer Criterion

that access is controlled according to their protec-
tion needs by security gateways on the perimeters –
of the virtual networks within the cloud service
for which they are responsible. Notes on Continuous Auditing
Notes on Continuous Auditing Feasibility: no
Feasibility: yes A continuous audit is not practical since infra-

structure components and the logical and phys-
If the control of the network perimeters is doc- ical separation of the networks are implemented
umented (e.g. by logs), these logs can be evalu- initially and a continuous audit of these compo-
ated automatically. This offers the possibility of nents may require a system status, but it is diffi-
a continuous audit for this part of the criterion. cult to test all aspects continuously.
If the security evaluation for access authorisa-
tions is carried out in a standardised form at the
Cloud Service Provider, this can also be evaluated
automatically. In this case, a continuous audit COS-06 Segregation of data traffic in jointly
for the second part of the criterion would also be used network environments
possible.
Basic Criterion
Data traffic of cloud customers in jointly used

network environments is segregated on net-
84
work level according to a documented concept Notes on Continuous Auditing

to ensure the confidentiality and integrity of the
data transmitted. Feasibility: no
The logical segregation of cloud customer net-

Additional Criterion work traffic at the network level is centrally con-
figured and rarely changed. Thus, a continuous
In the case of IaaS/PaaS, the secure segregation audit is not beneficial, since no highly frequented
is ensured by physically separated networks or automated query can be performed to support the
by means of strongly encrypted VLANs. For the continuous audit.
definition of strong encryption, the BSI Technical
Guideline TR-02102 must be considered.
COS-07 Documentation of the network

Supplementary Information topology
If the suitability and effectiveness of the logical The documentation of the logical structure of the
segmentation cannot be assessed with sufficient network used to provision or operate the Cloud
certainty (e.g. due to a complex implementation), Service, is traceable and up-to-date, in order to
evidence can also be provided based on audit avoid administrative errors during live operation
results of expert third parties (e.g. security audits and to ensure timely recovery in the event of mal-
to validate the concept). The segregation of stored functions in accordance with contractual obliga-
and processed data is subject of the criterion tions. The documentation shows how the subnets
OPS-24. are allocated and how the network is zoned and
segmented. In addition, the geographical loca-
After successful authentication via an insecure tions in which the cloud customers’ data is stored
communication channel (HTTP), a secure com- are indicated.
munication channel (HTTPS) is to be used.
With IaaS/PaaS, secure segregation is ensured by Additional Criterion

physically separated networks or strong encryp-
tion of the networks. For the definition of strong –
encryption, the BSI Technical Guideline TR-02102
must be considered (cf. CRY-01).
If the Cloud Service Provider does not use shared
network environments for cloud customers and About the Criterion
instead uses a physical segregation, the basic crite-
rion is not applicable. Zoning is a segmentation of the subnets with a
firewall implemented at the network perimeters.
Through suitable controls, cloud customers
ensure for parts of the cloud service under their –
responsibility that virtual networks are designed,
configured and documented in accordance with Notes on Continuous Auditing
their network security requirements (e.g. logical
segmentation of organizational units). Feasibility: no
85
The documentation of the logical structure of the the only attributes that can be tested are the last
network is rarely changed and is stored centrally. change date and the status of review or approval,
Therefore, a continuous audit is not effective. as far as this information is stored in a system. The
However, a continuous audit could return the content of a policy can hardly be tested automat-
date of the last change to the documentation. ically.
COS-08 Policies for data transmission 5.10 Portability and Interoperability (PI)
Basic Criterion Objective: Enable the ability to access the

cloud service via other cloud services or IT
Policies and instructions with technical and systems of the cloud customers, to obtain
organisational safeguards in order to protect the stored data at the end of the contractual
the transmission of data against unauthorised relationship and to securely delete it from the
interception, manipulation, copying, modifica- Cloud Service Provider.
tion, redirection or destruction are documented,
communicated and provided according to SP-01.
The policies and instructions establish a reference
to the classification of information (cf. AM-06). PI-01 Documentation and safety of input
and output interfaces
– The cloud service can be accessed by other cloud

services or IT systems of cloud customers through
documented inbound and outbound interfaces.
Supplementary Information Further, the interfaces are clearly documented for
subject matter experts on how they can be used to
About the Criterion retrieve the data.
A safeguard against unauthorised interception, Communication takes place through standard-

manipulation, copying, modification, redirection ised communication protocols that ensure the
or destruction of data during transmission is confidentiality and integrity of the transmitted
e.g. the use of transport encryption according to information according to its protection require-
CRY-02. ments. Communication over untrusted networks
is encrypted according to CRY-02.
The type and scope of the documentation on the
Cloud customers ensure through suitable controls interfaces is geared to the needs of the cloud cus-
that the transmitted data transmitted to the cloud tomers’ subject matter experts in order to enable
service is protected against tampering, copying, the use of these interfaces. The information is
modifying, redirecting or deleting in accordance maintained in such a way that it is applicable for
with their protection needs. the cloud service’s version which is intended for
productive use.
Feasibility: no Additional Criterion
A policy can change ad-hoc. However, the contin- –

86
Supplementary Information • Definition of the point in time as of which

the Cloud Service Provider makes the data
About the Criterion inaccessible to the cloud customer and deletes
these; and
–
• The cloud customers’ responsibilities and
Complementary Customer Criterion obligations to cooperate for the provision of
the data.
that the interfaces provided (and their security) The definitions are based on the needs of subject
are adequate for its protection requirements by matter experts of potential customers who assess
means of appropriate checks before the start of the suitability of the cloud service with regard to a
use of the cloud service and each time the inter- dependency on the Cloud Service Provider as well
faces are changed. as legal and regulatory requirements.

The design of the aspects is based on legal and
The defined input and output interfaces of cloud regulatory requirements in the environment of
services are rarely changed. Therefore, it is suffi- the Cloud Service Provider. The Cloud Service
cient for the auditor to test these interfaces, the Provider identifies the requirements regularly, at
communication of potential changes, and the least once a year, and checks these for actuality
associated documentation as part of the recurring and adjusts the contractual agreements accord-
audit. ingly.
In a continuous audit, however, the system status

of the interfaces could be queried and evaluated, Supplementary Information
continuously.
About the Criterion
The type and scope of the data and the respon-

PI-02 Contractual agreements for the provision sibilities for its provision depend on the service
of data model of the cloud service or the services and
functions provided:
Basic Criterion
In the case of IaaS and PaaS, the cloud customer is
In contractual agreements, the following aspects generally responsible for extracting and backing
are defined with regard to the termination of up the data which is stored in the cloud service
the contractual relationship, insofar as these are before termination of the contractual relationship
applicable to the cloud service: (cf. complementary requirement).
• Type, scope and format of the data the Cloud The Cloud Service Provider’s responsibility is
Service Provider provides to the cloud cus- typically limited to the provision of data for the
tomer; configuration of the infrastructure or platform
that the cloud customer has set up within its envi-
• Definition of the timeframe, within which the ronment (e.g. configuration of networks, images
Cloud Service Provider makes the data availa- of virtual machines and containers).
ble to the cloud customer;
With SaaS, the cloud customer typically relies on
export functions provided by the Cloud Service
87
Provider. Data created by the cloud customer The deletion includes data in the cloud custom-
should be available in the same format as stored er’s environment, metadata and data stored in the
in the cloud service. Other data, including rele- data backups.
vant log files and metadata, should be available in
an applicable standard format, such as CSV, JSON The deletion procedures prevent recovery by
or XML. forensic means.
In Germany, legal requirements for retention can

be found, for example, in the German Tax Code Additional Criterion
(§ 147 AO) and the German Commercial Code
(§ 257 HGB). These provide for a retention obliga- –
tion of six or ten years.
Complementary Customer Criterion Supplementary Information
Cloud customers ensure through suitable controls About the Criterion

that the data to which they are contractually enti-
tled is requested from the Cloud Service Provider Suitable methods for data deletion are e.g. multi-
at the end of the contract or accessed via defined ple overwriting or deletion of the encryption key.
interfaces (the type and scope of the data corre-
spond to the contractual agreements that were Complementary Customer Criterion
concluded prior to the use of the cloud service)
and that it is stored in accordance with the legal Cloud customers ensure through suitable controls
requirements applicable to this data. that the legal and regulatory framework (e.g. legal
requirements for storage and deletion) is identi-
Notes on Continuous Auditing fied and that the deletion of their data is initiated
accordingly.
Feasibility: no
The Cloud Service Provider should have a stand-
ardised template for its contracts. Hence, all Feasibility: yes
contracts are structured according to the same
pattern. The complete deletion of the data is documented
by the Cloud Service Provider using logs. The
This template is rarely changed. Therefore, a logs should include which data has been deleted
continuous audit is not practical. Therefore, it is so that it can be tracked whether data has been
sufficient to test the contracts and the associated deleted in the cloud customer’s environment,
template as part of the recurring audit. metadata and data in the backup.
The auditor can then perform an automated eval-

uation of these logs. The auditor can also check
PI-03 Secure deletion of data the system status of the procedure for deleting the
data.
Basic Criterion
The fact that the deletion procedures prevent
The Cloud Service Provider’s procedures for delet- recovery by forensic means does not have to be
ing the cloud customers’ data upon termination audited continuously. The deletion procedures
of the contractual relationship ensure compliance used can be tested as part of the recurring audit.
with the contractual agreements (cf. PI-02).
88
5.11 Procurement, Development and Supplementary Information

Modification of Information
Systems (DEV) About the Criterion
Objective: Ensure information security in the The software provision can be carried out e.g.
development cycle of information systems. with Continuous Delivery methods.
Accepted standards and methods are, for example:
DEV-01 Policies for the development/ • ISO/IEC 27034; and

procurement of information systems
• OWASP Secure Software Development Lifecy-
Basic Criterion cle (S-SDLC).
Policies and instructions with technical and Complementary Customer Criterion

organisational measures for the secure devel-
opment of the cloud service are documented, –
communicated and provided in accordance with
SP-01. Notes on Continuous Auditing
The policies and instructions contain guidelines Feasibility: no

for the entire life cycle of the cloud service and
are based on recognised standards and methods The contents of the policies and instructions
with regard to the following aspects: for the proper development or procurement of
information systems do not change at a high fre-
• Security in Software Development (Require- quency. A continuous audit of this documentation
ments, Design, Implementation, Testing and is not practical. Therefore, the integration of these
Verification); tests into the recurring audit is sufficient.
• Security in software deployment (including

continuous delivery); and
DEV-02 Outsourcing of the development
• Security in operation (reaction to identified
faults and vulnerabilities). Basic Criterion
In the case of outsourced development of the

Additional Criterion cloud service (or individual system components),
specifications regarding the following aspects are
In procurement, products are preferred which contractually agreed between the Cloud Service
have been certified according to the “Common Provider and the outsourced development con-
Criteria for Information Technology Security tractor:
Evaluation” (short: Common Criteria – CC)
according Evaluation Assurance Level EAL 4. If • Security in software development (require-
non-certified products are to be procured for ments, design, implementation, tests and
available certified products, a risk assessment is verifications) in accordance with recognised
carried out in accordance with OIS-07. standards and methods;
• Acceptance testing of the quality of the ser-

vices provided in accordance with the agreed
functional and non-functional requirements;
and
89
• Providing evidence that sufficient verifica- ment of system components of the cloud service
tions have been carried out to rule out the within the scope of software deployment are doc-
existence of known vulnerabilities. umented, communicated and provided according
to SP-01 with regard to the following aspects:
Additional Criterion • 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
Supplementary Information change and releases for deployment in the
production environment by authorised per-
About the Criterion sonnel or system components;
Outsourced development in the sense of the basic • Requirements for the performance and docu-
criterion refers to the development of system mentation of tests;
components used specifically for the cloud service
by a contractor of the Cloud Service Provider. The • Requirements for segregation of duties during
development takes place according to the pro- development, testing and release of changes;
cesses of the contractor.
• Requirements for the proper information of
The purchase of software available on the market cloud customers about the type and scope of
as well as the integration of external employees the change as well as the resulting obligations
into the processes of the Cloud Service Provider to cooperate in accordance with the contrac-
do not constitute outsourcing in the sense of this tual agreements;
basic criterion.
• Requirements for the documentation of
Complementary Customer Criterion changes in system, operational and user docu-
mentation; and
–
• Requirements for the implementation and
Notes on Continuous Auditing documentation of emergency changes that
must comply with the same level of security
Feasibility: no as normal changes.
An outsourced development of a Cloud Service

Provider’s cloud services and the associated con- Additional Criterion
tract creation and signing will not be performed
with high frequency. Changes in contract struc- –
tures are also rare. Therefore, a continuous audit
in these cases is not effective.
About the Criterion

DEV-03 Policies for changes to information
systems Changes in the sense of the basic criterion are
those that can lead to changes in the configu-
Basic Criterion ration, functionality or security of system com-
ponents of the cloud service in the production
Policies and instructions with technical and environment. This includes changes to the infra-
organisational safeguards for change manage- structure as well as to the source code.
90
If individual changes are combined in a new external employees on standards and methods
release, update, patch or comparable software of secure software development and provision
object for the purpose of software provisioning, as well as on how to use the tools used for this
this software object is deemed to be a change purpose. The program is regularly reviewed and
within the meaning of the basic criterion, but not updated with regard to the applicable policies and
the individual changes contained therein. instructions, the assigned roles and responsibili-
ties and the tools used.
Changes to the existing network configuration
must also undergo a specified procedure, as they
are necessary for effective segregation of cloud Additional Criterion
customers.
–
Personnel and system components receive
authorisation to approve changes in accordance
with the requirements for access and access Supplementary Information
authorisations (cf. IDM-01) via a specified proce-
dure (cf. IDM-02). Relevant information includes About the Criterion
descriptions of e.g. new functions.
–
The cloud customer’s obligations to cooperate can
define that, e.g. the cloud customer must carry out Complementary Customer Criterion
certain tests.
–
–
Feasibility: yes
The Cloud Service Provider can automatically
Feasibility: no check the valid policies and instructions, the
assigned roles and responsibilities and the tools
The contents of the policies and instructions for used and document the results in logs.
managing and modifying system components are
not changed at a high frequency. A continuous These logs can be automatically evaluated by
audit of this documentation is therefore not effec- the auditor and thus a continuous audit can be
tive. It is sufficient to integrate these tests into the carried out.
recurring audit.
DEV-05 Risk assessment, categorisation

DEV-04 Safety training and awareness and prioritisation of changes
programme regarding continuous software
delivery and associated systems, components Basic Criterion
or tools.
In accordance with the applicable policies (cf.
Basic Criterion DEV-03), changes are subjected to a risk assess-
ment with regard to potential effects on the sys-
The Cloud Service Provider provides a train- tem components concerned and are categorised
ing program for regular, target group-oriented and prioritised accordingly.
security training and awareness for internal and
91
Additional Criterion tomers are involved into the tests in accordance

with the contractual requirements.
In accordance with the contractual agreements,
meaningful information about the occasion, time, The severity of the errors and vulnerabilities
duration, type and scope of the change is submit- identified in the tests, which are relevant for the
ted to authorised bodies of the cloud customer so deployment decision, is determined according to
that they can carry out their own risk assessment defined criteria and actions for timely remedia-
before the change is made available in the pro- tion or mitigation are initiated.
duction environment. Regardless of the contrac-
tual agreements, this is done for changes that
have the highest risk category based on their risk Additional Criterion
assessment.
–
About the Criterion
About the Criterion
–
The errors and vulnerabilities identified in tests
Complementary Customer Criterion can be assessed, for example, according to the
Common Vulnerability Scoring System (CVSS).
–
Where changes are to be tested by the cloud
Feasibility: yes customers in accordance with the contractual
agreements prior to deployment in the produc-
The evaluation of changes in releases can be tion environment, the cloud customers ensure
standardised and automated by the Cloud Ser- through suitable controls that the tests are
vice Provider. If this evaluation is carried out in performed appropriately to identify errors. In
standardised and digital form (tickets/logs), an particular, this includes timely execution of the
automated evaluation can be carried out by the tests by qualified personnel in accordance with
auditor. the conditions specified by the Cloud Service
Provider.

DEV-06 Testing changes
Feasibility: yes
Basic Criterion
If the tests are carried out automatically, the exe-
Changes to the cloud service are subject to appro- cution and associated results can be documented
priate testing during software development and in logs. These logs can then be read continuously
deployment. by the auditor.
The type and scope of the tests correspond to Measures for the elimination of identified vul-
the risk assessment. The tests are carried out by nerabilities can also be documented and carried
appropriately qualified personnel of the Cloud out in a standardised manner, so that continuous
Service Provider or by automated test procedures auditing is possible.
that comply with the state-of-the-art. Cloud cus-
92
DEV-07 Logging of changes DEV-08 Version Control
Basic Criterion Basic Criterion
System components and tools for source code Version control procedures are set up to track
management and software deployment that are dependencies of individual changes and to restore
used to make changes to system components of affected system components back to their previ-
the cloud service in the production environment ous state as a result of errors or identified vulner-
are subject to a role and rights concept according abilities.
to IDM-01 and authorisation mechanisms. They
must be configured in such a way that all changes
are logged and can therefore be traced back to Additional Criterion
the individuals or system components executing
them. Version control procedures provide appropriate
safeguards to ensure that the integrity and availa-
bility of cloud customer data is not compromised
Additional Criterion when system components are restored back to
their previous state.
–
About the Criterion
About the Criterion
–
–
–
–
Feasibility: yes
Feasibility: yes
The procedures for version control of the Cloud
The changes to the role and rights concept Service Provider and, if necessary, resetting to
according to IDM-01 are documented in logs by previous states can be automated. This must be
the Cloud Service Provider. Thus, an automatic documented in logs. An automatic evaluation of
and continuous evaluation of these logs can be these logs makes continuous auditing possible.
carried out. Irregularities are detected and logged.
The auditor can perform a continuous audit by

automatically evaluating the logs and logged DEV-09 Approvals for provision in the
irregularities. production environment
Basic Criterion
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
93
are made available to the cloud customers in the DEV-10 Separation of environments
production environment.
Basic Criterion
Cloud customers are involved in the release
according to contractual requirements. Production environments are physically or
logically separated from test or development
environments to prevent unauthorised access to
Additional Criterion cloud customer data, the spread of malware, or
changes to system components. Data contained
– in the production environments is not used in
test or development environments in order not to
compromise their confidentiality.
About the Criterion Additional Criterion
The definitions for criterion DEV-03 apply. –

Where changes are to be approved by the cloud
customers in accordance with the contractual About the Criterion
agreements before they are made available in the
production environment, the cloud customers –
ensure through suitable controls that authorised
and qualified personnel receives the informa- Complementary Customer Criterion
tion 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. Notes on Continuous Auditing
Notes on Continuous Auditing Feasibility: yes
Feasibility: yes Since fundamental changes in test and devel-

opment environments, which would affect the
Verification that all tests have been completed, physical or logical separation, are rarely made, a
successful and approved by an authorised body continuous audit is not practical. The respective
can be automated by the Cloud Service Provider environments must be tested initially and then
and documented in logs. audited again if changes are made.
These logs can then be evaluated automatically

and continuously by the auditor.
94
5.12 Control and Monitoring of Service • Specifications for applying these requirements
Providers and Suppliers (SSO) also to service providers used by the third
parties, insofar as the services provided by
Objective: Ensure the protection of these service providers also contribute to the
information that service providers or suppliers provision of the cloud service.
of the Cloud Service Provider (subcontractors)
can access and monitor the agreed services and
security requirements. Additional Criterion
Subservice organisations of the Cloud Service

Provider are contractually obliged to provide reg-
SSO-01 Policies and instructions for controlling ular reports by independent auditors on the suita-
and monitoring third parties bility of the design and operating effectiveness of
their service-related internal control system.
Basic Criterion
The reports include the complementary subser-
Policies and instructions for controlling and vice organisations that are required, together with
monitoring third parties (e.g. service providers the controls of the Cloud Service Provider, to
or suppliers) whose services contribute to the meet the applicable basic criteria of BSI C5 with
provision of the cloud service are documented, reasonable assurance.
communicated and provided in accordance with
SP-01 with respect to the following aspects: In case no reports can be provided, the Cloud
Service Provider agrees appropriate information
• Requirements for the assessment of risks and audit rights to assess the suitability and effec-
resulting from the procurement of third-party tiveness of the service-related internal control
services; system, including the complementary controls, by
qualified personnel.
• Requirements for the classification of third
parties based on the risk assessment by the
Cloud Service Provider and the determination Supplementary Information
of whether the third party is a subcontractor
(cf. Supplementary Information); About the Criterion
• Information security requirements for the Reports by independent auditors on the suitabil-
processing, storage or transmission of infor- ity of the design and operating effectiveness of
mation by third parties based on recognised their service-related internal control system are,
industry standards; for example, attestation reports in accordance
with ISAE 3402, IDW PS 951, SOC 2 or BSI C5.
• Information security awareness and training
requirements for staff; Qualified personnel works, for example, in the
Cloud Service Provider’s internal audit depart-
• applicable legal and regulatory requirements; ment or is commissioned by the Cloud Service
Provider in form of expert third parties, such as
• Requirements for dealing with vulnerabilities, audit firms, and may hold relevant certifications
security incidents and malfunctions; such as “Certified Internal Auditor (CIA)”.
• Specifications for the contractual agreement The complementary controls at the sub-service
of these requirements; provider are necessary in order to, together with
the controls of the Cloud Service Provider, fulfil
• Specifications for the monitoring of these the applicable C5 criteria with reasonable assur-
requirements; and ance.
95
Applicable legal and regulatory requirements may reviewed regularly, at least annually, by qualified
exist, for example, in the areas of data protection, personnel of the Cloud Service Provider during
intellectual property rights or copyright. service usage.
If legal or regulatory requirements provide for The risk assessment includes the identification,
a regulation deviating from these criteria for analysis, evaluation, handling and documentation
the control of subcontractors, these regulations of risks with regard to the following aspects:
remain unaffected by the C5 criteria.
• Protection needs regarding the confidential-
Complementary Customer Criterion ity, integrity, availability and authenticity of
information processed, stored or transmitted
– by the third party;
Notes on Continuous Auditing • Impact of a protection breach on the provi-

sion of the cloud service;
• The Cloud Service Provider’s dependence on
Regarding the availability of the documentation, the service provider or supplier for the scope,
a continuous audit is not practical, since the complexity and uniqueness of the service
associated processes and steps can be tested in a purchased, including the consideration of
recurring audit. possible alternatives.
A continuous audit of whether changes have

been made to the policies is possible, provided Additional Criterion
that these changes are documented by the Cloud
Service Provider and can be evaluated. However, –
an automated audit of the meaningfulness of the
changes is difficult to implement.
Regarding the proof that a communication/provi-
sion has taken place, a continuous audit is consid- About the Criterion
ered possible.
–
For this, the Cloud Service Provider would have
to realise the notification based on a system (e.g. Complementary Customer Criterion
based on tickets or notes in the respective service
provider contract). –
SSO-02 Risk assessment of service providers Feasibility: no

and suppliers
Continuous auditing of the risk assessment is not
Basic Criterion effective, as only its regular execution could be
audited automatically, but not the content.
Service providers and suppliers of the Cloud
Service Provider undergo a risk assessment in In addition, the specified frequency of at least one
accordance with the policies and instructions year is covered by the recurring audit. Risk assess-
for the control and monitoring of third parties ments are rarely carried out dynamically and
prior to contributing to the delivery of the cloud therefore do not often change during the year.
service. The adequacy of the risk assessment is
96
SSO-03 Directory of service providers Notes on Continuous Auditing

and suppliers
Feasibility: no
Basic Criterion
An ad-hoc completeness checks on the specified
The Cloud Service Provider maintains a direc- criteria can safely take place automatically, as can
tory for controlling and monitoring the service a comparison of changed data with relevant com-
providers and suppliers who contribute services pany databases. This can be set up by the Cloud
to the delivery of the cloud service. The following Service Provider.
information is maintained in the directory:
The auditor can then examine deviations as part
• Company name; of the recurring audit.
• Address; However, due to the frequency and the complete-

ness analysis, a continuous audit is not efficient
• Locations of data processing and storage; due to the large effort required.
• Responsible contact person at the service

provider/supplier;
SSO-04 Monitoring of compliance with
• Responsible contact person at the cloud ser- requirements
vice provider;
Basic Criterion
• Description of the service;
The Cloud Service Provider monitors compli-
• Classification based on the risk assessment; ance with information security requirements and
applicable legal and regulatory requirements in
• Beginning of service usage; and accordance with policies and instructions con-
cerning controlling and monitoring of third-par-
• Proof of compliance with contractually agreed ties.
requirements.
Monitoring includes a regular review of the fol-
The information in the list is checked at least lowing evidence to the extent that such evidence
annually for completeness, accuracy and validity. is to be provided by third parties in accordance
with the contractual agreements:
Additional Criterion • reports on the quality of the service provided;
– • certificates of the management systems’ com-

pliance with international standards;
Supplementary Information • independent third-party reports on the

suitability and operating effectiveness of their
About the Criterion service-related internal control systems; and
It is not necessary to maintain a single central • Records of the third parties on the handling of
register in order to fulfil the basic criterion. vulnerabilities, security incidents and mal-
functions.
The frequency of the monitoring corresponds to
– the classification of the third party based on the
97
risk assessment conducted by the Cloud Service the findings into the risk assessment in order to
Provider (cf. SSO-02). The results of the monitor- derive and initiate mitigating actions:
ing are included in the review of the third party’s
risk assessment. • The scope and the validity respectively the
period covered by the evidence;
Identified violations and deviations are subjected
to analysis, evaluation and treatment in accord- • For attestation reports: Qualifications of the
ance with the risk management procedure (cf. opinion, included deviations/other observa-
OIS-07). tions including management’s response and
corresponding controls to be implemented
and executed by the Cloud Service Provider;
• Disclosed subcontractors incl. any changes
The procedures for monitoring compliance with among those (e.g. additional subcontractor);
the requirements are supplemented by automatic and
procedures relating to the following aspects:
• Stated security incidents.
• Configuration of system components;
• Performance and availability of system com-
ponents; Cloud customers ensure through suitable controls
that they stay informed about subservice organ-
• Response time to malfunctions and security isations of their Cloud Service Provider (e.g. on
incidents; and the basis of the information in the C5 attestation
report) and decide on the basis of their need for
• Recovery time (time until completion of error protection of their data processed and stored in
handling). the cloud service whether further action should
be taken to monitor and check these subservice
Identified violations and discrepancies are auto- organisations.
matically reported to the responsible personnel or
system components of the Cloud Service Provider Notes on Continuous Auditing
for prompt assessment and action.
Supplementary Information A continuous audit of some of the required evi-

dence, such as the reviews conducted and their
About the Criterion results, can be performed once the Cloud Service
Provider documents the associated steps using a
Evidence for the review of the suitability and tool.
operating effectiveness of the service-related
internal control system include reports in accord- However, a review on content-level, such as
ance with ISAE 3402, IDW PS 951, SOC 2 or BSI reviewing the response to risk assessments and
C5. violations of service provider requirements, is dif-
ficult as it requires a semantic understanding. As a
In the evidence provided by the third parties, the result, at least parts of the criterion are suitable for
Cloud Service Provider reviews, for example, the continuous audit.
following aspects and, if necessary, incorporates
98
SSO-05 Exit strategy for the receipt of benefits • The purchased service is absolutely required
for the provision of the cloud service – this
Basic Criterion situation is given when the Cloud Service
Provider:
The Cloud Service Provider has defined and docu-
mented exit strategies for the purchase of services – provides the cloud service from data centres
where the risk assessment of the service providers operated by third parties; and
and suppliers regarding the scope, complexity and
uniqueness of the purchased service resulted in a – provides a SaaS service and uses the IaaS or
very high dependency (cf. Supplementary Infor- PaaS of another Cloud Service Provider.
mation).
• The service cannot be obtained within one
Exit strategies are aligned with operational conti- month from an alternative service provider or
nuity plans and include the following aspects: supplier, as:
• Analysis of the potential costs, impacts, – It is unique on the market and no other
resources and timing of the transition of a supplier can deliver it;
purchased service to an alternative service
provider or supplier; – It is strongly individualised by the service
provider or supplier and/or the Cloud Ser-
• Definition and allocation of roles, responsibil- vice Provider;
ities and sufficient resources to perform the
activities for a transition; – It cannot be supplied by any other provider
in the required quality of service; and
• Definition of success criteria for the transi-
tion; and – It requires specific knowledge that is only/
mainly available to the current service
• Definition of indicators for monitoring the provider or supplier and not to the Cloud
performance of services, which should initiate Service Provider.
the withdrawal from the service if the results
are unacceptable. Complementary Customer Criterion
–
–
Feasibility: no
Supplementary Information The existence of individual exit strategies is not a

practical test item for continuous audit.
About the Criterion
A very high dependency can be assumed in the

following situations in particular:
99
5.13 Security Incident Management (SIM) Supplementary Information
Objective: Ensure a consistent and About the Criterion

comprehensive approach to the capture,
assessment, communication and escalation of –
security incidents.

SIM-01 Policy for security incident that they receive notifications from the Cloud Ser-
management vice Provider about security incidents that affect
them and that these notifications are forwarded in
Basic Criterion a timely manner to the responsible departments
for handling so that an appropriate response can
Policies and instructions with technical and be triggered.
organisational safeguards are documented,
communicated and provided in accordance Notes on Continuous Auditing
with SP-01 to ensure a fast, effective and proper
response to all known security incidents. Feasibility: partially
The Cloud Service Provider defines guidelines for A continuous audit of the documented policies
the classification, prioritisation and escalation of and instructions is not effective because they are
security incidents and creates interfaces to the not subject to high frequency changes. Thus, the
incident management and business continuity audit of the policies and instructions can be per-
management. formed in the recurring audit.
In addition, the Cloud Service Provider has set up Similarly, setting up a CERT is not suitable for
a “Computer Emergency Response Team” (CERT), continuous auditing as it is an organisational
which contributes to the coordinated resolution body and does not require continuous monitor-
of occurring security incidents. ing.
Customers affected by security incidents are The timely communication of security incidents
informed in a timely and appropriate manner. to affected customers can be covered by a contin-
uous audit approach. In addition, the Cloud Ser-
vice Provider can document not only the security
Additional Criterion incidents by means of logs, but also that they have
been communicated to the customer via e-mail,
There are instructions as to how the data of a for example. The fact that there was communi-
suspicious system can be collected in a conclu- cation to affected customers for every security
sive manner in the event of a security incident. incident can thus be evaluated automatically and
In addition, there are analysis plans for typical continuously by the auditor.
security incidents and an evaluation methodology
so that the collected information does not lose its However, this procedure can be combined with
evidential value in any subsequent legal assess- the audit approach of further requirements of
ment. Security Incident Management.
100
SIM-02 Processing of security incidents SIM-03 Documentation and reporting

of security incidents
Basic Criterion
Basic Criterion
Subject matter experts of the Cloud Service Pro-
vider, together with external security providers After a security incident has been processed, the
where appropriate, classify, prioritise and perform solution is documented in accordance with the
root-cause analyses for events that could consti- contractual agreements and the report is sent to
tute a security incident. the affected customers for final acknowledgement
or, if applicable, as confirmation.
The Cloud Service Provider simulates the identifi-
cation, analysis and defence of security incidents The customer can either actively approve solu-
and attacks at least once a year through appropri- tions or the solution is automatically approved
ate tests and exercises (e.g. Red Team training). after a certain period.
Information on security incidents or confirmed

Supplementary Information security breaches is made available to all affected
customers.
About the Criterion
The contract between the Cloud Service Provider
– and the cloud customer regulates which data is
made available to the cloud customer for his own
Complementary Customer Criterion analysis in the event of security incidents.
–
About the Criterion
Feasibility: yes
–
The Cloud Service Provider documents all secu-
rity incidents in digital form, which contains Complementary Customer Criterion
information about the classification, prioritisation
and root cause analysis of the incidents. The root Cloud customers ensure through suitable controls
cause analysis should be standardised to facilitate that they receive notifications from the Cloud
continuous auditing. Service Provider about security incident that
affect them and their resolution and that these
An automatic and continuous evaluation of these notifications are forwarded promptly to the entity
security incidents can then be carried out by the responsible for handling them so that an appro-
auditor by excluding the logs or tickets produced priate response can be made.
and testing whether the security incident has
been classified and prioritised and whether these Notes on Continuous Auditing
steps have been carried out based on a standard-
ised root cause analysis. The continuous audit Feasibility: yes
thus provides a constant statement as to whether
security incidents have been correctly recorded, In the logs or tickets that document the security
classified and subjected to a root cause analysis. incidents (cf. SIM-03), the Cloud Service Provider
also describes the solution pursued to elimi-
101
nate the incident. In addition, the Cloud Service Service Provider is required to process, are com-
Provider also documents the confirmation to the municated promptly to previously designated,
customer. responsible personnel.
The auditor can then automatically and contin- The identification of such security events is sup-
uously read out whether the documented secu- ported by suitable controls (cf. complementary
rity incidents have been resolved and whether a criterion for OPS-10).
solution has been documented. The same applies
to the communication of the resolution of the Notes on Continuous Auditing
incidents to affected customers. If this is not the
case, the unresolved security incident can be doc- Feasibility: partially
umented as the output value of the continuous
audit. The Cloud Service Provider should inform its
employees and external business partners about
their obligations in a standardised and digital
format. This obligation usually occurs when the
SIM-04 Duty of the users to report security employee joins the company or the business
incidents to a central body relationship.
Basic Criterion This enables the auditor to automatically and

continuously audit whether all employees and
The Cloud Service Provider informs employees external business partners are notified of their
and external business partners of their obliga- obligations by automatically testing whether the
tions. If necessary, they agree to or are contrac- clause, if any, is included in the contract when the
tually obliged to report all security events that contract is signed.
become known to them and are directly related
to the cloud service provided by the Cloud Service
Provider to a previously designated central office
of the Cloud Service Provider promptly. SIM-05 Evaluation and learning process
In addition, the Cloud Service Provider commu- Basic Criterion

nicates that “false reports” of events that do not
subsequently turn out to be incidents do not have Mechanisms are in place to measure and monitor
any negative consequences. the type and scope of security incidents and to
report them to support agencies. The information
obtained from the evaluation is used to identify
Additional Criterion recurrent or significant incidents and to identify
the need for further protection.
–
–
About the Criterion
– Supplementary Information
Complementary Customer Criterion About the Criterion
Cloud customers ensure through suitable controls Supporting bodies may be external service pro-
that identified security events, which the Cloud viders or government agencies such as the BSI.
102
Cloud customers ensure through suitable controls –

that they include into their ISMS the findings and
measures related to previous security incidents
reported by the Cloud Service Provider. The cloud Supplementary Information
customers evaluate whether and which support-
ing measures they might take on their side. About the Criterion
Notes on Continuous Auditing –
Feasibility: no Complementary Customer Criterion
The existing mechanisms for measuring the type –

and scope of security incidents are rarely changed.
As a result, continuous auditing is not effective. Notes on Continuous Auditing
In addition, in some cases it can be a manual task
carried out by employees to identify recurring Feasibility: no
incidents or incidents with significant conse-
quences and to develop associated protective The responsibilities for continuity and emergency
measures. management processes are initially named and
rarely changed afterwards. Therefore, a continu-
ous audit is not effective.
5.14 Business Continuity Management (BCM) A continuous audit can, however, return the date
of the last revision of the guidelines for continuity
Objective: Plan, implement, maintain and and emergency management.
test procedures and measures for business
continuity and emergency management.
BCM-02 Business impact analysis policies

and instructions
BCM-01 Top management responsibility
Basic Criterion
Basic Criterion
Policies and instructions to determine the impact
The top management (or a member of the top of any malfunction to the cloud service or enter-
management) of the Cloud Service Provider is prise are documented, communicated and made
named as the process owner of business con- available in accordance with SP-01. The following
tinuity and emergency management and is aspects are considered as minimum:
responsible for establishing the process within
the company as well as ensuring compliance with • Possible scenarios based on a risk analysis;
the guidelines. They must ensure that sufficient
resources are made available for an effective • Identification of critical products and services;
process.
• Identify dependencies, including processes
People in management and other relevant leader- (including resources required), applications,
ship positions demonstrate leadership and com- business partners and third parties;
mitment to this issue by encouraging employees
to actively contribute to the effectiveness of • Capture threats to critical products and ser-
continuity and emergency management. vices;
103
• Identification of effects resulting from as far as this information is stored in a system. The
planned and unplanned malfunctions and content of a policy can hardly be tested automat-
changes over time; ically.
• Determination of the maximum acceptable

duration of malfunctions;
BCM-03 Planning business continuity
• Identification of restoration priorities;
Basic Criterion
• Determination of time targets for the resump-
tion of critical products and services within Based on the business impact analysis, a single
the maximum acceptable time period (RTO); framework for operational continuity and busi-
ness plan planning will be implemented, doc-
• Determination of time targets for the max- umented and enforced to ensure that all plans
imum reasonable period during which data are consistent. Planning is based on established
can be lost and not recovered (RPO); and standards, which are documented in a “Statement
of Applicability”.
• Estimation of the resources needed for
resumption. Business continuity plans and contingency plans
take the following aspects into account:
Additional Criterion • Defined purpose and scope with considera-

tion of the relevant dependencies;
–
• Accessibility and comprehensibility of the
plans for persons who are to act accordingly;
• Ownership by at least one designated person
About the Criterion responsible for review, updating and approval;
Scenarios to be considered according to the basic • Defined communication channels, roles and
criterion are, for example, the loss of personnel, responsibilities including notification of the
buildings, infrastructure and service providers. customer;
Complementary Customer Criterion • Recovery procedures, manual interim solu-

tions and reference information (taking into
Cloud customers ensure through suitable controls account prioritisation in the recovery of cloud
that the scenarios for a failure of the cloud service infrastructure components and services and
or the Cloud Service Provider are sufficiently alignment with customers);
considered in the context of their business impact
analysis. • Methods for putting the plans into effect;
Notes on Continuous Auditing • Continuous process improvement; and
Feasibility: partially • Interfaces to Security Incident Management.

uous audit of policies is only partially feasible as Additional Criterion
change date and the status of review or approval, –
104
About the Criterion In addition to the tests, exercises are also carried
out which, among other things, have resulted
The consistency of plans according to the basic in scenarios from security incidents that have
criterion must also be maintained when different already occurred in the past.
locations are used.
Complementary Customer Criterion Supplementary Information
Cloud customers ensure through suitable controls About the Criterion

that the results of the Business Impact Analysis
are sufficiently considered when planning the Tests are primarily conducted at the operational
operational continuity and the business plan in level and are aimed at operational target groups.
order to provide for the effects of a failure of the Tests include e.g.:
cloud service or Cloud Service Provider.
• Test of technical precautionary measures;
trols that the availability of the cloud service, its • Functional tests; and
recovery time according to the BCM plan and the
data loss of the cloud service are consistent with • Plan review.
their own availability requirements and tolerable
data loss. Exercises also take place on a tactical and strategic
level. These include e.g.:
• Plan meeting;
Feasibility: no
• Staff exercise;
The introduction of the framework and the busi-
ness plan based on a business impact analysis is a • Command post exercise;
manual process of the Cloud Service Provider.
• Communication and alerting exercise;
A continuous audit is not practical. The plans can
be tested as part of the recurring audit. • Simulation of scenarios; and
• Emergency or full exercise.
BCM-04 Verification, updating and testing After a completed exercise:

of the business continuity
• Review and possible adaptation of the existing
Basic Criterion alarm plan.
The business impact analysis, business continu- Relevant third parties are in particular service
ity plans and contingency plans are reviewed, providers and suppliers of the Cloud Service Pro-
updated and tested on a regular basis (at least vider who contribute to the provision of the cloud
annually) or after significant organisational or service (cf. basic criteria SSO-02 and SSO-05).
environmental changes. Tests involve affected
customers (tenants) and relevant third parties. The Complementary Customer Criterion
tests are documented and results are taken into
account for future operational continuity meas- Cloud customers ensure through suitable controls
ures. that measures to prevent the impact of a cloud
105
service or Cloud Service Provider outage are 5.15 Compliance (COM)

regularly reviewed, updated, tested and exercised.
The Cloud Service Provider is involved in the tests Objective: Avoid non-compliance with legal,
and exercises in accordance with the contractual regulatory, self-imposed or contractual
agreements. information security and compliance
requirements.
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 COM-01 Identification of applicable
with regard to ensuring the customer’s opera- legal, regulatory, self-imposed or contractual
tional continuity. requirements
In tests and exercises that involve the customer Basic Criterion

and therefore require own measures on the
customer side, cloud customers ensure that the The legal, regulatory, self-imposed and contrac-
appropriate measures for coping with the sce- tual requirements relevant to the information
nario are practiced and tested by means of suita- security of the cloud service as well as the Cloud
ble BCM controls. Service Provider’s procedures for complying with
these requirements are explicitly defined and
Notes on Continuous Auditing documented.
Implementing the tests of the operational con-
tinuity plans in an annual cycle does not make a –
continuous audit of the entire criterion effective.
The effort for both Cloud Service Providers and
auditors to automate and continuously test this Supplementary Information
process would be higher than the results.
About the Criterion
However, it is possible to continuously audit
whether a test was carried out within the required The Cloud Service Provider’s documentation
time span. To do this, the Cloud Service Provider may refer to the following requirements, among
must document in a standardised manner that others:
and when a test was carried out.
• Requirements for the protection of personal
data (e.g. EU General Data Protection Regula-
tion);
• Compliance requirements based on contrac-

tual obligations with cloud customers (e.g.
ISO/IEC 27001, SOC 2, PCI-DSS);
• generally accepted accounting principles (e.g.

in accordance with HGB or IFRS);
106
• Requirements regarding access to data and Additional Criterion

auditability of digital documents (e.g. accord-
ing to GDPdU); and The Cloud Service Provider grants its cloud cus-
tomers contractually guaranteed information and
• Other laws (e.g. according to BSIG or AktG). audit rights.

–
About the Criterion
–
Feasibility: no
A continuous audit of contract specifications,
regulations and their documentation does not Cloud customers ensure through suitable controls
seem to be effective. In this case, the test within that appropriate responses are made to malfunc-
the recurring audit is sufficient. tions to the cloud service through such audits.
A continuous audit could assist in giving the date To the extent that contractually guaranteed infor-
of the last audit of the criteria. mation and audit rights exist, the cloud customers
ensure through suitable controls that these rights
are designed and executed in accordance with
their own requirements.
COM-02 Policy for planning and conducting
audits Notes on Continuous Auditing
Basic Criterion Feasibility: partially
Policies and instructions for planning and con- A policy can change ad-hoc. However, the contin-
ducting audits are documented, communicated uous audit of policies is only partially feasible as
and made available in accordance with SP-01 and the only attributes that can be tested are the last
address the following aspects: change date and the status of review or approval,
• Restriction to read-only access to system content of a policy can hardly be tested automat-
components in accordance with the agreed ically.
audit plan and as necessary to perform the
activities;
• Activities that may result in malfunctions to COM-03 Internal audits of the information
the cloud service or breaches of contractual security management system
requirements are performed during sched-
uled maintenance windows or outside peak Basic Criterion
periods; and
Subject matter experts check the compliance of
• Logging and monitoring of activities. the information security management system at
regular intervals, at least annually, with the rele-
vant and applicable legal, regulatory, self-imposed
or contractual requirements (cf. COM-01) as well
as compliance with the policies and instructions
107
(cf. SP-01) within their scope of responsibility (cf. Complementary Customer Criterion
OIS-01) through internal audits.
–
Identified vulnerabilities and deviations are sub-
ject to risk assessment in accordance with the risk Notes on Continuous Auditing
management procedure (cf. OIS-06) and follow-up
measures are defined and tracked (cf. OPS-18). Feasibility: yes
The regular performance of an internal audit

Additional Criterion of the ISMS can be set up as part of compliance
monitoring. For this purpose, the results of the
Internal audits are supplemented by procedures internal audit must be digitally documented, as
to automatically monitor applicable requirements well as the individual audit steps.
of policies and instructions with regard to the
following aspects: A continuous audit of this internal audit is not
effective but can only be considered after compli-
• Configuration of system components to ance monitoring has been set up.
provide the cloud service within the Cloud
Service Provider’s area of responsibility; The continuous audit can then supply the date of
the last audit as the output value.
• Performance and availability of these system
components;
• Response time to malfunctions and security COM-04 Information on information

incidents; security performance and management assessment
of the ISMS
• Recovery time (time to completion of error
handling); Basic Criterion
Identified vulnerabilities and deviations are The top management of the Cloud Service Pro-
automatically reported to the appropriate Cloud vider is regularly informed about the information
Service Provider’s subject matter experts for security performance within the scope of the
immediate assessment and action. ISMS in order to ensure its continued suitability,
adequacy and effectiveness. The information is
Cloud customers can view compliance with included in the management review of the ISMS
selected contractual requirements in real time. at is performed at least once a year.
About the Criterion –
Subject matter experts operate, e.g., in the Cloud

Service Provider’s internal revision department or Supplementary Information
expert third parties commissioned by the Cloud
Service Provider, such as auditing companies, and About the Criterion
may hold relevant certifications such as “Certified
Internal Auditor (CIA)”. The top management is a natural person or group
of people who make final decisions for the institu-
With regard to ISMS compliance, see Section 9.2 tion and are responsible for these.
of ISO/IEC 27001.
108
The aspects to be dealt with in the management Supplementary Information

review of the ISMS are listed in Section 9.3 of ISO/
IEC 27001. About the Criterion
Complementary Customer Criterion –
– Complementary Customer Criterion
Notes on Continuous Auditing Cloud customers ensure through suitable controls

that the type and scope of government investi-
Feasibility: partially gation requests and the associated disclosure of
their own data has been dealt with in their own
The actual transmission of information to the risk management and that the use of the cloud
Cloud Service Provider’s management can be service only takes place when this risk has been
logged and automated. However, the testing of deemed acceptable.
the contents of the communication and the that
these have also been included in the management Notes on Continuous Auditing
assessment must still be carried out within the
regular audit. Feasibility: no
Although a continuous audit of the performance

of the assessment and its documentation is
5.16 Dealing with investigation requests conceivable, a continuous audit is not practical.
from government agencies (INQ) Rather the criterion aims at the qualification
of the auditing personnel as well as the process
Objective: Ensure appropriate handling of behind it, which is both subject to manual audit.
government investigation requests for legal
review, information to cloud customers, and
limitation of access to or disclosure of data.
INQ-02 Informing Cloud Customers about
Investigation Requests
INQ-01 Legal Assessment of Investigative Basic Criterion

Inquiries
The Cloud Service Provider informs the affected
Basic Criterion Cloud Customer(s) without undue delay, unless
the applicable legal basis on which the govern-
Investigation requests from government agen- ment agency is based prohibits this or there are
cies are subjected to a legal assessment by subject clear indications of illegal actions in connection
matter experts of the Cloud Service Provider. The with the use of the Cloud Service.
assessment determines whether the government
agency has an applicable and legally valid legal
basis and what further steps need to be taken. Additional Criterion
–
109
About the Criterion –
This does not affect other legal or regulatory

requirements that requires earlier information for Supplementary Information
cloud customers.
About the Criterion
–
that such notifications are received and legally Complementary Customer Criterion
checked according to their own specifications and
possibilities. –
Notes on Continuous Auditing Notes on Continuous Auditing
Feasibility: partially Feasibility: yes
For internal process monitoring at the Cloud To the extent that a separate role is assigned to
Service Provider and facilitation of the audit, a the investigator in order to gain access to the data,
continuous audit of the period between receipt of the prerequisites specified in the request can be
the request and information of the customers is entered and checked by the system and linked to
conceivable. the assignment of the investigator role.
However, as this depends on local legal basis, the A continuous query can then be made to ensure
effort to establish this in the respective regions that the role was only granted if the prerequisites
will be quite high. defined by the system were fulfilled. Deviations
can be audited manually.
If a transaction processing system is implemented
at the Cloud Service Provider, at least the process
in this system can be continuously audited.
INQ-04 Limiting Access to or Disclosure of Data
in Investigation Requests
INQ-03 Conditions for Access to or Disclosure Basic Criterion

of Data in Investigation Requests
The Cloud Service Provider’s procedures estab-
Basic Criterion lishing access to or disclosing data of cloud
customers in the context of investigation requests
Access to or disclosure of cloud customer data from governmental agencies ensure that the
in connection with government investigation agencies only gain access to or insight into
requests is subject to the proviso that the Cloud the data that is the subject of the investigation
Service Provider’s legal assessment has shown request.
that an applicable and valid legal basis exists and
that the investigation request must be granted on If no clear limitation of the data is possible, the
that basis. Cloud Service Provider anonymises or pseu-
donymises the data so that government agencies
can only assign it to those cloud customers who
are subject of the investigation request.
110
Additional Criterion 5.17 Product Safety and Security (PSS)
– Objective: Provides up-to-date information

on the secure configuration and known
vulnerabilities of the cloud service for cloud
Supplementary Information customers, appropriate mechanisms for
troubleshooting and logging, as well as
About the Criterion authentication and authorisation of users of
cloud customers.
–

PSS-01 Guidelines and Recommendations
– for Cloud Customers
Notes on Continuous Auditing Basic Criterion
Feasibility: partially The Cloud Service Provider provides cloud cus-

tomers with guidelines and recommendations
A separate role for the investigator is to be pro- for the secure use of the cloud service provided.
vided (cf. also INQ-03). It is conceivable that The information contained therein is intended to
certain data types for this role may not be visible, assist the cloud customer in the secure configura-
pseudonymised or anonymised, or that data of tion, installation and use of the cloud service, to
customers that are not part of the investigation the extent applicable to the cloud service and the
may be excluded. responsibility of the cloud user.
However, this requires a manual effort in the con- The type and scope of the information provided
figuration and assignment of the investigator role. will be based on the needs of subject matter
experts of the cloud customers who set informa-
Under these conditions, however, a continuous tion security requirements, implement them or
audit of whether and to what extent the investiga- verify the implementation (e.g. IT, Compliance,
tor had access to data is conceivable. 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:
• Instructions for secure configuration;
• Information sources on known vulnerabilities

and update mechanisms;
• Error handling and logging mechanisms;
• Authentication mechanisms;
• Roles and rights concept including combina-

tions that result in an elevated risk; and
• Services and functions for administration of

the cloud service by privileged users.
111
The information is maintained so that it is appli- PSS-02 Identification of Vulnerabilities

cable to the cloud service provided in the version of the Cloud Service
intended for productive use.
Basic Criterion
Additional Criterion The Cloud Service Provider applies appropriate

measures to check the cloud service for vulnera-
– bilities which might have been integrated into the
cloud service during the software development
process.
The procedures for identifying such vulnerabili-
About the Criterion ties are part of the software development process
and, depending on a risk assessment, include the
– following activities:
Complementary Customer Criterion • Static Application Security Testing;
Cloud customers ensure through suitable controls • Dynamic Application Security Testing;
that the Cloud Service Provider’s information is
used to derive policies, concepts and measures • Code reviews by the Cloud Service Provider’s
for the secure configuration and use (according subject matter experts; and
to their own risk assessment) of the cloud service.
Compliance with these policies, concepts and • Obtaining information about confirmed
measures is checked. Changes to the information vulnerabilities in software libraries provided
are promptly assessed for their impact on these by third parties and used in their own cloud
documents and any necessary changes are imple- service.
mented.
The severity of identified vulnerabilities is
Notes on Continuous Auditing assessed according to defined criteria and meas-
ures are taken to immediately eliminate or miti-
Feasibility: partially gate them.
The provision of information from the Cloud

Service Provider to cloud customers can only Additional Criterion
be audited continuously to a limited extent. For
example, the Cloud Service Provider can make the The procedures for identifying such vulnerabil-
guidelines and recommendations available via its ities also include annual code reviews or secu-
internal customer portal, which makes a continu- rity penetration tests by qualified external third
ous audit only partially effective. parties.
Here, only an audit for completeness and the

last modification date is conceivable, although Supplementary Information
a discussion of the content of the changes is not
effective. For this, a semantic evaluation would be About the Criterion
necessary.
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
112
the subject of criteria OPS-23 (Management of possible follow-up measures on the part of cloud
vulnerabilities, malfunctions and errors – open users.
vulnerability assessment).
For each vulnerability, it is indicated whether
Complementary Customer Criterion software updates (e.g. patch, update) are available,
when they will be rolled out and whether they
– will be deployed by the Cloud Service Provider,
the cloud customer or both of them together.
Feasibility: yes Additional Criterion
The Cloud Service Provider automatically checks Assets provided by the Cloud Service Provider,
its cloud services for vulnerabilities. This check is which must be installed, provided or operated by
documented in a standardised digital form. cloud users within their area of responsibility, are
equipped with automatic update mechanisms.
By auditing this documentation, the auditor After approval by the respective cloud user,
verifies, whether the Cloud Service Provider software updates can be rolled out in such a way
has performed a vulnerability scan. In addition, that they can be distributed to all affected users
the severity of the identified vulnerabilities can without human interaction.
be integrated into this continuous audit if the
defined criteria and their application are stand-
ardised and machine-readable. Supplementary Information
The information on identified and/or repaired About the Criterion

vulnerabilities can also be transferred directly to
the affected customer and thus increased trans- Assets provided by the Cloud Service Provider
parency can be achieved. that cloud customers have to install, deploy or
operate themselves in their area of responsibility
are for example local software clients and apps as
well as tools for integrating the cloud service.
PSS-03 Online Register of Known
Vulnerabilities If the cloud service relies on other cloud services,
this registry has to incorporate or refer to the vul-
Basic Criterion nerabilities of those other cloud services in order
for this criterion to be met.
The Cloud Service Provider operates or refers to a
daily updated online register of known vulnera- Complementary Customer Criterion
bilities that affect the Cloud Service Provider and
assets provided by the Cloud Service Provider that Cloud customers ensure through suitable controls
the cloud customers have to install, provide or that the information in this register is incorpo-
operate themselves under the customers respon- rated sufficiently quickly into their own risk man-
sibility. agement, evaluated and, if necessary, taken into
account in their own area of responsibility.
The presentation of the vulnerabilities follows the
Common Vulnerability Scoring System (CVSS). Notes on Continuous Auditing
The online register is easily accessible to any cloud Feasibility: yes

customer. The information contained therein
forms a suitable basis for risk assessment and A continuous audit includes, above all, whether
the information is updated daily. The distribution
113
of software updates must be documented by the for further processing this information as part of
Cloud Service Provider (logs). This documentation their Security Information and Event Manage-
can then be automatically and continuously eval- ment (SIEM).
uated by the auditor to ensure that the software
used on assets in the cloud users’ area of responsi-
bility is up-to-date. Supplementary Information
About the Criterion
PSS-04 Error handling and Logging Mechanisms In the case of a SaaS service for secure data
exchange, the terms data, services or functions
Basic Criterion would mean, for example, the logging of all read
or write accesses to the stored files and their
The cloud service provided is equipped with error metadata.
handling and logging mechanisms. These enable
cloud users to obtain security-related information Complementary Customer Criterion
about the security status of the cloud service as
well as the data, services or functions it provides. If the cloud service is equipped with error han-
dling and logging mechanisms, cloud customers
The information is detailed enough to allow cloud must activate these and configure them according
users to check the following aspects, insofar as to defined requirements. The cloud customer
they are applicable to the cloud service: must incorporate his own information security
management for this purpose.
• Which data, services or functions available to
the cloud user within the cloud service, have Notes on Continuous Auditing
been accessed by whom and when (Audit
Logs); Feasibility: yes
• Malfunctions during processing of automatic The information about the security status of
or manual actions; and cloud services and further data provided can be
read automatically and continuously, as these
• Changes to security-relevant configuration must be made available to cloud users in digital
parameters, error handling and logging mech- form.
anisms, user authentication, action author-
isation, cryptography, and communication This enables continuous auditing.
security.
The logged information is protected from unau-

thorised access and modification and can be PSS-05 Authentication Mechanisms
deleted by the Cloud Customer.
Basic Criterion
If the cloud customer is responsible for the activa-
tion or type and scope of logging, the Cloud Ser- The Cloud Service Provider provides authentica-
vice Provider must provide appropriate logging tion mechanisms that can force strong authen-
capabilities. tication (e.g. two or more factors) for users, IT
components or applications within the cloud
users’ area of responsibility.
These authentication mechanisms are set up at all
Cloud users can retrieve security-related informa- access points that allow users, IT components or
tion via documented interfaces which are suitable applications to interact with the cloud service.
114
For privileged users, IT components or appli- only deviations from target configurations can be
cations, these authentication mechanisms are checked. Whether these deviations are desired or
enforced. not must still be recorded in a manual audit.
PSS-06 Session Management
The cloud service offers out-of-band authentica-
tion (OOB), in which the factors are transmitted Basic Criterion
via different channels (e.g. Internet and mobile
network). To protect confidentiality, availability, integrity
and authenticity during interactions with the
cloud service, a suitable session management sys-
Supplementary Information tem is used that at least corresponds to the state-
of-the-art and is protected against known attacks.
About the Criterion Mechanisms are implemented that invalidate a
session after it has been detected as inactive. The
IT components in the sense of this criterion inactivity can be detected by time measurement.
are independently usable objects with external In this case, the time interval can be configured
interfaces that can be connected with other IT by the Cloud Service Provider or – if technically
components. possible – by the cloud customer.
Access points in the sense of this criterion are

those that can be accessed by users, IT compo- Additional Criterion
nents or applications via networks (for users, for
example, the login screen on the publicly accessi- –
ble website of the Cloud Service Provider).
Multi-factor authentication can be performed Supplementary Information

with cryptographic certificates, smart cards or
tokens, for example. About the Criterion
Complementary Customer Criterion Known attacks include manipulation, forgery,

session takeover, Denial of Service attacks, envel-
Cloud customers ensure through suitable controls oping, replay and null cipher attacks.
that the authentication mechanisms offered by
the cloud service are used in accordance with the Complementary Customer Criterion
customer’s identity and authorisation manage-
ment requirements. Cloud customers can use appropriate controls to
ensure that they are using the session manage-
Notes on Continuous Auditing ment protection features of the cloud service in
accordance with their own ISMS. They also set the
Feasibility: partially time period after which a session becomes invalid
according to their own ISMS specifications.
The implementation of authentication mecha-
nisms for users takes place via configurations that Notes on Continuous Auditing
are only adapted at a low frequency. Thus, contin-
uous auditing is only partially effective here. Feasibility: partially
Nevertheless, it is conceivable to monitor the sta- The use of Session Management is controlled by
tus of the underlying authentication system, but configurations. These configurations are changed
115
or adapted at a low frequency, so continuous current version of the BSI Technical Guideline
auditing is only partially effective. TR-02102-1 “Cryptographic mechanisms: Recom-
mendations and key lengths”. In version 2019-01
Nevertheless, monitoring the status of the under- of this guideline these were:
lying authentication system is conceivable, but
only deviations from target configurations can • SHA-256, SHA-512/256, SHA-384, SHA-512;
be checked. Whether these deviations are normal and
must still be tested in a manual audit.
• SHA3-256, SHA3-384, SHA3-512.

PSS-07 Confidentiality of Authentication
Information Cloud customers ensure through suitable controls
that they use sufficiently secure passwords (cf.
Basic Criterion IDM-09) according to their own assessment and
that the risks of unauthorised access associated
If passwords are used as authentication informa- with their own choice are borne.
tion for the cloud service, their confidentiality is
ensured by the following procedures: Notes on Continuous Auditing
• Users can initially create the password them- Feasibility: no

selves or must change an initial password
when logging in to the cloud service for the Compliance with security policies for password
first time. An initial password loses its validity assignment is configured centrally and adjusted at
after a maximum of 14 days. a low frequency. A continuous audit is therefore
only of limited use.
• When creating passwords, compliance with
the length and complexity requirements of
the Cloud Service Provider (cf. IDM-09) or the
cloud customer is technically enforced. PSS-08 Roles and Rights Concept
• The user is informed about changing or reset- Basic Criterion

ting the password.
The Cloud Service Provider provides cloud users
• The server-side storage takes place using with a roles and rights concept for managing
state-of-the-art cryptographically strong hash access rights. It describes rights profiles for the
functions in combination with at least 32-bit functions provided by the cloud service.
long salt values.
The rights profiles are suitable for enabling
cloud users to manage access authorisations and
Additional Criterion 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
Supplementary Information functions (“separation of duties”).
About the Criterion

The state-of-the-art regarding cryptographi-
cally strong hash functions is described in the –
116
Supplementary Information PSS-09 Authorisation Mechanisms
In IaaS, a role and rights concept would describe, Access to the functions provided by the cloud ser-
among other things, the rights profiles for the vice is restricted by access controls (authorisation
following functions of the cloud service: mechanisms) that verify whether users, IT compo-
nents, or applications are authorised to perform
• Administration of the states of virtual certain actions.
machines (start, pause, stop) as well as for their
migration or monitoring; The Cloud Service Provider validates the func-
tionality of the authorisation mechanisms before
• Management of available images that can be new functions are made available to cloud users
used to create virtual machines; and and in the event of changes to the authorisation
mechanisms of existing functions (cf. DEV-06).
• Management of virtual networks (e.g. configu- The severity of identified vulnerabilities is
ration of virtual routers and switches). assessed according to defined criteria based on
industry standard metrics (e.g. Common Vulner-
Complementary Customer Criterion ability Scoring System) and measures for timely
resolution or mitigation are initiated. Vulner-
Cloud customers ensure through suitable controls abilities that have not been fixed are listed in
that: the online register of known vulnerabilities (cf.
PSS-02).
• the granting of permissions to users in their
area of responsibility is subject to authorisa-
tion; and Additional Criterion
• the appropriateness of the assigned author- Access controls are attribute-based to enable
isations is regularly reviewed and authorisa- granular and contextual checks against multiple
tions are adjusted or withdrawn in a timely attributes of a user, IT component, or application
manner in the event of necessary changes (e.g. (e.g., role, location, authentication method).
employee resignation).
The existence of a roles and rights concept in –

the form of a configuration in the system can
be monitored. However, it should be noted that, Complementary Customer Criterion
regarding the content of this concept, only devi-
ations from target configurations can be checked. –
Whether these deviations are desired or not must
still be recorded in a manual audit. Notes on Continuous Auditing
Feasibility: yes
The changes to authorisation mechanisms and

the identification of vulnerabilities are docu-
mented in a standardised manner by the Cloud
Service Provider. This documentation can be
117
automated and continuously audited. If the be documented in a standardised manner by the

elimination of the vulnerabilities and their prior- Cloud Service Provider.
itisation also takes place in a standardised form
(according to standardised criteria), these points This documentation can be audited continuously
can be integrated into the continuous audit. and automatically by the auditor.
The “marking” of the data is carried out by a con-

figuration that has to be tested centrally. A contin-
PSS-10 Software Defined Networking uous audit of all transmitted data packets would
not be effective here.
Basic Criterion
The status of the configuration can be contin-
If the Cloud Service offers functions for soft- uously audited against a target value, a content
ware-defined networking (SDN), the confidenti- evaluation must be carried out manually.
ality of the data of the cloud user is ensured by
suitable SDN procedures.
The Cloud Service Provider validates the func- PSS-11 Images for Virtual Machines
tionality of the SDN functions before providing and Containers
new SDN features to cloud users or modifying
existing SDN features. Identified defects are Basic Criterion
assessed and corrected in a risk-oriented manner.
If cloud customers operate virtual machines or
containers with the cloud service, the Cloud Ser-
Additional Criterion vice Provider must ensure the following aspects:
– • The cloud customer can restrict the selection

of images of virtual machines or containers
according to his specifications, so that users
Supplementary Information of this cloud customer can only launch the
images or containers released according to
About the Criterion these restrictions.
This criterion is typically not applicable to the • If the Cloud Service Provider provides images
SaaS service model. of virtual machines or containers to the Cloud
Customer, the Cloud Service Provider appro-
Suitable SDN methods for increasing confiden- priately inform the Cloud Customer of the
tiality are, for example, L2 overlay networking changes made to the previous version.
(tagging) or tunnelling/encapsulation.
• In addition, these images provided by the
Complementary Customer Criterion Cloud Service Provider are hardened accord-
ing to generally accepted industry standards.
–
Notes on Continuous Auditing Additional Criterion
Feasibility: yes At startup and runtime of virtual machine or

container images, an integrity check is performed
Validation during provision and modification of that detects image manipulations and reports
SDN functions and identification of defects can them to the cloud customer.
118
Supplementary Information This must be ensured by the cloud architecture.
About the Criterion

This criterion is typically not applicable to the
SaaS service model. –
Generally accepted industry standards are, for

example, the Security Configuration Benchmark Supplementary Information
of the Centre for Internet Security (CIS) or the
corresponding modules in the BSI IT-Grund- About the Criterion
schutz-Kompendium.
This criterion supplements the General Condition
Complementary Customer Criterion BC-01.
Cloud customers use appropriate controls to The cloud architecture must exist in such a way
ensure that the images of virtual machines or that it enables the technical design of the IT infra-
containers they operate with the cloud service structure to provide the cloud service in accord-
comply with their information security manage- ance with the data location specifications agreed
ment requirements and that the results of the with the customer.
integrity checks at startup and at runtime are
processed according to these requirements. Complementary Customer Criterion
Notes on Continuous Auditing Cloud customers ensure through suitable controls

that, when selecting service providers and config-
Feasibility: partially uring the cloud service, they are informed about
the available data processing and storage loca-
These functions must be centrally audited at tions and, if there is a choice between different
regular intervals, but not continuously. Therefore, locations, that they select those that meet their
it is sufficient to integrate this into the recurring own requirements.
audit.
Depending on the use case and especially when
With an agent system, it would be possible to using services of a Cloud Service Provider which
continuously query the configurations of the indi- is based in another country, cloud customers take
vidual virtual machines and thus compare them the laws applicable to them into account when
with the target image. This could also be set up on making their selection (e.g. when processing
demand and thus become part of the control that personal data; compliance with legal retention
takes over the integrity check. obligations for business documents, etc.).
PSS-12 Locations of Data Processing Feasibility: yes

and Storage
A continuous survey of the location of the data
Basic Criterion and the country from which the service is pro-
vided can be carried out automatically by the
The cloud customer is able to specify the locations Cloud Service Provider. This information can then
(location/country) of the data processing and be made available to the customer, for example on
storage including data backups according to the his dashboard or on request.
contractually available options.
119
CLOUD COMPUTING COMPLIANCE CRITERIA CATALOGUE (C5) | Errata
Errata
The following corrections have been applied to the C5:2020 after its first publication on January 21th, 2020:
• Adjustments to the chapter numbers: The Preface of the President is now unnumbered, all other chapter
numbers have been decremented by one.
• Errata: This chapter has been added.
• 3.4.4.1 Description, First enumeration, last element:
“… as well as the resulting dependency of the Cloud Service Provider, and the availability of audit reports
according to the criteria in this criteria catalogue” changed to
“… as well as the resulting dependency of the Cloud Service Provider, (if carve-out method is applied) com-
plementary controls assumed in the design of the Cloud Service Provider’s controls, and the availability of
audit reports according to the criteria in this criteria catalogue”
• HR-05, Basic Criterion:
“which responsibilities, arising from the guidelines and instructions relating to information security, …”
changed to
“which responsibilities, arising from employment terms and conditions relating to information security, …”
• HR-06, Additional Criterion: Removed, since already covered in Basic Criterion
• PS-03, Basic Criterion:
“The security measures are designed to detect and prevent unauthorised access in a timely manner so that
it does not compromise the information security of the cloud service. The outer doors, windows and other
construction elements reach a level appropriate to the security requirements and withstand …” changed to
“The security measures are designed to detect and prevent unauthorised access so that the information
security of the cloud service is not compromised. The outer doors, windows and other construction ele-
ments exhibit an appropriate security level and withstand …”
• OPS-04, Basic Criterion:
“Policies and instructions that provide protection …” changed to
“Policies and instructions with specifications for protection …”
• OPS-06, Title: “Data Protection” changed to “Data Backup”
• IDM-08, Basic Criterion: Change reference from IDM-12 to IDM-09
• CRY-01, Basic Criterion: Add reference to AM-06
• COS-06, Supplementary Information: Removed information about session IDs, since these are addressed in
PSS-06.
• SSO-05, Basic Criterion: Supplementary Information: Correct indentation levels of bullet points
• COM-03, Basis Criterion: Remove reference to ISO/IEC 27001 as it is present in Supplementary Information
• COM-03, Supplementary Information:
”see Section 9.3 of ISO/IEC 27001” changed to
“see Section 9.2 of ISO/IEC 27001.”
• INQ-04, Basis Criterion:
“… procedures for setting up access to or disclosure of cloud customer data as part of an investigation
requests, ensure that government agencies only have access to the data they need to investigate.” changed to
“… procedures establishing access to or disclosing data of cloud customers in the context of investigation
requests from governmental agencies ensure that the agencies only gain access to or insight into the data
that is the subject of the investigation request.”
120
Legal notice
Published by:
Bundesamt für Sicherheit in der Informationstechnik (BSI)
53175 Bonn
Source:
Federal Office for Information Security (BSI)
Godesberger Allee 185–189
53175 Bonn
Phone: +49 (0) 228 999582-0
Fax: +49 (0) 228 999582-5400
Email: [email protected]
Internet: https://www.bsi.bund.de/EN/C5/
Last updated:
October 2020
Printed by:
Appel & Klinger Druck und Medien GmbH
Bahnhofstraße 3 a
96277 Schneckenlohe
Internet: www.ak-druck-medien.de
Content and editing:

Federal Office for Information Security (BSI)
Image credits:
Fotolia © sdecore
Item number:
BSI-Cloud 20/202
This brochure is part of the Federal Office for Information Security’s public relations work.
It is provided free of charge and is not intended for sale.
www.bsi.bund.de

Cloud Computing Compliance Criteria Catalogue - C5:2020

Uploaded by

Copyright:

Available Formats

Cloud Computing Compliance Criteria Catalogue - C5:2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cloud Computing Compliance Criteria Catalogue - C5:2020

Uploaded by

Copyright:

Available Formats

Cloud Computing

Preface by the President

Preface by the President 1

1.1 Preliminary remarks 10

2 Structure and Content of the Criteria 13

2.2 Content of the C5 Criteria 15

2.3 Underlying Standards and Publications 16

3 Providing Conformity through Independent Audits 18

3.2 Audit Standards to be Applied 19

3.3 Connection to Other Audits 20

3.4 Supplementary Requirements of the BSI 20

3.4.1 Audit Engagement 20

3.4.2 Criteria to be Applied 21

3.4.3 Subject Matter and Objective of the Audit 21

3.4.4 Requirements for the Description

3.4.5 Consideration of Subservice Organisations 24

3.4.6 Assessing the Fulfilment of Criteria

3.4.7 Deviation Handling 25

3.4.9 Qualification of the Auditor 26

3.4.10 Information on Limitation of Liability 27

3.5 Dealing with Criteria Catalogue Updates 27

4 Information on the General Conditions of the Cloud Service 29

 BC-01 Information on jurisdiction and locations 30

 BC-02 Information on availability and

 BC-03 Information on recovery parameters

 BC-04 Information on the availability of the data centre 31

 BC-05 Information on how investigation enquiries

 BC-06 Information on certifications or attestations 33

5 Basic Criteria, Additional Criteria and Supplementary Information 34

5.1 Organisation of Information Security (OIS) 35

 OIS-01 Information Security Management System

 OIS-02 Information Security Policy 35

 OIS-03 Interfaces and Dependencies 36

 OIS-04 Segregation of Duties 37

 OIS-05 Contact with Relevant Government Agencies

 OIS-06 Risk Management Policy 38

 OIS-07 Application of the Risk Management Policy 39

5.2 Security Policies and Instructions (SP) 39

 SP-01 Documentation, communication and

 SP-02 Review and Approval of Policies and Instructions 41

 SP-03 Exceptions from Existing Policies and Instructions 41

5.3 Personnel (HR) 42

 HR-01 Verification of qualification and trustworthiness 42

 HR-02 Employment terms and conditions 43

 HR-03 Security training and awareness programme 44

 HR-04 Disciplinary measures 44

 HR-05 Responsibilities in the event of termination

 HR-06 Confidentiality agreements 46

5.4 Asset Management (AM) 46

 AM-01 Asset Inventory 46

 AM-02 Acceptable Use and Safe Handling of Assets Policy 48

 AM-03 Commissioning of Hardware 48

 AM-04 Decommissioning of Hardware 49

 AM-05 Commitment to Permissible Use, Safe Handling

 AM-06 Asset Classification and Labelling 50

5.5 Physical Security (PS) 51

 PS-01 Physical Security and Environmental Control

 PS-02 Redundancy model 53

 PS-03 Perimeter Protection 54

Preface by the President 1

1.1 Preliminary remarks 10

2 Structure and Content of the Criteria 13

2.2 Content of the C5 Criteria 15

2.3 Underlying Standards and Publications 16

3 Providing Conformity through Independent Audits 18

3.2 Audit Standards to be Applied 19

3.3 Connection to Other Audits 20

3.4 Supplementary Requirements of the BSI 20

3.4.1 Audit Engagement 20

3.4.2 Criteria to be Applied 21

3.4.3 Subject Matter and Objective of the Audit 21

3.4.5 Consideration of Subservice Organisations 24

3.4.7 Deviation Handling 25

3.4.9 Qualification of the Auditor 26

3.4.10 Information on Limitation of Liability 27

3.5 Dealing with Criteria Catalogue Updates 27

4 Information on the General Conditions of the Cloud Service 29

BC-01 Information on jurisdiction and locations 30

BC-02 Information on availability and

BC-03 Information on recovery parameters

BC-04 Information on the availability of the data centre 31

BC-05 Information on how investigation enquiries

BC-06 Information on certifications or attestations 33

5 Basic Criteria, Additional Criteria and Supplementary Information 34

5.1 Organisation of Information Security (OIS) 35

OIS-01 Information Security Management System

OIS-02 Information Security Policy 35

OIS-03 Interfaces and Dependencies 36

OIS-04 Segregation of Duties 37

OIS-05 Contact with Relevant Government Agencies

OIS-06 Risk Management Policy 38

OIS-07 Application of the Risk Management Policy 39

5.2 Security Policies and Instructions (SP) 39

SP-01 Documentation, communication and

SP-02 Review and Approval of Policies and Instructions 41

SP-03 Exceptions from Existing Policies and Instructions 41

5.3 Personnel (HR) 42

HR-01 Verification of qualification and trustworthiness 42

HR-02 Employment terms and conditions 43

HR-03 Security training and awareness programme 44

HR-04 Disciplinary measures 44

HR-05 Responsibilities in the event of termination

HR-06 Confidentiality agreements 46

5.4 Asset Management (AM) 46

AM-01 Asset Inventory 46

AM-02 Acceptable Use and Safe Handling of Assets Policy 48

AM-03 Commissioning of Hardware 48

AM-04 Decommissioning of Hardware 49

AM-05 Commitment to Permissible Use, Safe Handling

AM-06 Asset Classification and Labelling 50

5.5 Physical Security (PS) 51

PS-01 Physical Security and Environmental Control

PS-02 Redundancy model 53

PS-03 Perimeter Protection 54

PS-04 Physical site access control 54

PS-05 Protection from fire and smoke 55

PS-06 Protection against interruptions caused

PS-07 Surveillance of operational and

5.6 Operations (OPS) 58

OPS-01 Capacity Management – Planning 58

OPS-02 Capacity Management – Monitoring 58

OPS-03 Capacity Management – Controlling

OPS-04 Protection Against Malware – Concept 60

OPS-05 Protection Against Malware – Implementation 60

OPS-06 Data Backup and Recovery – Concept 61

OPS-07 Data Backup and Recovery – Monitoring 62

OPS-08 Data Backup and Recovery – Regular Testing 62

OPS-09 Data Backup and Recovery – Storage 63

OPS-10 Logging and Monitoring – Concept 63

OPS-11 Logging and Monitoring – Metadata

OPS-12 Logging and Monitoring – Access, Storage

OPS-13 Logging and Monitoring – Identification

OPS-14 Logging and Monitoring – Storage

OPS-15 Logging and Monitoring – Accountability 66

OPS-16 Logging and Monitoring – Configuration 67

OPS-17 Logging and Monitoring – Availability

OPS-18 Managing Vulnerabilities, Malfunctions

OPS-19 Managing Vulnerabilities, Malfunctions

OPS-20 Managing Vulnerabilities, Malfunctions