DRAFT — for solicitor review; not yet in force.
Property Inspector — Data Retention and Backup Policy
1. Purpose
1.1 This policy explains how long MBGW Limited (MBGW) keeps data connected with the Property Inspector service (the Service), how backups are taken and kept, how you can export your data, and what happens to data when a workspace is closed. It forms part of the Terms of Service and the Data Processing Agreement.
1.2 It covers two kinds of data: Customer Data — everything you and your Users put into your workspaces (customers, sites, inspections, photographs, work orders, chat, documents, reports), which we hold as your processor — and subscriber account data, which we hold as controller and which is covered in section 8 and the Privacy Notice.
2. Where your data lives
2.1 Each workspace consists of five parts: its own office database; its own office file store (attachments and documents uploaded to the office), which lives with the office database in the workspace's own application container; its records in the shared API database, tagged with the workspace's identifier; its own prefix in MBGW's object storage for photographs, logos, documents and generated reports; and its own messaging domain for team chat. All of these are hosted on MBGW's estate in the United Kingdom.
2.2 If you connect Google Drive, Google Calendar or Microsoft 365, copies of reports and work orders are also written to your own Google or Microsoft accounts. Those copies are under your control and are not covered by this policy; closing your workspace does not delete them.
3. Retention during the subscription
3.1 While your subscription is active, Customer Data is kept until you or your Users delete it in the Service. The Service does not automatically expire inspection records, photographs or documents. [TBC: any feature that archives or purges old records automatically; none is known at present.]
3.2 Deleting a record in the office or the app removes it from the live workspace. It may persist in backups until those backups expire under section 5.
4. Exporting your data ("Download my data")
4.1 You can request a complete export of a workspace at any time from the subscriber portal using "Download my data" on the workspace's page. Today this sends an export request to MBGW; MBGW produces the export and tells you when it is ready and how to collect it. Exports can be requested throughout the subscription and throughout any closure notice period, and one is produced automatically at teardown. [TBC: a self-service export — produced and downloaded from the portal without contacting MBGW — is not yet built; the wording must not imply it until it is.]
4.2 An export contains: every record belonging to the workspace from the API database, as CSV and JSON files (one per table); the workspace's photographs, logos, documents and generated PDF reports; a curated copy of the office database records (excluding internal wizard, credential and token tables); and team chat message history. Secrets are never included: passwords, API keys, tokens and integration credentials are removed or redacted.
4.3 The export is packaged as a compressed archive, encrypted with a passphrase using AES-256, and digitally signed by MBGW so that you can verify it has not been altered. The passphrase is generated for each export and is held by MBGW in encrypted form; it is not written into the archive or sent with it. MBGW releases the passphrase to the subscriber account holder (or a person they authorise) on request, after confirming their identity. [TBC: delivery of the passphrase without a request to MBGW (portal reveal or email to the subscriber address) is not yet built.]
4.4 Exports are stored on MBGW's UK estate in a location separate from the workspace, so that tearing down the workspace does not remove them. Each export is retained for [TBC: e.g. 90 days] after it is created, after which it is deleted. You can request a fresh export at any time while the workspace exists.
5. Backups
5.1 What is backed up. A workspace backup captures all five parts of the workspace listed in section 2.1: office database, office file store, API database records, object storage and chat history. Unlike an export, a backup is unredacted, because its purpose is to restore the workspace exactly.
5.2 How backups are protected. Each backup is compressed, encrypted with AES-256 under a per-backup passphrase, signed by MBGW and checksummed. Backups are stored in MBGW's object storage on the UK estate and mirrored to MBGW's file server, which is itself mirrored to offline storage. The passphrase is stored encrypted and is never transmitted over the network in clear.
5.3 On-demand backups. MBGW can take a backup of a workspace at any time, for example before maintenance or a migration, and on request. These are retained until deliberately deleted by MBGW; they are not pruned automatically.
5.4 Scheduled backups. Scheduled backups are off by default for a new workspace. When a schedule is set (daily, weekly on a chosen day, or a custom schedule, at a chosen UK time), the Service keeps the most recent N scheduled backups and deletes older scheduled backups after each successful new one. The default value of N is 7; it can be set between 1 and 90. Only scheduled backups are pruned in this way — on-demand backups and exports are never pruned by the schedule. A failed backup never causes an older one to be deleted. [TBC: whether a schedule is set for every new workspace at go-live, and by whom (subscriber or MBGW); at present schedules are set by MBGW on request.]
5.5 Suspended and paused workspaces. Scheduled backups are skipped while a workspace is suspended or paused; existing backups are kept.
5.6 Restoring from backup. You may ask MBGW to restore a workspace from any retained backup. A restore replaces the workspace's current data with the backup's contents [TBC: or restores to a clone alongside the live workspace — confirm what is offered to subscribers]. MBGW will confirm the backup to be used before proceeding. [TBC: whether restores are chargeable.]
5.7 Backups at teardown. When a workspace is torn down, its backups are [TBC: deleted with the workspace / retained for [TBC] days then deleted — confirm the intended behaviour; at present teardown does not remove existing backup archives].
6. Pausing and closing a workspace
6.1 Pause. Pausing a workspace stops the Service for it but keeps all data. Nothing is deleted. Billing continues. You can resume at any time.
6.2 Close. Closing a workspace starts a 30-day notice period. During the notice period the workspace keeps running and you can export your data at any time under section 4. At the end of the notice period (the effective date) the workspace is torn down: a final export is produced, then the workspace is permanently deleted as described in section 7. You can cancel the closure at any time before the effective date and nothing is deleted. Closing a workspace is the only way to end your use of it and stop paying for it; there is no separate cancellation or immediate-deletion option. Billing for the workspace stops at the end of the notice period; where your subscription covers other workspaces that remain open, the subscription itself continues (see the Terms of Service, section 8.6).
6.3 Non-payment. If your subscription lapses for non-payment, the workspace is first suspended (data kept, no access) during a retention period of 30 days after the 14-day period to set up a new Direct Debit, as described in the Terms of Service. If payment is not restored by the end of that period the workspace is torn down with a final export.
7. What teardown deletes
7.1 Teardown permanently deletes: the office database and application container; the office file store; the workspace's prefix in object storage (photographs, logos, documents, reports and integration credentials); the workspace's chat domain and all its message history; and every record tagged with the workspace's identifier in the shared API database. Access tokens for connected Google and Microsoft accounts are discarded; you may also revoke the Service's access from your Google or Microsoft account settings.
7.2 Teardown runs stage by stage (office, file store, object storage, chat, API database) and stops and reports failure if any stage fails; the purge of the shared API database is a single transaction, so it either completes in full or leaves the records untouched for a retry. The set of API database tables that the purge covers is checked against the database schema whenever the schema is deployed, so that a new table capable of holding workspace data cannot be added without being included in the purge. [TBC: a verification after each teardown that no record tagged with that workspace's identifier remains is not yet performed; do not represent it until built.]
7.3 The following survive teardown: the final export (section 4.4); the audit record of the teardown itself; your subscriber account data (section 8); and backups as described in section 5.7. The subscriber's identity record is detached from the workspace but kept so that the same person can subscribe again.
7.4 Deleted data cannot be recovered after teardown except from a surviving export or backup.
8. Subscriber account data
8.1 Subscriber account data (registration details, billing profile, agreement acceptances, payment history, provisioning and closure records) is kept for the life of the subscription and for [TBC: e.g. 6 years] afterwards to meet accounting and legal obligations and to evidence the contract, then deleted or anonymised.
8.2 Records of which policy versions you accepted, and when, are kept for the same period.
9. Logs and telemetry
9.1 Operational logs, traces and metrics from the Service are kept for [TBC: telemetry retention period] and then deleted. They may contain user and workspace identifiers, IP addresses and request details, but not the content of inspections or photographs.
10. Requests and questions
10.1 To request an export outside the portal, the passphrase for an export, a restore, early deletion of an export or backup, or information about data held, contact [TBC: support/privacy contact email]. Requests relating to Customer Data must come from the subscriber account holder or a person they authorise.
11. Changes
11.1 MBGW may update this policy as described in the Terms of Service. A change that shortens a retention period or reduces backup protection is treated as a major version with 30 days' notice.