Security and trust

Architecture and hosting

The Ringinx platform is built on Google Cloud Platform as a set of managed services — Cloud Run services and jobs, virtual machines, managed databases, and object storage. Customer data is stored in the United States, with us-central1 as the default region. Certain storage services use multi-region configurations that remain within the United States.

Customers are isolated logically at the organization level. Enterprise organizations may additionally elect a customer-owned GCP deployment (BYO-GCP), in which platform components run in the customer's own Google Cloud project and the customer is billed directly by Google.

Authentication and access

End-user authentication methods supported:

• Microsoft Entra ID (Azure AD) Single Sign-On
• Google Workspace Single Sign-On
• Email and password for individual accounts — protected by email address verification and a one-time passcode sent to the account email at every login

Enterprise organizations are required to configure single sign-on to manage authentication at the organizational level. See User and access management for the full lifecycle from individual account through organization claim to enforced SSO.

Individual account authentication. Before first use, each individual account must verify ownership of its email address. At every login, after the password is entered, a single-use one-time passcode is sent to the account's email address and is required to complete sign-in. Passcodes are time-limited, single-use, and rate-limited. Under enforced SSO, password-based login is disabled and authentication is delegated to the organization's identity provider.

Internal access to production. Customer data is accessible only to authorized Ringinx personnel under role-based access controls, and only as required to operate the Services or provide support requested by a customer. Production access is limited to a small number of authorized accounts, with authentication via SSO and multi-factor authentication. Access is reviewed periodically and revoked promptly when no longer required.

Shared responsibility model

Ringinx is enterprise-oriented and built to be SOC 2-ready, with a Type I audit in preparation (see Compliance and certifications). Security is a shared responsibility: Ringinx operates the platform's controls, while your organization operates the complementary controls — proving domain ownership, managing users, and enforcing access policy — that a compliant deployment requires.

The platform supports two operating modes:

• Evaluation mode. Before an organization is claimed, approved-domain users self-register individual accounts. This simplifies product evaluation. Baseline controls still apply (domain allowlist, email verification, one-time passcode at login, encryption, and audit logging), but membership is not yet centrally governed and no administrator is designated. We recommend not placing sensitive or regulated corporate data in Ringinx while in this mode.
• Governed (enterprise) mode. After an administrator claims the organization and enforces single sign-on, membership follows the corporate identity provider, password login is disabled, and access is centrally managed. This is the intended mode for production use, and we encourage administrators to reach it as early as possible.

The division of responsibilities below reflects the customer controls a SOC 2 report refers to as Complementary User Entity Controls. See User and access management for the step-by-step transition and an administrator hardening checklist.

Encryption

• In transit: TLS 1.2 or higher for all customer-facing and inter-service traffic.
• At rest: AES-256, using Google-managed encryption keys by default. Customer-managed encryption key (CMEK) support is on the roadmap for enterprise organizations on customer-owned GCP deployments.

Sub-processors

Ringinx engages the following third-party sub-processors to provide the Services. Additions or material changes are reflected here and in the privacy policy.

Customer data submitted to OpenAI through the OpenAI API is not used to train OpenAI's models, in accordance with OpenAI's API data usage policy.

Website service providers

Separately from the platform sub-processors above, the marketing website uses the following providers. They process only website form submissions and anti-spam signals — not customer platform data.

Data handling

Data classification

Customer data — including user-provided content, prompts, responses, configurations, and integration data — is classified as confidential and handled accordingly.

Retention

Customer data is retained for as long as a customer's account is active. Following account closure, customer data is retained for up to 90 days to allow for recovery requests, after which it is deleted, except where retention is required by law or contract.

Export and deletion

Customers may request export or deletion of their data at any time by contacting legal@ringinx.com. Requests are acknowledged within five business days.

Customer-owned cloud (BYO-GCP)

Enterprise organizations may operate Ringinx in their own Google Cloud project and pay Google directly for the underlying infrastructure. In this configuration, customer data does not leave the customer's GCP boundary except via integrations the customer explicitly enables.

Logging and monitoring

Platform components emit application logs, audit logs, and infrastructure metrics into Google Cloud's logging and monitoring services. Audit logs capture authentication events, authorization decisions, configuration changes, and access to sensitive operations. Logs are retained for a minimum of 30 days, and longer where required for investigation or compliance.

Vulnerability management

• Dependency scanning. Third-party dependencies are scanned on every change. Known critical and high-severity vulnerabilities are remediated on a defined schedule.
• Container and image scanning. Container images are scanned for vulnerabilities prior to deployment.
• Patch management. Operating system and runtime patches are applied on a regular cadence; critical security patches are expedited.
• Independent penetration testing. Planned. Summary results will be made available to qualified prospects under NDA once completed.

Change management

• All production changes are made through version-controlled code reviewed by at least one engineer other than the author.
• Changes are deployed through automated CI/CD pipelines with automated tests and approval gates.
• Direct production access is restricted; manual changes follow a documented break-glass process and are logged for review.

Incident response

Ringinx maintains an internal incident response process for identifying, containing, eradicating, and recovering from security incidents. The process includes severity classification, on-call escalation, customer communications, and post-incident review with corrective actions.

Affected customers will be notified without undue delay following confirmation of an incident that affects their data, and in any event as required by applicable law and contract.

Business continuity and disaster recovery

Ringinx performs regular backups of customer data and platform state. Backups are stored in multi-region storage within the United States to support recovery in the event of an incident affecting a single region.

Recovery objectives and procedures are documented and reviewed periodically. Specific Recovery Point Objective (RPO) and Recovery Time Objective (RTO) commitments are made available to enterprise customers under contract.

Personnel security

• Personnel with access to customer data are bound by confidentiality obligations.
• Background checks are conducted prior to granting production access, where permitted by law.
• Security awareness training is provided at onboarding and at regular intervals thereafter.
• Access is provisioned based on role and revoked promptly upon role change or departure.

Compliance and certifications

Ringinx applies widely accepted security practices regardless of formal certification status. Current roadmap:

Documents available under NDA

The following documents are available to qualified prospects and customers upon execution of a mutual non-disclosure agreement. Contact legal@ringinx.com to request.

• SOC 2 report (once available)
• Independent penetration test summary (once available)
• Data Processing Addendum (DPA) — template
• Information Security Policy summary
• Certificate of cyber liability insurance (once placed)

Vulnerability disclosure

Security researchers and customers may report suspected vulnerabilities to legal@ringinx.com. Reporters are asked to provide a clear description and steps to reproduce, and to refrain from public disclosure until a remediation has been deployed.

Security contact

For security inquiries, vulnerability reports, and audit requests, contact legal@ringinx.com.

Last reviewed: 2026-07-18.