Data Processing Agreement
Version 2.6 · Effective date: 2 October 2026 · ProSurvey Apps Limited (company no. 17118570), registered in England and Wales. Registered office: Unit 13 Freeland Park, Wareham Road, Lytchett Matravers, Poole, BH16 6FA.
See also: Terms of Service · Privacy Policy · Acceptable Use Policy · Cookie Notice · Sub-processors
This Data Processing Agreement forms part of the agreement (the "Agreement", i.e. the Terms of Service) between ProSurvey Apps Limited (company number 17118570, England and Wales) ("Processor", "we", "us") and the customer organisation ("Controller", "you") for the HousingSurvey Pro Service. It governs our processing of Tenant Personal Data and any other personal data we process on your behalf. Where we process personal data as a controller (account, billing, website data), our Privacy Policy applies instead.
Terms defined in the Terms of Service have the same meaning here. "UK Data Protection Law" means the UK GDPR, the Data Protection Act 2018, and any successor or related legislation, as amended.
1. Roles and scope
1.1 You are the controller and we are the processor in respect of the personal data described in Annex 1. Where you are yourself a processor for a further controller (for example, a contractor acting for a landlord), you appoint us as your sub-processor and warrant you have authority to do so.
1.2 We process personal data only for the purpose of providing the Service and only as described in this DPA and Annex 1.
2. Processing on documented instructions
2.1 We process personal data only on your documented instructions, including those in the Agreement, this DPA, your configuration and use of the Service, and any further written instructions you give — unless required to do otherwise by law (in which case we will inform you, unless legally prohibited).
2.2 We will inform you if, in our opinion, an instruction infringes UK Data Protection Law. We are not obliged to act on an instruction that would.
3. Confidentiality
We ensure that personnel authorised to process personal data are bound by appropriate confidentiality obligations and access personal data only as needed to perform the Service.
4. Security (technical and organisational measures)
We implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, costs, and the nature, scope, context and purposes of processing. Our measures are set out in Annex 2 and are kept under review. We do not currently hold SOC 2, ISO/IEC 27001 or Cyber Essentials certification; we operate to those frameworks and are working towards certification.
5. Sub-processors
5.1 You provide general authorisation for us to engage the sub-processors listed in Annex 3 for the processing described.
5.2 We impose data-protection obligations on each sub-processor that are, in substance, no less protective than those in this DPA, and remain responsible to you for each sub-processor's performance.
5.3 We will give you at least 30 days' prior notice of any intended addition or replacement of a sub-processor (by updating the subprocessors page and, where you have subscribed, notifying your organisation administrators), giving you a reasonable opportunity to object on reasonable data-protection grounds. If we cannot resolve a reasonable objection, you may terminate the affected Service as your sole remedy.
6. Data-subject rights
Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures — including the Service's self-service export and deletion tools — to fulfil your obligation to respond to data-subject requests (access, rectification, erasure, restriction, portability, objection). If we receive a request directly, we will not respond to it ourselves (except to direct the individual to you) and will pass it to you promptly.
7. Assistance with obligations
We assist you, taking into account the nature of processing and the information available to us, with: security of processing (Art. 32); personal-data-breach notification and communication (Arts. 33–34); data-protection impact assessments (Art. 35); and prior consultation (Art. 36).
8. Personal-data breaches
We notify you without undue delay after becoming aware of a personal-data breach affecting personal data we process for you, and provide the information you reasonably need to meet your own notification obligations.
9. Deletion or return
On termination of the Service, and at your choice, we delete or return the personal data we process for you and delete existing copies, unless UK Data Protection Law (or another law to which we are subject) requires storage. The Service provides self-service export (for return) throughout the term and for the post-termination export window, and self-service/scheduled deletion, as described in the Terms of Service (clause 10.4) and Privacy Policy (clause 7). Retention of audit and accounting records, and of tamper-evident evidence for its configured retention period, is as described there.
10. Audits and information
We make available to you the information reasonably necessary to demonstrate compliance with Article 28, and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate. We may satisfy this by providing our security documentation, security-questionnaire responses, and (once obtained) certification/attestation reports, and by reasonable, scoped, confidential audits at reasonable frequency and cost. Our default position is documentation-first (security documentation and questionnaire responses, supplemented by certification/attestation reports once obtained), with a scoped on-site or remote audit step available for cause, on reasonable notice.
11. International transfers
Our database, file storage, server functions and reporting warehouse are in the UK (europe-west2, London). Some Google services we use are global (Firebase Authentication, Cloud Messaging and Analytics), and some lookup services in Annex 3 are outside the UK. Any transfer of personal data outside the UK arising from a sub-processor is made under an appropriate transfer mechanism — that sub-processor's UK IDTA/Addendum to the EU Standard Contractual Clauses (or equivalent), or an applicable adequacy decision, as set out per sub-processor in Annex 3 and on the subprocessors page. We will not transfer personal data outside the UK other than as described there without an appropriate safeguard.
12. Liability
Liability under this DPA is subject to the limitations and exclusions in the Agreement (Terms of Service, clause 12), except to the extent UK Data Protection Law requires otherwise.
13. Precedence and general
13.1 In the event of conflict between this DPA and the rest of the Agreement on a data-protection matter, this DPA prevails.
13.2 This DPA is governed by the law of England and Wales, consistent with the Agreement.
Annex 1 — Description of processing
| Item | Detail |
|---|---|
| Subject matter | Provision of the HousingSurvey Pro damp & mould evidence platform |
| Duration | The term of the Agreement, plus the post-termination export/retention windows described in the Terms and Privacy Policy |
| Nature and purpose | Capture, storage, hash-chaining, transmission and export of property-condition evidence and related work-management data, on the Controller's behalf |
| Types of personal data | Property addresses/UPRNs; environmental readings and observations; photographs of properties; inspection GPS coordinates; surveyor/Authorised-User identifiers; optional on-site presence check-ins; work-order and statutory-deadline data; tenant names and contact lines on work orders (used in notices); case-intake and resident-preference data (reason for inspection, HMO/occupant/pet details, contact and report-delivery preferences, preferred language). The Service is designed to describe properties, not people; the Controller is required to minimise personal data generally and not to enter special-category data anywhere except the fields built for it: the occupant-vulnerability record in a survey and the optional resident-triage feature, both described below |
| Categories of data subjects | Residents/occupiers and other individuals connected to a property (only to the extent the Controller enters such data); the Controller's own staff and contractors (as Authorised Users) |
| Special-category data | (a) The occupant-vulnerability record in every survey. The surveyor can record which of a fixed list of factors apply to the household (pregnancy; respiratory, heart or other long-term health conditions; weakened immunity; medication affecting tolerance of cold or heat; a mental-health condition; dependency on medical equipment; a mobility or sensory impairment; age 65 or over; children under 5 or under 14; spending most of the day indoors), with optional free-text detail and who recorded it, together with the vulnerable-occupant notes in the excess-cold and HHSRS sections. This record is part of the survey: it is sealed into the Evidence Record at finalisation, appears in the survey report by default, and is included in evidence bundles and data exports. It is available whether or not (b) is enabled, it is readable by anyone in the Controller's organisation who can read the survey, and it is never sent to an AI provider (the excess-cold note is included in draft executive summaries sent to the Controller's own AI provider). The Controller is responsible for its lawful basis under Art. 9 for recording it, typically to assess and prioritise hazards under the Housing Health and Safety Rating System and Awaab's Law. (b) The OPTIONAL resident vulnerability/safeguarding triage feature (org-configurable, off by default at the Controller's discretion — see clause below and docs/design/RESIDENT-TRIAGE.md): health-related data (respiratory/cardiac conditions, immunocompromised status), the presence of children under 5, elderly/mobility needs, and safeguarding flags. The Controller decides whether to enable this feature; where enabled, the Controller remains responsible for identifying its own lawful basis under Art. 9 for its own use of the feature (typically Art. 9(2)(g), substantial public interest — safeguarding of children and of individuals at risk, and/or reasons of substantial public interest in the equitable treatment of individuals, as recognised for regulated housing bodies under Schedule 1 of the Data Protection Act 2018) — this is our good-faith understanding, not legal advice, and the Controller should take its own advice before enabling the feature. Every question is optional and "prefer not to say" is always available to the data subject; the record captures who provided the answer. Any other special-category data (e.g. entered into general notes or other free-text fields) is not to be processed — the Controller undertakes not to enter it there |
| Frequency | Continuous, for the duration of the Service |
Annex 2 — Technical and organisational measures (drawn from the real security posture)
- UK data residency: Firestore, Cloud Storage, Cloud Functions and BigQuery in Google Cloud europe-west2 (London). The database and storage locations were fixed when the project was created and the functions region is set in code. Firebase Authentication, Cloud Messaging and Analytics are global Google services.
- Access control: default-deny Firestore/Storage rules; per-organisation isolation; role-based access (owner/org-admin/manager/coordinator/finance/ viewer/surveyor); contractor access only via explicit landlord grants; server-side custom claims minted only by controlled functions; SSO/SCIM on eligible plans.
- Field-level access for special-category data: where a Controller enables the optional resident-triage feature (Annex 1(b)), those answers are held in a separate access-controlled record, readable only by the Controller's own manager-or-above roles and the specific surveyor/operative assigned to that case — never by the Controller's org-wide viewer/ coordinator roles — enforced server-side, independently tested, and excluded from bulk data exports/API responses unless the requester holds the same access level. Answer values are never written to our operational (Cloud Logging) logs. The occupant-vulnerability record (Annex 1(a)) is part of the survey and has the survey's access controls, not these field-level ones.
- Authentication: TOTP and phishing-resistant WebAuthn passkeys are available and required by the apps for relevant roles; platform-superadmin rules/callables verify current second-factor proof server-side. Equivalent server-side step-up is not yet universal for ordinary manager/org-admin actions. Passwords are held by Identity Platform; high-entropy API/SCIM bearer tokens are stored only as SHA-256 digests and shown once.
- Evidence integrity: server-authoritative finalization (timestamp set by a function, never a device clock); per-property SHA-256 hash chaining with a nightly integrity verifier that flags (never alters) mismatches and raises audit/notification events; append-only, hash-chained audit log per organisation; signed evidence bundles independently verifiable by a third party.
- Encryption: TLS in transit; encryption at rest (managed by the cloud platform) throughout.
- Application security: app attestation (App Check); upload restrictions (images only, size-capped) enforced by Storage rules; signed webhooks (HMAC-SHA256); rate-limited, audited API access.
- Per-tenant AI isolation: AI runs only on the Controller's own key, scoped strictly to that Controller, and fails closed when unconfigured; there is no shared platform AI account for customer data. Photo analysis, executive summaries, text polish and room-note structuring are refused on finalised surveys. Statutory summaries and investigation-complete notices are drafted from finalised surveys without changing them, and these and the scheduling notices send the tenant's name to the Controller's AI provider. Repair-code suggestions can send a photo from a finalised survey.
- Logging and monitoring: Cloud logging on functions; append-only audit trail; nightly chain-verification run records.
- Backups/continuity: production Firestore has seven-day point-in-time recovery (PITR) plus daily backups retained for 98 days. Evidence Storage has object versioning, 14-day soft delete and a nightly mirror to a separate versioned Archive bucket in London. The same-region backup protects object/ bucket loss while preserving UK residency, but does not cover a whole-London- region outage. See the compliance mapping for current recovery-test gaps. These controls are separate from the cryptographic integrity guarantee, which does not depend on backups.
This annex reflects our current engineered security posture and is kept under review as controls land. We do not represent an in-progress control as complete, and we add no certification claim until one is actually held.
Annex 3 — Sub-processors
| Sub-processor | Role | Location / residency |
|---|---|---|
| Google Cloud / Firebase | Core hosting, database, storage, auth, functions, BigQuery, push notifications (Cloud Messaging) | Database, storage, functions and BigQuery: UK (europe-west2, London). Authentication and Cloud Messaging are global; any transfer outside the UK is under Google's standard contractual clauses (or equivalent transfer mechanism) |
| Stripe | Payments and invoicing | UK/EU and US-headquartered; card data is out of our scope entirely (Stripe is PCI-DSS certified). Any transfer outside the UK is under Stripe's standard contractual clauses (or equivalent transfer mechanism) |
| Cloudflare | CDN, DNS, WAF, Turnstile bot protection | Global CDN network, US-headquartered; any transfer outside the UK is under Cloudflare's standard contractual clauses (or equivalent transfer mechanism) |
| Google Workspace (SMTP) | Transactional/notification email, unless the Controller configures its own mail server | US-headquartered (Google LLC) / Ireland (Google Ireland Ltd); any transfer outside the UK is under Google's standard contractual clauses (or equivalent transfer mechanism) |
| Google Maps Platform (Geocoding, Places) | Map coordinates for a property and address suggestions (address and postcode) | US-headquartered; any transfer outside the UK is under Google's standard contractual clauses (or equivalent transfer mechanism) |
| postcodes.io | Postcode lookup (postcode only) | UK |
| Weather, map and soil services: OpenStreetMap Nominatim, Open-Meteo, OpenWeatherMap, RainViewer, ISRIC SoilGrids, OpenStreetMap tiles | Location, weather, condensation-risk, rain-radar, soil and map context. Nominatim, Open-Meteo and OpenWeatherMap receive the property address or postcode; the others map coordinates only | Outside the UK in several cases (EU, US); these are public data services used under their own terms |
| Apple Push Notification service | Push notifications to iPhone and iPad (notification text can include a property address) | US-headquartered; under Apple's own terms |
| Apple and Google sign-in | Sign-in with an Apple or Google account, where offered | US-headquartered; under each provider's own terms |
| EPC register (gov.uk) | Public energy-performance lookup (address and postcode, from our servers) | UK |
| Google (Gemini API) — public docs assistant only | Public website documentation assistant; no Customer/Tenant data | US-headquartered; receives public documentation and the question a website visitor types |
| Customer-keyed AI providers (Anthropic / Azure OpenAI / OpenAI / Google / BYO endpoint) | Advisory survey-content AI — the Controller's own account and DPA | Determined by the Controller's arrangement with its chosen provider — this is a sub-processor of the Controller's own choosing, not ours, listed here for transparency |
The full, current version of this table — kept up to date as sub-processors change — is published on the subprocessors page, which this Annex 3 mirrors.
ProSurvey Apps Limited · registered in England and Wales, company number 17118570 · HousingSurvey Pro™.
Changelog
- v2.6 (2 October 2026) — Current version.
- v2.4 (14 July 2026) — Full UK-law B2B SaaS suite drafted (W-E1), published live (W-E2/H-LEGAL-PUBLISH). Supersedes the v1.0 short-form page.