Property Inspector — Security Overview

1. Purpose

1.1 This document describes the technical and organisational measures that MBGW Limited (MBGW) uses to protect the Property Inspector service (the Service) and the data in it. It is the description of measures referred to in section 6 of the Data Processing Agreement and is provided to help subscribers meet their own obligations under UK GDPR Article 28 and Article 32.

1.2 It describes what is in place today. MBGW does not hold any external security certification (such as ISO 27001 or Cyber Essentials) and makes no claim to.

1.3 This is an overview. Detailed configuration is not published, because publishing it would weaken it. Subscribers who need more detail for a supplier assessment can ask at support@mbgw.co.uk.

2. Architecture and workspace isolation

2.1 Every subscriber workspace is a separate tenant. Isolation is enforced at each layer, not only in the user interface:

• Office application: each workspace has its own application container and its own database with its own database role. One workspace's office cannot open another's database.
• API and shared database: the API is shared, but every record in its database carries the owning workspace's identifier, and every read and write is fenced to the workspace named in the caller's signed token. The workspace identifier is taken from the token, never from the request, so it cannot be changed by the caller. Each office instance authenticates to the API with its own per-workspace key that resolves to that workspace only.
• Object storage: photographs, logos, documents, reports and integration credentials are stored under a per-workspace prefix in MBGW's object storage; the API resolves the prefix from the token.
• Team chat: each workspace has its own messaging domain on the chat server, and a server-side filter drops any message addressed between different domains, so cross-workspace messaging is blocked even at the transport level.
• Environments: development, staging and production are entirely separate stacks with separate databases, storage and credentials. Subscriber workspaces exist only in production.

2.2 When a workspace is torn down, each of these components is deleted in turn by a scripted run that stops and reports failure if any stage fails; the purge of the shared API database runs as a single transaction, so it either completes or leaves nothing half-deleted. The list of API database tables that the purge covers is checked against the database schema when the schema is deployed, so that a new table capable of holding workspace data cannot be introduced without being added to the purge. MBGW does not yet run a per-workspace check after each teardown; the guard in place is structural — every table capable of holding workspace data must be reachable by the purge, or the database deployment fails.

3. Hosting

3.1 The Service runs on infrastructure owned and operated by MBGW in the United Kingdom, consisting of virtual machines on a hypervisor and container runtimes, behind a firewall and TLS-terminating load balancer that MBGW also operates. No public cloud provider hosts the Service or its data.

3.2 The Service runs on MBGW's own hardware at a single site in the United Kingdom. There is no uninterruptible power supply or generator cover at present; a power or connectivity failure at the site would interrupt the Service until restored.

3.3 Operating systems and container images are kept patched. Security updates are applied within 14 days of release; other updates monthly.

4. Encryption

4.1 In transit. All connections between users' browsers, the mobile app, the subscriber portal, workspace offices, the API and the chat server use TLS. Internal connections between components use a private network segment, with TLS on the public-facing and chat listeners.

4.2 At rest. Backups and exports are encrypted with AES-256 under per-archive passphrases and digitally signed. Credentials for subscribers' connected Google and Microsoft accounts are encrypted with AES-256-GCM under a key held separately from the storage that holds the ciphertext. Passwords are stored only as salted hashes — by the identity broker, and by a workspace office for the accounts that hold a local office password (see 5.1); they are never stored or logged in clear text. Database and object-storage volumes are not encrypted at rest; backups and exports are.

5. Identity and access control

5.1 Single sign-on first. Users sign in through MBGW's identity broker, which supports Microsoft and Google accounts (OpenID Connect) and an email-and-password option. The subscriber's administrator account in a workspace office is created without a local password and can sign in only through the broker.

Workspace offices are built on the Odoo platform and do hold their own password hashes for some accounts: office user accounts that the Service creates automatically to mirror field teams and engineers are given a random password at creation; customer-portal logins hold a password where one has been set; and any office user who sets a local password keeps one. These are stored as salted PBKDF2 hashes in that workspace's own database (never in clear text) and are never shared between workspaces. An office checks a local password first and, if that fails, asks the broker. Where an office keeps a local password it is subject to Odoo's own password rules; the broker enforces the policy in 5.2 for broker accounts.

5.2 Password policy. Where email-and-password is used, passwords must be at least 12 characters. Accounts are locked for 15 minutes after 5 failed attempts. Sign-in responses do not reveal whether an email address is registered. Email addresses are verified before an account is used. Multi-factor authentication is not yet offered for email-and-password accounts; Microsoft and Google sign-in inherit those providers' MFA.

