Skip to content

IT Security FAQ#

This FAQ provides concise answers to common security, compliance, hosting, logging, access control, and data protection questions related to Mobile2b.

It is intended as a practical companion to the IT Security Manifesto and other Trust Center documents, especially for customer security reviews, audits, and procurement questionnaires.

Technology#

What is the underlying IT architecture?#

Mobile2b is based on a cloud-native microservice architecture. The platform runs on Kubernetes and uses multiple backend services with separated responsibilities. Depending on the service and use case, data is stored in technologies such as MongoDB and MySQL/MariaDB.

This architecture supports scalability, service isolation, and secure operation in shared, dedicated, or private cloud environments.

See IT Security Manifesto: Cloud.

Service Level#

Is Mobile2b reliable to use for business-critical processes?#

We offer different Service Level Agreements (SLA) for different operational requirements and use cases.

See Service Level Agreement.

What other services are offered in combination with Mobile2b?#

See IT Security Manifesto: External services.

Is cloud scalability contractually ensured?#

License models can be scaled based on customer demand. For concrete contractual scaling terms (commercial and technical), the governing Terms of Service and, where applicable, the Service Level Agreement apply.

IT Security#

Is my data secure on Mobile2b?#

Yes. Security is a core principle of the Mobile2b platform. We have created a dedicated document covering our security architecture, encryption, access control, logging, and backup measures:

See IT Security Manifesto and the full Security FAQ for details.

GDPR#

Does Mobile2b comply with GDPR?#

See GDPR Compliance.

Who is behind Mobile2b?#

Mobile2b is developed and maintained by:

Mobile2b GmbH
Im Mediapark 5
50670 Köln
Germany
+49 221 630 608 560
info@mobile2b.com
D-U-N-S® 34-232-7118

What happens when we decide we no longer want to use Mobile2b?#

When a contract ends, termination and data handling follow the agreed legal terms.

Before contract end, customers can export their data using the built-in export functionality and the API.
Supported export formats include CSV and JSON.

If a custom migration or export workflow is required, this should be explicitly agreed in the customer contract/order documentation.

What if something happens to Mobile2b, the company behind Mobile2b?#

In the unlikely event that Mobile2b stops its operations (e.g. insolvency, liquidation, etc.) or stops to actively maintain the Mobile2b platform, we offer a Contingency Agreement (German) to our customers.

No matter what, you should feel confident that you can build your future digital business on top of Mobile2b.

See Trust Center

People, Identity, and Access#

Are all users well-trained/informed about their responsibilities of the correct handling of information, and is that training ensured by information/system owner?#

Yes. Employees handling customer or company information are trained and regularly sensitized regarding their responsibilities for the secure and compliant handling of information. This includes confidentiality, data protection, and general information security practices.

These measures are supported through internal policies and organizational processes as part of our compliance-oriented security management approach.

Are contractors accessing/handling customer data required to sign a NDA?#

Yes, according to our data protection policy, all stakeholders handling customer data have a NDA with Mobile2b.

Can all employees', contractors', and partners' user identities be centrally managed?#

Yes, we offer the option to integrate any SSO provider to log into Mobile2b.

If applicable, are consumer identities centrally managed?#

Yes, since SSO Login is used all the users which are allowed to access the system are centrally managed in azure

Are access rights managed?#

  • Access rights management via an appropriate process (also with regard to the principle of least privileges (need-to-know principle)), which is determined, documented, and in place before the IT system is put into operation:
  • Assign, modify, revoke access rights
  • Information may be re-distributed on a business related need-to-know basis to other people.

Yes, RBAC is present. The permission of a role can be defined only by admins. Since SSO is utilized, the role a user gets can be matched based on the Azure groups they are part of.

Example: if group equals mobile2b_admin then the corresponding user will get the admin role in the environment.

Are users restricted from raising their own permissions?#

Yes. Users cannot raise their own permissions. Roles and permissions are managed by administrators, and access is controlled through role-based access control. When SSO is used, effective access can additionally depend on the user's assigned identity provider groups.

Do you have a password management policy? (i.e. password length, expiration, complexity, history, etc.)#

Yes, see our user management documentation for the password policy.

Is two-factor authentication used for authentication (administrative and customer)?#

Yes. Mobile2b supports Two-Factor Authentication (2FA) for all users. Administrators can enforce 2FA for all non-SSO users via the Security Settings.

When Single Sign-On (SSO) is used (e.g. via Azure AD), the identity provider manages authentication, including any multi-factor requirements configured there. Accounts are automatically created in the application if the SSO user is part of a specific group. If the user is not part of that group, login is revoked.

Is this a customer-managed user environment (e.g.: customer desktops, laptops, smartphones; virtual customer environments (e.g., desktop, application, capsule))?#

Yes, this is a customer-managed user environment. While the web application can be accessed from devices managed by the customer, it is not limited exclusively to customer-managed devices. Users may also access the application from non-customer-managed devices such as personal browsers or mobile devices.

Do you utilize any immobilized workstations in order to avoid unnecessary meandering of information?#

No. Mobile2b is a cloud-based web application and does not require or depend on immobilized workstations. Access is controlled through authentication (SSO or credentials with optional 2FA), role-based permissions, and session management rather than through physical device restrictions.

Do you prevent long-term storage (as defined by the data owner) in your local user working environments?#

Mobile2b is a cloud-based platform — all data is stored server-side and is not persisted locally on user devices. The web application does not store customer data in local storage beyond session tokens. Session tokens expire after 15 minutes (access token) and 1 day by default (refresh token), after which users must re-authenticate. Workspace administrators can configure the refresh token duration between 1 and 10 days via Security Settings.

Data Protection, Transfer, and Segregation#

Is data transfer always secured (e.g., encrypted email, encrypted file transfer, client server connections using state-of-the art encryption protocols)? What version of TLS and what cipher suites/algorithms are used to encrypt data in transit? Please provide url that customer will use to access the solution#

Please check our IT Security Manifesto for details on our encryption policy.

Do you enforce encryption of communication between client and server/application - preferably by the server/application?#

Please check our IT Security Manifesto for details on our encryption policy.

Is data only redistributed based upon the "need-to-know principle"?#

Yes

