Security FAQ

RIZM has implemented a comprehensive ISMS certified against ISO 27001. The certification covers the full scope of the SaaS platform and services provided to customers. RIZM also participates in the TISAX procedure (Scope ID: A5G4X6-1). The Statement of Applicability (SoA) can be provided under NDA.

Yes, RIZM engages independent third parties to perform regular technical audits, including yearly penetration tests of the platform. Audits are conducted annually for ISO 9001, ISO 27001, and ISO 22301, and every 4 years for TISAX assessments.

ISO 27001 (annual audit), ISO 9001 (annual audit), ISO 22301 (annual audit), TISAX (every 4 years, Scope ID: A5G4X6-1). All certifications cover the full scope of the SaaS platform.

Yes. The infrastructure provider (Google Cloud Platform) maintains SOC 2 and ISO 27001 attestations. RIZM's own reports/attestations can be shared under NDA.

No. RIZM has not been investigated or fined by any data-protection or regulatory authority in connection with an actual or suspected breach of customer data.

AES-256 encryption is applied at the storage layer for all primary data stores, file systems, and backups. Encryption is transparent to the application and managed via Google Cloud KMS. Keys are unique per service and never exposed in plaintext.

All external user interactions are secured using HTTPS with TLS 1.2 or higher (TLS 1.3 under evaluation). All database connections also require SSL/TLS.

Keys are managed via Google Cloud KMS, backed by FIPS 140-2 Level 3 validated Hardware Security Modules (HSMs). Keys are never exposed in plaintext to the application or developers. Access to the key store is strictly controlled by IAM policies with all operations logged. Customer-managed encryption keys (CMEK) are not part of the standard offering.

RIZM offers two models: (1) Standard Model — logical isolation with dedicated database schemas for each tenant; (2) Dedicated Instance Model — physical isolation via a dedicated Cloud SQL instance (physically separate VM). Kubernetes Namespaces and Network Policies enforce workload isolation.

All customer data is hosted and processed within the GCP Frankfurt, Germany region (europe-west3). Encrypted backups are stored in a separate GCP region in St. Ghislain, Belgium (europe-west1). No data processing occurs outside of these EU locations.

Yes, all data can be extracted via REST API compliant with the EU Data Act. Personal data records can be exported in standard formats (JSON, CSV). Data can be permanently and securely erased at the end of the retention period upon contract termination. GDPR 'right to be forgotten' processes are supported.

Access is governed by least privilege and controlled via integrated IAM and RBAC. Access is granted exclusively to authorized customer staff. Limited named RIZM support personnel may require temporary, monitored access for troubleshooting, which is logged and audited.

RIZM-built and validated reference scenarios are locked against modification; the customer's own scenarios remain freely editable.

Yes. All data is hosted and processed within the EU (GCP Frankfurt, backups in Belgium), a qualified Data Protection Officer is appointed, and a Data Processing Agreement (DPA) with technical and organisational measures (TOMs) is available. GDPR data-subject rights, including 'right to be forgotten', are supported.

Yes, a qualified DPO (Manuel Mueller, manuel.mueller@rizm.de) has been appointed to oversee GDPR compliance and all data protection activities.

Only minimal user-account data is stored to operate the platform — typically name, business email, and assigned role for authentication and RBAC. No special-category personal data is required. Where SSO is used, RIZM does not store user passwords.

Yes. Technical and organisational measures are in place (ISO 27001 ISMS, encryption at rest/in transit, RBAC/least privilege, access logging). Documented processes address data-subject rights and secure deletion of personal data at the end of the retention period or on demand. A documented personal-data breach process is in place, with affected customers notified without undue delay in line with GDPR.

Yes, the platform supports seamless integration with enterprise IAM systems via SAML 2.0 and OpenID Connect (OIDC). This allows integration with IdPs like Azure Active Directory and ensures centralized user management. RIZM never stores or manages customer user passwords when SSO is used. SSO is live in production at customers including BMW and Schaeffler.

For SSO users, MFA policies are inherited from the customer's Identity Provider. For platform-managed administrative accounts, MFA is mandatory and enforced. MFA is a non-negotiable requirement for all RIZM personnel with privileged access to any production systems.

