Security posture

Business records, financial inputs, valuation outputs, advisor review materials, and data room documents are intended to be private by default and available only to authenticated users with appropriate access.

Database policies and server-side checks should scope access to the business owner, authorized advisors, and approved buyer workflows. Public access should be limited to explicit buyer-safe teaser data selected by the owner.

Public teaser pages are designed to expose only owner-approved, buyer-safe fields. Full financial detail, uploaded documents, and sensitive company records should remain behind authenticated access and owner-controlled permissions.

Buyer request workflows are designed to collect buyer information before sensitive materials are shared. Owners should confirm confidentiality obligations before granting deeper access to financial statements, data room files, customer details, or operational records.

Accounting integrations use provider OAuth flows. ValuRight.ai requests the practical scopes needed to import financial reports, connection metadata, and account-level data used for mapping and normalization.

Connection tokens and imported financial data are handled as sensitive business information. Customers can revoke access through the accounting provider and supported product controls.

Financial documents and data room files should use private storage policies. Database access should enforce account ownership, advisor permissions, and buyer-view limitations at the server or database layer.

The product includes audit records for sensitive actions such as accounting connection events, imports, file access changes, advisor access changes, and buyer request handling where those workflows are implemented.

ValuRight.ai should use encrypted transport, managed authentication, private storage buckets for confidential files, token encryption for accounting credentials, least privilege database policies, and environment-specific secrets for integrations.

Security reviews should include dependency updates, provider configuration checks, database policy review, API route review, and verification that public pages do not expose owner-private data.

Production database backups should be enabled on the active backend before broader customer launch, with a documented retention window and restore owner. Where available, point-in-time recovery and private storage recovery/versioning should be enabled for financial data and data room materials.

Restore testing should be performed against a non-production database before launch. A restore test should verify that an owner account, business profile, financial years, valuation output, buyer settings, and uploaded-file metadata can be recovered without exposing another customer's data.

Restore incidents should preserve evidence, identify the affected provider project, validate recovered records, reload the database schema cache when needed, and document the restore point, data-loss window, validation result, and follow-up actions.

Customers should use strong account credentials, limit advisor and buyer access to people who need it, avoid uploading unnecessary sensitive personal data, review buyer-safe publishing settings before sharing a teaser, and revoke integrations or user access when no longer needed.

If you believe you have found a security issue, do not access, download, modify, or share data that is not yours. Report the issue through the support contact listed in your account or onboarding materials.

This security posture page is a transparency summary, not a guarantee that a system is free from risk. It should be reviewed by counsel and security advisors before public launch claims are finalized.