How VanVox protects your information

1. In short

• dashboard access requires signing in, and account features are protected behind authentication;
• a business can only see records belonging to that business — server-side checks enforce this;
• repeated WhatsApp deliveries are deduplicated, so the same message does not create duplicate records;
• heavy work runs in background jobs designed to be safe to retry;
• quotes and invoices are only finalised after your explicit confirmation;
• ordinary logs are designed to avoid your message content and customer records;
• some controls — hosting, backups, provider regions and monitoring — depend on deployment and still need verification;
• no formal certification is claimed, and no system can guarantee zero risk.

2. Protecting your account

Access to the VanVox dashboard is protected by authentication:

• dashboard and account features require you to sign in;
• sensitive areas additionally require a verified account before they can be used;
• passwords are stored using one-way hashing through Laravel’s supported authentication stack — they are never stored as plain text;
• sessions are handled by the framework’s session protections rather than a home-grown scheme;
• sign-in and other sensitive endpoints are rate limited to slow down abusive or automated access;
• each account is bound to its own business, so account access does not extend to other businesses.

We deliberately do not publish the exact session durations, lockout thresholds or rate-limit values, because those specifics would help an attacker more than they help you. If you ever think your account has been accessed by someone else, contact us straight away.

3. Authorisation and tenant isolation

Signing in is only the first step. Every request is also checked against what your business is allowed to see:

• you can only access records that belong to your business;
• server-side authorisation checks protect documents, customers, suppliers and stored files;
• a public or shareable identifier is never treated as a substitute for authorisation;
• hosted invoice links are scoped to a single document and can be revoked, so a shared link can be turned off.

These checks run on the server, not just in the browser, so they cannot be bypassed by editing a link or a page. We do not claim any formal multi-tenant certification; we describe the isolation the application actually enforces.

4. WhatsApp and message integrity

Because VanVox works over WhatsApp, it is built to handle the messy realities of message delivery without corrupting your records:

• inbound provider message identifiers are used to prevent the same message being processed twice;
• a webhook that is delivered more than once should not create duplicate documents;
• outbound messages use deduplication controls to avoid sending you the same thing twice;
• heavy processing runs in isolated background jobs rather than while a webhook is waiting;
• those jobs are designed to be safe to retry, so a transient failure and retry does not double up your data.

We do not publish the provider validation secrets, the internal structure of message records, or the names of the background jobs involved.

5. Application and data controls

Several controls protect the integrity of your records inside the application:

• structured validation checks details before they are stored;
• explicit confirmation is required before a quote or invoice is finalised — nothing is committed on your behalf without it;
• security and audit event records help us detect and investigate problems;
• failed background-job records have a bounded retention window and are pruned on a schedule, rather than being kept indefinitely;
• access to stored files is controlled rather than open;
• hosted document links can be revoked;
• retention and deletion routines run on a schedule.

Some particularly sensitive fields are encrypted at rest. Specifically, the application encrypts stored bank-account details, hosted-link access tokens and saved payment-provider credentials. This is selected-field encryption: we do not claim that all data is encrypted at rest. Whether whole-disk or whole-database storage is encrypted depends on the hosting and storage configuration used to deploy the service, and that deployment-level encryption is a configuration matter we do not assert as verified on this page.

6. Transport and provider security

• the production service is expected to be served over HTTPS, so traffic between your browser and VanVox is encrypted in transit;
• WhatsApp message delivery is handled through Meta;
• AI transcription and extraction may involve OpenAI;
• hosting, storage, email, monitoring and backup providers depend on how the service is deployed;
• the providers we can confirm, and the details still being verified, are recorded in our subprocessor register.

We do not independently claim on this page that production HTTPS, a specific provider region, or a particular contractual safeguard has been verified. Some processing may take place outside the United Kingdom. Provider security, regions and transfer safeguards remain subject to the published subprocessor register and to human and legal verification, and not every provider system is under VANVOX LTD’s direct control.

7. Privacy-safe logging

Our logging is designed to help us run the service without capturing the content of your work:

• ordinary logs are designed to avoid message bodies, transcripts and customer records;
• safe identifiers, event types, timestamps and status information may be recorded instead of raw content;
• security and audit records may be retained for operational and legal reasons;
• failed background-job records have a bounded retention window.

