Security & Data Protection

We pay special attention to the security of our customer data. To ensure the best possible protection of your data, we use technical, operational and contractual security measures to protect your data in the best possible way. Our systems are designed to collect only the most necessary data from our customers. However, it is not possible to be completely without personal data, which is why this data is specially protected.

Data Principle

The security of the data entrusted to us by our customers is of the highest relevance to us. We are therefore constantly working to further develop our standard. AppNavi's technology and business organization was built from the ground up with a strong focus on privacy. We take the approach of a data-minimal strategy. This means that we only collect and process data that is really relevant for the service we offer our customers. Data that we hold for our customers (such as analytics data) is subject to special protection and is encrypted by default. Since data security is highly dependent on the underlying storage and processing technology, we choose technologies very carefully and rely on proven market standards.

Hosting

The entire AppNavi backend is hosted in the Amazon Cloud. The decision was made consciously and for several reasons. These include technical reasons, as well as privacy reasons. The Amazon web services guarantee a high availability of 99.99% as well as maximum scalability and performance at low costs. All data is hosted in the AWS zone eu-central-1. To ensure that our customers' data is not used or passed on without authorization, we have taken appropriate contractual precautions and restricted service use to the EU area as far as possible. Technical measures have been implemented to regulate access. This applies to both daily operation and maintenance. Thus, AppNavi meets all requirements for GDPR compliant hosting. You can find more information about GDPR here.

Data Processing Addendum (DPA)

We follow the Court of Justice of the European Union (CJEU) validated Standard Contractual Clauses (SCCs), as a mechanism for transferring data outside the European Union. AWS has also included this standard clauses of the European Commission's Data Processing Addendum in the Online Service Terms and it is 100% compliant with them. Further information on the Standard Contractual Clauses can be found here.

Security Operations

Our policy is to encrypt as much data as possible. For this purpose, we use common and proven standards that encrypt data both in the database and on the way to the customer.

**Encryption of Data at Rest
We use a modern encryption method to encrypt data in databases. The AES-256 algorithm is used for this purpose. This means that the data is worthless without the corresponding key that is used for decryption. The keys are automatically exchanged at regular intervals using the key-ring method.

**Encryption of Data at Transit
The most secure data encryption is worthless if the data is tapped unencrypted on its way to the customer. For this reason, communication with AppNavi backend systems always runs over HTTPS and with transport security (TLS 1.2). As encryption standard we use the AES-256 cipher. We perform regular checks to ensure that only secure ciphers are used for encryption.

Monitoring

We intensively monitor our services to identify technical problems at an early stage and to detect and close potential security gaps. All monitoring measures are aimed at providing our customers with a highly available, maximally secure service. Monitoring is carried out with the following focal points.

Availability

• Availability of the application
• Accessibility of backend systems and services

Performance

• Response times of the services and apis
• Response times of backend systems
• Query times for database contents

Security

• Access logs
• Error logs

Security in Development

In the software development process, we have paid great attention to the orientation towards standards and automation.Our standards are guidelines such as the OWASP Top Ten and Microsoft SDL. The entire security verification process is standardized and automated via mechanisms in the Continues Integration. Our main guideline is based on the SDL principle defined by Microsoft see following illustration.

**Requirements-/Analysis-Phase
Software security already starts in the requirements and analysis phase. If the product team places new requirements on the product, our security team already checks the effects on product security in the design phase. If it turns out that the requirement offers a potential risk, this is evaluated. In the subsequent design phase, the measures required to minimize or completely eliminate the risk are examined.

Design-Phase
In the design phase, it is decided how the risks can be concretely avoided or mitigated. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t. For example, libraries that could be used in the development are examined. In addition, a plan is developed on how the security of the feature can be tested.

Development-Phase
The development of the source code is done with a high security focus. Among other things, we use a guideline document that describes important security principles. In addition, code reviews are performed after each implementation to ensure that the guidelines have been followed. These guidelines includes for example:

• A reference to the latest OWASP top ten list
• Using parameterized, read-only SQL queries to read data from the database and minimize chances that anyone can ever commandeer these queries for nefarious purposes
• Validating user inputs before processing data contained in them
• Sanitizing any data that’s being sent back out to the user from the database
• Checking open source libraries for vulnerabilities before using them

The code reviews consist of a manual part, which is a fixed part of the process. In this process, a senior developer or solution architect must approve the source code. In addition, we use tools for static code analysis. Their execution is automated and firmly integrated into the code integration process. New libraries are thoroughly tested before deployment. The question is always in the foreground: Is this library really needed, or is there already a library with similar functions in the project? If the use of the library is really necessary, it is checked for known weak points. In addition, the background of the community is illuminated. How large is the community? When was the library last updated? If the check is positive, the library is integrated into the project via a library manager. This ensures that there are no referenced libraries in the project.

Verification-Phase
In the verification phase, we use manual and automated tests to check whether the original requirements have been implemented correctly according to the specification. The tests include:

• Static code analysis
• Automated tests of critical paths in application
• Automated execution of application unit tests that verify the correctness of the underlying application
• Automated deployment tools that dynamically swap in application secrets to be used in production & test environment

Maintenance- and Evolution-Phase
In the operational phase, we rely primarily on monitoring tools that help us quickly identify problems and risks. Vulnaribility scanners help us identify security risks. If a security risk becomes known, it is assessed by our Security & Compliance team together with the developers. We classify these risks as follows:

Backups

To protect our customers data, we regularly perform backups at various levels. Our database backup allows us to restore data within minutes in the event of a disaster. In addition, we perform a daily backup for each tenant, which is kept for 7 days. All backups are also encrypted and can only be viewed by special personnel.