Richard · GoatBytes.IO
Security & controls packet
Built to support your organization's confidence in Richard. Explore the safeguards protecting your data, the controls governing access, and the commitments guiding our use of AI—all in one place for your security review.
- Last reviewed
- October 1, 2026
- Contact
- security@richard.law
1. Compliance standing
HIPAA
ActiveSecurity Rule compliant. BAA available.
Richard supports organizations handling protected health information with documented administrative, physical, and technical safeguards under the HIPAA Security Rule. Our program includes a risk analysis, written policies, a designated Security Official, workforce training, encryption, audit logging, and tested incident-response procedures. Signed BAAs cover Google Cloud and Anthropic. A Business Associate Agreement and supporting documentation are available for organizations that need them.
SOC 2 Type II
AlignedControls mapped to the Trust Services Criteria. No report issued.
Our controls map to the SOC 2 Trust Services Criteria across access management, audit logging, encryption, availability, backups, change management, secrets, and vendor oversight. Supporting documentation is available for your organization's security review.
SOC 2 alignment describes our control framework. We have not engaged an auditor. Contact security@richard.law for supporting documentation or to discuss an attestation requirement.
CCPA / CPRA
AlignedCalifornia consumer privacy rights supported.
Access, deletion, and correction are available to account holders as self-service, without an administrator in the loop. We do not sell or share personal information, and we run no cross-context behavioural advertising.
US data residency
ActiveAll customer data stored in the United States.
Primary storage is Google Cloud region us-central1 — Cloud SQL for the database, Cloud Storage for uploaded documents. The disaster-recovery copy of uploaded documents is held in us-east1. No customer data is stored outside the United States.
2. Controls
Our security program brings together access management, audit logging, encryption, recovery, and operational oversight to protect your organization's work.
2.1 Access control
Organization roles and secure sign-in help your team manage access to its work.
Role-based access within an organization
Organization roles include owner, admin, billing admin, member, viewer, guest, and custom roles. Permissions govern access to organization-owned records, with automated checks to review changes to the role matrix.
Authentication
Passwords are hashed with bcrypt at cost 12. Five failed attempts inside fifteen minutes lock the account. Password resets go through a time-limited email link, and changing a password or signing out invalidates every existing session.
Session handling
Session cookies are HttpOnly, Secure, and SameSite-scoped. Access tokens are short-lived and refreshed against a separate, path-scoped refresh cookie.
Pair these session protections with your organization's workstation lock policy; sessions remain active during inactivity.
Multi-factor authentication
Available today through single sign-on: once your organization's domain is provisioned, your team signs in with Google Workspace or Microsoft 365 and your identity provider's MFA policy applies.
2.2 Audit logging
Traceable records of authentication and access to customer records.
Append-only by construction
Audit entries record the actor, action, target, and, where applicable, before-and-after values. Database controls prevent ordinary application operations from updating or deleting entries.
Administrative database operations and account-erasure workflows sit outside these application-level protections.
Authentication and record-access events
Six authentication actions and seven record-read actions are recorded, along with rate-limit blocks. A documented set of review queries answers 'who accessed this record, and when' without engineering involvement.
Retention
Our retention policy sets a six-year minimum for audit history and infrastructure data-access logs, aligned with the HIPAA documentation-retention period.
The retention minimum is policy-based; automated enforcement is pending.
Audit coverage
Audit logging focuses on authentication and individual record access. Incremental search and index requests are excluded to keep review records focused.
Operator database access is logged at the connection level.
2.3 Encryption
Encrypted storage and client connections on Google Cloud under a signed BAA.
At rest
AES-256 using Google Cloud's managed encryption, the default for Cloud SQL and Cloud Storage, under our signed Google Cloud BAA.
In transit — public
TLS 1.2 or higher for every client connection, terminated by Google Cloud Run's managed HTTPS.
In transit — internal
Cloud SQL requires encrypted connections and operates without a public IP. Organization policy prevents public IP assignment.
The document-text cache is isolated within a private VPC with no public route; cache-level TLS and authentication are pending.
2.4 Availability & recovery
Regional availability, daily backups, and tested data recovery.
Backups
The database runs in a regional high-availability configuration with automated daily backups. Uploaded documents are versioned, carry a 30-day soft-delete window, and are copied daily to a second region.
Tested recovery
The latest database restore drill completed in 7 minutes 24 seconds. Document-store recovery completed in 13 minutes 46 seconds with zero data loss.
These drills cover data restoration; full application failover is outside the tested scope.
2.5 Change management
How code reaches production.
Pipeline
Changes build and deploy through CI. Formatting, linting, and static type checking run as pre-commit hooks and again in the pipeline. Specific compliance guarantees carry dedicated regression tests that fail the build if the guarantee is removed.
Secrets
Production secrets live in Google Secret Manager and are mounted at runtime. No secret is committed to the repository.
2.6 Data protection
Controls for application logging, organization access, and uploaded files.
Content logging safeguards
Application logging excludes user-content fields, with redaction across production processes and regression checks that flag reintroduced content fields.
Exception-text redaction uses pattern matching; clinical narrative is not reliably detected.
Tenant isolation
Records belong to an organization, and queries are scoped to that organization. Server-side authorization checks enforce access by resource type.
The extracted-text cache is shared for byte-identical uploads across organizations.
Upload validation
Uploaded files are validated by magic-byte inspection rather than by their declared MIME type or file extension.
2.7 Incident response
Documented response procedures, clear responsibilities, and tabletop exercises.
Playbook
A written incident-response and breach-notification plan with named roles, severity triage, a first-four-hours runbook, and the 45 CFR §164.402 four-factor breach risk assessment. Customer notification obligations under an executed BAA run on a 30-day window.
Exercised
Tabletop exercises test the response plan, with findings tracked through follow-up work to strengthen preparedness.
Reporting channel
security@richard.law is monitored, with an RFC 9116 record at /.well-known/security.txt and a published disclosure policy carrying safe-harbour terms for good-faith research.
2.8 Vendor management
Documented vendor relationships and quarterly reviews.
Register of record
A sub-processor register lists every external service that receives or processes customer data, the class of data it sees, and its BAA status. It is reviewed quarterly and updated in the same change as any vendor addition or removal.
Published
The customer-facing mirror of that register is the sub-processor page on this site. It is the URL our Business Associate Agreement points at.
3. Sub-processors
Anthropic
BAA signed- Purpose
- Generates Richard's responses.
- Data processed
- Your prompts, conversation history, and the contents of documents you upload for analysis.
- Location
- United States
Richard's language model runs on Anthropic under a signed BAA. Anthropic does not train on your content.
Google Cloud Platform
BAA signedGoogle LLC
- Purpose
- Application hosting, database, document storage, secrets, job scheduling, and logging.
- Data processed
- All customer data, encrypted at rest.
- Location
- United States (us-central1; us-east1 for disaster recovery)
Production services are checked against Google's HIPAA-covered products list each quarter. Storage encryption and private networking protect the infrastructure; the controls section describes transport security by service.
OpenAI
BAA signed- Purpose
- Generates the numeric embeddings behind case-law search, reference lookup, and tool discovery, and serves OpenAI chat models when one is selected.
- Data processed
- Search queries as entered, model-generated tool lookup queries, image-generation prompts, and chat content when an OpenAI model is selected. Uploaded documents, attachments, and extracted document text are not sent for search.
- Location
- United States
Processed under our signed BAA, in a dedicated OpenAI organization with HIPAA support enabled. Richard asks OpenAI not to store responses. BAA-scoped accounts restrict chat to providers with an executed BAA.
Stripe
No PHI — BAA not required- Purpose
- Subscription billing and invoicing.
- Data processed
- Billing contact details and subscription identifiers. No case content, no document text, no matter titles.
- Location
- United States
SendGrid
No PHI — BAA not requiredTwilio Inc.
- Purpose
- Transactional email — sign-up, password reset, invitations, billing and account notices.
- Data processed
- Email addresses and account details. Notification emails state that an event occurred and name the type of resource involved; they never quote conversation, report, or document content.
- Location
- United States
Enforced in code, not by convention: a regression test fails the build if free-text content is reintroduced into an email body.
People Data Labs
No PHI — BAA not required- Purpose
- Professional contact enrichment in the contact book.
- Data processed
- Business contact details only — name, work email, organization, LinkedIn URL.
- Location
- United States
Enrichment refuses any contact that is a claimant party on a case, or that carries a claimant category, before any identifier is extracted. Every attempt is audited. No case, injury, note, or document data is ever sent.
Google / Microsoft identity
No PHI — BAA not required- Purpose
- Optional single sign-on.
- Data processed
- Identity only — name and email — when your organization uses SSO.
- Location
- United States
4. AI governance
Your data does not train anyone's model
Your prompts, conversations, and uploaded files are not used to train or fine-tune AI models. Richard has no training pipeline, and our providers' commercial API terms exclude training by default. Anthropic processes case content under our signed BAA.
Processing to deliver your service
Providers process your content to answer requests and may retain it to deliver the service. Limited processing may also support trust, safety, and customer support. These uses are separate from model training.
BAA-scoped chat protection
For organizations configured as BAA-scoped, chat requests are restricted in code to providers with an executed BAA. Requests to other chat providers are blocked before processing. This protection applies to chat model selection; search and image-generation data flows are detailed in the sub-processor section. Contact us to configure BAA scope for your organization.
Organization settings enforced server-side
BAA scope is determined from your organization's server-side record, keeping provider restrictions under centralized control.
Purpose-built calculations and sourced research
Ratings, indemnity, commutations, and present value use deterministic calculators implementing the rating schedule and Labor Code. Case law and statutes come from curated databases built from official sources, with citations for your review.
You direct the work
Richard helps you research, calculate, and draft. You review the work and decide how to use it; Richard does not independently file, serve, or transact on your matters.
5. Frequently asked questions
- Will you sign a Business Associate Agreement?
- Yes. We offer a BAA for organizations handling protected health information whose client relationships require one. Email security@richard.law for our agreement and help coordinating your organization's requirements and account setup.
- Do you train AI models on our case files?
- No. Your prompts, conversations, and uploaded documents are not used to train or fine-tune models by Richard or our providers. Our AI governance page explains how content is processed to deliver the service.
- Are you SOC 2 certified?
- Our controls are aligned with the SOC 2 Trust Services Criteria; an independent report has not been issued. We can provide control documentation for your review. If your organization requires a SOC 2 report, contact us to discuss requirements and timing.
- Are you HIPAA certified?
- Richard self-attests to HIPAA Security Rule compliance, supported by documented safeguards, workforce training, a risk analysis, tested incident-response procedures, and signed BAAs with Google Cloud and Anthropic. HHS does not issue HIPAA certifications. Contact us for the documentation supporting our program.
- Where is our data stored?
- In the United States, on Google Cloud — region us-central1 for the database and document storage, with a disaster-recovery copy of documents in us-east1. No customer data is stored outside the United States.
- Who at your company can see our data?
- Access is limited to service personnel supporting a specific customer request or responding to an incident. Application record reads are audited, and direct operator database access is logged at the connection level.
- Can we get our data out?
- Yes. An organization owner can request a full export — conversations, messages, and files — generated asynchronously and delivered by a signed URL that expires after 24 hours.
- What happens when we delete an account?
- Account deletion is self-service, protected by a password and confirmation phrase. The account locks immediately, with a seven-day recovery window available through a one-time email link. After that, user records are permanently deleted and uploaded files are removed from live storage. Recoverable document copies age out over roughly 44 days through versioning and soft deletion. Organization deletion follows the same seven-day window; audit-linked records are handled as described below.
- Is anything kept after deletion?
- Audit history is retained to preserve accountability. Organization records referenced by audit entries are soft-deleted; user records are permanently deleted. Our BAA provides for de-identification of retained organization records, with the implementation of that workflow pending. Contact us to review retention and termination requirements for your organization.
- Do you enforce multi-factor authentication?
- Yes, through single sign-on. Once your organization's domain is provisioned, Google Workspace or Microsoft 365 applies your identity provider's MFA policy. Choose SSO when your organization requires MFA; native email/password sign-in does not include in-app two-factor authentication.
- Has the application been penetration tested?
- We run static analysis and dependency scanning in CI and maintain a public vulnerability-disclosure program with safe-harbor terms for good-faith research. An external penetration test has not yet been completed or scheduled.
Richard is a workers' compensation research platform operated by GoatBytes.IO. It is not a law firm and nothing here is legal advice. Questions, corrections, and questionnaires to security@richard.law.