Security Controls
Infrastructure, product, operations, privacy, and governance
The 63 controls that protect customer data in AssetLab, each traced to the document that evidences it. Prepared for IT, security, and procurement review.
Infrastructure Security
15 controlsSystems, networks, the cloud environment, encryption and monitoring.
| Control | Where AssetLab stands | Evidence |
|---|---|---|
| Data encrypted in transit | TLS 1.3 negotiated with modern clients. TLS 1.2 is the floor; TLS 1.1 and below are rejected. | Security Whitepaper 4.1 |
| Data encrypted at rest | AES-256 on the PostgreSQL database and on object storage. | Security Whitepaper 4.2 |
| Independent second encryption layer on backups | Offsite backups are encrypted client-side by AssetLab before upload, with the private key held offline. The storage provider holds ciphertext it has no means to decrypt. | Security Whitepaper 4.2, 4.3 |
| Web application firewall in place | Cloudflare WAF and rate limiting sit in front of the application. | Security Whitepaper 2.1, 6.3 |
| DDoS protection utilized | Cloudflare edge network. | Security Whitepaper 2.1 |
| HTTP Strict Transport Security enforced | HSTS served with a one-year max-age. Preload and includeSubDomains are not currently set. | Security Whitepaper 4.1 |
| Security response headers enforced | X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options and X-XSS-Protection. | Security Whitepaper 4.1 |
| Certificate transparency monitored | CT logs are polled. An unauthorized certificate issued for an AssetLab domain raises an alert. | Security Whitepaper 4.1, 8.2 |
| Encryption key management delegated to attested providers | Production keys are managed by Supabase, Clerk and Cloudflare under their own SOC 2 Type II processes. | Security Whitepaper 4.3 |
| Every sub-processor independently attested | All six carry SOC 2 Type II in their own name. Cloudflare additionally holds ISO/IEC 27001, ISO/IEC 27701 and PCI DSS Level 1. | Sub-processor List v1.2 |
| Canadian data residency for operational data | Customer Data, its backups and the user-identity mirror are held in AWS ca-central-1 (Montreal). | Security Whitepaper 6.1 |
| Continuous production monitoring | Four automated detection signal families run continuously, hosted outside the platform they observe. | Security Whitepaper 8.2 |
| Monitoring integrity verified independently | Every scheduled component reports a heartbeat to an external provider. A dead-man's switch alerts from outside if monitoring itself stops. | Security Whitepaper 8.2 |
| Infrastructure defined as code and version controlled | Application code, migrations, edge-function definitions and infrastructure definitions all live in versioned source control with peer review. | Security Whitepaper 9.4 |
| Minimal network requirements | Standard outbound HTTPS on port 443 only. No firewall changes, port openings or endpoint agents are required. | Security Whitepaper 2.4 |
Product Security
16 controlsPlatform and application-level controls, tenant isolation and access.
| Control | Where AssetLab stands | Evidence |
|---|---|---|
| Independent penetration testing performed | Third-party test conducted May 2026. The report is available to customers and active evaluations under mutual NDA. | Security Whitepaper 7.1 |
| Penetration test findings tracked to closure | Internal remediation register. Each finding carries a regression test that fails against the unfixed version. | Security Whitepaper 7.1 |
| Tenant isolation enforced at the database layer | PostgreSQL Row-Level Security on every tenant-scoped table, keyed to a cryptographically verified RS256 JWT. | Security Whitepaper 3.1 |
| Tenant isolation enforced in depth | Three independent layers: database row-level security, application permission checks, and UI route gates. | Security Whitepaper 3.1 to 3.3 |
| Tenant identifier never taken from user input | Derived from the verified JWT only, never from a request body or a URL. | Security Whitepaper 3.1 |
| Role-based access control implemented | A four-tier model - Administrator, Manager, Staff, Requester - enforced at all three layers. | Security Whitepaper 3.4 |
| Multi-factor authentication available | TOTP authenticator apps, SMS, backup codes and WebAuthn passkeys. | Security Whitepaper 5.1 |
| Passwordless authentication supported | Email one-time password and passkeys (WebAuthn). | Security Whitepaper 5.1 |
| Enterprise single sign-on supported | SAML 2.0 SSO and SCIM 2.0 provisioning via Clerk Organizations. | Security Whitepaper 5.2 |
| Breached-password detection enforced | HaveIBeenPwned checking where local passwords are enabled, with configurable length, complexity, expiry, history and lockout. | Security Whitepaper 5.1 |
| Session controls configurable | Per-organization session lifetime and idle timeout, with step-up authentication on critical operations. | Security Whitepaper 5.3 |
| API credentials scoped, hashed and revocable | Per-tenant API keys are stored as SHA-256 hashes, bound to one tenant at creation, and revocable with immediate effect. | Security Whitepaper 3.5 |
| Dependency vulnerability scanning enforced | A blocking gate on every lockfile change and nightly. Accepted findings are recorded individually with a written reason and a hard expiry date. | Security Whitepaper 7.2 |
| Pre-merge security gates enforced | Type checking at zero errors, linting, dead-code analysis, and security-pattern guards written for this codebase: tenant-filter enforcement, row-level-security correctness, security-definer grant checks, view security-invoker checks and migration collision detection. | Security Whitepaper 7.2 |
| Automated regression testing for security findings | Every closed security finding has a permanent regression test in the suite. | Security Whitepaper 7.2 |
| Responsible disclosure program operated | security@assetlab.ca. Receipt is acknowledged within two business days, and disclosure is coordinated with the reporter. | Security Whitepaper 7.5 |
Internal Security Procedures
11 controlsOperational routines, change management, incident response and continuity.
| Control | Where AssetLab stands | Evidence |
|---|---|---|
| Incident response plan established | Cyber Security Incident Response Plan v2.0, with version-controlled runbooks for credential compromise, sub-processor incident, row-level-security regression, data leak, availability incident and vulnerability disclosure. | Security Whitepaper 8.4, CSIRP v2.0 |
| Incident response plan reviewed on a defined cycle | At least annually, after any material incident, and on material architectural change. | Security Whitepaper 8.4 |
| Breach register maintained | Every breach of security safeguards involving personal information is recorded whether or not it is reportable, retained for not less than 24 months, and producible to the Privacy Commissioner of Canada. | Security Whitepaper 8.4 |
| Real-risk-of-significant-harm assessment documented | The assessment is recorded at the time, including where the conclusion is that no such risk exists. | Security Whitepaper 8.4 |
| Business continuity plan established | A Business Continuity Addendum covering key-personnel unavailability across short, medium, long and permanent-loss horizons, with a documented succession path. | Business Continuity Addendum v1.1 |
| Detection independent of personnel availability | Automated monitoring and alerting run continuously and independently of any individual. Statutory clocks expressly do not pause. | Business Continuity Addendum 2, 5.4 |
| Change management enforced | Peer-reviewed version control with blocking continuous-integration gates before code reaches production. | Security Whitepaper 7.2, 9.4 |
| Patch management operated | A continuous-deployment pipeline. Critical security patches are validated and deployed promptly, and security-relevant changes are communicated to tenant Administrators. | Security Whitepaper 7.4 |
| Availability commitment backed by service credits | 99.5% Monthly Availability with a credit schedule, on Enterprise subscriptions where the order form incorporates the AssetLab Service Level Agreement. | Service Level Agreement v2.0 |
| Public status page operated independently | status.assetlab.ca runs independently of the platform it reports on. Security findings are deliberately routed internally rather than published there. | Security Whitepaper 8.3 |
| Disaster recovery procedures documented | Per-component procedures with named scenarios and timed budgets. RPO is up to 24 hours; RTO is approximately one to two hours. | Security Whitepaper 9.2, 9.4 |
Data and Privacy
14 controlsData protection, privacy commitments, retention and deletion.
| Control | Where AssetLab stands | Evidence |
|---|---|---|
| Data Processing Agreement available | A DPA incorporating the EU Standard Contractual Clauses and the UK International Data Transfer Addendum. It is not self-executing and takes effect only on execution by both parties. | Security Whitepaper 10.1, DPA |
| Sub-processor list published | The full list, with purpose, processing location, data accessed and safeguards for each, published on this site and reproduced at Annex 3 of the DPA. | Sub-processor List v1.2 |
| Transfer Impact Assessments maintained | A written TIA for every sub-processor, with residual risk rated. Available to customers under confidentiality. | Security Whitepaper 6.4, TIA set |
| Sub-processor change notice with objection rights | At least thirty days advance notice before engaging a new sub-processor or materially changing an existing relationship, with a thirty-day objection window on reasonable data-protection grounds and termination with a pro-rata refund where an objection cannot be accommodated. | Terms of Service 8.7, DPA 6.3 |
| Breach notification commitment | Affected customers are notified without undue delay and, where feasible, within 72 hours of confirmation, with the nature of the breach, categories and approximate record count, likely consequences, mitigation and a contact point. | Security Whitepaper 8.4 |
| Data retention and disposal schedule adopted | Audit metadata is retained for 24 months to match the statutory breach-record duty. Stored request payloads are erased at 30 days. | Security Whitepaper 8.1 |
| Deletion on termination defined | A 30-day export window, production data deleted within 90 days thereafter, and backup copies purged within 180 days. A certificate of destruction is available on request. | Security Whitepaper 10.5 |
| Customer-initiated data export available at any time | CSV, XLS and PDF from the interface, and a full JSON export across all entities via the API. | Security Whitepaper 9.3 |
| Data subject rights supported | Export, edit and delete capability is provided so that you can fulfil access and correction requests as the Controller. | Security Whitepaper 11 |
| Audit logging in place | Authentication events, role assignments, API key issuance, OAuth grants, configuration changes, every external API call including reads, and database mutations captured by trigger. | Security Whitepaper 8.1 |
| Monitoring cannot read Customer Data | Every detection query executes inside the database and returns counts, hashes and booleans only. No rows and no personal information leave the data tier. Alert bodies carry identifiers, counts and first-response guidance, never record content, and source addresses are hashed before leaving the database. | Security Whitepaper 8.2 |
| No AI training on Customer Data | AssetLab transmits no Customer Data to any AI provider of its own initiative and trains no model on it. No AI provider is an AssetLab sub-processor. The optional customer-enabled assistant integration is off by default and runs under your own agreement with the provider you choose. | Security Whitepaper 10.2 |
| Prohibited data categories defined and enforced | Government identifiers, financial account information, protected health information, biometric data, sensitive personal characteristics, children's personal information and third-party credentials are contractually excluded. | Security Whitepaper 10.4, Terms of Service 6.2 |
| Privacy framework alignment documented | PIPEDA, Quebec Law 25, Ontario and BC FIPPA, Nova Scotia FOIPOP and PIIDPA including the foreign-demand notification trigger, CASL, and GDPR and UK GDPR supportability. | Security Whitepaper 10.3 |
Organizational Security
7 controlsGovernance, vendor management and continuity of the company behind the platform.
| Control | Where AssetLab stands | Evidence |
|---|---|---|
| Confidentiality agreements executed | A Confidentiality and Proprietary Property Agreement is in place for personnel. | Corporate formation records |
| Intellectual property assigned | An executed IP assignment covering existing intellectual property. | Corporate formation records |
| Mutual NDA available for security disclosures | A standard mutual NDA with an indefinite term for Security Information, used before releasing Transfer Impact Assessments, penetration test reports and continuity materials. | NDA template |
| Vendor management program operated | A written DPA with every sub-processor carrying obligations no less protective than our own, a maintained vendor DPA register, and collected certifications. | Sub-processor List v1.2, Vendor DPA Register |
| Sub-processor liability accepted | AssetLab remains liable to customers for the acts and omissions of its sub-processors. | Sub-processor List v1.2 |
| Outside counsel engaged for incident and regulatory matters | Named counsel with a defined activation path in the continuity plan. | Business Continuity Addendum 3 |
| Key-personnel succession documented | An always-staffed inbox, counsel escalation, source-code and backup-key custody, and documented wind-down or transfer paths. | Business Continuity Addendum 6, 7 |
Reviewing us for a procurement?
Send us your security questionnaire and we will complete it, together with the supporting documentation your review needs.
security@assetlab.ca for vulnerability reports • legal@assetlab.ca for documents