5.3 Tokens. The mobile app and offices authenticate to the API with short-lived signed tokens carrying the user's workspace, team and privileges, refreshed with rotating refresh tokens. Tokens are revoked at teardown and when a user is removed.

5.4 Privileges. Within a workspace, the subscriber's administrator assigns each user a role and feature-level privileges (for example view or edit for customers, sites, work orders, forms). The API enforces these on write operations; field users see only their own team's work orders unless granted more. Administrative privilege is a separate, explicit grant.

5.5 Rate limiting. The API applies per-address rate limits, with tighter limits on sign-in and credential endpoints, to slow credential-stuffing and abuse.

5.6 MBGW staff access. MBGW operators access production systems over SSH with key-based authentication from MBGW's own network, and workspace offices through the same SSO broker with named accounts. Access is limited to those who operate the Service. One person holds production access, plus the automated deployment identity. Actions through the control plane are logged; direct server access is logged by the operating system.

6. Application security

6.1 The Service is developed and maintained by MBGW. Changes are made through version control, reviewed, built and deployed by an automated pipeline, and promoted through development and staging before production.

6.2 Web applications include protection against cross-site request forgery, and user-supplied content is escaped on output. Secrets are supplied to services from the deployment pipeline's protected variables, not stored in source code.

6.3 The API validates the workspace fence and privileges on the server for every request; the mobile app and browser are never trusted to enforce access.

6.4 No independent penetration test has been carried out.

7. Logging and monitoring

7.1 The Service emits structured logs, traces and metrics from every component (API, offices, portal, chat, mobile app) to a central observability stack on MBGW's estate. Every request carries a correlation identifier that is recorded in the logs and returned in the API's error responses, so that a reported problem can be traced end to end.

7.2 Sign-in successes and failures, lockouts, rate-limit breaches, workspace lifecycle actions (create, pause, resume, close, suspend, backup, export, teardown) and privilege changes are logged with the acting user and reason.

7.3 A workspace's health (whether its office is serving and its database is reachable) is checked when the subscriber opens the workspace's health page in the portal, or when MBGW opens it in the control plane, and the result is shown there. A small set of automated alerts covers MBGW's shared infrastructure components. Every workspace's container and host is monitored continuously, with tenant-aware alerting to MBGW. Logs are retained for 30 days.

8. Backups and resilience

8.1 Backups and their protection, retention and restoration are described in the Data Retention and Backup Policy. In summary: full workspace backups (all five components), encrypted and signed, stored in object storage and mirrored to a file server and offline media on the UK estate; scheduled backups keep the last 7 by default (configurable 1–90); on-demand backups are never auto-pruned.

8.2 Backup integrity is verified by checksum and signature. Restore has been rehearsed end to end. Restore is re-tested at least quarterly.

9. Sub-processors and integrations

9.1 Third parties that process data for the Service are listed in the Sub-processor List. Google Drive/Calendar and Microsoft 365 integrations are opt-in per workspace; credentials are stored encrypted per workspace and are discarded at teardown. Push notifications to the mobile app (Google Firebase Cloud Messaging), live-traffic travel-time estimates (TomTom) and postcode address lookup (Ideal Postcodes) are used for every workspace, as described in that list. Base map tiles and geocoding are requested directly from the office user's browser by the OpenStreetMap Foundation, which is an independent controller of those requests rather than a sub-processor. Payment details are held by the payment provider, not by MBGW.

10. Incident response

10.1 MBGW treats any suspected unauthorised access, data loss or malware as a Severity 1 incident under the Service Level Agreement. Subscribers are notified of personal data breaches affecting their data without undue delay as set out in the Data Processing Agreement, with the information needed for their own notifications to the ICO and data subjects.

10.2 Security concerns or suspected vulnerabilities can be reported to support@mbgw.co.uk. MBGW asks reporters to allow a reasonable period for remediation before public disclosure.

11. Organisational measures

11.1 MBGW is a small company with a single director who operates the Service. Any contractor engaged is bound by written confidentiality obligations. Company devices used to operate the Service are encrypted and protected by multi-factor authentication.

12. Changes

12.1 This overview is updated when measures change. Each version is numbered and published with its effective date; a change that reduces protection is treated as a major version under the Terms of Service.