// Security and Compliance

Where your drawings live, who can reach them, and what we do with them.

QualRivu audits municipal and engineering drawings. These documents are often sensitive and not ours to move. This page sets out the controls in place today, the options configured per engagement, and the work still ahead. Every claim carries its status, so a reviewer can rely on the current ones without caveat and assess the rest on their own terms.

In place in place today
Per engagement configurable per deployment
Roadmap planned or in progress

// Data flows

What happens to a drawing, step by step

Where a drawing travels, in order, for a single audited sheet. The table that follows sets out where each category of data comes to rest.

  1. 01 Sign-in

    Sign-in runs on Microsoft Entra External ID, in the tenant’s own hosted user flow: the credential screens are Microsoft’s, so a password is never typed into or held by our code, which is a public client using PKCE and holds no secret. Every request and realtime connection then carries the resulting signed token, verified server-side rather than trusted from the browser. Identity is hosted outside Canada today; federating to the municipality’s own Entra ID tenant, so identity stays under the city’s control, is available per engagement.

  2. 02 Authorization

    Project-scoped and enforced on the server. Membership and role are checked before a drawing, audit record or live session is read or joined; hiding a control in the UI is convenience, not the control.

  3. 03 Storage

    The drawing is written to Azure Blob Storage in Canada Central: private container, no public read, reachable only through short-lived signed URLs, AES-256 at rest.

  4. 04 Preparation, in your browser

    The PDF text and CAD vector layers are parsed and the precision crops are cut on the reviewer’s own machine. Nothing has left your environment at this point.

  5. 05 Inference

    Crops and prompt leave our Canadian tier encrypted in transit under TLS 1.2/1.3, both directions, to Anthropic, OpenAI or Google on paid enterprise tiers that exclude training on customer content. Sent inline by default so nothing is stored provider-side; an oversized sheet that must be uploaded is deleted once the audit completes, and response storage is off. This is the one step not pinned to Canada — pinning it there is available per engagement via Google Vertex AI or Amazon Bedrock, subject to the model being offered in a Canadian region.

  6. 06 Checking

    The response returns to our own code, never to the provider. Cover, cross-fall, gradients, spacing and curve geometry are recomputed there, so the verdicts are ours rather than the model’s.

  7. 07 Record

    Findings, markups and audit results are written to Azure Database for PostgreSQL in Canada Central. The drawing stays where it was uploaded.

Next: where the data rests

// Data residency

Hosting & residency, by data category

Compute, the database and uploaded drawings are in Canada today. Identity and AI inference are not, and each has a defined route to in-country residency for municipalities that require it.

Hosting and data residency by data category
Data category Where it resides today Canadian-residency option
Application computeNode/Express on Azure Container Apps Azure Canada Central (Toronto).
In place
Already in Canada: no change needed.
Transactional databaseUser metadata, audit results, markups (PostgreSQL) Azure Database for PostgreSQL, Canada Central.
In place
Already in Canada. Customer-managed encryption keys available on request.
Object storageUploaded drawings (PDFs / images) Azure Blob Storage, Canada Central. Private container, no public read, access via short-lived signed URLs.
In place
Already in Canada: no change needed.
Identity & authenticationSign-in and user profiles (Microsoft Entra External ID) Microsoft Entra External ID, North America (US data centres).Entra External ID has no Canada-specific geography today.
Per engagement
Federate to the municipality’s own Entra ID tenant via SSO, so identity stays under the city’s control; or retain Entra External ID under PIPEDA-compliant cross-border safeguards with disclosure.
AI processingDrawing analysis (Anthropic, OpenAI, Google) Paid enterprise API tiers over TLS. Processing region is not pinned to Canada.Drawings leave Canada for inference and return, encrypted in transit with TLS 1.2/1.3 in both directions. Storage and records stay in Canada throughout, encrypted at rest with AES-256.
Per engagement
Pin inference to a Canadian region via Google Vertex AI or Amazon Bedrock, subject to the specific model being offered there.
Next: how PIPEDA is met

