Security & data residency

Where your data lives, which subprocessors handle it, how it's isolated and protected, and the security posture behind the platform.

Municipalities, school boards, and healthcare-adjacent organizations run on AssetLab; this page is written to be handed to their privacy officer.

Data residency

Your records and uploaded files are stored in Canada. The production database and file storage run in AWS ca-central-1 (Montréal), and that is where every asset, work order, work request, comment, form response, document, and photo lives. It isn't a plan tier - it's the architecture, and it applies to every organization on the platform.

Some supporting services operate outside Canada. They are listed in full below, because a residency claim is only useful to a privacy officer if it says exactly what it covers.

Subprocessors

Two notes on the list. Sentry is configured not to receive personal information - IP address, user agent, and request URL capture are off, session replay is disabled, and users appear only as an opaque identifier. AI access is off until you turn it on: no organization's data reaches an AI provider unless an Administrator creates an API key or MCP connection for it.

If your procurement or privacy assessment needs Canadian residency for identity and email as well, contact us before you sign - that configuration is on the roadmap and we would rather scope it with you than have you discover the gap in a PIA.

Regulatory posture

AssetLab is designed to support customers' obligations under PIPEDA, and the residency, isolation, and access controls described on this page are the technical part of that. To be precise about what that does and does not mean:

• PIPEDA permits transfers to a service provider outside Canada where comparable protection is in place, so the US services above are disclosed rather than prohibited.
• Ontario and BC FIPPA reach AssetLab through your institution's contract and its privacy impact assessment. We supply the inputs for that assessment on request.
• Nova Scotia's PIIDPA requires that personal information be both stored and accessed in Canada. The identity and email services above do not meet that bar today, so a NS public body should talk to us about scope before deploying.

Tenant isolation

Every record belongs to exactly one organization, and isolation is enforced at the database layer - every query, from the app, the API, or MCP, is constrained to the requesting organization's data by server-side policy. This is not an application-code filter that a bug could skip; it's the data layer's own rule.

The same principle governs identifiers: tenant identity always derives from the verified credential (session or API key) - never from anything a client sends in a request body.

Authentication

• Humans - email one-time passcode; no password database exists. Single sign-on is self-serve under Settings → SSO (Enterprise plan), and a separate Settings → Domain access tab restricts membership to verified email domains.
• Machines - API keys: hashed at rest, scoped, expiring, tenant-bound, instantly revocable.
• Sessions refresh automatically and respect organization membership changes.

Application security

• Encryption in transit everywhere; HTTPS with HSTS on all surfaces.
• File storage is private - every download is access-checked; there are no public bucket URLs.
• The external surfaces (REST gateway, MCP/OAuth server) have undergone third-party penetration testing, with findings remediated and locked in by regression tests that run on every change.
• Dependency vulnerability scanning runs nightly and on every dependency change; static analysis runs nightly.

Monitoring & audit

Every breach-notification duty - PIPEDA's, FIPPA's, and the one arriving in Nova Scotia in 2027 - starts on the word discovered. A well-drafted notification procedure attached to nothing that detects is a slower failure, not a fixed one. So AssetLab runs continuous automated monitoring for the events that indicate a breach in progress:

• Weakening of the data layer's security controls - isolation policies, database roles and privileges, or anything else that would erode the tenant boundary described above.
• Credential abuse - an API key used from an unfamiliar source, unusual request volumes, broad sweeps across resource types, or bursts of failed authentication.
• Privilege escalation - an account being granted administrator rights, or an administrator's sign-in address being changed.
• Mass or cross-organization deletion.
• Certificate and transport integrity - a certificate issued for our domains by an authority we don't use, DNS issuance controls being removed, or unexpected changes to the code served to browsers.

Findings reach a monitored inbox and carry the response step, not just the observation. The monitoring runs outside the application's own infrastructure, so it can still report when that infrastructure is unavailable - and it is itself watched by an external heartbeat, so if the monitoring stops, that raises an alarm of its own.

Alongside detection, API and integration access is logged with the acting key's identity, and application errors are captured with organization context for triage - without recording credentials or record contents in logs.

Your controls

Security is shared; your levers, all covered elsewhere in this section:

1. Role hygiene - least role, quarterly review, prompt removal of departed users.
2. User group scoping - keep group scopes aligned with how work is actually dispatched.
3. API key discipline - per-consumer, least-scope, expiring.
4. AI access - read-first rollout, write scopes per workflow.

Questions

Security questionnaires, privacy assessments, or procurement documentation: support@assetlab.ca.