Is data physically (e.g. extra disks) and/or logically (e.g. in extra databases) separated or masked from other customers' data? (How is customer data stored? In its own database, own VPC? Or is it a shared database? ) If data is in its own database, is the application layer shared with other customers or is this customer specific?#

In the Shared Cloud, customer data is logically isolated within shared database infrastructure. Each data record is bound to a unique account identifier, and all data access goes through an application-layer enforcement mechanism that ensures no cross-tenant data access is possible. The application layer is shared across customers, but tenant isolation is enforced at both the data access layer and the business logic layer. For full physical separation, Dedicated or Private Cloud deployments are available.

Does the hosting environment meet customer's "basic protection" and "hardening" control requirements?#

See the latest CIS benchmark results for Google Kubernetes Engine (GKE).

Malware protection#

We utilize Google Container Analysis to detect malware in our container images before deployed https://cloud.google.com/artifact-analysis/docs/artifact-analysis We have network policies to control traffic between all our workload, limiting the potential spread of malware within the cluster We keep our Kubernetes clusters, nodes, and container images up-to-date with the latest security patches

Firewall protection#

Please relate to https://cloud.google.com/kubernetes-engine/docs/concepts/firewall-rules?hl=de

Security patch management process#

We regularly scan our container images and Kubernetes nodes for known vulnerabilities using tools like Google Container Analysis We utilize GKE’s automatic upgrades feature to ensure our control plane and nodes are regularly updated with the latest patches We gather feedback from stakeholders and review the patch management process regularly to identify areas for improvement We conduct regular penetration tests (please see related assessment)

Auto-logoff/screensaver#

We utilize JSON Web Tokens (JWT) signed with HMAC-SHA512 (HS512). Users have a session active for 15 minutes and then automatically refreshed. After the refresh token expires (1 day by default, configurable up to 10 days), users are automatically logged out of the system and must log in again.

No installation of unnecessary components#

Deactivate unnecessary programs, services, commands#

Restrict/Control usage of privileged programs, system tools, and file shares#

Regular security checks#

Constant elimination of well-known vulnerabilities#

Yes. The platform uses an NGINX Ingress Controller with TLS termination managed by cert-manager and Let's Encrypt. All public endpoints are served exclusively over HTTPS (port 443); HTTP traffic is redirected to HTTPS. Publicly reachable endpoints are limited to the application API and frontend — no database or internal service is exposed outside the cluster.

Traffic security is enforced at multiple layers:

  • Network layer: GKE automatically manages firewall rules for cluster nodes. Kubernetes NetworkPolicies control and restrict traffic between workloads within the cluster.
  • Ingress layer: NGINX Ingress Controller enforces TLS, CORS policies, request size limits, and connection timeouts. Ingress metrics are collected and monitored via Prometheus and Grafana.
  • Application layer: All API endpoints require authentication (JWT). Brute-force protection limits failed login attempts. Input validation and OWASP Top 10 mitigations are applied in development. Regular penetration tests are conducted by external security experts.

Auto-logout: access tokens expire after 15 minutes. Refresh tokens expire after 1 day by default (configurable up to 10 days by workspace administrators).

Do you have an access rights management process?#

Yes, we implement access rights management within our Kubernetes environment. We leverage Google Cloud's RBAC, assigning limited rights to service accounts at the Kubernetes level. For example, our GitLab CI/CD pipeline utilizes a specific service account for image updates, while individual users have kubeconfig files with appropriate access levels based on their roles.

Is data flow control out of the respective environment (incl. deletion / destruction) managed by the user according to the "need-to-know principle"?#

yes, Our application's data flow adheres to the 'need-to-know principle,' including the use of Mailgun for email sending. We transmit only essential data to Mailgun, ensuring security through encryption and secure protocols. Example:

Admins of the platform have the ability to configure the email details such as the subject, recipient, and content. This configuration is limited to what is necessary for the task of sending an email. When an admin decides to send an email, they are directly controlling the flow of their data out of our environment to the external email recipient. All actions related to data flow, including sending emails and deleting configurations, are logged for audit purposes. This ensures that there is a trail of user actions which can be reviewed for compliance.

Is all unnecessary Internet access disabled for the application?#

Outbound internet access from the platform is limited to the specific external services required for platform functionality (e.g. Mailgun/SES for email delivery, Firebase and Apple Push Notification Service for mobile push notifications, reCAPTCHA for bot prevention, Sentry for error logging, AWS S3 for backup storage). Application services do not make arbitrary outbound requests to the internet.

Inbound traffic is fully controlled via the NGINX Ingress Controller, which enforces TLS and request validation. Inter-service communication within the cluster is restricted by Kubernetes NetworkPolicies. GKE manages node-level firewall rules for the cluster infrastructure.

All external services used are listed in the IT Security Manifesto: External services.

Do you have measures in place to protect your backups? Are backups encrypted? and provide algorithm#

See IT Security Manifesto.

