Skip to content
BeryX

Security and Trust

What we guarantee, what we don't have yet, and when

BeryX reads your data to measure its quality — it never changes it. This page shows the controls in place today, with evidence in the code, and the real status of each certification.

We do not yet hold ISO 27001 certification or a SOC 2 report. The status and dates of each are below, and change here when they change in reality.

Last reviewed: 7 October 2026

Read-only, in three boxes

Data leaves your sources for reading only, is measured in the EU, and only reaches an AI model if AI is switched on.

  1. 01

    Your sources

    Databases, warehouses and SaaS tools. BeryX only reads: metadata, aggregates and limited samples, through a read-only service user.

    Read only: writes are refused in code before they reach the network.

  2. 02

    BeryX (GCP, EU)

    Measures quality and proposes fixes on Google Cloud europe-west1. Encrypted credentials, per-workspace isolation, audit log.

    Only what the requested analysis needs; generated content is always labelled as AI.

  3. 03

    AI (optional)

    By default only Anthropic receives data, as limited, anonymisable samples. It can be switched off, or run on Bedrock/Vertex in your own cloud account.

Controls in place

Encryption

In place
  • Source credentials and integration tokens are encrypted with Fernet before they are stored, with key rotation (MultiFernet) and idempotent re-encryption. They are never returned by the API or written to logs.
  • In transit: TLS for the app, the API, the database and messaging (amqps). For sources, HTTP APIs, Fabric and SQL Server with Entra ID always verify the certificate. PostgreSQL and MySQL verify it by default on new connections. The exceptions are flagged in the app: connections older than this rule and connections without verification confirmed by an admin, which are recorded in the audit log. With SQL authentication, SQL Server is encrypted without validating the certificate.
  • At rest: database, secrets and images encrypted by Google Cloud with Google-managed keys. We do not yet offer customer-managed keys (CMEK).

EU data residency

Partial
  • Application and database on Google Cloud europe-west1 (Belgium), with backups in Google's EU multi-region. Messaging on AWS eu-west-1 (Ireland), carrying internal identifiers only.
  • Platform logs, with the IP address and browser of each request, are kept in Cloud Logging in the global location, so Google may store them outside the EU. The fix, a log bucket in europe-west1, is not done yet.
  • Providers in the USA, with each one's transfer mechanism on the sub-processor list: Anthropic (AI requests), Resend (transactional email), Sentry (application errors, without emails or IP addresses) and Stripe (billing, with processing in the USA). If an admin turns it on, also Voyage AI, with anonymised text for embeddings.
  • From 2026-11-16, the BeryxTech CRM, Twenty, stores contact requests and the business relationship in Frankfurt, but the company is in the USA and may access them from there, under standard contractual clauses.
  • AI requests to Anthropic are processed in the USA, under standard contractual clauses (GDPR Art. 46). To stay in the EU, AI can be switched off or run on Amazon Bedrock (eu-* regions) or Vertex AI (europe-* regions) in your own account — Enterprise plan.

Access control and MFA

Partial
  • Per-workspace roles (RBAC), OIDC single sign-on, scrypt password hashing, login rate limiting and sessions revoked when the password changes.
  • BeryxTech support only enters your workspace with your consent, read-only and for at most 72 hours, and it is logged.
  • TOTP MFA (authenticator app) with single-use recovery codes on password accounts. It is mandatory for organisation admins and BeryxTech staff, and each workspace can require it for every member; on self-serve sign-up it is optional by default. SSO accounts use your identity provider's MFA.
  • No SCIM provisioning yet: accounts join by invitation or on their first SSO login.

Audit log

In place
  • Administrative actions (roles, plans, connections, credentials, tokens, AI policy, support access) are recorded in the same transaction as the change.
  • Searchable and exportable to CSV by workspace admins. Technical logs contain no credentials or customer data.

Backups and disaster recovery