// Privacy law

PIPEDA

How the platform meets Canada’s federal privacy framework, and which data it governs.

What PIPEDA requires

  • PIPEDA protects personal information wherever it is processed. The standard is substantive: information handed to a service provider must be protected to a comparable level, and the organization remains accountable for it throughout.
  • Processing outside Canada is expressly permitted. What it asks in return is that the protection travel with the data (through contractual terms and technical safeguards) and that the practice be disclosed openly.
  • The platform meets both halves: comparable protection by contract and by technical control, and a clear account of where processing takes place. This page is that account.

How the platform meets it

  • Safeguards: TLS 1.2/1.3 in transit, AES-256 at rest, project-scoped authorization, private storage with short-lived signed access, secrets in a managed vault.
  • Comparable protection by contract: every AI provider is used on paid enterprise terms that exclude training on customer content, with formal zero-retention arrangements available per engagement.
  • Limiting retention: drawings are held in memory for the request only, and nothing is retained provider-side by our own systems.
  • Openness: this page. Cross-border AI processing is disclosed here rather than buried, which is what the openness requirement asks for.

What counts as personal information

  • PIPEDA governs personal information. Municipal engineering drawings (storm networks, road geometry, servicing plans) are generally not personal information at all.
  • The personal information the platform holds is account data: name, work email, role and project membership. That is held in the Canadian database.
  • Markup notes are the other place personal information can appear: reviewers write notes against a finding, attributed to the author and kept as part of the audit record. They are stored in the Canadian database and are append-only: a posted note cannot be edited or removed on its own. Notes are retained as part of the audit record while the markup exists; deleting a markup removes its discussion along with it.
  • Federating identity to a municipality’s own Entra ID tenant, so it stays under the city’s control, is available per engagement.
Next: AI data handling

// AI data handling

Training, retention and transparency

Our commitments on what happens to a drawing once it reaches a model, including the one that is only partly in place.

Zero training on customer data

In place

No drawing, standard or audit result is used to train any model. This holds across every provider we use: it is the default and contractual position on our Anthropic and OpenAI accounts, and on Google it follows from our paid-tier terms.

Zero data retention - our systems

In place

Drawings are sent inline with the request and are never written to a provider’s file store. Where a drawing is too large to send inline, it is uploaded and then explicitly deleted when the audit finishes, on failed runs as well as successful ones. Provider-side response storage is also disabled, so audit outputs cannot be retrieved afterwards.

The application server itself holds a drawing only in memory for the duration of the request. Nothing is persisted there.

Zero data retention - contractual

Per engagement

Absent a negotiated zero-retention agreement, providers keep a short abuse-monitoring window of their own (typically thirty days) independent of anything our code does. Formal zero-retention arrangements are available from our providers and from Google Cloud’s Data Processing Addendum under the Vertex AI option, and we put them in place per engagement where a customer requires it.

These are listed separately because they are separate. The engineering is complete; the contractual commitment is executed per engagement, and the two are not interchangeable.

Zero ignorance - transparency

In place

An audit never hides what it could not determine. Every finding carries the evidence it came from; a measurement taken from an incomplete source is reported as partial rather than rounded into a clean number; and a check skipped because the drawing did not carry the data says so instead of staying silent. A reviewer is told what was not examined, not only what was.

The same principle governs how the platform is documented: this page sets out our data flows and controls, and a full sub-processor register follows. It is a property of how the product is built rather than a term supplied by a vendor.

Next: encryption and access

// Controls

Encryption, access and isolation

The controls a security questionnaire asks for, and how they are implemented here.

Encryption

  • In transit: TLS 1.2 / 1.3 between browser, application and every third-party service. All back-end integrations are HTTPS-only.
  • At rest (database): AES-256 with service-managed keys. Customer-managed keys available as an option.
  • At rest (drawings): AES-256 applied before objects are written to disk.