Minimising the raw information that can be held in queued job payloads remains an internal assurance area we continue to improve, and our retention controls are designed to bound how long such records can persist. We do not publish the internal field names or example payloads used in our logs.

8. Secrets and access management

• secrets and credentials belong in deployment secret and environment management, not in source control;
• least-privilege access is the intended operating principle — people and systems should have only the access they need;
• credentials are rotated when there is any reason to believe they have been compromised;
• access to the production environment should be limited to authorised operators.

These are operational practices that people are responsible for, rather than something a public page can prove. We describe them at a high level and do not name the specific tools, hosts or accounts involved.

9. Backups and recovery

• backups are an operational safeguard intended to help recover from data loss;
• the actual backup provider, encryption, region, retention period and restore testing depend on deployment and require verification;
• backups may retain information for a limited period after it is removed from the live service;
• any destructive rollback is treated as a reviewed operation rather than a routine one.

We do not claim that every backup is encrypted, or that restore procedures have been tested, until that has been verified in the running environment. We would rather be honest about this than imply a guarantee we cannot yet evidence.

10. Retention and deletion

• source artefacts (such as voice notes and receipt images) and confirmed business records follow different lifecycles;
• automated purge controls remove source artefacts on configured schedules;
• you can request deletion of your information;
• hosted document links can be revoked;
• we may keep limited records where the law or a legitimate operational reason requires it;
• deletion from the live service is not the same as immediate removal from every backup copy — provider and backup copies may expire on separate cycles.

For the full picture, see the data-lifecycle walkthrough and the data deletion instructions.

11. Reporting a security issue

If something looks wrong, please tell us. You can report:

• suspected account compromise or unauthorised access;
• a document link that appears to be exposed or shared with the wrong person;
• suspicious activity on your account;
• a privacy incident;
• a potential vulnerability in the service.

A security or privacy concern is handled differently from ordinary product support. If you are not sure which it is, report it and we will route it to the right place. It helps to tell us the affected page or feature, roughly when you noticed it, and what you observed.

Report a suspected security issue privately to support@vanvox.co.uk, or use the routes on our contact page. For a privacy matter you can also reach us at privacy@vanvox.co.uk.

We acknowledge reports we receive with a short reference and assess them through an internal process, without repeating anything sensitive you sent back to you. Reports are triaged according to the operational processes we have available. We do not operate a bug-bounty programme, we do not promise a guaranteed response time during the beta, and we do not claim on this page that a mailbox is staffed around the clock. Support is handled on a reasonable-efforts basis during the beta. VanVox does not currently offer a formal SLA, guaranteed response time or round-the-clock support.

12. Your part in staying secure

Security is shared. VanVox implements the controls above, and a few simple habits on your side keep your account and your customers’ information safer:

• protect your account credentials and do not share them;
• use trusted, up-to-date devices to access VanVox;
• review the recipient before you send a document;
• remove access for staff who leave your business;
• report suspicious activity promptly;
• avoid sharing unnecessary sensitive information;
• check your commercial records before you confirm them.

These steps help, but they do not transfer VANVOX LTD’s own responsibilities to you. We remain responsible for the controls we operate; this section is about the parts that only you can control.

13. Assurance limitations

To keep this honest, we separate what is built and tested from what still depends on people and deployment:

Application security controls implemented

Authenticated access, tenant isolation, inbound and outbound deduplication, retry-safe background processing, validation, explicit confirmation, selected field encryption, privacy-safe logging, bounded failed-job retention, controlled storage access, hosted-link revocation, and retention and deletion controls are implemented in the codebase and covered by automated tests.

Deployment and provider verification outstanding

Hosting, storage, transport, provider regions, backup handling, monitoring and secret management depend on the deployed environment and still require environment-specific verification. They are not proven by this page.

No formal certification claimed

VANVOX LTD does not claim any formal security certification or independent audit result. No system can guarantee zero risk, and nothing on this page is a warranty.

This statement describes controls that are built and honest limits that remain. It reflects an internal readiness review and will be updated as those checks are completed.