Security and Reliability

Last reviewed: 2026-08-08

RNDBI Work is an invitation-only beta operated by a small team. Rather than answer a security questionnaire with the vague language a young product usually reaches for, this page states plainly what is in place and what is not. Everything in the second list is work in progress, not a hidden defect - a firm evaluating RNDBI Work should be able to weigh both halves before deciding whether the beta is appropriate for its data.

If your firm has a security questionnaire, send it. Questions that this page does not answer should go to legal@rndbi.com.

1. Where the Service runs

Sub-processors. Microsoft Azure is the only third party that processes Customer Data. The current list is maintained in our Privacy Policy, section 3, and we will provide notice before adding another.

2. Data protection

• Encryption in transit - connections to the Service use industry-standard TLS.
• Encryption at rest - Customer Data is encrypted at rest using Azure's default, Microsoft-managed keys.
• Database access - the application connects using a least-privilege database role rather than an administrative account.
• Administrative access - restricted to authorized RNDBI personnel.
• Credential recovery - we maintain an internal break-glass credential escrow practice, so that a single lost administrative credential cannot permanently strand access to infrastructure holding Customer Data.

Record integrity. Trust-accounting controls are enforced in the database rather than in application code. Posted trust transactions cannot be edited or deleted once recorded, by a database-level constraint rather than a UI restriction. This is a recordkeeping-integrity control; it is not a representation that use of the Service satisfies any bar's trust accounting rules. See Terms of Service, section 6.

3. Availability, backup, and recovery

• Backups - automated backups of the Service database are retained on a rolling seven-day window, supporting point-in-time recovery within that window.
• High availability - not enabled. The database runs as a single instance. This is a deliberate cost decision at beta stage, not an oversight, and it means a zone-level failure would take the Service offline until recovery completes.
• Restore testing - a full restore drill has not yet been performed and documented. We will not quote a recovery time objective we have not measured.
• Service level agreement - none is offered. Support is best-effort during business hours. See Terms of Service, section 12.

We would rather publish an unflattering, accurate reliability picture than an uptime number we cannot back.

4. Access, logging, and separation

• Audit logging - creation, modification, and deletion of records are logged.
• Read-access logging - not yet in place. We cannot today produce a "who has viewed this record" report. This is a priority engineering item. See Privacy Policy, section 5.2.
• Onboarding - there is no self-service sign-up. Each firm is provisioned individually by the administrator, and access is granted per engagement.

Separation between firms is currently maintained by controlled provisioning rather than by a boundary the system itself enforces. Access grants are scoped at the project level and issued one firm at a time by the administrator. A system-enforced client-organization boundary is under active development and is the largest single item on our engineering roadmap. Firms whose data-handling requirements depend on a system-enforced boundary rather than an operational one should wait for that work to ship before onboarding.

5. Incident response

If we become aware of a security incident that results in unauthorized access to, or acquisition of, Customer Data, we will notify affected Customers without undue delay and in any event as required by applicable law, with the information reasonably available to us about the nature of the incident, the data involved, and the steps being taken. We will cooperate with your own regulatory or client-notification obligations. This commitment is stated in Privacy Policy, section 7.

A formal, documented incident-response runbook with named roles and escalation paths does not yet exist. It is being written.

6. What we do not have

Stated once, in one place, so nobody has to infer it:

• No SOC 2, ISO 27001, or other third-party security certification. This is a future goal, not a current representation.
• No customer-managed encryption key (CMK) option.
• No per-record read-access logging.
• No tested disaster-recovery runbook and no published RTO or RPO.
• No database high availability or failover.
• No self-service data export. Data retrieval during the beta is a manual, administrator-run process; see Terms of Service, section 8.
• No uptime commitment or service level agreement.
• A single operator. There is no second administrator today, and no documented continuity plan covering a prolonged absence.

7. Contact

Security questions, vendor due-diligence questionnaires, and vulnerability reports: legal@rndbi.com

We will acknowledge a good-faith vulnerability report and will not pursue legal action against a researcher who reports one to us privately and gives us reasonable time to remediate before disclosure.

This page describes the Service as of the date above and will be revised as the items in section 6 are addressed.