Field service software holds the two things a building owner is most careful with: what the work costs and how to get inside. This page states what protects both, where each control framework actually stands, and what happens on the day something goes wrong.
SOC 2 Type IIAudit in progress
ISO/IEC 27001Controls aligned
HIPAA-compliant architectureControls aligned
PIPEDASupported
GDPRSupported
0 certified · 1 audit in progress, observation window 1 March 2026 – 30 November 2026, report expected Q1 2027 · the rest are aligned or supported controls. We publish the status and the dates, not the aspiration.
Trust Services Criteria for security, availability, and confidentiality. A nine-month observation window opened on 1 March 2026 with an independent CPA firm and closes on 30 November 2026; the report is expected in Q1 2027. No Type II report exists yet, we will not present one until it does, and a vendor questionnaire answered before then gets this same paragraph rather than a tick. Type I controls documentation and the auditor's engagement letter are available under NDA today.
Observation window 1 March 2026 – 30 November 2026
ISO/IEC 27001
Annex A controls mapped
The ISMS is built to the Annex A control set and operated against it, with a documented statement of applicability. We are not certified to 27001 and do not claim a certificate number. The control mapping is shared during security review.
HIPAA-compliant architecture
BAA available
Encryption, access control, audit logging, and transmission security are built to the HIPAA Security Rule safeguards, and we will execute a Business Associate Agreement. HIPAA has no certification body — any vendor claiming to be HIPAA-certified is describing something that does not exist.
PIPEDA
Canadian residency default
Production data is resident in ca-central-1 (Montréal) by default, which keeps personal information under Canadian jurisdiction. Consent, access, and correction workflows are exposed through the tenant admin console and the API.
GDPR
DPA and SCCs on file
A Data Processing Addendum with the current Standard Contractual Clauses is available before signature. Subject access, erasure, and portability requests are served from the same audit-logged endpoints your administrators use.
Core controls
Four things that have to be true.
Each pillar below states the control and then names the failure it exists to prevent. A control described without its failure mode is a feature list; a control described with one is something you can evaluate.
01 · Tenancy
Zero-trust data isolation
Every tenant gets a dedicated Postgres schema behind a connection role that cannot address any other schema. Isolation is enforced at the database boundary, not by a WHERE clause an application bug can drop.
Dedicated schema per tenant with row-level security as a second, independent gate.
AES-256-GCM at rest on every volume and every automated snapshot, keys held in a managed KMS with per-tenant data keys.
TLS 1.3 in transit, HSTS preloaded, TLS 1.0/1.1 and all CBC cipher suites refused at the edge.
No shared application credential reaches production; every service authenticates with a short-lived, scoped identity.
Failure mode. In a shared-table multi-tenant design, one missing tenant predicate in one query is a cross-customer data disclosure. Schema separation makes that class of bug a permission error instead of a breach.
02 · Field devices
Offline engine cryptography
Technicians work in mechanical rooms, underground parkades, and elevator shafts. The mobile app is built to run fully offline, which means the local database is a real attack surface and is treated as one.
The on-device SQLite store is encrypted with SQLCipher (AES-256) using a key held in the platform keystore — Keychain with Secure Enclave on iOS, StrongBox-backed Keystore on Android.
The key is never written to disk in plaintext and never leaves the device; a wiped or deprovisioned device is cryptographically unrecoverable.
Every queued mutation is signed with HMAC-SHA256 over a canonical payload, and the server verifies the signature before the write is admitted on reconnect.
Each mutation carries a monotonic sequence number and a nonce, so a captured sync payload cannot be replayed to duplicate a completion or a parts draw.
Failure mode. A stolen van tablet is the realistic threat, not a nation-state. Unencrypted local storage turns one lost device into a customer address book, a price list, and a set of building access notes.
03 · Authorisation
Role-based access control
Scopes are granular because the roles genuinely differ. A field technician needs today's addresses and no pricing; a CFO needs every margin and no customer phone numbers. Both are served from the same records with different projections.
Field technician — assigned work orders only, parts and completion writes, no cost, no margin, no customer list.
Dispatcher — full board read and assignment writes across the fleet, no rate-card edits and no billing surface.
Finance and CFO — quote economics, margin, invoicing, and export, with customer contact fields redacted by default.
Administrator — user lifecycle, SSO configuration, and rate-card governance, with every action written to the audit log and no ability to alter or delete that log.
Failure mode. Over-broad roles are how a routine offboarding becomes an incident. Scoping to the projection each role actually uses shrinks what a compromised session can reach.
04 · Lineage
Audit logging and lineage
Every priced quote and every dispatch decision is written to an append-only log with the inputs that produced it. A quote is reconstructible months later without trusting anyone's recollection.
Append-only event log; there is no UPDATE or DELETE path exposed to any role, including platform administrators.
Each entry is hash-chained to its predecessor, so a gap or an alteration is detectable rather than merely prohibited.
CPQ entries capture the full input vector, the rate-card version, and the derived line breakdown — the price is replayable, not just recorded.
FMS entries capture the technician set considered, the skill match, the distance basis, and the assignment actually made.
Logs stream to customer-owned storage or a SIEM over a signed webhook, so your retention policy governs, not ours.
Failure mode. Mutable logs are worth very little in a dispute or an audit. The value of the log is precisely that nobody — us included — can quietly change it.
Data path
From a parkade with no signal to an append-only log.
Select a stage to see what protects it. The interesting property of this path is that the device is treated as untrusted throughout — a signed mutation is verified at the edge before it is deserialised, not after.
Field device — offline store
The technician app is offline-first. Work orders, cut lists, and parts draws are written locally and queued; connectivity is treated as an optimisation, never a precondition.
SQLCipher AES-256 page encryption on the local database
Key sealed in Secure Enclave / StrongBox, never persisted in plaintext
Certificate pinning on the sync channel
Remote wipe and per-device revocation from the admin console
Stage cryptography: AES-256 · SQLCipher
Availability & identity
The target, and the measurement, side by side.
An SLA number is a contractual commitment with a credit attached. It is not the same thing as what the platform actually did last quarter, so both appear here.
Standard
99.9%
at most 43m 12s unavailable per month
Shared control plane in AWS ca-central-1, active-passive failover to a second AZ
10% of monthly fee below target
Business
99.95%
at most 21m 36s unavailable per month
Reserved capacity in AWS ca-central-1, active-passive with a warm standby and priority promotion
25% of monthly fee below target
Enterprise
99.99%
at most 4m 19s unavailable per month
Single-tenant cluster in AWS ca-central-1, hot standby across two Canadian AZs with automated promotion
50% of monthly fee below target, credited automatically
Measured, trailing 90 days
100.0%0.0%100.0%
Taken at the API edge in AWS ca-central-1, not at the load balancer.
At 99.95% measured, the platform is meeting the Standard and Business targets and is running below the 99.99% Enterprise commitment on shared infrastructure — which is exactly why that tier is served from a dedicated cluster rather than sold as a stronger promise over the same hardware. Monday–Friday, 07:00–19:00 ET. P0 incidents are covered 24/7.
Region and failover topology
Every tier runs in AWS ca-central-1 (Montréal). Active-passive across availability zones: a standby in a second availability zone is promoted on failure. We describe it that way rather than as active-active because active-active means both sides serving writes concurrently, and a buyer who designs around zero-loss failover on the strength of that word has been misled by it. What we commit to instead is bounded and measurable.
Recovery time objective
under 15 minutes
Recovery point objective
under 60 seconds
Failover is exercised on a scheduled basis rather than assumed to work, and the last exercise date is included in the security review pack.
Single sign-on and automated deprovisioning
SSO is included on every paid tier. SCIM matters more than SSO for a field business: it is what turns a termination in your HR system into a revoked tablet session within minutes, rather than whenever somebody remembers to say something.
Okta
SAML 2.0 · OIDC · SCIM 2.0 push
Microsoft Entra ID
SAML 2.0 · OIDC · SCIM 2.0 push
Google Workspace
SAML 2.0 · OIDC · SCIM 2.0 push
OneLogin
SAML 2.0 · SCIM 2.0 push
JumpCloud
SAML 2.0 · OIDC · SCIM 2.0 push
Any SAML 2.0 IdP
SAML 2.0 · Just-in-time or SCIM
What connecting your IdP actually involves
“Supports SAML 2.0” is on every vendor’s page and tells your IT lead nothing about the afternoon ahead. These are the four exchanges in order, with the artefact each produces, so the work can be scoped before a call.
01Exchange SAML metadata
~15 minutes
We issue your tenant's SP metadata — entity ID, ACS URL, and signing certificate, all tenant-scoped rather than shared across customers. You return your IdP metadata URL, which we poll so a certificate rotation on your side does not become an outage on ours.
→ Tenant-specific ACS URL and entity ID
02Map attributes to roles
~30 minutes
NameID must be a persistent, non-reassignable identifier — an email address is accepted but is the weaker choice, because addresses get reused. Group or role claims map to the RBAC scopes above through a mapping you define and can change without our involvement.
→ Claim-to-scope mapping, versioned and audit-logged
03Turn on SCIM 2.0 provisioning
~30 minutes
We issue a SCIM base URL and a bearer token scoped to provisioning only — it cannot read quotes, dispatch, or pricing. Users and groups push from your directory; a deactivation in your HR system revokes the tablet session within minutes rather than whenever somebody remembers to mention it.
→ SCIM base URL and a provisioning-only bearer token
04Enforce SSO and close the password path
~10 minutes
Once a break-glass administrator is verified against your IdP, password authentication is disabled for the whole tenant. We recommend this and do not charge for it; SSO on every paid tier is a security control, not a packaging lever.
→ Password login disabled tenant-wide
Key management
Encryption at rest is table stakes. Custody is the question.
Every vendor says AES-256. Far fewer will say where the key lives, who can export it, how often it rotates, and what happens to it when you leave. Those four answers are what a reviewer actually needs to score the section, so they are here rather than in a questionnaire response.
Key hierarchy
Envelope, per tenant
A tenant-specific data key encrypts that tenant's rows, snapshots, and object storage. The data key is itself encrypted by a customer master key held in the managed KMS and never leaves it in plaintext. Compromising one tenant's data key reaches exactly one tenant's data.
Key custody
FIPS 140-2 Level 3 HSM
Master keys are generated in and never exported from validated hardware security modules inside AWS ca-central-1. No engineer, including ours, can extract key material; the KMS performs the cryptographic operation and returns the result, and every call is logged.
Rotation
Annual, automatic
Master keys rotate on a twelve-month schedule with old versions retained for decryption, so rotation never requires re-encrypting history or a maintenance window. On-demand rotation is available and is what we do after any credential exposure, without waiting to be asked.
Bring your own key
Enterprise tier
Enterprise tenants may supply their own KMS key and retain the ability to revoke it. That is a real control and a real hazard: revoking the key renders your data unreadable to us and to you, immediately, and no support escalation reverses it. We will not enable BYOK without walking through that consequence first.
Destruction
Key, then ciphertext
On termination, the per-tenant data key is destroyed after the 35-day point-in-time recovery window ages out. Destroying the key is what makes the remaining ciphertext unrecoverable by construction rather than by policy, and a certificate of destruction is issued on request.
Security review
What your CIO is going to ask.
These are the eight questions that decide an enterprise security review. Answering them on a public page rather than in a questionnaire response is the point.
Where does our data physically live, and can it leave Canada?
Production data — the database, object storage, backups, and the audit log — is resident in AWS ca-central-1 (Montréal) by default. Nothing in the primary data path crosses the border. Two carve-outs are worth naming rather than burying: outbound technician SMS is delivered through a carrier gateway that may transit US infrastructure, and if you enable US-hosted mapping or accounting integrations those calls go where those vendors are. Both are individually switchable, and the subprocessor list naming every one of them is provided before signature rather than on request. A Toronto-region or on-premise deployment is available on the Enterprise tier.
Do you guarantee 99.99% uptime?
On the Enterprise tier, yes — contractually, with automatic service credits, on a single-tenant cluster in AWS ca-central-1 with a hot standby in a second Canadian availability zone. On Standard the commitment is 99.9% and on Business it is 99.95%. Two things worth being precise about. First, the topology is active-passive, not active-active: a standby is promoted on failure, which is why we publish an RTO of under 15 minutes and an RPO of under 60 seconds rather than implying zero of either. Second, we will not quote you the Enterprise number and deliver shared infrastructure. Our own trailing-90-day measured availability is published on this page next to the targets, taken at the API edge; when the measurement is below a target we say so and issue the credit without you having to claim it.
Can we use our existing SSO and automatically deprovision leavers?
Yes. SAML 2.0 and OIDC are supported against Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, or any compliant IdP, with SCIM 2.0 for provisioning. SCIM matters more than SSO here: it is what makes a termination in your HR system revoke a technician's tablet session within minutes rather than whenever somebody remembers. Enforced SSO — where password login is disabled entirely for your tenant — is available and is what we recommend. SSO is included on every paid tier; it is a security control, not an upsell.
A technician loses a tablet in a customer's building. What actually happens?
The local database is SQLCipher-encrypted with AES-256 and the key is sealed in the device's hardware keystore, so the data is not readable without the device unlocked by its owner. You revoke the device from the admin console, which invalidates its refresh token and queues a remote wipe on next contact. Any mutations still queued on that device cannot be replayed against the API, because each one carries a nonce and a monotonic sequence number the server has either already consumed or will reject. The audit log will show you precisely which work orders were resident on the device at the time it was last synced.
How does data migration off our current ERP work, and what breaks?
Migration runs in three passes against a staging tenant, never against production. Pass one loads customers, sites, and the rate card, and reconciles record counts and totals against your source export. Pass two replays a sample of historical quotes through the CPQ engine and diffs the derived price against the price your existing system produced — that diff is the deliverable, because it is where the interesting disagreements surface. Pass three loads open work orders and technician certifications. What typically breaks is not the data: it is undocumented pricing behaviour that lived in one estimator's spreadsheet. The diff makes it visible, and you decide which behaviour is correct.
Do you run penetration tests, and will you share the report?
An independent third-party penetration test is performed annually against the API, the web application, and the mobile clients, with a targeted retest after any material architectural change. The executive summary and the remediation status are shared under NDA; the full report is not distributed, because it is a working map of the environment and circulating it does not make you safer. Critical findings are remediated before the engagement closes. We also operate a private coordinated-disclosure programme — reports go to the security address on this page and are acknowledged within one business day.
Who else touches our data, and how do we find out when that changes?
The current subprocessor list — infrastructure, messaging, payments, and mapping — is published with the DPA and identifies what each one processes and where. Material additions are notified 30 days ahead of taking effect, which gives you a window to object rather than a notification after the fact. Every subprocessor is contractually bound to equivalent obligations, and none of them are permitted to use your data to train a model.
If we leave, how do we get our data out and how do we know it's gone?
Export is a first-class function, not an offboarding favour. Full relational export in Postgres dump and CSV, plus the complete audit log in JSON, is available from the admin console at any point during the subscription — you do not need to be leaving to take it. On termination the production tenant is destroyed within 30 days and encrypted backups age out on the 35-day point-in-time recovery window, after which the per-tenant KMS data key is destroyed and the ciphertext is unrecoverable by construction. A written certificate of destruction is issued on request.
Data residency
Canadian data stays in Canada.
Residency is only meaningful if it covers the replica, the backups, and the people who can reach production during an incident. All four are listed below because the first three are where residency claims usually quietly fail.
Primary region
AWS ca-central-1
Montréal. All application servers, the CPQ engine, and the dispatch service run here for Canadian tenants — the named AWS region, not a US region wearing a Canadian label.
Standby
Active-passive
The read replica and the promotion target sit in a second availability zone inside the same Canadian region, never a US secondary. Failover promotes the standby rather than running an active-active pair, which is why an RTO and an RPO are published on /security instead of a claim of zero.
Backups
Canada only
Encrypted snapshots are written to Canadian object storage with a 35-day retention window and are never replicated across the border.
Support access
Canada-based
Break-glass access to production is limited to Canadian-resident staff, logged to the append-only audit trail, and expires automatically.
Legal & policy
The 5 documents procurement asks for.
What follows is a plain-language summary of each policy, not the executed agreement. The full text is issued with the order form and, for Enterprise, is negotiated before signature — where the two disagree, the signed document governs.
Privacy Policy
Reviewed May 2026
What personal information the platform holds, why it holds it, and how long it keeps it. Most of it is workforce data — technician names, device identifiers, and location traces captured while a job is open.
Location history from the field app is retained for 90 days by default and is configurable down to 24 hours per tenant.
We do not sell personal information, and we do not use tenant data to train models offered to other tenants.
Customer records are exportable in full at any time in CSV and JSON without a support ticket.
Deletion requests are executed within 30 days across primary storage, and within 35 days across encrypted backups as they roll off.
Terms of Service
Reviewed May 2026
The commercial agreement: what we owe you, what you owe us, and what happens when either side wants out. Enterprise agreements are negotiated and supersede these terms where they conflict.
Subscription terms run 12 months by default, renewing for equal periods unless either side gives 30 days notice.
Availability credits are calculated against the target published on this page for your tier, and are applied automatically rather than on request.
Your data remains yours. On termination it stays exportable for 60 days before deletion begins.
Price changes at renewal are communicated at least 60 days before the renewal date.
Acceptable Use Policy
Reviewed March 2026
The narrow set of things that will get an account suspended. It exists to protect other tenants on shared infrastructure, not to give us discretion over how you run your business.
No attempts to access another tenant's data, including through the API or an exported credential.
No load testing against production. Sandbox exists for that and is not rate limited to the same ceiling.
No use of the dispatch or messaging surfaces for unsolicited bulk contact.
Suspension for anything other than an active security threat is preceded by written notice and a remediation window.
Subprocessors
Reviewed June 2026
Every third party that can process tenant data, what it does, and where it runs. The current list is published to customers under NDA with the control mapping; the categories are public here.
Cloud infrastructure and managed databases — Canada (ca-central-1), primary and replica.
Payment processing for subscription billing — processes billing contact and card data, never job or customer records.
Transactional email and SMS delivery for dispatch notifications — message content and recipient number only.
Error and performance telemetry — scrubbed of personal information before it leaves the tenant boundary.
PIPEDA Statement
Reviewed June 2026
How the platform maps to Canada's Personal Information Protection and Electronic Documents Act, and who to contact when an access or correction request arrives.
Consent, purpose limitation, and retention are configured per tenant rather than assumed globally.
A named Privacy Officer responds to access requests within 30 days, which is the statutory ceiling rather than a service target.
Cross-border transfer is avoidable end to end: the Canadian residency configuration keeps primary, replica, and backup inside Canada.
Breach notification follows the PIPEDA real-risk-of-significant-harm threshold, with tenant notification inside 72 hours of confirmation.
Request the full text, the subprocessor list, or a signed DPA from privacy@novelsystems.ca. No sales conversation is required first.
Send us your questionnaire.
CAIQ, SIG Lite, or your own spreadsheet — we complete it and return the control mapping, the penetration-test summary, and the subprocessor list under NDA. No sales call is required to get any of that.