Access is governed by a granular Role-Based Access Control (RBAC) model. Roles are assigned based on least privilege. User attributes and IdP groups can be mapped to roles for automated provisioning. Customer administrators have full control over assigning roles; RIZM personnel cannot view or modify these assignments.

Roles include: Global Admin (manages all systems), System Admin (per-tenant administration), Editor (creates/modifies data), Approver (approves optimizations), and Viewer (read-only access). Global roles can be synchronized via SSO; system-specific roles are managed within RIZM. One account can be connected to multiple sites.

Lifecycle management is automated via SSO. Provisioning and de-provisioning occur based on the user's status in the central IdP, ensuring immediate access revocation for departed employees. RESTful APIs are also available for custom provisioning workflows. Sessions can be invalidated server-side immediately, so a revoked access takes effect at once rather than after a token expires.

All communication between services within the private GKE cluster is encrypted. Authentication is managed using GCP's Workload Identity, which provides secure, short-lived, auto-rotated credentials based on least privilege, avoiding static keys.

RIZM operates on a Zero Trust model with no standing access to production environments. All default access is denied. Emergency access requires an audited 'Break-Glass' procedure following a 'Four-Eyes Principle' (dual approval). Time-bound credentials are generated upon approval, and direct SSH access to production nodes is prohibited.

Yes, a comprehensive RBAC model enforces segregation of duties. The Four-Eyes Principle is applied for all code deployments (Dev and Production). Privileged roles are granularly defined (e.g., Database Administrator, Site Reliability Engineer) with permissions strictly limited to job function. Access is reviewed regularly.

All commands executed and actions taken during privileged sessions are immutably logged and subject to mandatory review and audit. IAM policies strictly control access, and all administrative actions are captured in detailed audit logs.

All cryptographic keys, API keys, and application secrets are stored in Google Secret Manager with encryption at rest, fine-grained access control, and detailed audit logging. API tokens have expiration dates and can be IP-restricted for additional security.

Yes, an SSDLC is in place, incorporating mandatory security training for developers, threat modeling for new features, secure coding guidelines, and automated security testing (SAST/DAST) in the CI/CD pipeline. Development practices align with the OWASP Top 10.

A bi-weekly release cycle is used for standard updates via a zero-downtime blue-green CI/CD pipeline. Critical security vulnerabilities are patched outside the normal cycle with an internal SLA to patch within 24 hours of confirmation. The blue-green deployment strategy provides immediate rollback capability. A Four-Eyes Principle (dual approval) is applied to all deployments.

Yes, the platform is built on a modern stack of well-maintained, enterprise-grade open-source and managed cloud services. Automated dependency scanning tools are integrated in the CI/CD pipeline to continuously monitor all third-party libraries for known vulnerabilities.

Infrastructure runs on Google's Container-Optimized OS (COS), a minimal, hardened OS designed for security. All configurations align with CIS benchmarks. No unnecessary software or ports are present. Automated update channels ensure timely security patches.

Interfaces are: (1) the Web Application, (2) REST APIs for data push/pull and time-series integration, and (3) optional SFTP. All use standard protocols (HTTPS, REST, SFTP) — no proprietary protocols. No remote-access backdoors exist. API access uses token-based authentication with configurable expiration and optional IP restriction, governed by RBAC; all API activity is logged.

All file transfers occur over encrypted HTTPS and require authentication, with uploads scoped to the authenticated tenant. Uploaded files are validated against an allowlist of permitted content types, a 50 MB size limit, and server-side filename sanitization to prevent path traversal. Dedicated content-level anti-malware scanning of uploaded files can be added.

