Security and trust

What Genba protects, and how you can check it.

Controls the system runs, not only controls written in a policy.

Where data is stored

On the hosted package, data is stored in Google Cloud's Jakarta region (asia-southeast2): the database, documents and secrets.

Every request records which model served it and in which region it was processed. The residency report shows this by month and by department.

Separation between customers

  • Every row of data carries its customer's identity, and the database refuses rows that do not match (row-level security).
  • The website, Genba Admin and customer workspaces run as separate services with their own database logins.
  • Every release is tested with cross-customer requests that must always fail.

Access

  • Sign-in with the company account only (Google Workspace or Microsoft Entra ID). No Genba passwords.
  • Deny by default: a group reaches only the skills, models and collections granted to it.
  • Data labelled RAHASIA is never sent to a cloud model. On the hosted package it is refused.

The audit ledger

Every event, refusals included, is recorded in a per-customer hash chain that cannot be edited. An auditor can recompute every hash with any SHA-256 tool, without access to Genba.

What Cloud Ace staff can see

  • By default: configuration and metadata (status, timings, model), never request content, answers or documents.
  • Emergency access needs a reason and a second staff approver, lasts at most 24 hours, and is recorded in your ledger.
  • There is no "sign in as this user" feature.

Certification

Cloud Ace follows ISO 27001 practice. Genba itself is not certified yet. An external penetration test runs before launch.