DRAFT — for solicitor review; not yet in force.
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. [TBC: whether Cyber Essentials will be pursued before go-live.]
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 [TBC: security contact email].
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. [TBC: a per-workspace verification after each teardown (confirming that no row tagged with that workspace's identifier remains) is not yet performed; do not represent it until built.]
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 [TBC: physical security, power and connectivity resilience of the hosting site — describe accurately or omit; an uninterruptible power supply has not yet been installed.]
3.3 Operating systems and container images are kept patched. [TBC: state the patch cadence, e.g. security updates within N days.]
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 [TBC: TLS / a private network segment — state accurately].
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. [TBC: whether database and object-storage volumes are encrypted at rest; do not claim it unless confirmed.]
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. [TBC: the 12-character minimum and lockout in 5.2 are enforced by the broker; confirm what Odoo enforces for local office passwords, and decide whether local password sign-in to the office should be disabled so that the broker is the sole credential authority.]
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. [TBC: multi-factor authentication for email-and-password accounts is not yet offered; 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. [TBC: number of people with production access; whether administrative actions are logged to a tamper-evident store — 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 [TBC: whether independent penetration testing has been or will be carried out; do not claim it until done.]
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. [TBC: showing this identifier on user-facing error pages as a support reference is not yet built; do not represent it until it is.]
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. [TBC: continuous per-workspace health probing with automatic alerting to MBGW is not yet in place; do not represent it until built.] Logs are retained for [TBC: telemetry retention period].
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. [TBC: frequency of restore testing going forward.]
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), postcode address lookup (Ideal Postcodes) and base map tiles and geocoding requested from the office user's browser (OpenStreetMap Foundation) are used for every workspace, as described in that list. 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 [TBC: security contact email]. MBGW asks reporters to allow a reasonable period for remediation before public disclosure.
11. Organisational measures
11.1 [TBC: number of MBGW staff; confidentiality obligations in staff and contractor terms; security awareness; joiner/leaver process; device policy for MBGW's own equipment. State what is true for a small company; do not overstate.]
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.