Partial
  • Daily backups and point-in-time recovery (PITR) with 7-day retention, checked automatically on every deploy.
  • If AI fails, the product keeps working in offline mode — proven every night by chaos tests.
  • Single region (europe-west1), with no multi-region recovery plan yet.

Recovery objectives

RPO
Proposed: minutes (within the PITR window); up to 24 h without PITR · not measured
RTO
To be defined — no restore drill has measured it yet · not measured

Secure development and the Factory

Partial
  • Every change goes through mandatory CI: tests, lint, type checks, AI prompt evaluations and versioned database migrations. Each deploy validates production end to end.
  • Python and npm dependency scanning plus image scanning (Trivy) on every PR; failure on critical/high without a recorded exception; CycloneDX SBOM per deploy; monthly vulnerability report. Weekly DAST (OWASP ZAP baseline, passive only) against the website, the app and the API, with a weekly report.
  • In the Factory, code written by AI agents only reaches main after review by a second agent (reviewer ≠ author), a security gate when it touches sensitive surface, and owner approval before work starts.
  • Human approval of every deploy (GitHub production environment with the owner as reviewer), main branch protection, CODEOWNERS and cosign image signing defined as code; there is no evidence yet that the protection and the environment are applied on GitHub. No external penetration test yet.

AI and the AI Act

In place
  • By default, only Anthropic receives customer data. Any other provider only receives metadata or samples that are already anonymised (Presidio, with recognisers for Portuguese tax, social security, IBAN and ID-card numbers).
  • Per-workspace AI policy: switch AI off, restrict models per task, bring your own key, or run Claude in your Bedrock/Vertex account. If that route fails, it degrades to offline — never to BeryxTech's account.
  • AI Act Art. 50: all AI-generated content says so, names the model and provider that answered, and notes it is subject to human review. We export the Art. 10 evidence dossier for customers with high-risk systems.

Sub-processors

The public list states each provider's purpose, region, legal basis, transfer mechanism and DPA. A new provider or a region change is announced 30 days in advance, and during that period a new AI provider receives no data.

See the sub-processor list

Certifications: real status

Planned, in preparation, audit scheduled or obtained. A SOC 2 Type I report is never presented as Type II.

  • SOC 2 Type I

    Planned

    First milestone of the programme (ADR 0010, accepted by the owner on 2026-09-28). Phase 0 under way: GRC tooling (self-hosted Probo, EU) being provisioned and policies being signed; auditor still to be selected.

    since 28 September 2026

  • ISO/IEC 27001:2022

    Planned

    Phase 2 of the programme, after SOC 2 Type I. ISMS policies drafted, not yet approved.

    since 25 September 2026

  • SOC 2 Type II

    Planned

    Requires an observation window of at least 6 months, starting after Type I.

    since 25 September 2026

  • ISO/IEC 27701

    Planned

    Privacy extension; only after ISO 27001 (phase 3).

    since 25 September 2026

  • ISO/IEC 42001

    Planned

    AI management system; only after ISO 27001 (phase 3).

    since 25 September 2026

Data processing agreement (DPA)

The DPA template (GDPR Art. 28) is drafted but has not yet been reviewed by a lawyer. Request it by email: we send it after that review, with the sub-processor list attached.

Request the DPA

Responsible disclosure

  • Report vulnerabilities by email to the security contact. We acknowledge receipt within 3 business days and send a first assessment within 5; the target fix time follows our vulnerability policy (7, 30 and 90 days for critical, high and medium).
  • Test only against your own account and workspace. Do not access third-party data, do not run load or denial-of-service tests and do not use social engineering.
  • We do not run a paid bug bounty. We credit reporters publicly after the fix, if they wish.

Security contact: seguranca@praxis.lbostuff.tech · security.txt

Full policy: scope, response times and safe harbour

External penetration test

We have not had an external penetration test yet. The scope, test accounts and rules are prepared; the provider is not yet contracted. It is planned before the SOC 2 Type I audit and yearly after that; the summary will be published here.

Downloads

Privacy Policy