Secrets & keys

  • All API keys and service credentials live in Azure Key Vault, reached through a scoped managed identity rather than long-lived credentials.
  • No secret is ever delivered to the browser: every AI call is routed server-side, and the shipped bundle is verified to carry no provider key.
  • Rotation is centralised but currently manual; a documented cadence is scheduled alongside the identity migration.

Access control

  • Server-side authentication: every API route requires a verified identity token, enforced in middleware rather than the browser.
  • Project-scoped authorization: access to drawings, audits and markups is gated on role and verified project membership.
  • Review integrity: issuing or reversing a review verdict requires the reviewer or project-manager role.
  • Private object access: uploads and downloads use short-lived signed URLs; containers are never publicly readable.

Tenant isolation

  • Shared platform In place: logical per-tenant scoping within one managed environment.
  • Dedicated database per tenant Per engagement: physical separation for municipalities that require it.
  • Deployment into your own Azure subscription Per engagement: the platform running inside the city’s tenant and cost centre.

Operational data flow

  • Upload: the drawing goes directly to encrypted Canadian storage through a short-lived signed URL, never landing on the application server.
  • Audit: the server holds the file in memory only for the request and transmits it over TLS for inference.
  • Storage: structured results are written to the Canadian database.
  • Cleanup: anything uploaded to a provider is deleted when the run ends.

Change control

  • Peer review and the full automated test suite are required status checks before any change reaches the main branch.
  • The gate is enforced by the system rather than by convention; it applies to every contributor, with no bypass.
  • Deployment runs through federated identity with no long-lived credentials.
Next: independent assessment

// Assurance

Security assessment

What has been reviewed, and the limits of that review.

What we review

  • A systematic review of application code, cloud configuration, dependencies and access controls against a defined control checklist, with non-destructive verification that documented protections behave as intended.
  • Findings are tracked to closure, and every fix is tested against the full automated suite before it can merge.
  • The review is a standing programme rather than a one-off, and runs against the current architecture as it changes.

Scope and limitations

  • Not a penetration test. No exploitation was attempted, and the work was done by the engineering team rather than an independent third party.
  • An independent penetration test is scheduled for Q3 2026.
  • No load, denial-of-service, red-team or social-engineering testing has been performed. Runtime cross-tenant verification requires two provisioned accounts and is scheduled as a manual test.
Next: compliance roadmap

// Roadmap

Compliance roadmap

Every item we are asked about in procurement, with its current status.

Compliance roadmap with status for each item
Item Status Notes
Canadian residency - compute & database In place Application compute and PostgreSQL run in Azure Canada Central (Toronto).
Canadian residency - object storage In place Uploaded drawings in Azure Blob Storage, Canada Central. Private container, no public read, short-lived signed access.
No AI training on customer data In place Paid enterprise tiers across every provider we call. Not conditional on a negotiated agreement.
Zero data retention - our systems In place Drawings sent inline, oversized uploads explicitly deleted after each run, provider-side response storage disabled.
Zero data retention - contractual Per engagement Providers keep a short abuse-monitoring window of their own absent a negotiated agreement. Put in place per engagement.
NIST AI Risk Management Framework In place Our voluntary governance model for responsible AI design, deployment and monitoring.
Canadian AI inference region Per engagement Available via Google Vertex AI or Amazon Bedrock, subject to the specific model being offered in a Canadian region.
SSO / SAML for municipal identity Per engagement Federation to the municipality’s own Microsoft Entra ID tenant, configured per engagement — a natural fit for Microsoft-shop municipalities.
SOC 2 Type II Roadmap An independent attestation over a 3–12 month observation window, which we intend to enter. Not yet attested.
Independent penetration test Roadmap Scheduled Q3 2026.
Public trust centre Roadmap Full documentation of data flows, sub-processors and controls. This page is the first instalment.

This overview does not constitute a contractual service-level or compliance commitment. Specific residency, retention and isolation configurations are confirmed in writing per engagement. To report a security concern, or to request the detailed assessment and remediation record, contact us through the form on our homepage.

Last updated August 2026