Are users able to see that information stored in your system is classified as "Restricted" customer data? (i.e. can users see that information stored in your system is classified (e.g. labeled as "internal" or "restricted" per customer's classification system)?#

Rather than relying on visible classification labels such as "internal" or "restricted", access to data is controlled through role-based permissions and object-level access rights.

Users only see Business Objects they are permitted to access. Objects a user has no access to are filtered out and are not shown in lists, searches, or regular object views.

See Roles and Business Objects Access Rights.

Compliance, Audits, and Monitoring#

Does your organization follow professional system management processes according to ITIL, ISO 20000, or similar compliance standards?#

Yes, Mobile2b is ISO 27001 certified.

Does your organization follow information security management processes according to ITIL, ISO 27001, or similar compliance standards?#

Yes, Mobile2b is ISO 27001 certified.

Do you have regular provisions of any information security program certificates such as ISO 27001, SOC2, SOC1, HITRUST, etc.?#

Yes, Mobile2b is ISO 27001 certified.

Do you permit audits on demand by customer or trusted third parties? If yes, can you provide the report? Also, do you permit clients to perform onsite audits upon request?#

Although Mobile2b is conducting regular Penetration test, we are open to collaborate with you for additional Penetration Tests. (Contact us for contractual details).

Are you able to report relevant incidents of customer to customer in time within 24 hours?#

Please refer to our SLA.

Are your administrators well-trained and committed to ensuring the confidentiality, integrity, and availability of customer data?#

Yes, Mobile2b is ISO 27001 certified.

Do you log and monitor administrative activities on systems that process, transmit, and/or store customer's data?#

Yes. Administrative activities are logged and monitored on systems that process, transmit, and/or store customer data.

This includes application-level audit events as well as operational monitoring through our observability stack. Logs, metrics, and monitoring are supported through tools such as Grafana, Loki, and Prometheus.

In the Mobile2b UI, administrators can also review activity events in the Account > Activity area. This includes events such as who exported data from the system, who deleted Business Objects, and who created new Business Models.

See IT Security Manifesto: Logs.

Do you use Privileged Access Management tools like CyberArk or a jump server to monitor privileged access? If not, how are administrative activities tracked and monitored? How do you ensure admins and other employees aren't extracting customer data from your environment? Can anyone place information on a usb, send through email, etc.?#

Logging and Monitoring Administrative Activities#

We maintain audit logs for various activities such as exporting data, importing data, deleting, and updating objects, enabling us to track and review administrative actions.

Use of Privileged Access Management Tools#

While we currently do not utilize Privileged Access Management tools like CyberArk or a jump server, our audit logs capture administrative activities, including those performed by privileged users. These logs are regularly reviewed to ensure compliance and detect any unauthorized access or activities.

Prevention of Data Extraction#

To prevent unauthorized data extraction, we rely on role-based access control (RBAC) with finely-tuned permissions. Access to sensitive data is restricted based on job roles and responsibilities, ensuring that employees only have access to the data necessary to perform their duties. Regular reviews and monitoring of access permissions further mitigate the risk of unauthorized data extraction.

Do you log and monitor security events on systems that process, transmit, and/or store customer's data? How do you become aware of malicious events? How do you monitor your network and application traffic for suspicious activity and threats?#

Yes, we utilize Prometheus & Loki to gather metrics & logs from our Kubernetes cluster, including network activity and resource usage and application data. Grafana visualizes these metrics and triggers alerts via email and Slack when specific thresholds are exceeded, enabling us to promptly detect and respond to potential security incidents

Do you delete/remove customer's data from your systems? (e.g. deletion of files, overwriting of data, etc.).#

Link

Who is your hosting provider? Are they ISO 27001 certified? Do they have SOC 2 Type 2 audit reports available for review?#

See IT Security Manifesto: Cloud.

Our hosting provider is Google Cloud Platform (GCP). Google Cloud is ISO 27001 certified. As for SOC 2 Type 2 audit reports, Google Cloud typically undergoes regular audits to assess the effectiveness of their controls and processes

Secure Development and Vulnerability Management#

Do you conduct 3rd party network penetration tests against your infrastructure at least annually?#

Yes, Mobile2b regularly conducts third-party penetration tests with external security experts. These assessments help identify potential weaknesses in relevant subsystems and infrastructure components and support continuous security improvement.

See IT Security Manifesto: Penetration tests.

Do you follow a documented secure software development lifecycle?#

  • Yes, every code modification undergoes a review process, adhering to the principle of requiring at least two qualified reviewers.
  • We also integrate SonarQube's Quality Gates into our review process, which automatically assesses the code against predefined criteria before it is considered for approval
  • We leverage SonarQube for both code quality assessments and security vulnerability detection as an part of our development pipeline
  • This automated analysis is triggered with every change to the codebase, ensuring continuous identification of potential security issues before deployment to production
  • Additionally, we utilize Google Container Analysis to scan vulnerabilities in our Docker images at the Kubernetes level, enhancing our security measures and maintaining the integrity of our containerized applications

Do you conduct code reviews prior to production implementation? What about any Static/Dynamic application security vulnerability testing (DAST/SAST)?#

  • Every code modification undergoes a review process, adhering to the principle of requiring at least two qualified reviewers.
  • We also integrate SonarQube's Quality Gates into our review process, which automatically assesses the code against predefined criteria before it is considered for approval
  • We leverage SonarQube for both code quality assessments and security vulnerability detection as an part of our development pipeline
  • This automated analysis is triggered with every change to the codebase, ensuring continuous identification of potential security issues before deployment to production
  • Additionally, we utilize Google Container Analysis to scan vulnerabilities in our Docker images at the Kubernetes level, enhancing our security measures and maintaining the integrity of our containerized applications

Do you verify that all of your software suppliers adhere to industry standards for Systems/Software Development Lifecycle (SDLC) security?#

  • We ensure the security of our applications by reviewing their security practices and maintaining up-to-date versions
  • This process involves regularly reviewing security advisories, applying timely patches, and implementing Kubernetes security updates to mitigate risks
  • Being ISMS certified, we consistently review and ensure that the software we utilize complies with the stringent security guidelines required under ISO 27001.

Do you review your applications for security vulnerabilities and address any issues prior to deployment to production?#

  1. Automated Code Analysis: Utilizing SonarQube, we perform automated security scanning and code quality checks on every code change
  2. Container and Cluster Security: Given our use of Kubernetes for orchestrating all our applications, we implement security measures at the container level and throughout our cluster. This includes network policies, role-based access control (RBAC), and secure container configurations.
  3. Monitoring and Logging: With Grafana, Loki, and Prometheus, we have a robust monitoring and logging framework that allows us to detect and respond to security incidents in real-time
  4. Regular Security Reviews and Updates: Beyond automated tools, we conduct regular security reviews and update our dependencies and containers to mitigate known vulnerabilities

Do you encrypt data at rest (on disk/storage) within your environment? If so, what algorithm is used?#

See IT Security Manifesto: Encryption

Is customer data encrypted with its own key?#

No. Customer data is not encrypted with individual per-customer keys. Encryption at rest is applied uniformly across all customer data using the infrastructure provider's encryption mechanisms. See IT Security Manifesto: At-rest encryption for details.

What key generation/management solution do you use? Do you generate/upload/manage your own keys? How are they accessed? How often are they rotated?#

See IT Security Manifesto: At-rest encryption

Does customer get administrative accounts were they can create roles and give access to other customer users? Is customer able to see user activity logs within the application? Example: user logins, access to data, change of data, change to user permission, admin activities?#

Yes. Customer administrators can create and manage roles and assign them to users, controlling access to features and data.

Administrators can also view activity logs within the application under Account > Activity. The audit trail tracks the following events:

  • who exported data
  • who imported data
  • who created data
  • who deleted data
  • who edited data

See Security Settings: Audit Trail for more details.

Do you monitor and log user logins, access to data, change of data, change to user permission, admin activities? If not, is this activity something that can be exported to customer on a frequent basis?#

Yes. User activities including logins, data access, data changes, permission changes, and administrative actions are monitored and logged. Administrators can review activity events in the application under Account > Activity.

See IT Security Manifesto: Logs for details on our logging infrastructure.

Do you have a DLP solution? If so, what solution?#

Mobile2b does not use a dedicated Data Loss Prevention (DLP) product. Data loss risk is mitigated through a combination of compensating controls:

  • Cloud-only storage: all data resides server-side; no customer data is persisted locally on end-user devices
  • Role-based access control: granular permissions limit who can read, export, or delete data
  • API key management: administrators can create, audit, and revoke API keys at any time
  • Activity logging: all data access, exports, permission changes, and administrative actions are logged and visible to workspace administrators under Account > Activity
  • TLS encryption in transit: prevents interception of data in transit
  • No unrestricted data export: data exports are logged and subject to user permissions
  • SSO integration: when using Single Sign-On (Azure AD, ADFS), access is centrally controlled — revoking a user in the identity provider immediately removes platform access

Do you support SAML 2.0 SSO?#

Yes. Mobile2b supports SAML 2.0 for Single Sign-On, including integration with providers such as Azure AD and ADFS. Additionally, OAuth 2.0-based SSO is supported. See ADFS SSO and OAuth 2 SSO for configuration details.

Do you have documented business continuity and redundancy plans and disaster recovery plans? How often are these plans tested?#

See IT Security Manifesto: Backup and recovery

Will you be providing customer with a mobile application?#

Yes. Mobile2b provides native mobile applications for iOS and Android, in addition to the web application. See Getting Started: Mobile Apps for details.

How do you address security with your hosting provider and any other providers?#

Mobile2b conducts annual supplier and provider reviews as part of its Information Security Management System (ISMS) certification process. This includes evaluating the security posture and compliance certifications of hosting providers and other third-party services.

See IT Security Manifesto: External services for details.

Do you have any contractual obligations with your providers to ensure security requirements are met?#

Yes. Mobile2b maintains Data Processing Agreements (DPAs) and Service Level Agreements (SLAs) with its hosting providers and other third-party service providers to ensure security requirements are met. These contractual obligations are reviewed as part of the annual supplier review process within our ISMS.

How is data handled and deleted at the end of service? Is this documented in your contract?#

Upon termination of service, customers can submit a deletion request. Mobile2b will then delete all user data associated with the customer's account and provide a detailed deletion log. Without an explicit deletion request, customer data is automatically deleted from all production and backup systems 90 days after the end of the contractual relationship.

Within the platform, workspace administrators can also configure deletion periods and submit deletion requests at any time via the Data Protection Settings. See Data Protection Settings and IT Security Manifesto: Data deletion.

Do you conduct network, operating system and application layer vulnerability scans regularly? If so, how often?#

We utilize Google Container Analysis to scan vulnerabilities in our Docker images at the Kubernetes level, enhancing our security measures and maintaining the integrity of our containerized applications Additionally, we conduct regular penetration tests

Do you have a capability to rapidly patch vulnerabilities across all of your computing devices, applications, and systems? Please specify your patching timeframes for Critical/High/Medium findings#

Deployments, including updates and patches, are automatically applied to customer's environment, eliminating the need for manual user intervention

  • Hotfixes: Deployable at any time to address urgent issues
  • Feature Releases: Scheduled every 4-6 weeks, following thorough testing to ensure quality
  • Changelog and Schedule Communication: We maintain a detailed changelog that includes information on when the next update is scheduled and details about the changes or new features being applied. This changelog helps keep all stakeholders informed about upcoming updates
  • Discord Notifications: We have a dedicated Discord channel that notifies stakeholders when a new update has been deployed

Is there a network architecture and data flow diagram?#

https://git.mobile2b.de/mybusiness-ai/infrastructure/-/raw/develop/kubernetes/mybusiness-ai-k8s.png

Do you review firewall settings? If so, how frequent? Do you have a deny all default setting then open up ports as needed?#

Yes. Firewall rules for the Kubernetes cluster nodes are automatically managed by GKE. Within the cluster, Kubernetes NetworkPolicies are in place to control and restrict traffic between workloads. Only HTTPS (port 443) is exposed publicly via the ingress controller. Firewall configurations are reviewed as part of our regular security reviews under our ISO 27001 certified ISMS.

See GKE Firewall Rules for details on the underlying firewall mechanism.

Do you utilize IDS/IPS systems for protection?#

Mobile2b does not deploy a dedicated IDS/IPS appliance. Detection and protection is achieved through a combination of cloud-native and application-level measures:

  • GKE-managed firewall rules: automatically restrict inbound traffic to cluster nodes; only HTTPS (port 443) is publicly exposed
  • Kubernetes NetworkPolicies: control and restrict traffic between workloads within the cluster
  • NGINX Ingress Controller: enforces TLS, request size limits, and connection timeouts; metrics are collected and monitored via Prometheus and Grafana
  • Brute-force protection: after a configurable number of failed login attempts from the same IP address within a 15-minute window, further attempts are blocked and workspace administrators are notified by email
  • Anomaly monitoring: cluster and application metrics are monitored via Grafana; alerts are configured for abnormal behavior
  • Activity logging: all login events, permission changes, and administrative actions are logged for audit purposes

How do you ensure OS baseline compliance monitoring and remediation? Do you include client computers in your hardening processes? Are the administrative consoles hardened?#

As part of our commitment to security and compliance, we maintain a formal information security management approach aligned with ISO 27001 requirements. This includes controls for operating system baseline compliance, hardening processes for client computers used by remote employees, and the security of administrative consoles managing our Kubernetes environment.

Do you have an up-to-date virus and malware protection installed on all systems?#

Yes. We utilize Google Container Analysis to detect malware and vulnerabilities in container images before deployment. Kubernetes NetworkPolicies control traffic between workloads, limiting potential spread within the cluster. Nodes and container images are kept up-to-date with the latest security patches via GKE automatic upgrades.

Architecture, Platform Security, and Data Handling#

How do you ensure that development and consolidation systems are separated from productive systems; and how are changes from the development system transferred to the production system via the consolidation system, as well as how the test or consolidation system is supplied with test data?#

For testing and development purposes, there are multiple separate clients, exclusively filled with manually generated dummy data (no productive data!), but otherwise providing all aspects for testing the functionality of the software.

Testers and developers do not have access to productive systems.

How do you ensure that the confidentiality level (internal/confidential/secret) is marked on relevant emails, documents, and external data storage?#

Mobile2b does not apply confidentiality labels (e.g. "internal", "confidential", "secret") to documents stored within the platform. Information classification labeling of customer-owned documents is the responsibility of the customer's organization and is outside the scope of the platform.

Access to information within Mobile2b is controlled through role-based permissions and object-level access rights — users only see data they are explicitly authorized to access. For Mobile2b's own internal information assets, classification is governed by our ISMS in accordance with ISO 27001.

How do you ensure that the confidentiality level (internal/confidential/secret) is labeled on (digital) information (e.g. in PowerPoint presentations) and on mobile storage media (e.g. USB sticks, CDs, or external hard drives)?#

Mobile2b is a server-based cloud platform — no customer data is stored on local devices or external storage media (USB sticks, CDs, external drives). All data resides exclusively on Mobile2b's managed server infrastructure.

Classification labeling of digital information (e.g. markings on presentation files) is the responsibility of the customer's organization. Mobile2b does not enforce or apply document-level classification labels on customer-uploaded files. Access control within the platform is enforced through role-based permissions and object-level rights.

Do you implement a multi-layer architecture or install the application on a secure server with remote display capabilities for handling data with high or very high protection requirements?#

All data except documents and photos (files) are stored in databases. Documents and photos are encrypted at-rest using 256 bit AES.

How do you ensure that the data is tagged with an authenticity feature to prove its authenticity for later processing?#

No further authenticity features. Data is only used internally (interface through intermediate file).

How do you ensure that the collected data is authentic?#

No further authenticity features. Data is only used internally (interface via intermediate file).

How do you ensure that end/system users are restricted to access only the data they are authorized for ("Need-To-Know")?#

There are roles. These roles are assigned to individual users. The number and content of the roles can be flexibly adjusted by the admin.

How do you ensure that the implementation of the authorization concept is done server-side in multi-tier architectures (n-tier architectures)?#

The entire application is server-based, therefore also the rights & roles model.

Do you process company data only on devices provided by the customer or certified devices (e.g. NPC)?#

Login via AzureAD, therefore only possible with licensed devices. However, pinging the homepage is possible with all devices.

How do you ensure that you use the services or mechanisms available in the infrastructure to protect the integrity of the data?#

We ensure data integrity by storing all data in databases (mariadb, mongodb, influxdb) and have backups in place in case of data loss or corruption.

How do you ensure that the authenticity of the data to be processed is verified?#

We use JSON Web Tokens (JWT) signed with HMAC-SHA512 (HS512) to transmit authenticated information. JWTs are always verified for authenticity.

How do you ensure that data is stored securely in a restricted area with appropriate access rights or encrypted?#

Data transfers from/to clients is encrypted with TLS. Persistent disks used by the hosted kubernetes service are encrypted at the hardware layer.

Do you store company data on network drives?#

Files are stored on network drives and linked in the system.

How do you ensure that the data is transmitted within secured network zones or encrypted?#

Incoming and outgoing data is always encrypted. Apart from GCP in-transit encryption, inside the cluster there is no additional encryption.

How do you ensure that emails are deleted after their retention period?#

See IT Security Manifesto.

Logging and Traceability#

How do you ensure that the log records contain sufficient information for evaluating a security event, including user identification, timestamp within a specified tolerance, access point, type of event, identification of the resource involved, and success/failure of the action?#

Application logs are collected and stored via Grafana Loki, running within the cluster. Loki logs do not store business-level user data — only system and operational events.

Login events are stored in the application database (MariaDB).

Kubernetes cluster control plane logs are handled by the GKE service and include an audit log for cluster operations, which covers the event types listed above.

Log exchange with a customer log solution or SIEM is not currently available as a standard feature. For Dedicated or Private Cloud deployments, this may be evaluated on a case-by-case basis.

See IT Security Manifesto: Logs for the full retention overview.

How do you ensure that the IT system protects against unauthorized deletion?#

K8s cluster audit logs can't be deleted or modified by an administrator.

How do you ensure that the IT system provides complete logging with:#

  • Sufficient buffer for log data in case the log host is unreachable?
  • Warnings when the available storage space for logs is running low?

Application logs are collected via Promtail and stored in Grafana Loki for 10 days. Alerts are in place that fire when disk space is low. Kubernetes pod logs are captured from container stdout/stderr streams and forwarded to Loki. GKE cluster logs are retained by the GKE service: standard logs 30 days, audit logs 400 days.

See IT Security Manifesto: Logs for the full retention overview.

How do you ensure that known vulnerabilities of the application are promptly addressed through updates (security advisory patches) and/or changes in security settings, based on the criticality and exploitability of the vulnerability within specific timeframes as defined in the security concept ISMS-3b-014 Vulnerability Management?#

Regular penetration tests of all subsystems are carried out by external security experts.

How do you ensure that the executables are protected against unauthorized disclosure through architectural measures?#

User authentication on google cloud web console is handled by username and password prompt as well as 2FA. Google can challenge users for additional information based on risk factors such as whether they have logged in from the same device or a similar location in the past. After authenticating the user, the identity service issues credentials such as cookies and OAuth tokens that can be used for subsequent calls. Google Identity and access management service authorizes access to specific resources based on roles and permission policies.

How do you ensure that the application's runtime behavior is protected from indirect manipulation?#

Do you develop the application according to the currently valid security standards described in the internal development guidelines?

Best practices measures are considered in software security development (e.g. consideration of OWASP Top 10, input validation, protection against XSS, CSRF, etc.).

How do you ensure that unauthorized users do not have write access to executables or detect manipulations to executables and prevent the execution of manipulated executables for customers with normal/high protection requirements?#

Unauthorized personnel do not have write access to executables. Docker images are automatically scanned for issues and vulnerabilities upon push to the registry.

How do you ensure that all accesses to an application and outgoing data transmissions are disclosed and documented?#

All accesses to the application and outgoing data transmissions are disclosed and documented through third-party providers in our architecture diagram.

How do you ensure that the authentication mechanism is protected against brute force attacks?#

Mobile2b implements application-level brute-force protection. After a configurable number of consecutive failed login attempts from the same IP address within a 15-minute window, further attempts are blocked and workspace administrators are automatically notified by email. The threshold is configurable per account. All failed login attempts are logged for audit and monitoring purposes.

How do you ensure that existing permissions can be efficiently identified in the system?#

Permissions are granted through groups. Within the groups, the assigned users are listed in a way that allows for efficient verification.

How do you ensure that the application is prepared for productive use (hardening), including deactivating all unnecessary interfaces, using a communication protocol appropriate for the data sensitivity, removing all test users, and removing default usernames and passwords?#

No test or default users are used in production environments, instead there is a concept of a support user that is only active for 15 minutes after activation by the customer.

How do you ensure that the application is designed as a multi-tier architecture or n-tier application (n>1) (recommendation: n=3)?#

Mobile2b is built as a microservices architecture deployed on Kubernetes. The platform consists of multiple independent backend services, a dedicated API gateway, and separate database systems (MariaDB, MongoDB, InfluxDB, Redis, OpenSearch, Qdrant, MinIO). Services communicate internally over HTTP and database-native protocols within the private cluster network. Kubernetes NetworkPolicies enforce traffic segmentation between workloads. This architecture provides logical multi-tier separation at the service and data access layer.

How do you ensure that only the operations provided by the business logic at a given time and for which the user is authorized are available to the user to protect data from unauthorized changes?#

Only roles are assigned. New roles can be created and assigned as needed.

How do you ensure that mechanisms are provided to revoke unused or compromised credentials in the application?#

Revocation information is published through OCSP.

How do you ensure that the user can verify that the application is authentic?#

The URL only contains the customer name.

How do you ensure that you implement organizational, procedural, and technical measures for regular analysis of traces and access logs of users and subcontractors to detect any abnormalities?#

Mobile2b is ISO 27001 certified, with regular internal and external audits as part of our ISMS.

Do you log the following events:#

• Failed authentication attempts (if authentication is present) • Anomalies detected by the application • Application exceptions (crashes, unhandled exceptions, ...) • Access through maintenance interfaces

Failed login attempts are logged. Exceptions and crashes are logged. Brute-force protection blocks further login attempts from the same IP address after a configurable threshold is reached within a 15-minute window, and workspace administrators are notified automatically.

How do you ensure that every data export is logged?#

Every data export as well as deletion process is logged in the environment. The individual events can be viewed in a list under "Account" > "Activity" by administrators. This list can be filtered by any date.

How do you ensure that applications use at least the local log service of the underlying platform?#

Application logs are collected via Promtail and stored in Grafana Loki (10-day retention). Kubernetes cluster control plane logs are handled and stored by the GKE service.

How do you ensure that activities of emergency users are logged and there is a documented retention period for the log data?#

There are no emergency users, only support access if opted-in by the client's administrator.

Cryptography and Credential Management#

Do you use appropriate procedures and sufficient key lengths in accordance with cryptographic algorithm requirements for generating certificates and key pairs?#

RSA 2048-bit encryption is used.

How do you ensure that the generation of certificates and key pairs is done according to the specifications for creating certificates and key pairs (see cryptography concept)?#

TLS certificates are issued by cert-manager, a cloud native client implementing the Let's Encrypt ACME protocol, which watches for specific annotations on ingress resources to issue certificates accordingly. RSA 2048-bit encryption is utilized.

How do you ensure that the storage areas used for credentials are overwritten once they are no longer needed by an application?#

Each user is created as a user in the system. User authentication is done via the configured identity provider (SSO) or local credentials, with a session active for 15 minutes and then automatically refreshed. After the refresh token expires (1 day by default, configurable up to 10 days), users are automatically logged out of the system and must log in again.

The integration of additional interfaces is possible. For this, administrators can create, manage, and delete API keys under the "System Integration" menu.

How do you ensure that time-limited credentials or authenticity proofs are renewed in a timely manner?#

User accounts are created in the system for each user. Users log in using the configured identity provider (SSO) or local credentials, where a session is active for 15 minutes and is automatically refreshed afterwards. Users are automatically logged out of the system after the refresh token expires (1 day by default, configurable up to 10 days) and must log in again. Certificates are valid for 3 months and are refreshed when 30 days of validity remain.

Additional interfaces can be connected by creating, managing, and deleting API keys under the menu item "System Integration" by the administrator.

How do you ensure that the authenticity of the change request is verified before credentials are modified?#

Password changes require the current password to be provided. If a user has 2FA enabled, the second factor (TOTP) must be re-entered to complete a credential change. Workspace administrators can additionally enforce 2FA for all non-SSO users via Security Settings, ensuring the second factor is always required. When SSO is used, credential management and authentication verification are handled by the identity provider (e.g. Azure AD, ADFS).

How do you ensure that credentials are protected from interception during their transmission?#

Credentials are protected from interception during transmission by ensuring that all incoming network traffic is encrypted, with TLS connections terminated on the ingress controller inside the cluster.

How do you ensure that credentials are deleted once they are no longer needed?#

API keys are always hard-deleted.

How do you ensure that the validity of the credentials is revoked, if the type of credentials allows it?#

Revocation information for certificates is published through OCSP, and they can be revoked using the command certbot revoke --cert-path /path/to/certificate --key-path /path/to/key.

How do you ensure that before permanently deleting credentials, it is verified that they are no longer needed to access stored or archived data?#

Before permanently deleting credentials, it is verified that they are no longer needed to access stored or archived data.

Do you provide details about the components you use?#

We have no control over the operating system used by the managed cloud service. For details on components such as databases, logging, monitoring, and ingress, please refer to the provided architecture model.

Do you have a security zone concept in place?#

In the Shared Cloud, tenant isolation is enforced at the application and data access layer. Every data record is bound to a unique account identifier, and the business logic ensures that users can only access data belonging to their own account. Database infrastructure is shared, but cross-tenant access is prevented at the application layer. For customers requiring infrastructure-level separation, Dedicated or Private Cloud deployments provide dedicated environments.

How do you ensure communication relationships (including protocols and security concept)?#

Database connections (MariaDB, MongoDB, InfluxDB, Redis, OpenSearch, Qdrant) are established within the private GKE cluster network using each database's native protocol. No database is exposed outside the cluster — there are no public endpoints for any database service. Access between application services and databases is restricted through Kubernetes NetworkPolicies. All persistent data is encrypted at rest at the infrastructure level by GKE/GCP. GCP additionally encrypts data in transit within its own network infrastructure. Application-level TLS on database connections is not configured, as isolation is enforced at the network and infrastructure layer.

Backup, Recovery, and Availability#

Do you provide backup and restore functionality with defined Recovery Point Objective (RPO) and Recovery Time Objective (RTO)?#

The application provides backup and restore functionality with defined Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

How do you ensure that you have a backup process for your Information System that is limited in access, password-restricted, and tracked, with a tested restoration process in place?#

The backup process for our Information System is limited in access, password-restricted, and tracked, with a tested restoration process in place.

Do you provide export interfaces for data?#

A complete data export is possible via the REST API.

How do you ensure the availability in case of physical impairments?#

Backups are stored only in S3. However S3 itself is redundant inside an AWS region.

How do you ensure the irretrievable deletion of all customer data after the end of the contract?#

See IT Security Manifesto.

How do you ensure that customer data is protected from unauthorized read and write access?#

All data at rest is encrypted by our hosting partners at the infrastructure level. Storage volumes, databases, and backup data (AWS S3) are encrypted using AES-256 by the respective cloud provider. Mobile2b does not currently offer customer-managed encryption keys (BYOK/KMS). All data in transit is protected with TLS 1.2 or higher. See IT Security Manifesto: Encryption for details.

How do you ensure the maintenance of data integrity?#

See IT Security Manifesto.

Do you implement hardening measures for components such as disabling unnecessary services, deleting test users, and checking patches for security implications?#

Do you adhere to security standards such as CIS Benchmarks, OWASP, BSI recommendations, NIST, and manufacturer recommendations? What security software do you use, such as IDS, IPS, AV, SIEM, TripWire?

We have implemented measures to strengthen the security of our Kubernetes cluster and applications following best practices outlined in CIS benchmarks.

How do you ensure that personal data is anonymized in the Cloud environments for development, integration, testing, and pre-production?#

User data creation is fully in control of the client.

Authorization, Sessions, and Service Operations#

How do you ensure the design of the rights/roles model?#

Access to cloud infrastructure (GCP, AWS) and the Kubernetes cluster is managed through IAM roles following the principle of least privilege. Access rights are assigned based on job function and reviewed as part of our regular ISMS audit processes.

Within the Kubernetes cluster, application service accounts are granted only the minimum permissions required — for example, read access to specific endpoints via RBAC. No application service account has cluster-wide administrative permissions.

A detailed overview of IAM assignments is available to auditors on request under NDA.

How do you ensure that user access to the application is based on the authentication system, preferably SAMLv2 federated identity with IDP? If the solution does not support federated identity and manages accounts and passwords locally, how do you enforce the specific password security policy of the customer?#

SSO fully supported, AzureAD, ADFS using SAML, any OAuth2.0 Provider

How do you ensure that the authorization workflows for access to classified data are formalized by the project manager?#

The project manager formalizes the authorization workflows for access to classified data through a Full Role and Permission System implemented in the software.

How do you ensure that the solution allows automated user account management through a connector or API?#

Mobile2b supports automated user account management through the following mechanisms:

  • JIT provisioning via SSO: when a user authenticates for the first time through a connected identity provider (Azure AD, ADFS, or OAuth2), their account is automatically created or updated in Mobile2b based on the claims provided by the IdP. No manual user creation is required.
  • SSO-enforced mode: workspace administrators can enforce SSO-only authentication, ensuring that user lifecycle (activation, deactivation) is fully controlled by the customer's identity provider.
  • REST API: user accounts can be created, updated, and deactivated programmatically via the Mobile2b REST API, enabling integration with existing IAM or HR systems.

SCIM is not currently supported.

How do you ensure that the solution displays the date and time of the last user connection after the user's authentication to detect unauthorized account usage?#

Authentication events are logged internally.

How do you ensure that sessions are automatically disconnected after a configurable period of inactivity and redirected to a dedicated "end of session" page?#

Sessions are automatically disconnected after the AuthToken expires in 15 minutes and users are automatically redirected to the Login Page.

How do you ensure that the solution does not allow 2 or more simultaneous connections with the same user account?#

The use of multiple clients in parallel is currently allowed.

How do you ensure that the agreed service levels are met?#

We monitor cluster node host metrics, pod/container metrics, and application availability using external services.

Do you have requirements and procedures in place for vetting and auditing subcontractors?#

There are confidentiality agreements between Mobile2b and other subcontractors.

Do you provide an overview of the cryptographic algorithms used and their parameterization?#

We use bcrypt for password hashing. We use a 256-bit AES encryption for documents and photos.

How do you ensure the monitoring and maintenance of the security level of the cryptographic algorithms used?#

Cryptographic implementations are reviewed as part of regular penetration tests and ISMS processes. The following algorithms and mechanisms are in use:

  • TLS 1.2 for all external client-to-server communication
  • HMAC-SHA512 (HS512) for JWT signing
  • AES-256 for documents and photos stored at rest
  • bcrypt for password hashing
  • RSA 2048-bit for TLS certificates, auto-renewed every 3 months via cert-manager (Let's Encrypt)
  • Hardware-level at-rest encryption provided by GKE/GCP for all cluster storage
  • AWS S3 at-rest encryption for backups
  • AWS access keys and secrets are rotated annually

How do you ensure that authentication credentials/passwords meet specified requirements?#

Do you have processes for password management?#

New users receive a one-time login link via email and are forced to change their password on the first login, or single sign-on (SSO) via Active Directory can be used. Password reset is done by clicking a "Forgotten password" link and following the provided instructions.

How do you ensure that processes and technologies are in place for managing key material?#

We are rotating AWS keys and secrets once a year.

How do you ensure timely handling of vulnerabilities and security incidents?#

Static code analysis with SonarLint, TSLint, SonarQube, internal reviews, and pentests. Container images are scanned for vulnerabilities and issues automatically upon pushing to the registry.

How do you ensure the detailed logging as well as the technical and temporal availability of log files for the detection and investigation of security events/incidents?#

See IT Security Manifesto. We guarantee detailed logging and the technical and temporal availability of log files for the detection and investigation of security events/incidents.

How do you ensure that IT security aspects are considered in the change management process?#

See Patch Management.

Do you have processes in place for physical authorization management, authorization review, and physical access traceability?#

Physical access control is managed by Google Cloud employees as the service is cloud-based, and no other individuals have physical access.

Governance and Certifications#

How do you ensure that you respect good security practices mentioned in international standards such as ISO 27xxx standards and OWASP guides? Can you provide a list of your certifications, application scope, and validity period?#

Mobile2b is ISO 27001 certified. Our ISMS covers information security governance, risk management, access control, incident management, business continuity, and supplier relationships. Security practices follow ISO 27001 controls and OWASP guidelines are applied during development. Current certification details and scope are available on request.

See Compliance.

How do you ensure that the Service Provider is ISO27001 certified for projects involving critical data, especially personal data?#

Mobile2b is ISO 27001 certified as the service provider. Our hosting infrastructure runs on GCP, which is also ISO 27001 certified. Current certification scope and validity are available on request.

See Compliance.

How do you ensure that a CISO is appointed at your company?#

Mobile2b has a designated person responsible for information security within the organization. This role is part of our ISO 27001 certified ISMS governance structure and covers responsibilities including security policy ownership, risk management, incident coordination, and ISMS oversight. Contact info@mobile2b.com for further details.

Do you provide the information system security policy that you have implemented and inform customers of any changes in this policy?#

We have implemented an information system security policy and will inform customers of any changes in this policy.

Additional Security Questionnaire#

Has top management formally assumed overall responsibility for information security and data protection?#

Yes. Top management has formally committed to the ISMS, including management review, provision of resources, and continuous improvement of information security. This commitment is reflected in our documented information security policy and ISMS governance processes. These governance measures are part of our ISMS, which is ISO 27001 certified.

Are information security risks part of the company-wide risk management process?#

Information security risks are addressed through a documented ISMS risk assessment and risk treatment process. These processes are used to identify, assess, prioritize, and treat information security risks and are supported by operational security controls such as penetration testing, vulnerability scanning, and patch management. This is covered by our ISMS, which is ISO 27001 certified.

Is it ensured that significant changes to the IT infrastructure consider impacts on information security and data protection at an early stage?#

Yes. Information security is considered as part of documented change management controls for infrastructure and platform changes. Relevant changes are reviewed, implemented, and safeguarded through the established operational, patch, and security processes within our ISMS, which is ISO 27001 certified.

Is information classified according to its protection needs?#

Yes. Information classification is covered by our ISMS, which is ISO 27001 certified. Information protection needs are reflected through role and permission concepts, tenant separation, separated environments, and customer-specific requirements. At application level, access and processing can be restricted according to the need-to-know principle.

Are risk analyses repeated at defined intervals?#

Yes. Risk analyses and security assessments are repeated and updated when needed, for example as part of regular security reviews, penetration tests, vulnerability scans, and relevant technical changes. This is covered by our ISMS, which is ISO 27001 certified.

Is appropriate asset management established?#

Yes. Asset management is covered by our ISMS, which is ISO 27001 certified. Documented operational processes exist for managing relevant systems, services, access paths, and backup objects of the operated platform components. These assets are incorporated into monitoring, backup, patch, and access processes.

Are contractors assessed with regard to risks to information assets, including personal data where relevant to the engagement?#

Yes. Subcontractors and external services are assessed within the scope of data protection and security requirements. This includes DPA arrangements, confidentiality requirements, location and compliance requirements, and a documented list of sub-processors.

Is remote access to internal IT resources via untrusted networks such as the internet or Wi-Fi specially secured?#

Yes. Remote access to internal IT resources is protected through secured methods such as encrypted connections, centralized authentication, role and permission concepts, and logging. Additional monitoring and security mechanisms are used for administrative access.

Are the records of security reviews made available to the customer?#

Evidence and results from security reviews can be provided as required and subject to contractual alignment. This especially includes information from penetration tests, audits, or patch and security processes, as far as this is compatible with confidentiality obligations and protection of the overall environment.

Is the flow of information regarding significant security incidents from the contractor to the customer ensured?#

Yes. Documented processes exist for recording, assessing, and handling significant security incidents. Communication with customers takes place in line with the contractual agreements, especially through SLA and support processes and defined points of contact.

Further Questions#

Do you ensure traceability in your app?#

How do you ensure that the solution allows the exchange of logs with a log collector or SIEM of the Customer?#

Log forwarding to a customer-managed log collector or SIEM is not available as a standard feature in the Shared Cloud. For Dedicated or Private Cloud deployments, integration with a customer SIEM can be evaluated on a case-by-case basis. Please contact us to discuss your requirements.

Could you provide support for your app?#

How do you ensure that state-of-the-art security measures are implemented in your developments, including following OWASP recommendations?#

Regular developer training, internal best practices, and regular penetration testing by external parties according to OWASP are implemented to ensure state-of-the-art security measures are in place.

Do you conduct regular audit and penetration testing on your app to ensure its security?#

How do you ensure that your solution and all its components are regularly audited, at least annually, as part of a continuous improvement process? Can we access the audit reports on the services used?#

We were fully TISAX-certified for 3 years without any non-conformities. To appeal to a broader range of industries, Mobile2b is now also ISO 27001 certified.

How do you ensure that regular audits, including penetration tests and configuration audits, are conducted on the solution? Do you consider executing automatic solutions for intrusion tests on cloud services? How do you ensure that any detected gaps are corrected promptly and within a reasonable period according to their criticality?#

We are open to collaborate for additional penetration tests even though we conduct regular penetration tests.