Yes. Machine learning is used for forecasting and optimization; core optimization uses deterministic algorithms (the Gurobi solver, which runs internally within RIZM's GCP environment with no external data exposure). Optional LLM capabilities (the RIZMO agent, via Google Vertex AI) run entirely within GCP Europe. External REST APIs are used strictly for fetching weather and spot-market data.

Customer data is not shared with third-party AI providers and is not used to train external models. Tenant data segregation and GDPR controls apply equally to AI features.

The infrastructure resides within a dedicated Virtual Private Cloud (VPC) isolated from the corporate network. Critical backend services (databases) are isolated in private subnets with no direct internet access. All internet traffic terminates at a managed API gateway in a public subnet. A logical DMZ architecture is implemented.

Yes, through the use of API Gateways, authenticated service-to-service communication via Workload Identity, Kubernetes Network Policies enforcing 'deny-by-default' micro-segmentation, and no standing privileged access.

The platform is protected by Google Cloud Armor, which functions as a Web Application Firewall (WAF) and provides advanced DDoS mitigation at the network edge. It protects against common web exploits including the OWASP Top 10.

Yes. Geo-based access restrictions (country/region rules) can be configured on request via Google Cloud Armor.

Google Data Centers enforce strict access control via 24/7 security personnel, multi-factor biometric identification, electronic logging, and high-definition video surveillance. RIZM personnel do not have physical access to data centers.

Yes, Google data centers feature redundant power, cooling, and advanced fire detection and suppression systems with environmentally-safe suppression agents. Hardware processing sensitive data is kept in locked cabinets or cages.

RPO is 24 hours (daily encrypted backups). RTO is 4 hours. Point-in-Time Recovery (PITR) is enabled. Automated disaster recovery processes are tested quarterly. Backups are stored in a geographically separate region (Belgium) and are immutable for their retention period.

Standard SLA is 99.9% uptime. Higher availability options are available at additional cost. A hot-standby production environment in a second region can be architected for custom BC plans.

Yes, RIZM maintains formal BC/DR plans (ISO 22301 certified). Plans cover procedures for responding to and recovering from disruptions, including roles, activation criteria, and communication procedures. Cross-region disaster recovery architecture enables failover to the Belgium region.

Comprehensive structured logging captures user ID, source IP, timestamp, action (login, data export, configuration/admin changes), and outcome (success/failure) for all key operations. All CRUD operations on key data entities are logged. Logs are encrypted at rest and access is restricted via IAM roles. Change history is held in 49 immutable audit tables and is filterable by user, period, site, and object type.

Yes, logging is clearly separated by tenant after authentication. Before login, only minimal actions are possible (language change, ticket creation). If a dedicated Kubernetes cluster is used, logs are completely tenant-specific.

Comprehensive monitoring via GCP Security Command Center provides threat detection, vulnerability scanning, and security posture management. Alerts trigger incident response procedures. A dedicated security operations team monitors events 24/7. Customer notification occurs without undue delay for confirmed incidents affecting customer data.

Customers are notified immediately for any security incident affecting their data, in accordance with contractual obligations and GDPR. Relevant logs and security event information are made available in standard formats (JSON) to support joint investigation.

Yes. Security events can be exported in standard formats (JSON) for ingestion into the customer's SIEM/SOC. A customer-facing health dashboard (availability, performance, standard metering points) can be enabled on request.

Yes. Customer-initiated penetration testing is supported, subject to coordinated testing plans and rules of engagement to protect the multi-tenant environment. Customers may also run synthetic uptime checks against their tenant endpoint, with source IPs and schedule allowlisted with RIZM beforehand.

All employees receive mandatory information security and data privacy awareness training upon onboarding and annually thereafter. Developers undergo specialized SSDLC training covering secure coding practices, threat modeling, and OWASP Top 10 vulnerabilities. Training completion is tracked for compliance.

Binding security requirements are established for all third-party contractors and suppliers. The primary infrastructure provider (GCP) is monitored via publicly available audit reports and adherence to standards like ISO 27001 and SOC 2. Security requirements for suppliers are designed to be comparable to RIZM's own standards.

Two options exist: (1) central IT integration via an opened firewall port for IT-OT communication, or (2) an Edge Controller/Edge Device near the control systems with LTE/mobile connectivity. The Edge Device communicates with PLCs via Modbus, OPC-UA, or Profibus. Data flows bidirectionally — measurement data pushed to cloud, setpoint commands pushed to the Edge.

RIZM provides setpoint recommendations to PLCs, but the PLC always has final authority. Safety is maintained locally — the PLC rejects infeasible setpoints. RIZM cannot override the PLC; it only makes suggestions the PLC validates against its safety parameters. RIZM has no inbound access to SCADA, PLC, or field level; every connection is initiated from the plant side.

Setpoints are handed over in advance with a validity window of up to 168 hours, so on connection loss the plant continues on the last valid schedule. After the validity expires, the site falls back to a predefined emergency control strategy — the optimization is lost, not the production. Failed handovers are retried up to three times, and the receiver acknowledges each command individually, including the error reason (e.g. unreachable controller or expired validity).