Tenancy and access
Data is scoped to the organisation and project that own it. Row-level security is enabled on every application table in the public schema, with 890 policies applying that scoping to user-originated reads and writes.
Security and controls
Enforced in the database for user-originated writes.
An assurance record is only worth what its controls can guarantee. BuildAssure puts the controls that matter — authority, evidence, history — beneath the interface, where bypassing the screen does not bypass the rule.
Authority
Signing, rejecting and releasing are role-checked in the database. Direct signature insertion is restricted; a signature exists because the signing action ran, with the right role, at the right step.
Evidence
Evidence rules — such as Red and Amber audit answers requiring an evidence note — are database constraints, not form validation. They hold for every user-originated write path.
History
Key record types carry append-only histories. Updates and deletes to recorded events are blocked; corrections are new events with a named author.
Reporting
Completed insight reports are published as immutable snapshots, so a report reviewed by leadership cannot quietly change afterwards.
Scope of the claim
These controls constrain user-originated writes. Platform administration and infrastructure operate under their own responsibilities — we do not claim the service role or infrastructure administrators can never bypass controls.
Hosting
Your data is stored at rest in the United Kingdom.
BuildAssure's primary infrastructure is hosted in the UK (AWS eu-west-2, London).
Data residency
Customer data stored at rest in the United Kingdom (AWS eu-west-2, London).
DPA Annex 2 Part A
Transfers outside the UK
Where a sub-processor processes personal data outside the UK, BuildAssure will ensure an appropriate safeguard is in place — UK adequacy ("data bridge") regulations where applicable, or the UK International Data Transfer Agreement or the International Data Transfer Addendum to the EU Standard Contractual Clauses — supported by a transfer risk assessment applying the test as reworded by the Data (Use and Access) Act 2025.
DPA §13
Access control
Role- and permission-based access by organisation, project and module; least-privilege administration. Multi-factor authentication is available on every account and can be enabled by the account holder; organisation-wide enforcement is on our roadmap below.
Trust and Security page
Registration
Build Assure Limited is registered in England & Wales (Company No. 16843792) and registered with the Information Commissioner's Office under registration reference ⟦ICO registration number⟧.
Privacy Policy §1
Sub-processors
Every provider that receives personal data, named.
The following sub-processors are authorised to process Customer personal data. This list is kept current and made available to Customer on request, together with advance notice of any proposed change under Section 7.
| Sub-processor | Service provided | Processing location | Transfer safeguard |
|---|---|---|---|
| Supabase | Database, authentication and file storage underlying the platform | AWS eu-west-2 (London, UK) | UK-hosted; no restricted transfer |
| Vercel | Application hosting and content delivery | London region where configured | UK-hosted where configured; IDTA or Addendum for any processing outside the UK |
| Resend | Transactional and system email delivery | EU/UK region where configured | IDTA or Addendum, plus transfer risk assessment, for any processing outside the UK |
| Anthropic | AI-assisted features (Claude API) | United States | IDTA or Addendum, plus Anthropic's data processing terms |
| AI-assisted features (Gemini API) | United States, or the Google Cloud region configured for the endpoint in use | IDTA or Addendum, plus Google's Cloud Data Processing Addendum |
Customer data submitted to either AI provider is processed only to return the requested output for the relevant feature, is limited to the data needed for that feature, and is not used to train the providers' models under their applicable commercial terms. AI output assists a human user and is not used to make final safety-critical or statutory decisions.
No monitoring, analytics or payment sub-processor is currently engaged. Any such engagement will be added to this Annex with advance notice under Section 7.
BuildAssure will give Customer at least 30 days' advance notice of any intended addition or replacement of a sub-processor, allowing Customer to object on reasonable data-protection grounds; if the objection cannot be resolved in good faith, Customer may terminate the affected part of the Service as its exclusive remedy.
Known gap — disclosed, not yet in Annex 3
The platform contains a drawing-analysis capability which sends a whole uploaded CAD drawing file and its filename to a separate extraction service. That service is not yet named in Annex 3 of our Data Processing Agreement. Section 7 of that agreement requires us to give Customers at least 30 days' advance notice before adding a sub-processor, and adding this one is subject to that notice.
Where we are
What we operate today, and what we have not built yet.
We would rather show a truthful maturity picture than claim controls we do not run. The left column is what the Data Processing Agreement warrants; the right column is not warranted and should not be relied on.
In place as at the effective date
These are the measures BuildAssure warrants under Section 6.
- Tenant isolation. Multi-tenant architecture enforced by database-level Row Level Security, logically isolating each Customer's data, with server-side authorisation checks on every request.
- Encryption. Data encrypted in transit using TLS 1.2 or higher, and encrypted at rest.
- Data residency. Customer data stored at rest in the United Kingdom (AWS eu-west-2, London).
- Access control. Role- and permission-based access control within each tenant, restricting visibility by user group; least-privilege administration, with access reviewed and revoked promptly on leaver or role change.
- Credential handling. Passwords stored using industry-standard one-way hashing; plain-text credentials are never stored.
- Environment separation. Production separated from development and demonstration environments; live Customer personal data is not used in development or demos.
- Change control. Changes managed through version control, peer review and controlled deployment, with automated dependency and vulnerability scanning.
- Incident response. A documented process covering detection, containment, recovery, customer notification and lessons-learnt review.
- Sub-processor governance. A maintained sub-processor register and written data-processing terms with material suppliers.
- Backups. Backups managed through the hosting platform, supplemented by Customer-available data exports.
Planned — not yet implemented
These are not yet implemented and are stated for transparency only. They are not warranted under Section 6 and Customer should not rely on them. BuildAssure will update this Annex as each is completed.
- Enforcement of multi-factor authentication across administrative and end-user accounts.
- An independent penetration test, before Tier 1 production rollout.
- A documented backup restore test, after which BuildAssure will publish contractual recovery point and recovery time objectives. Until that test is complete, BuildAssure makes no contractual recovery commitment.
- Expanded logging, monitoring and alerting, with a defined retention and review cadence.
- Cyber Essentials certification. Target date: ⟦target date⟧.
On certifications
BuildAssure does not itself hold ISO 27001 or SOC 2 certification and does not claim to. The infrastructure we build on is independently certified: Supabase, which provides our database, authentication and file storage, holds ISO 27001 and SOC 2 Type II, and Vercel, which hosts the application layer, holds ISO 27001 and SOC 2 Type II. Those certifications cover our providers' platforms and not BuildAssure's own controls — our application logic, access rules and internal processes are outside their scope — and we do not present them as ours.
Questionnaire pack
The due-diligence answers, with the clause each one comes from.
These are the answers we give to a security questionnaire, quoted from the documents you will be sent rather than written for this page. If a question is not answered here, ask us — we will tell you where we are rather than guess.
- Where is our data stored?
- BuildAssure's primary infrastructure is hosted in the UK (AWS eu-west-2, London). Customer data stored at rest in the United Kingdom (AWS eu-west-2, London).
- DPA §13 and Annex 2 Part A
- What happens when a sub-processor is outside the UK?
- Where a sub-processor processes personal data outside the UK, BuildAssure will ensure an appropriate safeguard is in place — UK adequacy ("data bridge") regulations where applicable, or the UK International Data Transfer Agreement or the International Data Transfer Addendum to the EU Standard Contractual Clauses — supported by a transfer risk assessment applying the test as reworded by the Data (Use and Access) Act 2025.
- DPA §13
- Which certifications does BuildAssure hold?
- BuildAssure does not itself hold ISO 27001 or SOC 2 certification and does not claim it. Its principal infrastructure sub-processors are independently certified: Supabase (database, authentication and file storage) holds ISO 27001 and SOC 2 Type II, and Vercel (application hosting) holds ISO 27001 and SOC 2 Type II. Those certifications attest to the providers' own control environments only. They do not extend to BuildAssure's application logic, tenant access rules, administrative practices or internal processes, and BuildAssure does not rely on them as evidence of its own certification. Current attestation reports and certificates are available directly from each provider's trust centre.
- DPA Annex 2 Part C
- Is multi-factor authentication enforced across our organisation?
- Role- and permission-based access by organisation, project and module; least-privilege administration. Multi-factor authentication is available on every account and can be enabled by the account holder; organisation-wide enforcement is on our roadmap below. (see the roadmap above)
- Trust & Security page, "Access control"
- How quickly are we told about a personal data breach?
- BuildAssure will notify Customer without undue delay, and in any event within 48 hours of becoming aware of a personal data breach affecting Customer's personal data, and will provide reasonably available information to assist Customer in meeting its own notification obligations to the ICO and to affected data subjects.
- DPA §9
- What are your recovery point and recovery time objectives?
- A documented backup restore test, after which BuildAssure will publish contractual recovery point and recovery time objectives. Until that test is complete, BuildAssure makes no contractual recovery commitment.
- DPA Annex 2 Part B — planned, not in place
- Can we audit you?
- BuildAssure will make available to Customer the information reasonably necessary to demonstrate compliance with this DPA, and will allow for and contribute to audits, including inspections, conducted by Customer or an auditor mandated by Customer, subject to reasonable notice, confidentiality, and no more than once per year absent a substantiated concern or a personal data breach.
- DPA §12
- Is our data used to train AI models?
- Customer data submitted to either AI provider is processed only to return the requested output for the relevant feature, is limited to the data needed for that feature, and is not used to train the providers' models under their applicable commercial terms. AI output assists a human user and is not used to make final safety-critical or statutory decisions.
- DPA Annex 3
- What happens to our data when the contract ends?
- On termination or expiry of the Agreement, BuildAssure will, at Customer's election, delete or return all personal data processed on Customer's behalf and delete existing copies, unless UK law requires continued storage. Customer may request a standard export of its tenant's data for 30 days after termination. BuildAssure will then delete or anonymise personal data from active systems within 60 days, after which residual copies persist only in encrypted backups until overwritten in the ordinary backup cycle.
- DPA §11
- Who is the controller and who is the processor?
- Where a construction company or its project team ("Customer") uses BuildAssure to record information about its own personnel, contractors, sites and projects, the Customer is the data controller and BuildAssure acts only as a data processor, handling that data on the Customer's documented instructions.
- Privacy Policy §2
Still open — we will not guess these
- Our ICO registration reference is ⟦ICO registration number⟧ — the reference has not been issued yet.
- The Cyber Essentials target date is ⟦target date⟧.
- Also still open: retention periods, cookie audit results, analytics tool choice, commercial terms.
- The Privacy Policy (v0.4) and the Data Processing Agreement (v0.5) are drafts and have not been reviewed by a solicitor.
For the contractual text, read the Data Processing Agreement and the Privacy Policy. For anything else, including a completed copy of your own questionnaire or a suspected security issue, write to buildassureapp@gmail.com.
Security and controls
Controls that do not disappear when someone bypasses the screen
Key controls are enforced beneath the interface, in the database, for user-originated writes. The screen is a convenience; the control is the constraint.
Row-level security throughout
Every application table in the public schema has row-level security enabled, backed by 890 policies scoping data to the organisations and projects that own it.
Append-only histories
Key record types keep append-only histories. Corrections are new events with a named author, never edits to what was recorded.
Authority checks in the database
Who can sign, reject or release is checked in the database for user-originated writes — not only in the interface.
Evidence rules enforced
Rules like “Red and Amber audit answers require an evidence note” are database constraints, so they hold however the record is written.
Immutable published reports
Completed insight reports are published as immutable snapshots. The pack the board saw stays the pack the board saw.
See how BuildAssure would structure one of your live work packages.
Bring a package name, an ITP or a project specification. We will show how BuildAssure turns it into a controlled project workflow.