Security & Data Architecture | HousingSurvey Pro

Audience: IT managers, security reviewers, procurement. This page answers the core security-questionnaire questions. Deeper topics link out to their own pages in the Technical & Trust Portal.

Platform summary

HousingSurvey Pro is a multi-tenant SaaS for UK housing associations and their contractors: a management dashboard (web) and a mobile capture app (iOS/Android via Capacitor), sharing one backend. Each customer is a tenant (an "organisation"); a landlord organisation owns its evidence, and contractor organisations perform work against it under scoped grants.

Data flow, at a glance

A surveyor captures a survey in the mobile app (offline-capable).
On finalisation the record is sealed: cryptographically hashed and chained (see below). Photos are hashed at capture with provenance metadata.
Sealed evidence syncs to the backend; the management dashboard reads it, generates branded reports, drives work orders and the Awaab's Law timeline.
Access is mediated by server-side rules and callable checks using the signed identity, live membership/role and any server-written module override.

Evidence integrity (tamper-evidence)

Every finalised survey is an append-only, hash-chained record:

Each record's canonical JSON (sorted keys, volatile fields excluded) is hashed with SHA-256; the hash includes the previous record's hash (prevRecordHash) and a monotonic chainSeq, forming a chain per data owner.
The canonicaliser exists as a byte-identical twin on client and server, guarded in CI by a parity test and a hash-canonicaliser field check, so a record sealed on-device verifies identically on the backend.
Photos are SHA-256-hashed at capture and carry provenance (EXIF timestamp preferred over device clock; camera make/model recorded).
Tampering is detectable, not silently correctable: a verifier recomputes the chain; a broken link quarantines the record (display-metadata only, excluded from the hash) and raises an audit event and org notification. Bytes are never modified — disclosure beats concealment. If a chain-verification mismatch is detected, we follow a documented internal incident procedure to investigate and remediate.
Report versioning rides this chain: editing a sealed report creates a new sealed version linked to its predecessor, so history is ordered and every prior version is retained and independently retrievable.

Tenant isolation & access control

Every document is scoped to an organisation. Signed claims establish the presented tenant context, while Firestore and Storage rules require an active member whose current role still matches it. Cross-tenant reads are denied at the data layer, not just the UI.
Eight organisation roles provide backwards-compatible module baselines. Sparse per-member None/View/Edit/Module-admin overrides are live, server-written and immediately evaluated by callables and rules. They cannot create owner/platform power or weaken sealed-record constraints (see Access Control & Permissions).
Surveyor/operative evidence, property, work-order and scheduling permissions stay assignment-scoped even when upgraded. Explicit administrative and non-record grants may be organisation-scoped.
Evidence images use assignment-bearing survey/work-order paths. Storage rules resolve the linked record, allow only append-only image creates within the effective level/scope, and deny new writes to legacy paths that cannot prove assignment. Evidence bundles remain client-inaccessible.
Licensed data (e.g. the Schedule of Rates catalogue) is tenant-private and proven isolated by emulator rules tests in CI.
Privileged surfaces (members, audit events, API keys, billing, org private secrets) are server-write-only — clients cannot write them even as admin.

AI: customer-controlled, advisory-only

AI features run on the customer's own per-tenant provider key (Anthropic/ OpenAI/Azure/Gemini/BYO). There is no shared platform key; with no key configured, AI features fail closed.
AI output is advisory and drafts-only — it never auto-enters evidence. Assessments (HHSRS, condensation, IAQ) are computed by deterministic domain engines, not by a model.

Cryptography & secrets

In transit: TLS to all endpoints.
At rest: managed encryption via the cloud platform (Firestore/Storage).
Passwords: never stored or logged by the application; authentication is delegated to the identity platform. Non-email field logins are provisioned by a tenant admin and backed by the same identity platform (see Access control).
Secrets (e.g. external register keys) are held in the managed secret store and injected server-side only; never shipped to clients.
App Check attests app/web clients (reCAPTCHA Enterprise on web; App Attest / Play Integrity on native builds). It is enforced across the production data plane; nonprod is deliberately monitor-only.

Data protection & subject rights

GDPR: subject-access/full-organisation export and authorised, audited, cooldown-gated deletion are implemented. An Art. 30 Record of Processing Activities and a DSAR-handling procedure are maintained; a customer-admin per-organisation evidence-retention setting remains planned. See Data Protection & GDPR.
Remote control: an admin can revoke a surveyor's sessions/tokens (remote logout) from the dashboard.
Auditing: privileged and destructive actions are recorded as immutable audit events.

Compliance posture

Controls are mapped to UK GDPR, SOC 2, ISO/IEC 27001 and Cyber Essentials in Compliance Mapping. The register distinguishes implemented, partial and planned controls and explicitly records that no SOC 2, ISO/IEC 27001 or Cyber Essentials assurance/certification is currently held.

An internal ISMS policy set — information security, access control and a quarterly access-review procedure, incident response, business continuity/DR, data retention and disposal, vendor management, and internal acceptable use, with the founder as interim CISO — backs these controls and is shared with procurement and auditors on request.

Hosting & residency

Runs on Google Cloud / Firebase; primary region europe-west2 (London). Subprocessors and residency detail: Subprocessor Register.

Status: living document. Sections marked in progress are tracked on our internal roadmap; this page is updated as those land so it never overstates the platform's current posture.