Merge pull request #2 from corona-warn-app/master

Merge back
2020-06-14 21:43:21 +02:00 · 2020-06-14 21:43:21 +02:00 · 2021f04cb5
parent 720b294184 c627fbf485
commit 2021f04cb5
10 changed files with 694 additions and 191 deletions
--- a/README.md
+++ b/README.md
@ -57,17 +57,17 @@ The project scope has been agreed on jointly by Deutsche Telekom AG and SAP SE a
 The technical documents are intended for a technical audience and represent the most recent state of the architecture. The solution architecture and concepts might change over time as external dependencies (e.g. the framework provided by Apple/Google) are still changing and new requirements need to be included or existing ones change. We appreciate feedback to all elements of these technical documents. 

 * [Corona-Warn-App - Solution Architecture](solution_architecture.md)
-* [Corona-Warn-App Server Architecture](https://github.com/corona-warn-app/cwa-server/blob/master/docs/architecture-overview.md)
+* [Corona-Warn-App Server Architecture](https://github.com/corona-warn-app/cwa-server/blob/master/docs/ARCHITECTURE.md)
 * [Corona-Warn-App Verification Server Software Design](https://github.com/corona-warn-app/cwa-verification-server/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Verification Portal Server Software Design](https://github.com/corona-warn-app/cwa-verification-portal/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Test Result Server Software Design](https://github.com/corona-warn-app/cwa-testresult-server/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Mobile Client (Android) Architecture](https://github.com/corona-warn-app/cwa-app-android/blob/master/docs/architecture-overview.md)
 * [Corona-Warn-App Mobile Client (iOS) Architecture](https://github.com/corona-warn-app/cwa-app-ios/blob/development/docs/architecture-overview.md)
 * [Criteria for the Evaluation of Contact Tracing Apps](pruefsteine.md)
+* [Corona-Warn-App Security Overview](overview-security.md)

 To be published:
 * System Operation
-* Technical Security Concept
 * Data Privacy Concept

 ### Glossary
--- a/glossary.md
+++ b/glossary.md
@ -7,6 +7,7 @@ This overview provides a description for all acronyms and special terms which ar
 | AEM | Acronym for "[Associated Encrypted Metadata](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf)". A privacy preserving encrypted metadata that shall be used to carry protocol versioning and transmit (Tx) power for better distance approximation. The Associated Encrypted Metadata changes about every 15 minutes, at the same cadence as the Rolling Proximity Identifier, to prevent wireless tracking of the device.  |
 | AES | Acronym for "[Advanced Encryption Standard](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)", used in the [Exposure Notification Framework](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf) |
 | API | An [Application Programming Interface](https://en.wikipedia.org/wiki/Application_programming_interface) (API) is a computing interface which defines interactions between multiple software intermediaries. |
+| APNs | Acronym for "[Apple Push Notification service](https://en.wikipedia.org/wiki/Apple_Push_Notification_service)", a platform notification service created by Apple Inc. |
 | BGG | The [German Equality of Persons with Disabilities Act](https://www.gesetze-im-internet.de/bgg/), acronym for "Behindertengleichstellungsgesetz", long term: "Gesetz zur Gleichstellung von Menschen mit Behinderungen". |
 | BLE, BTLE | [Bluetooth Low Energy](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) is a wireless personal area network technology. It is used in the Corona-Warn-App. |
 | BMG | German [Federal Ministry of Health](https://www.bundesgesundheitsministerium.de/en/en.html), acronym for "Bundesministerium für Gesundheit". |
@ -18,6 +19,7 @@ This overview provides a description for all acronyms and special terms which ar
 | DP-3T | [Decentralized Privacy-Preserving Proximity Tracing](https://github.com/DP-3T/documents), another approach to an exposure notification app, mainly driven by institutions from Switzerland. |
 | ENA | Acronym for "Exposure Notification App", used as internal identifier for the Corona-Warn-App in certain locations. |
 | FAQ | Frequently Asked Questions |
+| FCM | Acronym for "[Firebase Cloud Messaging](https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging)", a cross-platform cloud solution for messages and notifications. |
 | GUID | Acronym for "[Globally Unique Identifier](https://en.wikipedia.org/wiki/Universally_unique_identifier)". |
 | IfSG | The [German Prevention and Control Act of infectious diseases among humans](https://www.gesetze-im-internet.de/ifsg/index.html), acronym for "Infektionsschutzgesetz", long term: "Gesetz zur Verhütung und Bekämpfung von Infektionskrankheiten beim Menschen". | 
 | OTC | Acronym for "[Open Telekom Cloud](https://open-telekom-cloud.com/)"
--- a/images/solution_architecture/figure_12.svg
+++ b/images/solution_architecture/figure_12.svg
--- a/images/solution_architecture/figure_13.svg
+++ b/images/solution_architecture/figure_13.svg
--- a/images/solution_architecture/figure_14.svg
+++ b/images/solution_architecture/figure_14.svg
--- a/images/solution_architecture/figure_2.svg
+++ b/images/solution_architecture/figure_2.svg
--- a/overview-security.md
+++ b/overview-security.md
@ -0,0 +1,473 @@
+# Secure Development
+## Risk Assessment
+An essential part of the development of secure applications is the risk assessment. 
+### Threat Modeling
+At the very beginning of the development process of this solution, development teams started to conduct threat modeling workshops. Within the threat modeling workshops, the teams identified risks, assets and assumptions, decided on risk response and created or updated their security plans.
+
+## Identified Risks, Threats and Proposed Controls
+Risks and threats identified during the conducted workshops are listed below. Please note that listed risks, threats and proposed controls are non-exhaustive and will be updated regularly.
+
+### Technical Risks
+ - <a name="risk-identification-of-infected-person">Identification of infected persons and/or persons under test</a>
+ 	- Related threats
+		- [Insecure design](#threat-insecure-design)
+   		- [Insecure programming](#threat-insecure-programming)
+		- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
+		- [Code injection flaws](#threat-code-injection-flaws)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Wrong choice of technology](#threat-wrong-choice-of-technology)
+		- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
+		- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
+		- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
+		- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
+		- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
+		- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
+ - <a name="risk-location-disclosure-of-infected-persons">Disclosure of the location of infected persons</a>
+ 	- Related threats
+		- [Insecure design](#threat-insecure-design)
+   		- [Insecure programming](#threat-insecure-programming)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Wrong choice of technology](#threat-wrong-choice-of-technology)
+		- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
+ - <a name="risk-social-network-disclosure">Social network disclosure</a>
+ 	- Related threats
+		- [Insecure design](#threat-insecure-design)
+ - <a name="risk-disclosure-of-notification-status">Disclosure of notification status</a>
+ 	- Related threats
+		- [Insecure programming](#threat-insecure-programming)
+		- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
+		- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
+		- [Code injection flaws](#threat-code-injection-flaws)
+		- [Transaction hijacking](#threat-transaction-hijacking)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Wrong choice of technology](#threat-wrong-choice-of-technology)
+		- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
+		- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
+		- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
+		- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
+		- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
+		- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
+ - <a name="risk-disclosure-of-personal-data">Disclosure of personal data</a>
+ 	- Related threats
+		- [Insecure programming](#threat-insecure-programming)
+		- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
+		- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
+		- [Code injection flaws](#threat-code-injection-flaws)
+		- [Transaction hijacking](#threat-transaction-hijacking)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Wrong choice of technology](#threat-wrong-choice-of-technology)
+		- [Spoofing of mobile application](#threat-spoofing-of-mobile-application)
+		- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
+		- [Information leakage of unprotected phone and/or mobile application](#threat-information-leakage-unprotected-phone)
+		- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
+		- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
+		- [Identity disclosure through metadata correlation](#threat-identity-disclosure-meta-data-correlation)
+ - Non-availability of app functionality
+ 	- Related threats
+		- [Insecure programming](#threat-insecure-programming)
+		- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
+		- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
+		- [Code injection flaws](#threat-code-injection-flaws)
+		- [Transaction hijacking](#threat-transaction-hijacking)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Denial-of-service attack against endpoints exposed to the internet](#threat-dos-against-internet-endpoints)
+		- [Denial-of-service against phone and/or mobile application for backend communication](#threat-dos-against-phone)
+		- [Mobile application acting as distributed denial-of-service device](#threat-mobile-application-as-ddos-device)
+		- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
+		- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
+		- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
+		- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
+ - <a name="risk-incorrect-notification-status">Incorrect notification status</a>
+ 	- Related threats
+		- [Insecure programming](#threat-insecure-programming)
+		- [Using components with known vulnerabilities](#threat-using-components-with-known-vulnerabilities)
+		- [PostgreSQL SQL injection](#threat-postgresql-sql-injection)
+		- [Code injection flaws](#threat-code-injection-flaws)
+		- [Transaction hijacking](#threat-transaction-hijacking)
+		- [Security misconfiguration](#threat-security-misconfiguration)
+		- [Missing cross-country interoperability of mobile application](#threat-missing-cross-country-interoperability)
+		- [Malicious phone and/or mobile application usage](#threat-malicious-phone-application-usage)
+		- [Misusage of phone and/or mobile application by user](#threat-misusage-of-phone-application)
+		- [Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application](#threat-misbehavior-of-mobile-application-backup-restore)
+		- [Tampering of upload authorization](#threat-tampering-of-upload-authorization)
+		- [Brute forcing of teleTANs](#threat-brute-forcing-of-teletans)
+		- [Tampering of test retrieval and upload parameters](#threat-tampering-test-retrieval)
+		- [Tampering of diagnosis keys](#threat-tampering-diagnosis-keys)
+		- [False notifications](#threat-false-notifications)
+### Non-Technical Risks
+ - <a name="risk-no-alert-on-contact-with-international-users">No alert on contact with international infected users</a>
+### Threats and Proposed Controls
+#### Use-Case-Independent Threats
+ - <a name="threat-insecure-design">Insecure design</a>
+ 	- Proposed controls
+		- Use of decentralized architecture based on Google, Apple and [DP-3T](https://github.com/DP-3T/) approach
+ - <a name="threat-insecure-programming">Insecure programming</a>
+ 	- Proposed controls
+		- Static application security testing
+		- Dynamic application security testing
+		- Penetration testing
+ - <a name="threat-using-components-with-known-vulnerabilities">Using components with known vulnerabilities</a>
+ 	- Proposed controls
+		- Open-source software security testing
+		- Regular open source software security
+		- Usage of GitHub security alerts
+ - <a name="threat-postgresql-sql-injection">PostgreSQL SQL injection</a>
+ 	- Proposed controls
+		- Static application security testing
+		- Dynamic application security testing
+		- Penetration testing
+		- Input validation
+ - <a name="threat-code-injection-flaws">Code injection flaws</a>
+ 	- Proposed controls
+		- Static application security testing
+		- Dynamic application security testing
+		- Penetration testing
+		- Input validation		
+ - <a name="threat-transaction-hijacking">Transaction hijacking</a>
+ 	- Proposed controls
+		- TLS certificate pinning
+		- TLS certificate validation
+ - <a name="threat-security-misconfiguration">Security misconfiguration</a>
+ 	- Proposed controls
+		- Security concept
+		- Infrastructure as code
+		- Configuration change management
+		- Automated configuration checks
+ - <a name="threat-dos-against-internet-endpoints">Denial of service attack against endpoints exposed to the internet</a>
+ 	- Proposed controls
+		- Distributed denial-of-service countermeasures
+		- Use of mutual TLS v1.3 for server to server communication
+#### Tracing Only
+ - <a name="threat-wrong-choice-of-technology">Wrong choice of technology</a>
+ 	- Proposed controls
+		- App-specific notification mechanism
+		- Minimal logging
+		- Minimal mobile application permissions
+ - <a name="threat-spoofing-of-mobile-application">Spoofing of mobile application</a>
+ 	- Proposed controls
+		- Use of iOS and Android signing and store infrastructure
+ - <a name="threat-missing-cross-country-interoperability">Missing cross-country interoperability of mobile application</a>
+ 	- Proposed controls
+		- Roaming alert
+ - <a name="threat-malicious-phone-application-usage">Malicious phone and/or mobile application usage</a>
+ 	- Proposed controls
+		- Inform user if functionality seems impaired
+ - <a name="threat-misusage-of-phone-application">Misusage of phone and/or mobile application by user</a>
+ - <a name="threat-misbehavior-of-mobile-application-backup-restore">Misbehavior of mobile application due to backup and/or restore of phone and/or mobile application</a>
+ - <a name="threat-information-leakage-unprotected-phone">Information leakage of unprotected phone and/or mobile application</a>
+ 	- Proposed controls
+		- Additional password protection of the mobile application
+ - <a name="threat-dos-against-phone">Denial-of-service against phone and/or mobile application for backend communication</a>
+ 	- Proposed controls
+		- Input validation
+		- TLS certificate pinning
+		- TLS certificate validation		
+ - <a name="threat-mobile-application-as-ddos-device">Mobile application acting as distributed denial-of-service device</a>
+ 	- Proposed controls
+		- Hardcoded server endpoints
+		- Digital signature
+		- Digital signature verification
+		- Timestamping of digital signature
+- <a name="threat-false-notifications">False notifications</a>
+	- Proposed controls
+		- No usage of operating system intents
+#### Submission of Exposure Keys
+ - <a name="threat-tampering-of-upload-authorization">Tampering of upload authorization</a>
+ 	- Proposed controls
+		- Enforce QR code one-time-usage
+		- TAN as one-time token for upload of diagnosis keys
+		- Flexibility to adjust teleTAN complexity to situational needs
+ - <a name="threat-brute-forcing-of-teletans">Brute forcing of teleTANs</a>
+ 	- Proposed controls
+		- Identify clients with features such as SafetyNet attestation or similar
+		- Increase teleTAN complexity
+		- Decrease teleTAN lifetime
+		- Security event monitoring incl. feature toggle
+		- Flexibility to adjust teleTAN complexity to situational needs
+ - <a name="threat-tampering-test-retrieval">Tampering of test retrieval and upload parameters</a>
+ 	- Proposed controls
+		- Input validation
+		- Digital signature
+		- Digital signature verification
+		- Use of mutual TLS v1.3
+		- Use of TLS v1.2/1.3 server authentication only
+		- Chain diagnosis key delta-packages
+		- Secure database connections
+		- Secure Exposure Notification Framework access
+		- Identify clients with features such as SafetyNet attestation or similar
+ - <a name="threat-tampering-diagnosis-keys">Tampering of diagnosis keys</a>
+  	- Proposed controls
+		- Input validation
+		- Digital signature
+		- Digital signature verification
+		- Use of mutual TLS v1.3
+		- Use of TLS v1.2/1.3 server authentication only
+		- Chain diagnosis key delta-packages
+		- Secure database connections
+		- Secure Exposure Notification Framework access
+		- Identify clients with features such as SafetyNet attestation or similar
+ - <a name="threat-identity-disclosure-meta-data-correlation">Identity disclosure through metadata correlation</a>
+ 	- Proposed controls
+		- Separation of metadata and payload
+		- No TAN storage in verification server back end
+		- Dummy packages for diagnosis key upload
+		- Use mix network for anonymity during diagnosis keys upload
+
+## Security Planning
+Based on the results of the risk assessment, the teams derive the security and also privacy requirements applicable to the solution to mitigate the risks. For each applicable requirement, the team defines a suitable security control, which usually consists of a security activity, a verification measurement, and the time to apply it. The security plan encompasses all security controls that the team decides to complete.
+
+## Security Testing
+The teams performs further verifications of the implemented security controls by security testing, following the security test plan the teams created. 
+
+### Static Application Security Testing (SAST)
+Whenever possible, the developers integrate these tools directly into their tool environment and use them daily. If this is not possible, the teams sets up daily or weekly runs of the static-code analyzers and feeds the results back to the developers for immediate audit and analysis during the development. 
+
+ - [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
+	 - Checkmarx Static Application Security Testing (CxSAST)  
+ - [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
+	 - Checkmarx Static Application Security Testing (CxSAST) 
+ - [cwa-server](https://github.com/corona-warn-app/cwa-server)
+	 - Micro Focus Fortify Static Code Analyzer
+ - [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
+  	 - Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
+ - [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
+   	 - Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
+ - [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
+ 	 - Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
+ - [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
+ 	 - Checkmarx Static Application Security Testing (CxSAST), SonarQube, Micro Focus Fortify Static Code Analyzer
+
+### Open-Source Known Vulnerability Scans
+Besides to SAST and whenever applicable, the developers frequently scan their used open-source components for known vulnerabilities and to mitigate findings by patching to a secure version. 
+
+- [cwa-app-android](https://github.com/corona-warn-app/cwa-app-android)
+	- BlackDuck
+- [cwa-app-ios](https://github.com/corona-warn-app/cwa-app-ios)
+	- BlackDuck	
+- [cwa-server](https://github.com/corona-warn-app/cwa-server)
+	- WhiteSource
+	- Synopsys Protecode
+	- Eclipse Steady (former SAP Vulas)
+- [cwa-testresult-server](https://github.com/corona-warn-app/cwa-testresult-server)
+	 - OWASP Dependency Checker
+- [cwa-verification-iam](https://github.com/corona-warn-app/cwa-verification-iam)
+	 - OWASP Dependency Checker
+- [cwa-verification-portal](https://github.com/corona-warn-app/cwa-verification-portal)
+	 - OWASP Dependency Checker
+- [cwa-verification-server](https://github.com/corona-warn-app/cwa-verification-server)
+	 - OWASP Dependency Checker
+
+# Secure Operations
+## Overview
+Deutsche Telekom AG deploys a secure operations framework to maintain security during the lifecycle of all services. Operations of the corona warn app is covered by this in-house standard. Its top-level structure is divided into 18 capabilities that cover the different fields of action:
+- [Asset and Configuration Management of Hardware and Software](#asset-and-configuration-management-of-hardware-and-software)
+- [Vulnerability Management and Assessment](#vulnerability-management-and-assessment)
+- [Incident and Problem Management](#incident-and-problem-management)
+- [Change Management](#change-management)
+- [Security Services](#security-services)
+- [Security Testing](#security-testing-1)
+- [Threat Intelligence](#threat-intelligence)
+- [Technical Cyber Resilience](#technical-cyber-resilience)
+- [Logging and Monitoring, Event Management and Alarming](#logging-and-monitoring-event-management-and-alarming)
+- [Partner Management](#partner-management)
+- [Secure Development](#secure-development-1)
+- [Backup & Restore](#backup-and-restore)
+- [Risk Management](#risk-management)
+- [Lifecycle Management](#lifecycle-management)
+- [Privileged Access Management](#privileged-access-management)
+- [Physical Security](#physical-security)
+- [Security Trainings and Skill Assessment](#security-trainings-and-skill-assessment)
+- [Customer and Authority Interaction](#customer-and-authority-interaction)
+
+The following chapters contain a brief introduction to each capability.
+
+## Capability Descriptions
+### Asset and Configuration Management of Hardware and Software
+#### Subject
+- Asset Management is a process for developing, operating, maintaining, upgrading, and disposing of hardware and software. An asset in terms of secure operations is any technical resource (configuration item). Configuration management is a process for hardware and software to establish and maintain performance consistency, ensure functional and physical attributes with its requirements and keep design and operational information throughout the lifecycle.
+- The Asset Register provides an overview of all relevant assets of an organization and ensures that all relevant business information is identified, defined and organized to facilitate its use and access. Furthermore, the register avoids duplicate information. 
+- Secure Operations Center (SOC) teams and Computer Emergency Response Teams (CERT) require access to this inventory.
+#### Objective
+- Gain overview of all relevant assets, responsibilities and ownership.
+- Use the asset register as a base for vulnerability management, incident and problem management, change management, risk management, logging, monitoring, event management and alarming. Enable secure operations to act.
+- Remediate vulnerabilities to reduce the likelihood of exploitation through a threat agent.
+
+### Vulnerability Management and Assessment
+#### Subject
+- Vulnerability Management & Assessment collects, detects, categorizes, prioritizes and communicates vulnerabilities and remediation information. It enforces and tracks mitigation, e.g. by introducing patch management for security vulnerabilities.
+
+#### Objective
+- Provide transparency of generic vulnerabilities.
+- Provide transparency of environment-specific vulnerabilities for each asset. 
+- Remediate vulnerabilities to reduce the likelihood of exploitation through a threat agent.
+
+### Incident and Problem Management
+#### Subject
+- Incident Management is an instrument for the structured treatment of security incidents by collaboration between security services and business operations. It includes all measures, responsibilities and principles for dealing with incidents of the operating processes.
+- Management is supported by establishing standardized customer business impact categories.
+#### Objective
+- Minimize the impact of security incidents and problems in order to avert potential damage to the company, employees and customers - sometimes with a handover to problem management.
+- Enable early identification and measurement of incidents and, if needed, timely reporting to regulatory authorities (e.g. Bundesnetzagentur, Bundesbeauftragter für den Datenschutz und die Informationsfreiheit).
+- Enable standardized incident reporting and monitoring which allows management escalation to solve security incidents accordingly. 
+- Manage security incidents in a standardized way.
+- Generate further input for other Information Security Management System (ISMS) processes (e.g. awareness campaigns).
+
+### Change Management
+#### Subject
+- The change management process has the primary goal of enabling beneficial changes while avoiding negative impact on IT services.
+- Change management ensures that all changes have been approved before the go-live and monitors if the approved change is aligned with the security requirements.
+#### Objective
+- Avoid unsecure and unauthorized changes. 
+- Reduce security risk during/due to operational changes. This applies if security-relevant aspects of the change have not been considered before.
+- Remediate vulnerabilities through change management to reduce the chance of exploitation through a threat agent.
+
+### Security Services
+#### Subject
+- Security Services include a single point of contact for internal/external incident reporters who perform a first evaluation of and reaction to security incidents. In case of critical incidents, additional on-demand incident response/hunting capabilities are available to perform a deep-dive analysis and resolution.
+- Last-level security responsibility as part of security services handles and takes responsibility for security incidents where dispatch is unclear.
+#### Objective
+- Evaluate security incidents and minimize the response time including certain event messages and alarming as well as incidents triggered by user reports. 
+- Handle reported security incidents.
+- Minimize the impact of security incidents.
+- Provide deep-dive analyses of critical incidents (e.g. advanced persistent threats (APT)).
+- Resolve “deadlock” situations during security incidents.
+- Support certificates.
+
+### Security Testing
+#### Subject
+- Security testing checks whether the security measures and procedures are still in line with the risk assessments from the company's point of view; check whether the corresponding measures and procedures are regularly tested and kept up to date. Infiltrate through existing perimeters (e.g. technical, physical, access control).
+- Security testing assesses if system and configuration settings are compliant to the security requirements and if the implementation contains vulnerabilities. 
+- It verifies of company and industry requirements e.g. through audits
+- During the lifecycle of a system or application, different types of testing are required. Findings are addressed in related ITIL processes.
+#### Objective
+- Identify, remediate or accept 
+	- known (e.g. existing Common Vulnerabilities and Exposures(CVE) score) vulnerabilities, 
+	- undiscovered (e.g. SQL injection) vulnerabilities and 
+	- architectural/processing vulnerabilities.
+- Ensure that security and business requirements are fulfilled.
+
+### Threat Intelligence
+#### Subject
+- Threat Intelligence collects, assesses and shares information on technical and non-technical threats. 
+- This information is enriched/extended by collaboration with external associations and non-profit organizations (e.g. FIRST, DAX 30, CSSA, ISF, etc.). It is primarily used for updating the technical security defense and monitoring infrastructure.
+#### Objective
+- Provide transparency and situational awareness for technical and non-technical cyber security threats.
+
+### Technical Cyber Resilience
+#### Subject
+- Technical Cyber Resilience solutions defend against specific threats. They are planned, built and operated based on threat exposure. This includes reaction processes for alerts. 
+- Examples: distributed denial-of-service (DDoS) attack protection, intrusion detection systems (IDS) / intrusion prevention systems (IPS), APT detection, antivirus, web application firewalls, proxies, spam filter. 
+#### Objective
+- Minimize impact of specific threats and attacks that consist of: 
+	- Dynamic polymorphic malware 
+	- Multi-stage malware
+	- (Multi-vector) Distributed denial-of-service attack
+	- Coordinated persistent attack 
+	- Network anomalies
+- Prevent unauthorized access and modification.
+- Provide secure architectures (e.g. layered security).
+- Support service continuity and disaster recovery.
+
+### Logging and Monitoring, Event Management and Alarming
+#### Subject
+- Logging and Monitoring, Event Management and Alarming covers the steps from a single log entry on a device up to creating a resulting security incident. It contains activities like log and alarm definition, log transport and security information and event management system (SIEM) operation including event correlation and analytics.
+- Messages and log files of different systems will be collected and evaluated. Suspicious events or dangerous trends can be detected (in real time).
+#### Objective
+- Detect attackers on internal networks due to behavior that triggers use cases.
+- Support investigations in the context of intrusions, breaches, regulatory or policy violations by focusing on highly technical evidence acquisition and evidence analysis. 
+- Provide input to and support an incident response process. 
+- Provide input to and support legal/disciplinary actions by giving a plausible reconstruction of attacker or user activity.
+- Troubleshoot operational security problems.
+- Provide advice on needed and common logfiles.
+
+### Partner Management
+#### Subject
+- Partner Management supports buyers to avoid or reduce risks associated with third-party products and services. 
+- Security requirements must be also fulfilled by external service providers / partners. Therefore, this must be clearly stated in the contracts (e.g. security annex, data processing agreement (DPA), audit rights). The requirements relate among other things to the identification of risks, contract management, control of service during execution and withdrawal of authorizations from external parties upon termination of service provision.
+- The partner must ensure functioning hiring and leaving processes for their employees. If needed, services must be provided by security-checked employees.
+- The partner must deliver security-related services such as vulnerability information, patch and release delivery or incident collaboration and support. 
+#### Objective
+- Guarantee a consistently high level of security even for services performed by external partners.
+- Avoid security gaps in contracts.
+- Guarantee collaboration and support by partners in case of security incident (e.g. to update or recover a system in the specified time).
+- Ensure controlled, monitored and minimized access for partners.
+- Ensure compliance with internal/external requirements (e.g. security checks).
+- Cooperate with selected/certified suppliers (blacklist/whitelist).
+
+### Secure Development
+#### Subject
+- Secure development (security by design and default) includes considering security aspects in the development stage of systems and platforms adequately. Default settings (e.g. required privileges) should be as low as possible and rarely used features should be deactivated by default. This is a prerequisite for secure operations.
+- Some security problems detected during the operations phase can be fixed with a workaround. This should be reported back to development as part of a systematic feedback from operations to development and vice versa. 
+#### Objective
+- Operate/use only secure systems/platforms.
+- Enhance secure development by providing feedback from secure operations.
+
+### Backup and Restore
+#### Subject
+- Backup and restore in terms of secure operations means to create backups and restore from backups in a secure way in case of disaster recovery.
+#### Objective
+- Ensure integrity, availability and confidentiality of backups.
+- Ensure defined retention times.
+
+### Risk Management
+#### Subject
+- Risk Management in terms of secure operations means that security risks are transferred and treated according to the risk management process.
+#### Objective
+- Identify and assess risks and hand them over to the according risk management process.
+- Treat risks with a structured approach (e.g. defined ownership, risk lifecycle, report, review tracking). 
+- Provide resources for enhanced risk mitigation.
+
+### Lifecycle Management
+#### Subject
+- Lifecycle Management in terms of secure operations focuses on technical rule sets, digital certificates and software in general.
+- Lifecycle Management ensures 
+	- maintenance of technical rule sets, 
+	- digital certificates being updated with end of life and
+	- deactivation of systems out of support of the partner. 
+#### Objective
+- Ensure up-to-dateness and traceability of technical security rule sets (e.g. firewall configuration).
+- Ensure operation only of systems (Development/Test/Production) that are still actively supplied with security patches from the vendor.
+- Ensure that digital certificates are always valid.
+
+### Privileged Access Management
+#### Subject
+- Privileged access management in terms of secure operations focuses on control processes and the monitoring of accounts with elevated rights.
+#### Objective
+- Ensure that privileged access is only granted on a need-to-know basis.
+- Ensure segregation of duties.
+- Ensure detection, alarming and reaction regarding privileged access policy violations.
+- Ensure trustworthy and complete authorization for employees and 3rd parties.
+
+### Physical Security
+#### Subject
+- Physical Security considers the security of buildings/locations (e.g. data center) and the protection/maintenance of infrastructure and resources as well as access controls to prevent loss, damage, theft, compromise or service interruption of an organization's assets.
+#### Objective
+- Maintain confidentiality, integrity and availability from a physical access perspective.
+
+### Security Trainings and Skill Assessment
+#### Subject
+- Security trainings and skill assessments
+	- inform about the specific company guidelines and processes for security. Participants receive information on which procedures to follow or which persons to inform when security-relevant events are detected.
+	- inform about specific threat scenarios which should be known by all employees. 
+	- provide guidance for administrators in form of how-tos (e.g. log file extraction and transfer, etc.). 
+- Specific trainings for security/operation staff (e.g. incident response, IDS, etc.) must be available.
+#### Objective
+- Strengthen the overall safety awareness and minimize the risks to IT security caused by internal and external employees 
+- Gain awareness to handle security threats.
+- Improve staff’s abilities to perform secure operations.
+
+### Customer and Authority Interaction
+#### Subject
+- Customer interaction in terms of secure operations means extending existing customer communication with security subjects and ensure the availability of a real-time communication channel in case of an incident. 
+- Adequately and timely communication with authorities and stakeholders is required.
+#### Objective
+- Improve customer relationship/satisfaction.
+- Foster trustful partnerships. 
+- Gain ideas for product improvements. 
+- Provide standardized communication structure in case of incident.
+- Support customers in identifying security gaps at an early stage and initiate appropriate measures.
+- Ensure compliance with reporting obligations towards authorities. Examples:
+	- General data protection regulation (GDPR)
+	- Sarbanes-Oxley Act (SOX)
+	- Kritische Infrastrukturen (KRITIS) 
+- Ensure prompt action to media reports (e.g. fake news).
--- a/scoping_document.md
+++ b/scoping_document.md
@ -1,7 +1,7 @@
 # TABLE OF CONTENTS
 1. [INTRODUCTION](#introduction)
 2. [USER JOURNEY](#user-journey)
-   1. [Description of Users (Stakeholders)](#description-of-users-stakeholders)
+   1. [Description of Usage Profiles (Stakeholders)](#description-of-usage-profiles-stakeholders)
   2. [User Journey](#user-journey-1)
 3. [FUNCTIONAL DESCRIPTION](#functional-description)
   1. [Overview of Epics](#overview-of-epics)
@ -17,79 +17,80 @@
      9. [Accessibility](#accessibility)
      10. [Content Management](#content-management)

-NOTE: This Scoping Document is also available [in German](translations/scoping_document.de.md).
+NOTE: This scoping document is also available [in German](translations/scoping_document.de.md).

 HINWEIS: Dieses Scoping-Dokument ist ebenfalls [auf Deutsch](translations/scoping_document.de.md) verfügbar.

 # INTRODUCTION
-The aim of the Corona-Warn-App is to identify SARS-CoV-2 chains of infection as quickly as possible and to break them. It does this by rapidly and reliably notifying users who have come into contact with infected users of the app that they may have been exposed to the virus. These individuals can then self-isolate to help stop the SARS-CoV-2 pandemic.
+The aim of the Corona-Warn-App is to identify SARS-CoV-2 chains of infection as quickly as possible and to break them. It does this by rapidly and reliably notifying people that they have had contact with infected persons and therefore may have been exposed to the virus. These individuals can then self-isolate, to help stop the SARS-CoV-2 pandemic.

 This document describes the functional requirements of the app’s design from a technical and process-based perspective. This version of the scope document describes the first release and an initial version of the app only.

 The overall planning also foresees publishing other development documents, to solicit feedback from an early stage for potential incorporation in the project. The release architecture document and back-end alpha source code will be made available subsequently.

-The requirements have been defined and outlined according to a user-centric methodology. This means the entire process flow is designed from the perspective of the respective app users and the other stakeholders involved in the process. The aim is to map user needs in such a way that it promotes a high degree of acceptance and makes the respective functions intuitive to use.
+The requirements have been defined and outlined according to a person-centric methodology. This means the entire process flow is designed from the perspective of the people who use the app and the other stakeholders involved in the process. The aim is to map the needs of all stakeholders in such a way that it promotes a high degree of acceptance and makes the respective functions intuitive to use.

 The interaction points and user experience are mapped based on a user journey. The resulting requirements are assigned to “epics”, or descriptions of the requirements at a high level of abstraction. These epics describe the individual contact points and general functions throughout the process that are required for usage and acceptance of the app. In turn, the epics are used to derive the detailed requirements in the form of user stories (software requirements formulated in everyday language). Through this approach, the individual requirements are structured as they are incorporated in the development process.

 # USER JOURNEY

-## Description of Users (Stakeholders)
-The following key users and stakeholders are integrated in the user journey, or overall process, and described in their roles:
+## Description of Usage Profiles (Stakeholders)
+The following key usage profiles and stakeholders are integrated in the user journey, or overall process, and described in their roles:

 #### App User
-Any potential user who uses the app to find out whether they have been near anyone who is infected, to verify their own test results, and who then, under a pseudonym and voluntarily, warns all other users.
+All persons who use the app: Are notified of potential exposure to infected persons, verify their own test results, and then warn all the people they have encountered – voluntarily and under a pseudonym.

 #### Hotlines
-Support app users in answering questions about how to use the app, the technology, and data privacy. If asked, they provide information on proper conduct and where to get further information in case of contact or infection.
-Help verify and release test results in the app for infected individuals and can recommend them to contact their health department.
+Provide support to persons who use the app by in answering questions about how to use the app, the technology, and data privacy. If asked, they provide information on proper conduct and where to get further information in case of contact or infection.
+Help verify and release test results in the app for infected individuals and can recommend that they contact their health department.

-#### Robert-Koch-Institut (RKI)
-Provides epidemiological information and recommendations for action to app users (content). Determines the parameters used to measure the number of contacts (to the extent of the API’s technical capabilities).
+#### Robert Koch Institute (RKI)
+Provides epidemiological information and recommendations for using the app (content). Determines the parameters used to measure the number of contacts (to the extent of the API’s technical capabilities).
 ## User Journey
-App usage is divided into different phases, based on contact points and user interactions that occur successively. In each phase, users are assigned motivations or requirements that meet their expectations of the app and guide them intuitively through the process.
+App usage is divided into different phases, based on contact points and interactions between people that occur successively. In each phase, persons are assigned motivations or requirements that meet their expectations of the app and guide them intuitively through the process.

-![Graphic 5: User Journey](user_journey.png "User Journey")
+![Figure 1: User Journey](user_journey.png "User Journey")

-#### Idea phase
-In this phase, a user decides to get more information about the app. In this phase, users may have different questions regarding usage of the app (application, data privacy, accessibility, and so on). It should be possible to have these questions answered before downloading the app (hotline, information on the websites of the RKI, Federal Ministry of Health (BMG), App Store/Google Play Store).
+#### *Idea* phase
+In this phase, a person decides to get more information about the app. In this phase, persons may have different questions regarding usage of the app (application, data privacy, accessibility, and so on). It should be possible to have these questions answered before downloading the app (hotline, information on the websites of the RKI and Federal Ministry of Health (BMG), App Store/Google Play Store).

-#### Installation phase
-A user decides to download the app (App Store/Google Play Store) and, after the technical installation process, is given an introduction to the app the first time it is opened. In this introductory phase, app users are given an overview of the functionality, terms of use, and privacy provisions; are asked for the necessary consent; and guided through the notification and other settings.
+#### *Installation* phase
+A person decides to download the app (App Store/Google Play Store) and, after the technical installation process, is given an introduction to the app the first time it is opened. In this introductory phase, app users are given an overview of the functionality, terms of use, and privacy provisions; are asked for the necessary consent; and guided through the notification and other settings.

-#### Usage phase
-The usage phase is subdivided into four further areas, in which app users have different needs.
+#### *Usage* phase
+The usage phase is subdivided into four further areas, in which people who use the app have different needs.

 1. **Background**

-   In idle mode, the application runs in the background on the smartphone and saves the pseudo IDs of other nearby app users, automatically and encrypted. At regular intervals, the app pulls from the server a list of pseudo IDs of the app users who have voluntarily reported that they are infected. The app compares their pseudo IDs with those stored on the smartphone to determine whether there has been any exposure.
+   In idle mode, the application runs in the background on the smartphone and saves the pseudo IDs of other nearby app users, automatically and encrypted. At regular intervals, the app pulls from the server a list of pseudo IDs of the persons who have voluntarily reported that they are infected. The app compares their pseudo IDs with those stored on the smartphone to determine whether there has been any exposure.

 2. **Exposure**

-   If exposure to infected persons is determined, the app user receives a notification and recommendations on what to do. For instance, that they should contact their physician, their health department, and whether they should self-isolate.
+   If exposure to infected persons is determined, app user receives a notification and recommendations on what to do. For instance, that they should contact a medical professional or their responsible health department, and whether they should self-isolate.

 3. **Testing**

-   If the app user is tested for a SARS-CoV-2 infection, they can start the digital test information process in the app, which notifies them of their test result.
+   If an app user is tested for a SARS-CoV-2 infection, they can start the digital test information process in the app, which notifies them of their test result.

 4. **Infection case**

-   If an app user tests positive for infection, they can voluntarily publish the pseudonymized warn IDs saved in their app. That way, other app users can use their smartphone to find out whether they were in contact with the infected user.
+   If an app user tests positive for SARS-COV-2 infection, they can voluntarily publish the pseudonymized warn IDs saved in their app. That way, other app users can use their smartphones to find out whether they have been exposed to the infected user.

-#### Uninstallation phase
-An app user can uninstall the app at any time, and completely delete all the data stored in it.
+#### *Uninstallation* phase
+A person can uninstall the app at any time, completely deleting all the data stored in it.

 # FUNCTIONAL DESCRIPTION
+
 ## Overview of Epics
 The app functions are divided into user process phases (with direct ties to the user journey) and general support processes. An overview of the epics is depicted below:

-#### User process phases
+#### Process Phases of Use
 | # | Epic | Description |
 |---:|--------|--------------|
 | 1 | Onboarding and Installation | All processes that take place the first time the app is used (such as consent, data privacy, language selection) |
 | 2 | Information and Instructions for Using the App | Help tools for using the app (such as user manual, tutorial), as well as publication information for the app |
 | 3 | Use in the Regular Process | App functions in idle mode (such as activate/deactivate, changing settings, monitoring app activities) |
-| 4 | Exposure (Contact with an Infected Person) | Contains all the functions associated with contact points (such as notifications, recommended actions) |
+| 4 | Exposure (Contact with an Infected Person) | All functions associated with contact points (such as notifications, recommended actions) |
 | 5 | Notification of Covid-19 Test Results | Functions related to the notification of test results |
 | 6 | Warning trigger | Process to trigger a warning if a test result is positive |

@ -102,78 +103,78 @@ The app functions are divided into user process phases (with direct ties to the
 | 10 | Content Management | To adjust and update content in the app (texts, links, hotlines, and so on) |

 ## Overview of User Stories
-The requirements the Corona-Warn-App must satisfy, and which define its functional scope, are formulated below in the usual format of a user story:
+The requirements the Corona-Warn-App must satisfy, and which define its functional scope, are formulated below in the usual format of a user story, unless specified otherwise:

-_“As a &lt;stakeholder&gt;, I want &lt;goal&gt;, so that &lt;reason&gt;.”_
+_“As &lt;stakeholder&gt;, I want &lt;goal&gt;, so that &lt;reason&gt;.“_

-The corresponding acceptance criteria supplement the specification of the requirements by defining the conditions that the software must fulfill to satisfy customer needs.
+The corresponding acceptance criteria supplement the specification of the requirements by defining the conditions that the software must fulfill to satisfy user needs..

 ### Onboarding and Installation
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
 | E01.01 | As an app user, the first time I launch the app, I want to receive an introduction to how it works (app motivation). | 1. An introduction to how the app works is displayed the first time the app is launched.<hr/>2. The introduction to how the app works is not displayed when the app is launched subsequently.<hr/>3. The explanatory content is available to app users in the respective functional areas. |
-| E01.02 | As an app user, the first time I launch the app, I want to be notified about the terms of use and privacy provisions (data privacy screen) and grant my consent, so that I know how my data will be used within the app. | 1. By using the app, the app user accepts the terms of use and privacy provisions.<hr/>2. The terms of use can be displayed within the app.<hr/>3. The consent prompt is shown only the first time a user launches the app. |
-| E01.03 | As an app user, the first time I use the app, I want to be asked whether I consent to the creation of pseudonymized IDs and sending them to devices near me, so that I am informed about how the app works. | 1. Confirmation of the creation of pseudonymized IDs and sending them to nearby devices by the app is a prerequisite for using the app.<hr/>2. The prompt no longer appears after the first time the app is used. |
-| E01.04 | As an app user, the first time I use the app, I want to be asked whether the application can access the smartphone’s Bluetooth function, so that I can control how the app is used on the smartphone. | 1. In using the app, users confirm access to the Bluetooth (BLE) function. |
-| E01.05 | As an app user, the first time I use the app, I want to be asked whether the application can send me notifications, so that I can receive push notifications in a variety of situations. | 1. The app’s notification settings are queried before the app is used for the first time.<hr/>2. The prompt no longer appears after the first time the app is used. |
-| E01.06 | As an app user, I want the app to be displayed in my language the first time I use it, so that I understand what is happening. | 1. The configured system language is detected.<hr/>2. If the content is not available in the detected system language, English is selected by default.<hr/>3. The first version of the app is expected to be available also in languages other than English. |
-| E01.07 | As an app user, I want to see help and settings regarding accessibility, so that I can use the app. | 1. Accessibility is provided depending on the options available in the respective operating system. |
+| E01.02 | As an app user, the first time I launch the app, I want to be notified about the terms of use and privacy provisions (data privacy screen) and grant my consent, so that I know how my data will be used within the app. | 1. By using the app, the user accepts the terms of use and privacy provisions.<hr/>2. The terms of use can be displayed within the app.<hr/>3. The consent prompt is shown only the first time a user launches the app. |
+| E01.03 | As an app user, the first time I use the app, I want to be asked whether I consent to the creation of pseudonymized IDs and sending them to devices near me, so that I am informed about how the app works. | 1. Confirmation of the creation of pseudonymized IDs and their transmission to nearby devices by the app is a prerequisite for using the app.<hr/>2. The prompt no longer appears after the first time the app is used. |
+| E01.04 | As an app user, the first time I use the app, I want to be asked whether the application can access the smartphone’s Bluetooth function, so that I can control how the app is used on the smartphone. | 1. This user story is tantamount to E01.03. The authorization to use the generation of pseudonymous IDs and send them to nearby devices is already contained in the usage of Bluetooth Low Energy (BLE).<hr/>2. The configuration of the general Bluetooth functions is only possible in the system settings. |
+| E01.05 | As an app user, the first time I use the app, I want to be asked whether the application is allowed to send me notifications, so that I can get notifications in a variety of situations. | 1. The app’s notification settings are queried before the app is used for the first time. This enables local notifications. True push notifications from external servers are not supported (APNs/FCM). <hr/>2. The prompt no longer appears after the first time the app is used. |
+| E01.06 | As an app user, I want the app to be displayed in my language the first time I use it, so that I can understand how to use the app. | 1. The configured system language is detected.<hr/>2. If the content is not available in the detected system language, English is selected by default.<hr/>3. The first version of the app is expected to be available also in languages other than English. |
+| E01.07 | As an app user, I want to see help functions and settings for accessibility during the onboarding process, so that I can use the app. | 1. Accessibility is provided depending on the options available in the respective operating system. |

 ### Information and Instructions for Using the App
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E02.01 | As an app user, I want to have access to a FAQ list, to find answers to questions I might have about the app. | 1. A link to a web page with FAQs is defined in the app menu. |
-| E02.02 | As an app user, I want to have access to instructions that tell me how to use the app and its functions. | 1. A link to a web page with a user manual is defined in the app menu. |
-| E02.03 | As an app user, I want to have access to an explanatory video for the app, so that I understand how to use the app and its functions. | 1. A link to a web page with a user manual is defined in the app menu. |
+| E02.01 | As an app user, I want to have access to a FAQ list, so that I can find answers to questions I might have about the app. | 1. The app will either contain a link to a web page with FAQs, which is displayed in a browser window, or the web page will be displayed within the app itself. |
+| E02.02 | As an app user, I want to have access to instructions, so that I can understand the app and its functions. | 1. An explanation of the app’s various functions will be provided. |
+| E02.03 | As an app user, I want to have access to an explanatory video, so that I can understand how to use the app and its functions. | 1. An explanation of the app’s various functions will be provided. |
 | E02.04 | As an app user, I want to be able to display publication information for the app, so that I can see who is responsible for development and content of the app. | 1. There is a “Publication information” item in the menu.<hr/>2. The publication information contains the usual information required. |
 | E02.05 | As an app user, I want to be able to display the terms of use and data privacy information at any time. | 1. The app provides simple access to the terms of use and data privacy information. |
-| E02.06 | As an app user, I want to be able to see various hotlines for technical, privacy-related, health-related, and psychological questions, as well as for verification of test results, so that I can receive information or answers to my questions. | 1. Display of phone numbers of the hotlines (for technical, privacy-related, health-related, and psychological questions).<hr/>2. Display the times when the hotline can be reached (for example: 24/7)<hr/>3. Phone numbers can be called directly from the app. |
+| E02.06 | As an app user, I want to be able to see various hotlines for technical, privacy-related, health-related, and psychological questions, as well as for verification of test results, so that I can receive further information or answers to my questions. | 1. The app offers access to a technical hotline and a hotline for obtaining a phone TAN.<hr/>2. The times the hotline is available (such as 24/7) is displayed.<hr/>3. Phone numbers can be called directly from the app. |

 ### Use in the Regular Process
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E03.01 | As an app user, I want to be able to activate and deactivate the app, so that I can switch the function on and off. | 1. A toggle button activates and deactivates the function (Bluetooth in the background and hash generation).<hr/>2. The consequences of activation/deactivation are explained. |
-| E03.02 | As an app user, I want to be able to reset to the app to the delivery defaults, so that I can reconfigure it. | 1. The app can be reset to the delivery defaults with a setting option, but the traces saved from recent days are retained. |
-| E03.03 | As an app user, I want to be able to adjust the app settings (access permissions, such as Bluetooth and notifications) in a menu, so that I can manage the app functions and accesses. | 1. App users can call a menu for app settings.<hr/>2. Notifications can be activated and deactivated.<hr/>3. The user can permit the app to access Bluetooth, and remove that permission.<hr/>4. Before access permissions are deactivated, I receive information as to which app functions will no longer work (in full). |
+| E03.01 | As an app user, I want to be able to activate and deactivate the app, so that I can switch the functions on and off. | 1. The functions for generating pseudonymized IDs and sending them to nearby devices can be activated and deactivated. <hr/>2. The consequences of activation/deactivation are explained. |
+| E03.02 | As an app user, I want to be able to reset to the app to the delivery defaults, so that I can reconfigure it. | 1. The app can be reset to the delivery defaults with a setting option. The saved traces have to be deleted through the system settings. |
+| E03.03 | As an app user, I want to be able to adjust the app settings (access permissions, such as notifications) in a menu, so that I can manage the app functions and accesses. | 1. App users can call a menu for app settings. <hr/>2. Notifications can be activated and deactivated.<hr/>3. Access to the functions for generating pseudonymized IDs and sending them to nearby devices can be activated and deactivated.<hr/>4. Before access permissions are deactivated, I receive information as to which app functions will no longer work (in full). |

 ### Exposure (Contact with an Infected Person)
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E04.01 | As an app user, I want to be notified when a person I have had contact with has reported an infection, so that I can then take the appropriate measures to stop the spread of the virus. | 1. The app sends a notification to the app user.<hr/>2. The notification notifies the app user that the risk has changed (depending on the provided API function). |
-| E04.02 | As an app user, if I am exposed to the virus, I want to receive instructions from the application, so that I can adapt my behavior to RKI recommendations. | 1. Notification leads to defined recommended actions in case of exposure. |
+| E04.01 | As an app user, I want to be notified when a person I have had contact with has reported an infection, so that I can then take the appropriate measures to stop the spread of the virus. | 1. Depending on the notification settings, the app sends a notification to the user.<hr/>2. If the risk assessment for a user changes, a notification informs users that there is news in the app. The actual changed risk assessment is not displayed until the app is opened. |
+| E04.02 | As an app user, if I am exposed to the virus, I want to receive instructions from the app, so that I can adapt my behavior to RKI recommendations. | 1. A notification leads the user to the app. The recommendations from the RKI are defined statically in the app. |

 ### Notification of Covid-19 Test Results
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E05.01 | As the RKI, I want only positive tested users to trigger a one-time warning, so that I can avoid misuse. | 1. Only positive tests can trigger a warning.<hr/>2. A warning can only be triggered once for each test. |
-| E05.02 | As an app user, in case of a positive test result, I want to receive information about the illness and the necessary next steps, so that I can adapt my behavior to RKI recommendations. | 1. Notification of receipt of a test result.<hr/>2. Display of an information text in the app with defined content (such as information about the outcome of the test result, information about necessary measures, a hotline number). |
+| E05.01 | As the RKI, I want only positive tested users to trigger a one-time warning, so that I can prevent misuse. | 1. Only positive tests can trigger a warning. This is ensured by the verification server and the hotline for the phone TAN procedure.<hr/>2. A warning can only be triggered once for each test. |
+| E05.02 | As an app user, in case of a positive test result, I want to receive information about the illness and the necessary next steps, so that I can adapt my behavior to RKI recommendations. | 1. A notification merely informs you that there is news in the app. The test result itself can only be seen in the app. <hr/>2. An info text with defined content is displayed in the app (for example, information about the outcome of the test result, information about necessary measures, a hotline number). |

 ### Triggering a Warning
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E06.01 | As a user of the app, I want to be able to scan a QR code provided by my doctor or test center, so that I can receive my test result in the Corona-Warn-App. | 1. A QR code provided on a flyer from the doctor or test center can be scanned with the warn app.<hr/>2. An explanatory text is displayed. |
-| E06.02 | As a user of the app, I want to be notified within the Corona-Warn-App as soon as a test result becomes available. | 1. The app user receives a notification as soon as a verified test result is available.<hr/>2. The notification does not indicate whether the result is positive or negative. |
-| E06.03 | As a user of the app, if I receive a positive test result, I want to be able to grant my consent to sending the pseudonymized IDs, under which I was visible to other app users in recent days, to the Warn server, so that the people I have been in contact with can be warned by their apps. | 1. The IDs can be sent to the Warn server pseudonymized.<hr/>2. Data transmission is only possible if successfully verified beforehand.<hr/>3. Data transmission is only possible if the app user has granted consent beforehand. |
-| E06.04 | As a user of the app, I want to be able to use a manual process (in addition to the digital process), for example, through a call center and without a QR code, to send the pseudonymized IDs, under which I was visible to other app users in recent days, to the Warn server, so that the people I have been in contact with can be warned by their apps. | 1. The center responsible can generate a TAN and provide it to the app user (the TAN is generated by a server, not the call center itself). |
-| E06.05 | As an app user, I want to be able to enter a TAN in the app, to use the TAN I have been given to assign my test result to my instance of the app. | 1. It is possible to enter a TAN within the app.<hr/>2. Verify and provide feedback as to whether the entered TAN was correct (must be checked whether technically possible). |
-| E06.06 | As a user of the app, after the TAN is verified, I want to share my pseudonymized IDs and warn persons I may have been in contact with. | 1. The IDs can be sent to the Warn server pseudonymized.<hr/>2. Data transmission is only possible if successfully verified beforehand.<hr/>3. Data transmission is only possible if the app user has granted consent beforehand. |
+| E06.01 | As an app user, I want to be able to scan a QR code provided by a medical professional or test center, so that I can receive my test result in the Corona-Warn-App. | 1. A QR code provided on a flyer from the medical professional or test center can be scanned with the Corona-Warn-App.<hr/>2. An explanatory text is displayed. |
+| E06.02 | As an app user, I want to be notified within the Corona-Warn-App as soon as a test result becomes available. | 1. A notification merely informs you that there is news in the app. The test result itself can only be seen in the app.<hr/>2. The notification does not explicitly indicate whether the result is positive or negative. |
+| E06.03 | As an app user, if I receive a positive test result, I want to be able to grant my consent to sending the pseudonymized IDs under which I was visible to other people in recent days to the Warn server, so that the people I have been in contact with can be warned by their apps. | 1. The IDs can be sent to the Warn server pseudonymized.<hr/>2. Data transmission is only possible if successfully verified beforehand. This is ensured by the verification server and the hotline for the phone TAN procedure.<hr/>3. Data transmission is only possible if the app user has granted consent beforehand. |
+| E06.04 | As an app user, I want to be able to use a manual process (in addition to the digital process), for example, through a call center and without a QR code, to send the pseudonymized IDs under which I was visible to other app users in recent days, to the Warn server, so that the people I have been in contact with can be warned by their apps. | 1. The center responsible can generate a TAN and provide it to the person. (The TAN is generated by a server, not the call center itself.) |
+| E06.05 | As an app user, I want to be able to enter a TAN in the app, so that I can use the TAN I have been given to assign my test result to my instance of the app. | 1. It is possible to enter a TAN within the app.<hr/>2. The app verifies the entered TAN and provides feedback as to whether it was correct (must be checked whether technically possible). |
+| E06.06 | As an app user, after the TAN is verified, I want to share my pseudonymized IDs voluntarily, so that I can warn persons I may have been in contact with. | 1. The IDs can be sent to the Warn server pseudonymized.<hr/>2. Data transmission is only possible if successfully verified beforehand. This is ensured by the verification server and the hotline for the phone TAN procedure.<hr/>3. Data transmission is only possible if the person has granted consent beforehand. |

 ### Parameter Settings
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E07.01 | As the RKI, I want to be able to configure the parameters (to the extent the API is able to do this) for risk scoring, so that I can keep up with the latest research findings on virus transmission. | 1. Thresholds can be configured dependent on the provided API.<hr/>2. These settings will be modified on user devices without requiring an update of the app. |
+| E07.01 | As the RKI, I want to be able to configure the parameters (to the extent the API is able to do this) for risk scoring, so that I can keep up with the latest research findings on virus transmission. | 1. Thresholds can be configured dependent on the provided API.<hr/>2. The app receives dynamic configurations from the RKI that can affect how the risk assessment is calculated. |

 ### Technical Support
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E08.01 | As an app user, I want to be able to contact a hotline, to resolve technical problems with the app. | 1. The phone number of the technical hotline is stored in the application. |
+| E08.01 | As an app user, I want to be able to contact a hotline, so that I can resolve any technical problems with the app. | 1. The phone number of the technical hotline is stored in the app. |

 ### Accessibility
 | # of user story ID | User story | Acceptance criteria |
 |-----------------|------------|--------------------|
-| E09.01 | As a user of the app, I want it to have audio output (if I have impaired or no vision, for example). | 1. Accessibility regarding audio output is provided depending on the options available in the respective operating system. |
+| E09.01 | As an app user, I want it to have audio output, so that I can use the app even if I have impaired vision (or am blind), for example. | 1. Accessibility regarding audio output is provided depending on the options available in the respective operating system. |
 | E09.02 | As an app user, I want to have good contrast settings, modifiable font sizes, and an easily readable font, so that I can read the texts in the app easily. | 1. Accessibility regarding contrast and font size/type is provided depending on the options available in the respective operating system. |
-| E09.03 | As an app user, I want to have content in simplified language, so that I can easily understand how to use the app and why I should use it. | 1. Accessibility is taken into account within content management. |
+| E09.03 | As an app user, I want to have the content in simplified language, so that I can easily understand how to use the app and why I should use it. | 1. The texts and languages are defined by the ordering party. |

 ### Content Management
 | # of user story ID | User story | Acceptance criteria |
--- a/solution_architecture.md
+++ b/solution_architecture.md
@ -1,12 +1,12 @@
 # CORONA-WARN-APP SOLUTION ARCHITECTURE

-This document is intended for a technical audience and represents the most **recent state of the architecture, which might not be final yet**, as external dependencies (e.g. the framework provided by Apple/Google) are still changing.
+This document is intended for a technical audience. It represents the most **recent state of the architecture and is still subject to change** as external dependencies (e.g. the framework provided by Apple/Google) are also still changing.

-Diagrams  reflect the current state but might as well change at a later point of time. [Technical Architecture Modeling (TAM)](http://www.fmc-modeling.org/fmc-and-tam) is used for some of the diagrams.
+The diagrams  reflect the current state but may also change at a later point in time. For some of the diagrams, [Technical Architecture Modeling (TAM)](http://www.fmc-modeling.org/fmc-and-tam) is used.

-Please note that further technical details on the individual components, the security concept and the data protection concept will be made available at a later date.
+Please note that further technical details on the individual components, the security concept, and the data protection concept are provided at a later date.

-Assuming a close association of a mobile phone and its user, we equate the device (phone, app) and the person using it (person, user, individual) and use these terms interchangeable. 
+We assume a close association of a mobile phone and its user and, thus, equate the device (phone, app) and the person using it (person, user, individual) and use these terms interchangeably. 

 ![Corona-Warn-App Components](images/solution_architecture/CWA_Components.png "Corona-Warn-App Components")

@ -29,117 +29,121 @@ Assuming a close association of a mobile phone and its user, we equate the devic

 ## INTRODUCTION

-To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic) it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and affected individuals identified these in personal dialogues based on people’s memory, which led to a high number of unknown connections, e.g. when using public transport. 
+To reduce the spread of [COVID-19](https://www.ecdc.europa.eu/en/covid-19-pandemic), it is necessary to inform people about their close proximity to positively tested individuals. So far, health departments and affected individuals have identified possibly infected individuals in personal conversations based on each individuals' memory. This has led to a high number of unknown connections, e.g. when using public transport. 

 ![Figure 1: High-level architecture overview](images/solution_architecture/figure_1.svg "Figure 1: High-level architecture overview")

-With the Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, individuals are enabled to trace their personal exposure risk through the means of their mobile phones. The application makes use of a new framework made available by Apple and Google, called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). It employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics that let the individual phones act as beacons (constantly broadcasting a temporary identifier (called Rolling Proximity Identifier – RPI) to be remembered by), while scanning for identifiers of other phones at the same time (shown on the right side of *Figure 1*). 
-Identifiers are ID numbers sent out by the phones. To ensure privacy and prevent tracking of movement patterns of the app user, those broadcasted identifiers are only temporary and  change constantly. New identifiers are derived from a Temporary Exposure Key (TEK) that substitutes daily at midnight (UTC) through means of cryptography, which will be explained in more detail in *Figure 10*. When the TEKs are linked to a positive test, they remain technically the same, but are called Diagnosis Keys.
+The Corona-Warn-App (see [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md )), shown centrally in *Figure 1*, enables individuals to trace their personal exposure risk via their mobile phones. The Corona-Warn-App uses a new framework provided by Apple and Google called [Exposure Notification Framework](https://www.apple.com/covid19/contacttracing). The framework employs [Bluetooth Low Energy (BLE)](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy) mechanics. BLE lets the individual mobile phones act as beacons meaning that they constantly broadcast a temporary identifier called Rolling Proximity Identifier (RPI) that is remembered and, at the same time, lets the mobile phone scan for identifiers of other mobile phones. This is shown on the right side of *Figure 1*. 
+Identifiers are ID numbers sent out by the mobile phones. To ensure privacy and to prevent the tracking of movement patterns of the app user, those broadcasted identifiers are only temporary and change constantly. New identifiers are derived from a Temporary Exposure Key (TEK) that is substituted at midnight (UTC) every day through means of cryptography. For a more detailed explanation, see *Figure 10*. Once a TEK is linked to a positive test result, it remains technically the same, but is then called a Diagnosis Key.

-The collected identifiers of other users, as well as the own keys (which can later be used to derive the identifiers) are stored locally on the phone within the secure storage of the framework provided by Apple and Google. This secure storage cannot be accessed directly by the application, but only through the interfaces provided by the Exposure Notification Framework. Some of those interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures), in order to prevent misuse. In case users were tested positively for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys of up to 14 days. Once the keys have been uploaded to the Corona-Warn-App backend server, all keys of positively tested people are aggregated. This list of keys is then made available to all mobile phones with the app installed. Additionally, configuration parameters for the framework are available for download, so that adjustments to the calculation of the risk score can be taken (see the section regarding *Risk Scores*).
-Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification framework, which analyzes whether one of the identifiers collected by the phone matches to those of an infected person. Additionally, meta data that has been broadcasted together with the identifiers (e.g. transmit power), can now be decrypted and used. Based on the collected data a risk score for each individual exposure as well as for the overall situation is calculated for every single user within the Exposure Notification framework by Apple and Google. Exposures are defined as an aggregation of all encounters with another person on a single calendar day (UTC timezone). For privacy reasons it is not possible to track encounters with other individuals across multiple days.
+The collected identifiers from other users as well as the own keys, which can later be used to derive the identifiers, are stored locally on the phone in the secure storage of the framework provided by Apple and Google. The application cannot access this secure storage directly, but only through the interfaces the Exposure Notification Framework provides. To prevent misuse, some of these interfaces are subjected to [rate limiting](https://developer.apple.com/documentation/exposurenotification/enmanager/3586331-detectexposures). If  app users are tested positively for SARS-CoV-2, they can update their status in the app by providing a verification of their test and select an option to send their recent keys from up to 14 days back. On the Corona-Warn-App back-end server, all keys of positively tested individuals are aggregated and are then made available to all mobile phones that have the app installed. Additionally, the configuration parameters for the framework are available for download, so that adjustments to the risk score calculation can be made, see the *Risk Scores* section.
+Once the keys and the exposure detection configuration have been downloaded, the data is handed over to the Exposure Notification Framework, which analyzes whether one of the identifiers collected by the mobile phone matches those of a positively tested individual. Additionally, the metadata that has been broadcasted together with the identifiers such as the transmit power can now be decrypted and used. Based on the collected data, the Exposure Notification Framework provided by Apple and Google calculates a risk score for each individual exposure as well as for the overall situation. Exposures are defined as an aggregation of all encounters with another individual on a single calendar day (UTC timezone). For privacy reasons, it is not possible to track encounters with other individuals across multiple days.

-It is important to notice at this point, that the people that have been exposed to a positively tested person are **not informed by a central instance**, but the risk of an exposure is calculated locally on their phones. The information about the exposure remains on the user’s phone and is not shared.
+It is important to note that the persons that have been exposed to a positively tested individual are **not informed by a central instance**, but the risk of an exposure is calculated locally on their phones. The information about the exposure remains on the user’s mobile phone and is not shared.

-The app pursues two objectives: First, supporting individuals in finding out whether they have been exposed to a person that has later been tested positively, and second receiving results of a SARS-CoV-2 test on their phone through an online system. This helps to reduce the period until necessary precautions (e.g. contact reduction and testing) can be taken.
-In order to prevent misuse, users need to provide proof that they have been tested positive before being able to upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users. 
-They only have to confirm to the app and the Exposure Notification Framework that they are willing to share their diagnosis keys. Manual verification is also possible, if the lab that performed the testing does not support the direct electronic transmission of test results to the users' phone or if users have decided against the electronic transmission of their test results. 
+The Corona-Warn-App pursues two objectives:
+1. It supports individuals in finding out whether they have been exposed to a person that has later been tested positively.
+2. It receives the result of a SARS-CoV-2 test on a user's mobile phone through an online system. This helps reduce the time until necessary precautions, e.g. a contact reduction and testing, can be taken.

-### Retrieval of lab results and verification process
+In order to prevent misuse, individuals need to provide proof that they have been tested positively before they can upload their keys. Through this integrated approach, the verification needed for the upload of the diagnosis keys does not require any further action from the users. 
+They only have to confirm in the app and for the Exposure Notification Framework that they agree to share their diagnosis keys. Manual verification is also possible if the lab that performed the testing does not support the direct electronic transmission of test results to the users' mobile phones or if users have decided against the electronic transmission of their test results. 

-Reporting positive tests to the app is crucial for others to get informed about a relevant exposure and potential infection. However, a verification before the upload of any diagnosis keys is required in order to prevent misuse. 
+### Retrieval of Lab Results and Verification Process
+
+Reporting positive tests to the Corona-Warn-App is crucial for informing others about a relevant exposure and potential infection. However, to prevent misuse, a verification is required before diagnosis keys can be uploaded. 
 There are two ways for receiving this verification: 
-1. Use of the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 2, Step 4a). Through this integration, the positive test result is already verified, and the diagnosis keys can be uploaded right after users have given their consent. 
-2. Use of a human-readable token (e.g. a number or a combination of words) and provide this as verification to the app. This token is called teleTAN (see Figure 2, Step 4b).
+1. Using the integrated functionality of the Corona-Warn-App to retrieve the results of a SARS-CoV-2 test from a verification server (see Figure 2, Step 4a). With this integration, the positive test result is already verified and the diagnosis keys can be uploaded right after the users have given their consent. 
+2. Providing a human-readable token, e.g. a number or a combination of words, as verification to the app. This token is called teleTAN (see Figure 2, Step 4b).

 ![Figure 2: Interaction flow for verification process](images/solution_architecture/figure_2.svg "Figure 2: Interaction flow for verification process")

-Both, *Figure 2* and *Figure 3* illustrate the verification process. While *Figure 2* shows the interaction flow of the user, *Figure 3* focuses on the flow and storage of data. Additions to the preexisting 'conventional' process through the introduction of the Corona-Warn-App and the integrated test result retrieval are marked blue in *Figure 2*.
+*Figure 2* and *Figure 3* illustrate the verification process. *Figure 2* shows the interaction flow of the user and *Figure 3* the flow and storage of data. Additions to the preexisting 'conventional' process through the introduction of the Corona-Warn-App and the integrated test result retrieval are marked blue in *Figure 2*.

-This preexisting process for the processing of lab results includes that the doctor requesting the test also receives the results, so patients can be informed in a timely manner. As required by law ([§9 IfSG](https://www.gesetze-im-internet.de/ifsg/__9.html)), the responsible health authority (“Gesundheitsamt”) is notified by the lab about the test results as well. The notifications in case of a positive test includes amongst others name, address and date of birth of the affected patients, so they can be contacted and be informed about the implications of their positive test. This is also represented in step 3 of *Figure 2*.
+This preexisting process for the processing of lab results includes that the doctor requesting the test also receives the results, so patients can be informed in a timely manner. As required by law ([§9 IfSG](https://www.gesetze-im-internet.de/ifsg/__9.html)), the responsible health authority (“Gesundheitsamt”) is notified by the lab about the test results as well. The notifications in case of a positive test includes, amongst others, the name, address, and date of birth of the positively tested individuals, so that they can be contacted and informed about the implications of their positive test. This is also represented in step 3 of *Figure 2*.

 The flow for using the app is as follows, referencing the steps from *Figure 2*:

 - **Step 1:** Users of the Corona-Warn-App (i.e. broadcasting and collecting RPIs)
 	- (1) When a test is conducted, they receive an information flyer with a custom QR code. The code is either created on-site or is already available as a stack of pre-printed QR codes. The QR code contains a globally unique identifier (GUID).
-	- (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1) – if users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before.
-	- (3) When the code is scanned, a web service call (REST) is placed against the Verification Server (*Figure 3*, step 2), linking the phone with the data from the QR code through a registration token, which is generated on the server  (*Figure 3*, step 3) and stored on the phone  (*Figure 3*, step 4).
- **Step 2:** The samples are transported to the lab (together with a “Probenbegleitschein”, which has a machine-readable QR code on it, as well as multiple other barcodes (lab ID, sample IDs).
- **Step 3:** As soon as the test result is available (i.e. the samples have been processed), the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System, together with the GUID from the QR code. The Laboratory Information System hashes the GUID and posts it together with the test result to the Test Result Server through a REST interface (*Figure 3*, step A), which in turn makes it available to the verification server.
- **Step 4a:** After signing up for notifications in step 1, the user’s phone regularly checks the Verification Server for available test results (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed about the availability of information and only after opening the app, the result is displayed, together with recommendations for further actions (see scoping document for more details).
- In case the test returned a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server (see also *Figure 3*, steps 9-13). As then Verification Server does not persist the test result, it is fetched from the Test Result Server once more (*Figure 3*, steps 10-11). The TAN is uploaded together with the diagnosis keys of up to the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 14).
+	- (2) Optionally, they can scan the QR code with the Corona-Warn-App (*Figure 3*, step 1). If users decide against using the test retrieval functionality of the Corona-Warn-App, they still receive their test results through the regular channels explained before.
+	- (3) When the code is scanned, a web service call (REST) is placed against the Verification Server (*Figure 3*, step 2), linking the mobile phone with the data from the QR code through a registration token, which is generated on the server  (*Figure 3*, step 3) and stored on the mobile phone  (*Figure 3*, step 4).
+- **Step 2:** The samples are transported to the lab together with a “Probenbegleitschein” which has a machine-readable QR code on it as well as other barcodes (lab ID, sample IDs).
+- **Step 3:** As soon as the test result is available meaning the samples have been processed, the software running locally in the lab (lab client) transmits the test result to the Laboratory Information System together with the GUID from the QR code. The Laboratory Information System hashes the GUID and posts it together with the test result to the Test Result Server through a REST interface (*Figure 3*, step A), which in turn makes it available to the verification server.
+- **Step 4a:** After signing up for notifications in step 1, the user’s mobile phone regularly checks the Verification Server for available test results (polling, figure 3, steps 5-8). This way, no external push servers need to be used. If results are available, the user is informed that information is available. The result themselves as well as recommendations for further actions are only displayed after the user has opened the app (see the scoping document for more details).
+- If the test returns a positive result, users are asked to upload their keys to allow others to find out that they were exposed. If the users agree, the app retrieves a short-lived token (TAN) from the Verification Server (see also *Figure 3*, steps 9-13). As the Verification Server does not persist the test result, it is fetched from the Test Result Server once more (*Figure 3*, steps 10-11).
+The TAN is used as authorization in the HTTP header of the POST request for upload of the diagnosis keys of the last 14 days to the Corona-Warn-App Server (*Figure 3*, step 14).
 - The Corona-Warn-App Server uses the TAN to verify the authenticity (*Figure 3*, steps 15-17) of the submission with the Verification Server.
-	- The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 16)
+	- The TAN is consumed by the Verification Server and becomes invalid (*Figure 3*, step 16).
 	- If the Corona-Warn-App Server receives a positive confirmation, the uploaded diagnosis keys are stored in the database (*Figure 3*, step 18). 
 	- The TAN is never persisted on the Corona-Warn-App Server.
 	- In case of a failing request, the device receives corresponding feedback to make the user aware that the data needs to be re-submitted.

 ![Figure 3: Data flow for the verification process](images/solution_architecture/figure_3.svg "Figure 3: Data flow for the verification process")

-Note regarding *Figure 3* and *Figure 4*: The white boxes with rounded corners represent data storage. The HTTP method POST is used instead of GET for added security, so data (e.g. the registration token or the TAN) can be transferred in the body.
+Note regarding *Figure 3* and *Figure 4*: The white boxes with rounded corners represent data storage. The HTTP method POST is used instead of GET for added security, so data (e.g. the registration token) can be transferred in the body.

-As mentioned before, users might have decided against retrieving test results electronically or the electronic process might not be supported by the lab. Within step 3 of *Figure 2*, it is shown, that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding positive test results, they can choose to receive a teleTAN. The teleTan is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5), who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17).
+As mentioned before, users might have decided against retrieving test results electronically, or the lab may not support the electronic process. Step 3 of *Figure 2* shows that in these cases the health authority (“Gesundheitsamt”) reaches out to the patient directly. Also during this conversation, the teleTAN can be provided to the patient, which can be used to authorize the upload of diagnosis keys from the app to the Corona-Warn-App Server (step 4b of *Figure 2*). This process is also visualized in *Figure 4*. Whenever patients are contacted regarding a positive test result, they can choose to receive a teleTAN. The teleTan is retrieved from the web interface (*Figure 4*, step 1) of the portal service by a public health officer. This service in turn is requesting it from the Verification Server (2-3). The teleTAN is then issued to the officer (4-5) who transfers it to the patient (6). Once the patient has entered the teleTAN into the app (7), it uses the teleTAN to retrieve a registration token from the Verification Server (8-10). Once the user has confirmed the upload of the Diagnosis Keys, the application requests a TAN from the server, using the registration token (11-13). This TAN is needed by the server to ensure that the device is allowed to do the upload. These TANs are not visible to the user. After uploading the TAN and the diagnosis keys to the Corona-Warn-App Server (14), the Corona-Warn-App Server can verify the authenticity of the TAN with the Verification Server (15-16) and upon receiving a confirmation, store the diagnosis keys in the database (17).

 ![Figure 4: Verification process for teleTAN received via phone](images/solution_architecture/figure_4.svg "Figure 4: Verification process for teleTAN received via phone")

-The retrieval of the registration token, ensures a coupling between a specific phone and a GUID/teleTAN, preventing others (even when they have the QR code) to retrieve test results and/or to generate a TAN for uploading diagnosis keys. Upon the first connection with the Verification Server, a registration token is generated on the server and sent back to the client. The patients should be asked within the information they receive to scan the QR code as soon as possible, as all further communication between client and server only uses the registration token, which can only be created once.
-If a user deletes and re-installs the app, the stored registration token is lost, making it impossible to retrieve the test results. Then, the fallback to the health authority workflow (through a hotline) needs to be used.
-From the perspective of privacy protection, sending push notifications via Apple’s or Google’s push service is not acceptable in this scenario. Even though no specific test results are included in the notifications, the message itself signals that the user has taken a SARS-CoV-2 test. Thus, polling and local notifications is used instead. If a user also decides against local notifications, a manual update of the test results is possible as well.
+The retrieval of the registration token ensures a coupling between a specific mobile phone and a GUID/teleTAN, preventing others (even when they have the QR code) to retrieve test results and/or to generate a TAN for uploading diagnosis keys. Upon the first connection with the Verification Server, a registration token is generated on the server and sent back to the client. In the information they receive, the patients should be asked to scan the QR code as soon as possible, as all further communication between client and server only uses the registration token which can only be created once.
+If a user deletes and reinstalls the app, the stored registration token is lost, making it impossible to retrieve the test results. In this case the fallback with the health authority workflow (through a hotline) needs to be used.
+From a privacy protection perspective, sending push notifications via Apple’s or Google’s push service is not acceptable in this scenario. Even though no specific test results are included in the notifications, the message itself signals that the user has taken a SARS-CoV-2 test. Thus, polling and local notifications are used instead. If a user also decides against local notifications, a manual update of the test results is also possible.

-If a user did not receive a teleTAN from the health authority and/or has lost the QR code, a teleTAN needs to be retrieved from a hotline, which needs to ensure that users are permitted to perform an upload before issuing the teleTAN. It is then used as described before, starting from *Figure 4*, step 7. 
+If a user did not receive a teleTAN from the health authority and/or has lost the QR code, a teleTAN needs to be retrieved from a hotline. The hotline ensures that users are permitted to perform an upload before issuing the teleTAN. It is then used as described before, starting from *Figure 4*, step 7. 

-### Upload schedule for Diagnosis Keys
+### Upload Schedule for Diagnosis Keys

-According to the current state of the documentation from Apple and Google (1.3), the first set of up to 14 Temporary Exposure Keys (called Diagnosis Keys when linked to a positive test) needs to be uploaded after the positive test result becomes available and the consent to the upload has been given (see (1) in *Figure 5*). As the TEK of the current day can still be used to generate new RPIs it cannot be made available right away. If it was uploaded before the end of the day, malicious third parties could use it to generate valid RPIs linked to a positive test. Instead, it is uploaded once replaced by a new TEK (see (2) in *Figure 5*). This upload takes place in the background and require no additional consent, as the framework grants a 24-hour grace period for the request of Diagnosis Keys.
+According to the current version of the documentation from Apple and Google (1.3), the first set of up to 14 Temporary Exposure Keys (TEK; called Diagnosis Keys when linked to a positive test) needs to be uploaded after the positive test result becomes available and the consent to the upload has been given (see (1) in *Figure 5*). As the TEK of the current day can still be used to generate new RPIs, it cannot be made available right away. If it was uploaded before the end of the day, malicious third parties could use it to generate valid RPIs linked to a positive test. Instead, once it is uploaded, it is replaced by a new TEK (see (2) in *Figure 5*). This upload takes place in the background and requires no additional consent as the framework grants a 24-hour grace period for the request of Diagnosis Keys.

 ![Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)](images/solution_architecture/figure_5.svg "Figure 5: Upload schedule for Temporary Exposure Keys (Diagnosis Keys)")

-As there is no requirement for users to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (3) in *Figure 5*). It would require explicit consent of the user for each day and could take place until the person is not considered contagious anymore, but also not longer, as it would lead to false positives. 
+As users are not required to confirm negative test results, the functionality of uploading Diagnosis Keys on subsequent days remains theoretical. Each of those uploads could take place earliest at the end of each subsequent day (see (3) in *Figure 5*). It would require explicit consent of the user for each day and could take place up to the time when the person is not considered contagious anymore (but not any longer, as this would lead to false positives). 

-As of now, two uploads are required from the same phone (past diagnosis keys and the current day): This means, the registration token may not be invalidated after the first upload but must remain active. The TANs sent to the Corona-Warn-App Server are only valid for a single use. In case of the teleTAN, an additional registration token is created, which then allows the application to retrieve TANs for individual uploads.
+As of now, two uploads are required from the same mobile phone (past diagnosis keys and from the current day). This means, the registration token may not be invalidated after the first upload, but must remain active. The TANs sent to the Corona-Warn-App Server are only valid for a single use. In case of the teleTAN, an additional registration token is created which then allows the app to retrieve TANs for individual uploads.

-## Backend
+## Back End

 ![Figure 6: Actors in the system, including external parties (blue components to be open-sourced)](images/solution_architecture/figure_6.svg "Figure 6: Actors in the system, including external parties (blue components to be open-sourced)")

 The Corona-Warn-App Server needs to fulfill the following tasks:
 - Accept upload requests from clients
-	- Verify association with a positive test through the Verification Server and the associated workflow (explained in the chapter “Retrieval of lab results and verification process”, shown in the center of the left side of *Figure 6*).
-	- Accept uploaded diagnosis keys and store them (optional) together with the corresponding transmission risk level parameter (integer value of 1-8) into the database. Note that the transport of metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labelled “Transport Metadata Removal” in *Figure 6*.
+	- Verify association with a positive test through the Verification Server and the associated workflow as explained in the “Retrieval of Lab Results and Verification Process” section and shown in the center of the left side of *Figure 6*.
+	- Accept uploaded diagnosis keys and store them (optional) together with the corresponding transmission risk level parameter (integer value of 1-8) into the database. Note that the transport of metadata (e.g. IP) of the incoming connections for the upload of diagnosis keys is removed in a dedicated actor, labeled “Transport Metadata Removal” in *Figure 6*.
 - Provide [configuration parameters](#data-format) to the mobile applications
 	- Threshold values for [attenuation buckets](#attenuation-buckets)
 	- Risk scores for defined values
 	- Threshold values for risk categories and alerts
 - On a regular schedule (e.g. hourly)
 	- Assemble diagnosis keys into chunks for a given time period
-	- Store chunks as static files (in protocol buffers, compatible with format specified by Apple/Google)
-	- Transfer files to a storage service (shown at the bottom of *Figure 6*), which acts as a source for the Content Delivery Network (CDN)
+	- Store chunks as static files (in protocol buffers, compatible with the format specified by Apple and Google)
+	- Transfer files to a storage service as shown at the bottom of *Figure 6* which acts as a source for the Content Delivery Network (CDN)

-Those tasks are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represent one device with the Corona-Warn-App installed. The user of Phone 1 has taken a SARS-CoV-2 test (which comes back positive later). The users of Phone 2 and Phone n only use the functionality to trace potential exposure.
-The Corona-Warn-App Server represents the outside picture of the individual service working in the backend. For a better understanding, the database has been visualized separately.
+Those tasks are visualized in *Figure 7*. Each of swim lanes (vertical sections of the diagram) on the left side (Phone 1, Phone 2, Phone n) represent one device that has the Corona-Warn-App installed. The user of Phone 1 has taken a SARS-CoV-2 test (which comes back positive later). The users of Phone 2 and Phone n only use the functionality to trace potential exposure.
+The Corona-Warn-App Server represents the outside picture of the individual service working in the back end. For a better understanding, the database has been visualized separately.

-![Figure 7: Interaction of the mobile application(s) with the backend servers and CDN](images/solution_architecture/figure_7.svg "Figure 7: Interaction of the mobile application(s) with the backend servers and CDN")
+![Figure 7: Interaction of the mobile application(s) with the back-end servers and CDN](images/solution_architecture/figure_7.svg "Figure 7: Interaction of the mobile application(s) with the back-end servers and CDN")

-It is to note that even if a user has not been tested positive, the app randomly submits requests to the Corona-Warn-App Server (represented in *Figure 7* by Phone 2), which on the server side can easily be ignored, but from an outside perspective exactly looks, as if a user has uploaded positive test results. This helps to preserve the privacy of users actually submitting their diagnosis keys due to positive test results. If there were no dummy requests, it would be clear to a malicious third party monitoring the traffic, that users uploading something to the server have been infected. With our approach, no pattern can be detected, and no assumption can be taken.
+Note that even if a user has not been tested positive, the app randomly submits requests to the Corona-Warn-App Server (represented in *Figure 7* by Phone 2) which on the server side can easily be ignored, but from an outside perspective exactly looks as if a user has uploaded positive test results. This helps to preserve the privacy of users who are actually submitting their diagnosis keys due to positive test results. Without dummy requests, a malicious third party monitoring the traffic could easily find out that users uploading something to the server have been infected. With our approach, no pattern can be detected and, thus, no assumption can be taken.

 If diagnosis keys need to be uploaded on subsequent days of the submission of a positive test result, also that behavior should be represented within the random (dummy) submissions.

-The possibility to identify temporary exposure keys belonging together (i.e. to the same user) is given, as they are posted together – resulting in them being in a sequential order in the database.
-To prevent this, the aggregated files will be shuffled, e.g. by using an ORDER BY RANDOM on the database side while fetching the data for the corresponding file.
+It could be possible to identify temporary exposure keys that belong together, i.e. belong to the same user, because they are posted together which results in them being in a sequential order in the database.
+To prevent this, the aggregated files are shuffled, e.g. by using an ORDER BY RANDOM on the database while fetching the data for the corresponding file.
 Alternatively, returning them in the lexicographic order of the RPIs (which are random) is a valid option as well. The latter might be more efficient for compressing the data afterwards.

 The configuration parameters mentioned above allow the health authorities to dynamically adjust the behavior of the mobile applications to the current epidemiological situation. For example, the risk score thresholds for the risk levels can be adjusted, as well as how the individual data from exposure events influence the overall score.
 
-Further information can be found in the dedicated architecture documents for the Corona-Warn-App Server, the Verification Server and the Portal Server. The documents will be linked here, as soon as they are available. 
+Further information can be found in the dedicated architecture documents for the Corona-Warn-App Server, the Verification Server, and the Portal Server. The documents will be linked here, as soon as they are available. 

-### Data format
+### Data Format

-The current base unit for data chunks will be one hour. Data will be encoded in the protocol buffer format, as specified by Apple/Google (see *Figure 8*). It is planned, that in case a data chunk does not hold any or too little diagnosis keys, the chunk generation will be skipped.
+The current base unit for data chunks will be one hour. Data will be encoded in the protocol buffer format as specified by Apple and Google (see *Figure 8*). It is planned that in case a data chunk does not hold any or too few diagnosis keys, the chunk generation will be skipped.

 The server will make the following information available through a RESTful interface:
- available items through index endpoints (not all implemented in first iteration)
- the newly added Diagnosis Keys (Temporary Exposure Keys) for the time frame
- configuration parameters
+- Available items through index endpoints (not all implemented in first iteration)
+- Newly-added Diagnosis Keys (Temporary Exposure Keys) for the time frame
+- Configuration parameters
 	- 32 parameters for configuring the risk score of the Apple/Google Exposure Notification Framework
 	- [Attenuation bucket](#attenuation-buckets) thresholds
 	- Risk score threshold to issue a warning
@ -147,7 +151,7 @@ The server will make the following information available through a RESTful inter

 Return data needs to be signed and will contain a timestamp (please refer to protocol buffer files for further information). Using index endpoints will not increase the number of requests, as they can be handled within a single HTTP session. In case the hourly endpoint does not hold diagnosis keys for the selected hour, the mobile application does not need to download it. If, on the other hand multiple files need to be downloaded (e.g. because the client was switched off overnight), they can be handled in a single session as well.

-In order to ensure the authenticity of the files, they need to be signed (according to the specifications of the API) on a server side with a private key, while the mobile application use the public key to verify that signature. To ensure roaming qualities (protocol interoperability with servers in other geographical regions) the plan is to move to a single agreed protocol once finally defined.
+In order to ensure the authenticity of the files, they need to be signed (according to the specifications of the API) on server side with a private key, while the app uses the public key to verify that signature. To ensure roaming qualities (protocol interoperability with servers in other geographical regions), it is planned to move to a single agreed protocol once finally defined.

 ![Figure 8: Data format (protocol buffer) specified by Apple/Google](images/solution_architecture/figure_8.svg "Figure 8: Data format (protocol buffer) specified by Apple/Google")

@ -155,27 +159,29 @@ In order to ensure the authenticity of the files, they need to be signed (accord

 Retrieving the data in a RESTful format, making it clearer to make it available through a transparent CDN (only requesting the files once). 

-If no diagnosis keys are available for the selected parameters, but the time frame has already passed, a signed payload with a timestamp and an empty list of diagnosis keys is returned. As also this file is signed by the server (and is different from other files without diagnosis keys, through the timestamp), its authenticity can be verified.
+If no diagnosis keys are available for the selected parameters, but the time frame has already passed, a signed payload with a timestamp and an empty list of diagnosis keys is returned. As this file is also signed by the server and, through the timestamp, is also different from other files without diagnosis keys, its authenticity can be verified.

 Further details of the API are explained in the documentation of the Corona-Warn-App Server.

-### Data retention
+### Data Retention

-The data on the all involved servers will only be retained as long as required. Diagnosis Keys will be removed from Corona-Warn-App Server once they refer to a period more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the test result server, as otherwise a second upload privilege (i.e. a registration token) could be fetched with the same GUID.
+The data on all involved servers is only retained as long as required. Diagnosis Keys will be removed from the Corona-Warn-App Server when they refer to a period of more than 14 days ago. TANs on the Verification Server will be removed as soon as they have been used. The hashed GUID on the Verification Server needs to be retained as long as the GUID can be used to retrieve test results from the test result server. Otherwise, a second upload privilege, i.e. a registration token, could be fetched with the same GUID.

 ## MOBILE APPLICATIONS

-The functional scope of the mobile applications is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The applications will be developed natively for Apple’s iOS and Google’s Android operating system. They will make use of the respective interfaces for the exposure notification (i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 9*). For Apple devices (starting from _<to be determined>_) an OS version of at least 13.5 will be required for the system to work, as the framework is integrated into the operating system.
+The functional scope of the mobile applications (apps) is defined in the corresponding [scoping document](https://github.com/corona-warn-app/cwa-documentation/blob/master/scoping_document.md). The apps are developed natively for Apple’s iOS and Google’s Android operating systems. They make use of the respective interfaces for the exposure notification, i.e. broadcasting and scanning for Bluetooth advertisement packages, see *Figure 9*.

-For Android, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android 6.0 (API version 23) and integrated BLE chips will be [supported](https://static.googleusercontent.com/media/www.google.com/de//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf).
+For Apple devices (starting from _<to be determined>_), an OS version of at least 13.5 will be required for the system to work, as the framework is integrated into the operating system.
+
+For Android devices, the features will be integrated into the [Google Play Services](https://9to5google.com/2020/04/13/android-contact-tracing-google-play-services/), which means that only this specific application needs to be updated for it to work. Devices starting with Android 6.0 (API version 23) and integrated BLE chips will be [supported](https://static.googleusercontent.com/media/www.google.com/de//covid19/exposurenotifications/pdfs/Android-Exposure-Notification-API-documentation-v1.3.2.pdf).

 ![Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)](images/solution_architecture/figure_9.svg "Figure 9: Architecture overview of the mobile application (focused on API usage/BLE communication)")

-The app itself does not have access to the exposures collected (i.e. the Rolling Proximity Identifiers), neither is it informed if a new one has been collected by the framework. As visible in figures *Figure 10* and *Figure 11*, the Exposure Notification encapsulates handling of the keys, including all cryptographic operations on them. The only output of the black box upon an infection is a collection of temporary exposure keys, as shown in *Figure 10*. Those are subsequently called diagnosis key.
+The app itself does not have access to the collected exposures, i.e. the Rolling Proximity Identifiers, and neither is it informed if a new one has been collected by the framework. As depicted in the *Figure 10* and *Figure 11*, the Exposure Notification encapsulates handling of the keys, including all cryptographic operations on them. The only output of the black box upon an infection is a collection of temporary exposure keys as shown in *Figure 10*. Those are subsequently called diagnosis keys.

 ![Figure 10: Key flow from the sending perspective (as described in the specification by Apple/Google)](images/solution_architecture/figure_10.svg "Figure 10: Key flow from the sending perspective (as described in the specification by Apple/Google)")

-The encapsulation especially applies to the part where matches are calculated, as the framework only accepts the diagnosis keys as input, matches them to (internally stored) RPIs and returns a list of exposure events – without a link to the corresponding Rolling Proximity Identifiers (see *Figure 11*). With the use of the corresponding Associated Encrypted Metadata Key, the Associated Encrypted Metadata (AEM) of the captured RPI can be decrypted. This metadata contains the transmission power (which is used to calculate the attenuation). Additionally, an epoch (usually a 24 hour window) for the exposure is determined, as well as the duration of the exposure in 5-minute increments (capped at 30 minutes).
+The encapsulation especially applies to the part where matches are calculated, as the framework only accepts the diagnosis keys as input, matches them to (internally stored) RPIs and returns a list of exposure events without a link to the corresponding Rolling Proximity Identifiers (see *Figure 11*). With the use of the corresponding Associated Encrypted Metadata Key, the Associated Encrypted Metadata (AEM) of the captured RPI can be decrypted. This metadata contains the transmission power (which is used to calculate the attenuation). Additionally, an epoch (usually a 24 hour window) for the exposure is determined, as well as the duration of the exposure in 5-minute increments (capped at 30 minutes).

 ![Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)](images/solution_architecture/figure_11.svg "Figure 11: Key flow from the receiving perspective (as described in the specification by Apple/Google)")

@ -190,38 +196,55 @@ The encapsulation especially applies to the part where matches are calculated, a
 ### Attenuation Buckets

 Both, Apple and Google allow to define a low and a high threshold for the attenuation, forming three individual buckets:
- attenuation < low threshold
- low threshold <= attenuation < high threshold
- high threshold <= attenuation
+- Attenuation < low threshold
+- Low threshold <= attenuation < high threshold
+- High threshold <= attenuation

-While in the Google implementations of the Exposure Notification framework, those buckets are contained within the `ExposureSummary` (`attenuationDurations`), Apple has added them to the [`metadata`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586326-metadataenexposureinfo) attribute of the [`ENExposureInfo`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo).
+While in the Google implementation of the Exposure Notification Framework, those buckets are contained within the `ExposureSummary` (`attenuationDurations`), Apple has added them to the [`metadata`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586326-metadataenexposureinfo) attribute of the [`ENExposureInfo`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo).
 In the latter implementation, the [`attenuationDurations`](https://developer.apple.com/documentation/exposurenotification/enexposureinfo/3586325-attenuationdurations) of the `ENExposureInfo` contains two buckets around a fixed threshold of 50.

-### Risk score calculation
+### Risk Score Calculation

-The information listed above is not visible to the user, but is used internally to calculate a risk score, which again is mapped to one specific app-defined risk level. This easy to understand risk level is displayed to the user. Further information regarding the individual exposure events (such as the matched Rolling Proximity Identifier, the Temporary Exposure Key or the exact time) remains within the secure storage of the framework and cannot be retrieved by the application.
+The information listed above is not visible to the user, but is used internally to calculate a risk score, which again is mapped to one specific app-defined risk level. This easy-to-understand risk level is displayed to the user. Further information regarding the individual exposure events (such as the matched Rolling Proximity Identifier, the Temporary Exposure Key or the exact time) remains within the secure storage of the framework and cannot be retrieved by the application.

-![Figure 12: Calculation of the risk](images/solution_architecture/figure_12.svg "Figure 12: Calculation of the risk")
+![Figure 12: Risk calculation](images/solution_architecture/figure_12.svg "Figure 12: Risk calculation")

-*Figure 12* displays how the total risk score is being calculated. The application is provided with a set of parameters, which are marked in blue within the figure. Each risk category (days since exposure, exposure duration, weighted signal attenuation and the transmission risk factor) receives an input value from the event, which is then mapped to a pre-defined value range. According to the [documentation of the framework](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration), "the attenuation is weighted by the duration at each risk level and averaged for the overall duration". 
-Each of those value ranges gets assigned a risk score from 0-8, where 0 represents a very low risk and 8 represents a very high risk. This means that from each of the rows in the figure, one value is selected according to the input value for the corresponding category. The product of risk scores is the total risk score, which is used to determine, which defined risk level should be displayed to the user (e.g. “low risk” or “high risk”). For this decision, app-defined thresholds for the individual risk levels apply. 
-As all values are multiplied, a single category with a risk score of 0 means that also the overall risk score will be 0. Additionally, a central risk threshold specifies, when the user shall be explicitly notified about an exposure event.
+*Figure 12* displays how the total risk score is being calculated. The application is provided with a set of parameters, which are marked in blue within the figure. 
+Those parameters are regularly downloaded from the CWA Server, which means they can be modified without requiring a new version of the application. 
+Each risk category (days since exposure, exposure duration, weighted signal attenuation, and the transmission risk factor) receives an input value from the event which is then mapped to a predefined value range. 
+According to the [documentation of the framework](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration), "the attenuation is weighted by the duration at each risk level and averaged for the overall duration". 
+Each of those value ranges is assigned a risk score from 0-8, where 0 represents a very low risk and 8 represents a very high risk. This means that from each of the rows in the figure, one value is selected according to the input value for the corresponding category. The product of the risk scores is used as the **total risk score** of the individual exposure.

-Note that the transmission risk level plays a special role: It can be defined by the app and be associated with each individual diagnosis key (i.e. specific for each day of an infected person) that is being sent to the server. It contains a value from 1 to 8, which can be used to represent a calculated risk defined by the health authority.
+In order to incorporate the time spent within the ranges of attenuation buckets mentioned before, each of those three buckets is assigned a weight value as shown in *Figure 13*.
+ The individual time values are multiplied with their according weight (*weight_1*, *weight_2* and *weight_3*). 
+ Their sum and a default bucket offset (called *weight_4* in *Figure 13*) forms the *Exposure Score*. 
+ The *total risk score* provided by the Exposure Notification Framework is then normalized and multiplied with the exposure score, resulting in the combined risk score.

-### Data transfer and data processing
+The combined risk score is used to determine which defined risk level should be displayed to the user, e.g. “low risk” or “high risk”. For this decision, app-defined thresholds for the individual risk levels apply. 
+As the values above are multiplied with each other, a single category with a risk score of 0 means that the overall risk score is also 0. 
+Additionally, a central threshold for the combined risk score specifies whether an exposure event should be considered or not. 
+Furthermore the Google/Apple framework allows to set a [```minimalRiskScore```](https://developer.apple.com/documentation/exposurenotification/enexposureconfiguration/3583692-minimumriskscore) to exclude exposure incidents with scores lower than the value of this property. 
+In the current version of the API the time spent within the ranges of attenuation buckets are accumulated over all exposure incidents during one matching session. 
+Since the number of requests is currently limited, it is not possible to get these values for each day and each exposure incident separately. 
+While by default there is no minimum value set, this value is being configured accordingly, so that resumably irrelevant exposure incidents are excluded. 
+
+![Figure 13: Calculation of the combined risk score](images/solution_architecture/figure_13.svg "Figure 13: Calculation of the combined risk score")
+
+Note that the transmission risk level plays a special role: It can be defined by the app and be associated with each individual diagnosis key (i.e. specific for each day of an infected person) that is being sent to the server. It contains a value from 1 to 8, which can be used to represent a calculated risk defined by the health authority and estimates the infectiousness and hence the likelihood of transmitting the disease.
+
+### Data Transfer and Data Processing

 In order to be able to regularly match the RPIs associated with positive tests (derived from Diagnosis Keys) against the RPIs stored in the framework, the mobile applications need to download the former regularly.

-In order to prevent load peaks at the backend, the downloads need to be spread evenly across the set time interval (currently an hour). To achieve that, each client needs to randomly decide on a point of time within the given hour, when it will download the data. With a large number of clients, this should statistically lead to an even distribution of requests.
+In order to prevent load peaks in the back end, the downloads need to be spread evenly across the set time interval (currently an hour). To achieve that, each client needs to randomly decide on a point of time within the given hour, when it will download the data. With a large number of clients, this should statistically lead to an even distribution of requests.

-However, [Apple’s background tasks](https://developer.apple.com/documentation/backgroundtasks) don’t allow a specific point of time, when the download task shall be distributed, but instead only let the developer define a [minimum time interval](https://developer.apple.com/documentation/backgroundtasks/bgtaskrequest/3142244-earliestbegindate) after which the tasks should be executed. Even though exact execution times cannot be guaranteed, we expect a behavior as specified above. 
+However, [Apple’s background tasks](https://developer.apple.com/documentation/backgroundtasks) don’t allow a specific point of time when the download task shall be distributed, but instead only let the developer define a [minimum time interval](https://developer.apple.com/documentation/backgroundtasks/bgtaskrequest/3142244-earliestbegindate) after which the tasks should be executed. Even though exact execution times cannot be guaranteed, we expect a behavior as specified above. 

-To ensure that not more requests are made than being absolute necessary, the earliest point in time should be at the beginning of the next availability interval. A random number should be added to ensure that the earliest start dates are spread evenly across all clients. For an hourly interval this could be calculated as follows:
+To ensure that as few requests as absolutely necessary are made, the earliest point in time should be at the beginning of the next availability interval. A random number should be added to ensure that the earliest start dates are spread evenly across all clients. For an hourly interval this could be calculated as follows:

 `minimum seconds until execution = (seconds until beginning of next interval) + random(3600)`

-In some scenarios it is possible that a client has been unable to retrieve data for one or more intervals. This might be due to the device being turned off, background activations not firing automatically (e.g. during the night, as described above) or unavailability of an internet connection. It is very important, that the client ensures that after one of those breaks, all available data is being caught up to – a match for the last 14 days might be contained.
+In some scenarios, it is possible that a client has been unable to retrieve data for one or more intervals. This might be due to the device being turned off, background activations not firing automatically (e.g. during the night, as described above), or unavailability of an internet connection. It is very important that the client ensures that after one of those breaks, all available data is being caught up to and a match for the last 14 days might be contained.

 In case the download of the diagnosis keys and the exposure detection configuration from the server fails, the client application needs to retry gracefully, i.e. use a random time component for the retry, as well as extending retry intervals. However, it needs to be ensured that all diagnosis keys are downloaded from the server. Otherwise, possible matches could be skipped.

@ -229,28 +252,28 @@ Further details can be found in the dedicated architecture documents for the mob

 ## RUNTIME ENVIRONMENT (HOSTING)

-The backend will be made available through the [Open Telekom Cloud (OTC)](https://open-telekom-cloud.com/).
+The back end will be made available through the [Open Telekom Cloud (OTC)](https://open-telekom-cloud.com/).

-For the operation of the backend, several bandwidth estimations need to be taken. As a high adoption rate of the app is an important requirement, we are considering up to 60 million active users.
+For the operation of the back end, several bandwidth estimations need to be taken. As a high adoption rate of the app is an important requirement, we are considering up to 60 million active users.

-### Bandwidth estimations
+### Bandwidth Estimations

-While each set of 14 diagnosis keys only has the small size of 392 Byte, all newly submitted diagnosis keys of a time period need to be downloaded by all mobile phones having the application installed. When considering 2000 new cases for a day, a transmission overhead (through headers, handshakes, failed downloads, etc.) of 100% and 30 million clients, this adds up to approximately 1.5MB per client, i.e. **42.8TB** overall traffic. If a day is split into 24 chucks (one per hour), this results in a total number of **720 million requests per day**. If the requests are evenly spread throughout the corresponding hour, approximately **8,500 session requests** per second need to be handled. Detailed descriptions of the connections can be found in the chapter ["Data transfer and data processing"](#data-transfer-and-data-processing). Those number exclude possible interoperability with other countries.
+While each set of 14 diagnosis keys only has the small size of 392 bytes, all newly submitted diagnosis keys of a time period need to be downloaded by all mobile phones having the application installed. When considering 2000 new cases for a day, a transmission overhead (through headers, handshakes, failed downloads, etc.) of 100% and 30 million clients, this adds up to approximately 1.5MB per client, i.e. **42.8TB** of overall traffic. If a day is split into 24 chunks (one per hour), this results in a total number of **720 million requests per day**. If the requests are evenly spread throughout the corresponding hour, approximately **8,500 session requests** per second need to be handled. Detailed descriptions of the connections can be found in the chapter ["Data transfer and data processing"](#data-transfer-and-data-processing). Those number exclude possible interoperability with other countries.

-If the backend calls from the mobile applications cannot be spread as evenly as we expect, we might experience peaks. To achieve an even spread (and to be able to handle a peak), we will employ a Content Delivery Network (CDN) by T-Systems to make the individual aggregated files available. According to an evaluation with T-Systems, the estimated throughput and request number can be handled by their infrastructure.
+If the back end calls from the mobile applications cannot be spread as evenly as we expect, we might experience peaks. To achieve an even spread (and to be able to handle a peak), we will employ a Content Delivery Network (CDN) by T-Systems to make the individual aggregated files available. According to an evaluation with T-Systems, the estimated throughput and request number can be handled by their infrastructure.

-## Cross-border interoperability
+## Cross-Border Interoperability

-A definite prerequisite for compatibility is, that the identifiers of the mobile devices can be matched, i.e. the framework by Apple/Google is being used. 
+A definite prerequisite for compatibility is that the identifiers of the mobile devices can be matched, i.e. the framework by Apple and Google is being used. 

 Further details will be added as soon as they are available.

 ## LIMITATIONS

-Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positively later on, the system also has limits (shown in *Figure 13*), which needs to be considered. One of those limitations is, that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those [listening windows are currently up to five minutes](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) apart and are defined as being only very short. In our considerations we expect the windows to have a length of two to four seconds. For the attenuation, the two buckets provided by the framework are being considered. A lower attenuation means that the other device is closer; we assume that an attenuation <50dB translates to a distance below two meters. A higher attenuation might either mean that the other device is farther away (i.e. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall), but humans or animals also.
+Even though the system can support individuals in finding out whether they have been in proximity with a person that has been tested positively later on, the system also has limits (shown in *Figure 14*) that need to be considered. One of those limitations is that while the device constantly broadcasts its own Rolling Proximity Identifiers, it only listens for others in defined time slots. Those [listening windows are currently up to five minutes](https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf) apart and are defined as being only very short. In our considerations we expect the windows to have a length of two to four seconds. For the attenuation, the two buckets provided by the framework are being considered. A lower attenuation means that the other device is closer; we assume that an attenuation <50dB translates to a distance below two meters. A higher attenuation might either mean that the other device is farther away (i.e. a distance of more than two meters) or that there is something between the devices blocking the signal. This could be objects such as a wall, but also humans or animals.

-![Figure 13: Limitations of the Bluetooth Low Energy approach](images/solution_architecture/figure_13.svg "Figure 13: Limitations of the Bluetooth Low Energy approach")
+![Figure 14: Limitations of the Bluetooth Low Energy approach](images/solution_architecture/figure_14.svg "Figure 14: Limitations of the Bluetooth Low Energy approach")

-In *Figure 13*, this is visualized, while focusing on the captured Rolling Proximity Identifiers by only a single device. We are assuming that devices broadcast their own RPI every 250ms and use listening windows with a length of two seconds, five minutes apart. There are five other active devices – each representing a different kind of possible exposure. In the example, devices 3 and 4 go completely unnoticed, while a close proximity with the user of device 2 cannot be detected. In contrast to that very brief, but close connection with the user of device 5 (e.g. only brushing the other person in the supermarket) is noticed and logged accordingly. The duration and interval of scanning needs to be balanced by Apple and Google against battery life, as more frequent scanning consumes more energy.
+In *Figure 14*, this is visualized, while focusing on the captured Rolling Proximity Identifiers by only a single device. We are assuming that devices broadcast their own RPI every 250ms and use listening windows with a length of two seconds, five minutes apart. There are five other active devices – each representing a different kind of possible exposure. In the example, devices 3 and 4 go completely unnoticed, while a close proximity with the user of device 2 cannot be detected. In contrast to that very brief, but close connection with the user of device 5 (e.g. only brushing the other person in the supermarket) is noticed and logged accordingly. The duration and interval of scanning needs to be balanced by Apple and Google against battery life, as more frequent scanning consumes more energy.

-It must be noted, that some of the encounters described above are corner cases. While especially the cases with a very short proximity time cannot be detected due to technical limitations, the framework will be able to detect longer exposures. As only exposures of longer duration within a certain proximity range are considered relevant for the intended purpose of this app, most of them will be covered.
+It must be noted that some of the encounters described above are corner cases. While especially the cases with a very short proximity time cannot be detected due to technical limitations, the framework will be able to detect longer exposures. As only exposures of longer duration within a certain proximity range are considered relevant for the intended purpose of this app, most of them will be covered.
--- a/translations/scoping_document.de.md
+++ b/translations/scoping_document.de.md
@ -7,7 +7,7 @@
    1.  [Übersicht der Epics](#übersicht-der-epics)
    2.  [Übersicht der User Stories](#übersicht-der-user-stories)
          1.  [Anbahnung und Installation (Onboarding-Prozess)](#anbahnung-und-installation-onboarding-prozess)
-          2.  [Informationen und Instruktionen zur Nutzung der Applikation](#informationen-und-instruktionen-zur-nutzung-der-applikation)
+          2.  [Informationen und Instruktionen zur Nutzung der App](#informationen-und-instruktionen-zur-nutzung-der-app)
          3.  [Nutzung im Regelprozess](#nutzung-im-regelprozess)
          4.  [Kontaktfall (Begegnung mit infizierter Person)](#kontaktfall-begegnung-mit-infizierter-person)
          5.  [Covid-19-Testergebnismeldung](#covid-19-testergebnismeldung)
@ -48,7 +48,7 @@ Stellt epidemiologische Informationen und Handlungsempfehlungen für die Bedienu
 ## User Journey
 Die Nutzung der App wird aufgrund von nacheinander stattfindenden Kontakt-Ereignissen und Interaktionen von Personen in verschiedene Phasen eingeteilt. Zu jeder Phase sind den Personen Motivationen oder Anforderungen zugeordnet, die ihre Erwartungen an die Funktionsweise erfüllen und intuitiv durch den Prozess leiten.

-![Abbildung 5: User Journey](user_journey.de.png "User Journey")
+![Abbildung 1: User Journey](user_journey.de.png "User Journey")

 #### Phase *Idee*
 In dieser Phase entscheidet eine Person, sich über die App zu informieren. Das kann über unterschiedliche Quellen erfolgen. In dieser Phase haben die Personen ggf. verschiedene Fragestellungen zur Nutzung der App (Anwendung, Datenschutz, Barrierefreiheit etc.). Diese sollen bereits vor dem Download beantwortet werden können (Hotline, Informationen auf Internetseiten des RKI und des BMG, App Store/Google Play Store).
@ -79,15 +79,16 @@ Die Phase der Anwendung ist in vier weitere Bereiche unterteilt, in welchen die
 Eine Person kann die App jederzeit deinstallieren. Alle in der App gespeicherten Daten werden vollständig gelöscht.

 # FUNKTIONSBESCHREIBUNG
+
 ## Übersicht der Epics
-Die Funktionen der Applikation sind in Prozessphasen der Nutzung (mit direktem Bezug zur User Journey) und übergreifende Unterstützungsprozesse unterteilt. Eine Übersicht der Epics ist nachfolgend dargestellt:
+Die Funktionen der App sind in Prozessphasen der Nutzung (mit direktem Bezug zur User Journey) und übergreifende Unterstützungsprozesse unterteilt. Eine Übersicht der Epics ist nachfolgend dargestellt:

 #### Prozessphasen der Nutzung
 | #  |   Epic | Beschreibung |
 |---:|--------|--------------|
-|  1 | Anbahnung und Installation (Onboarding-Prozess) | Sämtliche Prozesse, die insbesondere bei erstmaliger Nutzung der Applikation erfolgen (z.B. Zustimmung Datenschutz, Sprachauswahl)
-|  2 | Informationen und Instruktionen zur Nutzung der Applikation | Hilfestellungen zur Nutzung der Applikation (z.B. Anwendungshandbuch, Tutorial) sowie Informationen zum Impressum der Applikation
-|  3 | Nutzung im Regelprozess | Funktionen der Applikation im "idle mode" (z.B. Aktivierung/Deaktivierung, Anpassung von Einstellungen, Überwachung von App-Aktivität)
+|  1 | Anbahnung und Installation (Onboarding-Prozess) | Sämtliche Prozesse, die insbesondere bei erstmaliger Nutzung der App erfolgen (z.B. Zustimmung Datenschutz, Sprachauswahl)
+|  2 | Informationen und Instruktionen zur Nutzung der App | Hilfestellungen zur Nutzung der App (z.B. Anwendungshandbuch, Tutorial) sowie Informationen zum Impressum der App
+|  3 | Nutzung im Regelprozess | Funktionen der App im "idle mode" (z.B. Aktivierung/Deaktivierung, Anpassung von Einstellungen, Überwachung von App-Aktivität)
 |  4 | Kontaktfall (Begegnung mit infizierter Person) | Funktionen rund um Kontaktpunkte (z.B. Benachrichtigungen, Handlungsempfehlungen)
 |  5 | Covid-19-Testergebnismeldung | Funktionen im Zusammenhang mit der Testergebnismeldung
 |  6 | Auslösung einer Warnung | Prozess zur Auslösung einer Warnung im Falle eines positiven Testergebnisses
@ -98,83 +99,83 @@ Die Funktionen der Applikation sind in Prozessphasen der Nutzung (mit direktem B
 |  7 | Parametrisierung | Parameter der Kontaktpunktdefinition
 |  8 | Technische Unterstützung | Support-Prozesse (z.B. Hotlines)
 |  9 | Barrierefreiheit | Apps von Trägern öffentlicher Gewalt müssen dem Behindertengleichstellungsgesetz (BGG) nach barrierefrei sein (§ 12). Apps sollen von allen Menschen mit Behinderungen bedient werden können.
-| 10 | Content-Management | Zur Anpassung und Aktualisierung von Inhalten in der Applikation (Texte, Links, Hotlines etc.)
+| 10 | Content-Management | Zur Anpassung und Aktualisierung von Inhalten in der App (Texte, Links, Hotlines etc.)

 ## Übersicht der User Stories
 Die Anforderungen an die Corona-Warn-App, die den fachlichen Umfang der Anwendung definieren, sind nachfolgend in der üblichen Form aus Sicht der nutzenden Personen formuliert, sofern nicht anders angegeben:

-_„Als \<Stakeholder> möchte ich <Handlung durchführen>, um <gewünschtes Ergebnis zu erzielen>.“_
+_„Als &lt;Stakeholder&gt; möchte ich &lt;Handlung durchführen&gt;, um &lt;gewünschtes Ergebnis zu erzielen&gt;.“_

 Die zugehörigen Akzeptanzkriterien ergänzen die Spezifikation der Anforderungen, indem sie Bedingungen definieren, die die Software erfüllen muss, um die Bedürfnisse der nutzenden Personen zu befriedigen.

 ### Anbahnung und Installation (Onboarding-Prozess)
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E01.01          | Bei der Nutzung der App möchte ich beim erstmaligen Start der Applikation eine Einleitung zur Funktionsweise der Applikation erhalten (App-Motivation). | 1. Einführung in die Funktionsweise der App wird bei erstmaligem Start der Applikation angezeigt. <hr/> 2. Einführung in die Funktionsweise der App wird bei weiteren Startvorgängen nicht angezeigt. <hr/> 3. Die erklärenden Inhalte sind in den jeweiligen Funktionsbereichen zur Nutzung vorhanden.
-| E01.02          | Bei der Nutzung der App möchte ich beim erstmaligen Start der Applikation über die Nutzungsbedingungen und Datenschutzbestimmungen (Data Protection Screen) informiert werden und meine Zustimmung geben, um über den Umgang mit meinen Daten innerhalb der Anwendung aufgeklärt zu sein. | 1. Mit Nutzung der App akzeptiert die Person die Nutzungsbedingungen und Datenschutzbestimmungen. <hr/> 2. Die Nutzungsbedingungen sind innerhalb der App einsehbar. <hr/> 3 Die Abfrage erfolgt nur bei der erstmaligen Nutzung.
-| E01.03          | Bei der erstmaligen Nutzung der App möchte ich gefragt werden, ob ich der Erstellung pseudonymer IDs und deren Aussendung an Geräte in meiner Nähe durch die App zustimme, damit ich über die Funktionsweise der Applikation informiert bin. | 1. Eine Bestätigung der Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe durch die Applikation ist Voraussetzung für die App-Nutzung. <hr/> 2. Nach der erstmaligen Nutzung erfolgt die Abfrage nicht.
-| E01.04          | Bei der erstmaligen Nutzung der App möchte ich gefragt werden, ob die Applikation auf die Bluetooth-Funktion des Smartphones zugreifen darf, damit ich die mobiltelefonseitige Nutzung der Applikation kontrollieren kann. | 1. Eine Bestätigung der Bluetooth-Nutzung (BLE) erfolgt durch die Nutzung der Applikation.
-| E01.05          | Bei der erstmaligen Nutzung der App möchte ich gefragt werden, ob die Applikation mir Benachrichtigungen schicken darf, damit in verschiedenen Situationen Push-Notifications ausgegeben werden können. | 1. Eine Abfrage zu den Benachrichtigungseinstellungen der Applikation findet vor erstmaliger Nutzung statt. <hr/> 2. Nach der erstmaligen Nutzung erfolgt die Abfrage nicht.
-| E01.06          | Bei der erstmaligen Nutzung der App möchte ich meine Sprache angezeigt bekommen, damit die Nutzung der App für mich verständlich ist. | 1. Erkennung der eingestellten Systemsprache wird durchgeführt. <hr/> 2. Wenn die erkannte Systemsprache nicht im Content hinterlegt ist, wird im Default Englisch ausgewählt. <hr/> 3. In der ersten Version der App ist Mehrsprachigkeit vorgesehen.
-| E01.07          | Bei der Nutzung der App möchte ich bereits während des Onboardings Hilfen und Einstellungen zur Barrierefreiheit bekommen, um die App nutzen zu können. | 1. Die Barrierefreiheit wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
+| E01.01          | Als Person, die die App nutzt, möchte ich beim erstmaligen Start der App eine Einleitung zur Funktionsweise der App erhalten (App-Motivation). | 1. Einführung in die Funktionsweise der App wird bei erstmaligem Start der App angezeigt. <hr/> 2. Einführung in die Funktionsweise der App wird bei weiteren Startvorgängen nicht angezeigt. <hr/> 3. Die erklärenden Inhalte sind in den jeweiligen Funktionsbereichen zur Nutzung vorhanden.
+| E01.02          | Als Person, die die App nutzt, möchte ich beim erstmaligen Start der App über die Nutzungsbedingungen und Datenschutzbestimmungen (Data Protection Screen) informiert werden und meine Zustimmung geben, um über den Umgang mit meinen Daten innerhalb der App aufgeklärt zu sein. | 1. Mit Nutzung der App akzeptiert die Person die Nutzungsbedingungen und Datenschutzbestimmungen. <hr/> 2. Die Nutzungsbedingungen sind innerhalb der App einsehbar. <hr/> 3 Die Abfrage erfolgt nur bei der erstmaligen Nutzung.
+| E01.03          | Als Person, die die App nutzt, möchte ich bei der erstmaligen Nutzung der App gefragt werden, ob ich der Erstellung pseudonymer IDs und deren Aussendung an Geräte in meiner Nähe durch die App zustimme, damit ich über die Funktionsweise der App informiert bin. | 1. Eine Bestätigung der Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe durch die App ist Voraussetzung für die App-Nutzung. <hr/> 2. Nach der erstmaligen Nutzung erfolgt die Abfrage nicht.
+| E01.04          | Als Person, die die App nutzt, möchte ich bei der erstmaligen Nutzung der App gefragt werden, ob die App auf die Bluetooth-Funktion des Smartphones zugreifen darf, damit ich die mobiltelefonseitige Nutzung der App kontrollieren kann. | 1. Diese User Story ist gleichbedeutend mit E01.03. Die Berechtigung zur Nutzung der Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe beinhaltet die Nutzung von Bluetooth Low Energy (BLE) bereits. <hr/> 2. Die Einstellungen für die generellen Bluetooth-Funktionalitäten sind nur in den Systemeinstellungen möglich.
+| E01.05          | Als Person, die die App nutzt, möchte ich bei der erstmaligen Nutzung der App gefragt werden, ob die App mir Benachrichtigungen schicken darf, damit in verschiedenen Situationen Push-Notifications ausgegeben werden können. | 1. Eine Abfrage zu den Benachrichtigungseinstellungen der App findet vor der erstmaligen Nutzung statt. Es können damit lokale Benachrichtigungen erhalten werden. Echte Push-Notifications von externen Servern werden nicht unterstützt (APNs/FCM). <hr/> 2. Nach der erstmaligen Nutzung erfolgt die Abfrage nicht.
+| E01.06          | Als Person, die die App nutzt, möchte ich bei der erstmaligen Nutzung der App meine Sprache angezeigt bekommen, damit die Nutzung der App für mich verständlich ist. | 1. Erkennung der eingestellten Systemsprache wird durchgeführt. <hr/> 2. Wenn die erkannte Systemsprache nicht im Content hinterlegt ist, wird im Default Englisch ausgewählt. <hr/> 3. In der ersten Version der App ist Mehrsprachigkeit vorgesehen.
+| E01.07          | Als Person, die die App nutzt, möchte ich bereits während des Onboardings Hilfen und Einstellungen zur Barrierefreiheit bekommen, um die App nutzen zu können. | 1. Die Barrierefreiheit wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems genutzt.

-### Informationen und Instruktionen zur Nutzung der Applikation
+### Informationen und Instruktionen zur Nutzung der App
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E02.01          | Bei der Nutzung der App möchte ich Zugriff auf eine FAQ-Liste haben, um mir bei Fragen zur Applikation selbst weiterhelfen zu können. | 1. Ein Link auf eine Internetseite mit FAQs ist im Applikationsmenü hinterlegt.
-| E02.02          | Bei der Nutzung der App möchte ich Zugriff auf eine Anleitung zur Applikation haben, um die Anwendung und ihre Funktionen zu verstehen. | 1. Ein Link auf eine Internetseite mit Nutzungshandbuch ist im Applikationsmenü hinterlegt.
-| E02.03          | Bei der Nutzung der App möchte ich Zugriff auf ein Erklärvideo zur Applikation haben, um die Anwendung und ihre Funktionen zu verstehen. | 1. Ein Link auf eine Internetseite mit Erklärvideo ist im Applikationsmenü hinterlegt.
-| E02.04          | Bei der Nutzung der App möchte ich das Impressum der Applikation einsehen können, um zu sehen, wer für die Entwicklung und Inhalte der Applikation verantwortlich ist. | 1. Es gibt ein Untermenü "Impressum". <hr/> 2. Das Impressum beinhaltet die üblichen Angaben zur Impressumspflicht.
-| E02.05          | Bei der Nutzung der App möchte ich Nutzungsbedingungen und Datenschutzinformationen jederzeit einsehen können. | 1. Die App bietet einfachen Zugriff auf Nutzungsbedingungen und Datenschutzinformationen.
-| E02.06          | Bei der Nutzung der App möchte ich die verschiedenen Hotlines zu technischen, datenschutzbezogenen, gesundheitsbezogenen und psychologischen Fragestellungen sowie zur Verifikation eines Testergebnisses angezeigt bekommen, damit ich weitere Informationen erhalte oder Fragen beantwortet bekomme. | 1. Die App bietet einfachen Zugriff auf die Telefonnummern der Hotlines (für technische, datenschutzbezogene, gesundheitsbezogene und psychologische Fragestellungen). <hr/> 2. Die zeitliche Erreichbarkeit der Hotlines (z.B. 24/7) wird angezeigt. <hr/> 3. Telefonnummern können direkt aus der App gewählt werden.
+| E02.01          | Als Person, die die App nutzt, möchte ich Zugriff auf eine FAQ-Liste haben, um mir bei Fragen zur App selbst weiterhelfen zu können. | 1. Es wird entweder ein Link auf eine Internetseite mit FAQs zur Verfügung gestellt, oder die Internetseite wird integriert innerhalb der App dargestellt.
+| E02.02          | Als Person, die die App nutzt, möchte ich Zugriff auf eine Anleitung haben, um die App und ihre Funktionen zu verstehen. | 1. Eine entsprechende Erläuterung der verschiedenen Funktionalitäten der App wird bereitgestellt.
+| E02.03          | Als Person, die die App nutzt, möchte ich Zugriff auf ein Erklärvideo haben, um die App und ihre Funktionen zu verstehen. | 1. Eine entsprechende Erläuterung der verschiedenen Funktionalitäten der App wird bereitgestellt..
+| E02.04          | Als Person, die die App nutzt, möchte ich das Impressum der App einsehen können, um zu sehen, wer für die Entwicklung und Inhalte der App verantwortlich ist. | 1. Es gibt ein Untermenü "Impressum". <hr/> 2. Das Impressum beinhaltet die üblichen Angaben zur Impressumspflicht.
+| E02.05          | Als Person, die die App nutzt, möchte ich Nutzungsbedingungen und Datenschutzinformationen jederzeit einsehen können. | 1. Die App bietet einfachen Zugriff auf Nutzungsbedingungen und Datenschutzinformationen.
+| E02.06          | Als Person, die die App nutzt, möchte ich die verschiedenen Hotlines zu technischen, datenschutzbezogenen, gesundheitsbezogenen und psychologischen Fragestellungen sowie zur Verifikation eines Testergebnisses angezeigt bekommen, damit ich weitere Informationen oder Antworten auf Fragen erhalte. | 1. Die App bietet einen Zugriff auf eine technische Hotline und eine Hotline zur Erlangung einer Telefon-TAN. <hr/> 2. Die zeitliche Erreichbarkeit der Hotlines (z.B. 24/7) wird angezeigt. <hr/> 3. Telefonnummern können direkt aus der App gewählt werden.

 ### Nutzung im Regelprozess
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E03.01          | Bei der Nutzung der App möchte ich die Applikation aktivieren und deaktivieren können, um die Funktion ein- und auszuschalten. | 1. Eine Umschaltfläche schaltet die Funktion (Bluetooth im Hintergrund und Hash-Generierung) ein und aus. <hr/> 2. Die Konsequenzen des Ein-/Ausschaltens werden erklärt.
-| E03.02          | Bei der Nutzung der App möchte ich die App in den Auslieferungszustand zurücksetzen können, damit ich sie neu konfigurieren kann. | 1. Die App kann über eine Einstellung in den Auslieferungszustand zurückgesetzt werden, die gespeicherten Traces der letzten Tage bleiben aber erhalten.
-| E03.03          | Bei der Nutzung der App möchte ich die Applikationseinstellungen (Zugriffsrechte, z.B. Bluetooth, Benachrichtigungen) in einem Menü anpassen können, um Funktion und Zugriffe der Applikation verwalten zu können. | 1. Ein Menü zu Applikationseinstellungen kann durch die nutzende Person aufgerufen werden. <hr/> 2. Die Benachrichtigungen können ein- und ausgeschaltet werden. <hr/> 3. Die Zugriffsrechte der Applikation auf Bluetooth können durch die Person erteilt und entzogen werden. <hr/> 4. Vor Deaktivierung der Zugriffsrechte erhalte ich Informationen darüber, welche Funktionen der App dadurch nicht mehr (vollumfänglich) funktionieren.
+| E03.01          | Als Person, die die App nutzt, möchte ich die App aktivieren und deaktivieren können, um die Funktion ein- und auszuschalten. | 1. Die Funktionalität zur Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe kann ein- und ausgeschaltet werden. <hr/> 2. Die Konsequenzen des Ein-/Ausschaltens werden erklärt.
+| E03.02          | Als Person, die die App nutzt, möchte ich die App in den Auslieferungszustand zurücksetzen können, damit ich sie neu konfigurieren kann. | 1. Die App kann über eine Einstellung in den Auslieferungszustand zurückgesetzt werden. Die gespeicherten Traces müssen über die Systemeinstellungen gelöscht werden.
+| E03.03          | Als Person, die die App nutzt, möchte ich die App-Einstellungen (Zugriffsrechte, z.B. Benachrichtigungen) in einem Menü anpassen können, um Funktion und Zugriffe der App verwalten zu können. | 1. Ein Menü zu App-Einstellungen kann durch die nutzende Person aufgerufen werden. <hr/> 2. Die Benachrichtigungen können ein- und ausgeschaltet werden. <hr/> 3. Der Zugriff auf die Funktionalität zur Erstellung pseudonymer IDs und deren Aussendung an Geräte in der Nähe kann ein- und ausgeschaltet werden. <hr/> 4. Vor der Deaktivierung der Zugriffsrechte erhalte ich Informationen darüber, welche Funktionen der App dadurch nicht mehr (vollumfänglich) funktionieren.

 ### Kontaktfall (Begegnung mit infizierter Person)
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E04.01          | Bei der Nutzung der App möchte ich informiert werden, wenn eine Person, zu der ich Kontakt hatte, sich als infiziert gemeldet hat. Damit kann ich geeignete Maßnahmen treffen, um die Verbreitung des Virus zu stoppen. | 1. Eine Notifikation durch die Applikation wird an die möglicherweise betroffene Person verschickt. <hr/> 2. Die Notifikation informiert die möglicherweise betroffene Person über eine Risikoänderung (abhängig von der zur Verfügung gestellten API-Funktion).
-| E04.02          | Bei der Nutzung der App möchte ich im Kontaktfall Handlungsanweisungen durch die Applikation bekommen, um mein Verhalten an die Empfehlungen des RKI anzupassen. | 1. Die Notifikation führt zu hinterlegten Handlungsempfehlungen für den Kontaktfall.
+| E04.01          | Als Person, die die App nutzt, möchte ich informiert werden, wenn eine Person, zu der ich Kontakt hatte, sich als infiziert gemeldet hat. Damit kann ich geeignete Maßnahmen treffen, um die Verbreitung des Virus zu stoppen. | 1. In Abhängigkeit der Benachrichtigungseinstellung schickt die App eine Benachrichtigung an die nutzende Person.<hr/> 2. Bei einer Änderung der Risikoeinschätzung für die nutzende Person informiert die Benachrichtigung die nutzende Person über Neuigkeiten in der App. Die tatsächlich geänderte Risikoeinschätzung wird erst innerhalb der App angezeigt. 
+| E04.02          | Als Person, die die App nutzt, möchte ich im Kontaktfall Handlungsanweisungen durch die App bekommen, um mein Verhalten an die Empfehlungen des RKI anzupassen. | 1. Die Benachrichtigung führt die nutzende Person zur App. Handlungsempfehlungen des RKI sind in der App statisch hinterlegt.

 ### Covid-19-Testergebnismeldung
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E05.01          | Als RKI möchte ich, dass ausschließlich positiv getestete Personen einmalig eine Warnung auslösen können, um Missbrauch zu vermeiden. | 1. Nur positive Tests können eine Warnung auslösen. <hr/> 2. Für jeden Test kann nur einmal eine Warnung ausgelöst werden.
-| E05.02          | Bei der Nutzung der App möchte ich im Falle eines positiven Testergebnisses Informationen über die Erkrankung und nötige nächste Schritte bekommen, um mein Verhalten an die Handlungsempfehlungen des RKI anpassen zu können. | 1. Eine Benachrichtigung über den Eingang des Testergebnisses wird angezeigt. <hr/> 2. In der App wird ein Infotext mit definiertem Inhalt angezeigt (z.B. Informationen zum Ausgang des Testergebnisses, Informationen über erforderliche Maßnahmen, eine Hotline-Nummer).
+| E05.01          | Als RKI möchte ich, dass ausschließlich positiv getestete Personen einmalig eine Warnung auslösen können, um Missbrauch zu vermeiden. | 1. Nur positive Tests können eine Warnung auslösen. Der Verifikationsserver und die Hotline zum Telefon-TAN-Verfahren stellen dies sicher. <hr/> 2. Für jeden Test kann nur einmal eine Warnung ausgelöst werden.
+| E05.02          | Als Person, die die App nutzt, möchte ich im Falle eines positiven Testergebnisses Informationen über die Erkrankung und nötige nächste Schritte bekommen, um mein Verhalten an die Handlungsempfehlungen des RKI anpassen zu können. | 1. Eine Benachrichtigung informiert lediglich über Neuigkeiten in der App. Das Testergebnis selbst kann nur in der App eingesehen werden. <hr/> 2. In der App wird ein Infotext mit definiertem Inhalt angezeigt (z.B. Informationen zum Ausgang des Testergebnisses, Informationen über erforderliche Maßnahmen, eine Hotline-Nummer).

 ### Auslösen einer Warnung
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E06.01          | Bei der Nutzung der App möchte ich einen vom medizinischen Fachpersonal oder Test-Center ausgehändigten QR-Code scannen können, damit mir später das Testergebnis in der Warn-App zur Verfügung gestellt werden kann. | 1. Ein auf dem Flyer des medizinischen Fachpersonals oder Test-Centers vorhandener QR-Code kann mit der Warn-App gescannt werden. <hr/> 2. Erklärungstext wird angezeigt.
-| E06.02          | Bei der Nutzung der App möchte ich innerhalb der Warn-App informiert werden, sobald ein Testergebnis verfügbar ist. | 1. Die Person erhält eine Benachrichtigung, sobald ein verifiziertes Testergebnis vorliegt. <hr/> 2. Die Benachrichtigung enthält nicht das Ergebnis positiv oder negativ.
-| E06.03          | Bei der Nutzung der App möchte ich, dass bei Vorliegen meines positiven Testergebnisses nach meiner Zustimmung die pseudonymisierten IDs, auf deren Basis ich an den vergangenen Tagen für andere Personen sichtbar war, an den Warn-Server übermittelt werden, damit Kontaktpersonen durch ihre Apps gewarnt werden können. | 1. IDs können pseudonymisiert an den Warn-Server übermittelt werden. <hr/> 2. Die Übermittlung ist nur möglich, sofern zuvor eine Verifikation erfolgreich durchgeführt wurde. <hr/> 3. Die Übermittlung ist nur möglich, sofern die Person vorher zugestimmt hat.
-| E06.04          | Bei der Nutzung der App möchte ich neben dem digitalen auch einen manuellen Prozess, z.B. über ein Call-Center nutzen können, damit auch ohne einen vorhandenen QR-Code die pseudonymisierten IDs, unter denen ich in den vergangenen Tagen für andere Personen sichtbar war, an den Warn-Server übermittelt werden, so dass Kontaktpersonen durch ihre Apps gewarnt werden können. | 1. Die zuständige Stelle kann eine TAN generieren und diese der Person mitteilen. (Generiert wird die TAN von einem Server, nicht durch das Call-Center selbst.)
-| E06.05          | Bei der Nutzung der App möchte ich die Möglichkeit zur Eingabe einer TAN innerhalb der App haben, damit ich die mir telefonisch mitgeteilte TAN zur Zuordnung meines Testergebnisses zu der von mir genutzten Instanz der App nutzen kann. | 1. Die Eingabe einer TAN innerhalb der App ist möglich. <hr/> 2. Es wird überprüft und zurückgemeldet, ob die eingegebene TAN korrekt war (zu prüfen, ob technisch möglich).
-| E06.06          | Bei der Nutzung der App möchte ich, dass ich nach der Verifikation der TAN meine pseudonymen IDs freiwillig teilen und etwaige Kontaktpersonen warnen kann. | 1. IDs können pseudonymisiert an den Warn-Server übermittelt werden. <hr/> 2. Die Übermittlung ist nur möglich, sofern zuvor eine Verifikation erfolgreich durchgeführt wurde. <hr/> 3. Die Übermittlung ist nur möglich, sofern die Person vorher zugestimmt hat.
+| E06.01          | Als Person, die die App nutzt, möchte ich einen vom medizinischen Fachpersonal oder Test-Center ausgehändigten QR-Code scannen können, damit mir später das Testergebnis in der Corona-Warn-App zur Verfügung gestellt werden kann. | 1. Ein auf dem Flyer des medizinischen Fachpersonals oder Test-Centers vorhandener QR-Code kann mit der Warn-App gescannt werden. <hr/> 2. Erklärungstext wird angezeigt.
+| E06.02          | Als Person, die die App nutzt, möchte ich innerhalb der Corona-Warn-App informiert werden, sobald ein Testergebnis verfügbar ist. | 1. Eine Benachrichtigung informiert lediglich über Neuigkeiten in der App. Das Testergebnis selbst kann nur in der App eingesehen werden. <hr/> 2. Die Benachrichtigung enthält explizit nicht das Ergebnis positiv oder negativ.
+| E06.03          | Als Person, die die App nutzt, möchte ich, dass bei Vorliegen meines positiven Testergebnisses nach meiner Zustimmung die pseudonymisierten IDs, auf deren Basis ich an den vergangenen Tagen für andere Personen sichtbar war, an den Warn-Server übermittelt werden, damit Kontaktpersonen durch ihre Apps gewarnt werden können. | 1. IDs können pseudonymisiert an den Warn-Server übermittelt werden. <hr/> 2. Die Übermittlung ist nur möglich, sofern zuvor eine Verifikation erfolgreich durchgeführt wurde. Der Verifikationsserver und die Hotline zum Telefon-TAN Verfahren stellen dies sicher. <hr/> 3. Die Übermittlung ist nur möglich, sofern die Person vorher zugestimmt hat.
+| E06.04          | Als Person, die die App nutzt, möchte ich neben dem digitalen auch einen manuellen Prozess, z.B. über ein Call-Center nutzen können, damit auch ohne einen vorhandenen QR-Code die pseudonymisierten IDs, unter denen ich in den vergangenen Tagen für andere Personen sichtbar war, an den Warn-Server übermittelt werden, so dass Kontaktpersonen durch ihre Apps gewarnt werden können. | 1. Die zuständige Stelle kann eine TAN generieren und diese der Person mitteilen. (Generiert wird die TAN von einem Server, nicht durch das Call-Center selbst.)
+| E06.05          | Als Person, die die App nutzt, möchte ich die Möglichkeit zur Eingabe einer TAN innerhalb der App haben, damit ich die mir telefonisch mitgeteilte TAN zur Zuordnung meines Testergebnisses zu der von mir genutzten Instanz der App nutzen kann. | 1. Die Eingabe einer TAN innerhalb der App ist möglich. <hr/> 2. Es wird überprüft und zurückgemeldet, ob die eingegebene TAN korrekt war (zu prüfen, ob technisch möglich).
+| E06.06          | Als Person, die die App nutzt, möchte ich, dass ich nach der Verifikation der TAN meine pseudonymen IDs freiwillig teilen und etwaige Kontaktpersonen warnen kann. | 1. IDs können pseudonymisiert an den Warn-Server übermittelt werden. <hr/> 2. Die Übermittlung ist nur möglich, sofern zuvor eine Verifikation erfolgreich durchgeführt wurde. Der Verifikationsserver und die Hotline zum Telefon-TAN Verfahren stellen dies sicher. <hr/> 3. Die Übermittlung ist nur möglich, sofern die Person vorher zugestimmt hat.

 ### Parametrisierung
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E07.01          | Als RKI möchte ich die Parameter zur Risiko-Score-Bestimmung (im Rahmen der technischen Möglichkeiten durch die API) einstellen können, um stets den aktuellen Forschungsergebnissen zur Virusübertragung zu entsprechen. | 1. In Abhängigkeit von der bereitgestellten API können Schwellenwerte konfiguriert werden. <hr/> 2. Die Anpassung wird auf den Endgeräten vorgenommen, ohne dass ein Update der App erforderlich ist.
+| E07.01          | Als RKI möchte ich die Parameter zur Risiko-Score-Bestimmung (im Rahmen der technischen Möglichkeiten durch die API) einstellen können, um stets den aktuellen Forschungsergebnissen zur Virusübertragung Rechnung zu tragen. | 1. In Abhängigkeit von der bereitgestellten API können Schwellenwerte konfiguriert werden. <hr/> 2. Die App bezieht dynamische Konfigurationen des RKI, die die Berechnung der Risiko-Einstufung beeinflussen können.

 ### Technische Unterstützung
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E08.01          | Bei der Nutzung der App möchte ich eine Hotline kontaktieren können, um technische Probleme mit der Applikation zu lösen. | 1. Die Telefonnummer der technischen Hotline ist in der Applikation hinterlegt.
+| E08.01          | Als Person, die die App nutzt, möchte ich eine Hotline kontaktieren können, um technische Probleme mit der App zu lösen. | 1. Die Telefonnummer der technischen Hotline ist in der App hinterlegt.

 ### Barrierefreiheit
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E09.01          | Bei der Nutzung der App möchte ich eine Sprachausgabe nutzen können, um die Applikation (z.B. bei fehlendem oder eingeschränktem Sehvermögen) nutzen zu können. | 1. Die Barrierefreiheit bzgl. Sprachausgabe wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
-| E09.02          | Bei der Nutzung der App möchte ich gute Kontraste, veränderbare Schriftgrößen und eine gut lesbare Schriftart haben, um die Texte der Applikation gut lesen zu können. | 1. Die Barrierefreiheit bzgl. Kontraste und Schrift wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
-| E09.03          | Bei der Nutzung der App möchte ich, dass mir die Inhalte in einfacher Sprache zur Verfügung gestellt werden, damit ich leicht verstehe, wie ich die App nutzen kann und warum ich es tun sollte. | 1. Die Barrierefreiheit wird im Rahmen des Content-Managements berücksichtigt.
+| E09.01          | Als Person, die die App nutzt, möchte ich eine Sprachausgabe nutzen können, um die App (z.B. bei fehlendem oder eingeschränktem Sehvermögen) nutzen zu können. | 1. Die Barrierefreiheit bzgl. Sprachausgabe wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
+| E09.02          | Als Person, die die App nutzt, möchte ich gute Kontraste, veränderbare Schriftgrößen und eine gut lesbare Schriftart haben, um die Texte der App gut lesen zu können. | 1. Die Barrierefreiheit bzgl. Kontraste und Schrift wird im Rahmen der Möglichkeiten der Version des jeweils hinterlegten Betriebssystems verfügbar gemacht.
+| E09.03          | Als Person, die die App nutzt, möchte ich, dass mir die Inhalte in einfacher Sprache zur Verfügung gestellt werden, damit ich leicht verstehe, wie ich die App nutzen kann und warum ich es tun sollte. | 1. Die Texte und Sprachen werden vom Auftraggeber definiert.

 ### Content Management
 | # User Story ID | User Story | Akzeptanzkriterien |
 |-----------------|------------|--------------------|
-| E10.01          | Als RKI möchte ich die Inhalte der Applikation zentral verwalten, um Aktualisierungen von Texten, Links, Hotlines etc. einmalig für alle Stellen in der App durchführen zu können. | 1. Das Content-Management erfolgt auf Grundlage der Anforderungen des RKI <hr/> 2. Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert <hr/> 3. Aktualisierungen erfolgen in der ersten Version über ein App-Update.
+| E10.01          | Als RKI möchte ich die Inhalte der App zentral verwalten, um Aktualisierungen von Texten, Links, Hotlines etc. einmalig für alle Stellen in der App durchführen zu können. | 1. Das Content-Management erfolgt auf Grundlage der Anforderungen des RKI <hr/> 2. Der Content wird auf statische und dynamische Inhalte entsprechend der technischen Machbarkeit differenziert <hr/> 3. Aktualisierungen erfolgen in der ersten Version über ein App-Update.