Trust
Security you can check, not security we assert.
Written for whoever has to fill in a due-diligence form about us: how your data is kept separate from another customer’s, where it sits, how the software is built — and what CyberWave does not have. Every line carries a state.
Configuration facts were read from the live production environment on 14 September 2026.
The activity log, with the columns it genuinely records. Attribution matters more than volume: the log answers “who changed this, and when”. Example workspace — Northstar Manufacturing Ltd. is fictional.
- Isolation
- Row-level security
- Enforced by the database
- Data at rest
- Canada
- Supabase, ca-central-1
- Application
- United States
- Vercel, iad1
- AI processing
- United States
- Anthropic
The register
Every claim on this page, with a state against it.
Including the rows we do not have. A security page that only lists strengths has to be read twice, and the second reading is the one that costs you trust.
- VERIFIED
- Read out of the live production configuration or the source on 14 September 2026.
- OPERATING
- A practice we run. Real, but a habit rather than a configuration line you can point at.
- LIMITED
- In place, with the limitation written into the row rather than left for you to discover.
- NOT AVAILABLE
- Not in the product today. If your policy requires it, price the gap in now.
- NOT HELD
- No certificate, report or attestation exists. There is nothing to send you.
| Area | State | What is actually in place |
|---|---|---|
| Tenant isolation | VERIFIED | Row-level security in Postgres on the tables holding customer data, plus authorisation in the server route, which resolves the caller’s organisation before it reads anything. Integration tests assert one organisation cannot read another’s rows. |
| File isolation | VERIFIED | Uploads live in a private bucket, path-scoped by organisation, with its own storage policy. Downloads are served through short-lived signed URLs. |
| Authentication | VERIFIED | Supabase Auth. Email and password, minimum eight characters, checked against known breached passwords. An email address must be confirmed before a workspace can be created. Password reset by emailed link. |
| MFA on your Sentinel login | LIMITED | Two-step verification with a time-based code from an authenticator app, enrolled by the account holder in Account → Security. An owner or admin can make it required for everyone in the workspace. Enforcement is not only in the interface: a password-only session belonging to an account that has a verified factor is refused in the database by a restrictive policy on every tenant table and on file storage, so it can read nothing. The limits, stated rather than left for you to find: authenticator apps only — no passkeys, no security keys, no SMS codes and no printable recovery codes; if you lose your authenticator, recovery is a support request that revokes your sessions, not a self-service reset. Enrolment, challenge and the database refusal were exercised end to end against production on 28 September 2026. |
| SSO / SAML | NOT AVAILABLE | The SSO endpoint is a stub and returns "not implemented". There is no identity-provider integration to configure. |
| Authorisation | VERIFIED | Role-based inside each workspace, checked on the server on every request. Platform administration is a separate path with its own audit table that records state before and after. |
| Encryption in transit | VERIFIED | TLS to the application and between the application and the database. HSTS with a two-year max-age, includeSubDomains and preload; CSP, X-Frame-Options DENY, nosniff and a strict referrer policy on every response. |
| Encryption at rest | OPERATING | Provided by the managed database and storage platform under its own terms. CyberWave does not implement it, so this page does not name a cipher on the platform’s behalf. |
| Auditability | VERIFIED | A per-organisation activity log recording actor, action, resource, the changed fields, IP address, user agent and timestamp. |
| Audit-write failure | LIMITED | Audit writes never throw, so a logging failure cannot break a customer’s work — which means a failed write is silent rather than blocking. That trade-off is ours and it is stated. |
| Rate limiting: sign-up and sign-in | VERIFIED | Counted atomically in the database and shared by every application instance. Sign-up, password reset and verification-email resend are limited per IP address and per email address, sign-in per IP address, and workspace creation per account. IP addresses and emails are stored only as keyed hashes, and sign-in attempts against an email are counted without locking that account. |
| Rate limiting: other routes and bots | LIMITED | Other API routes, including AI and uploads, are limited per IP by edge middleware whose counters are per instance and in memory, so they are not a global limit. There is no CAPTCHA on sign-up. |
| Data residency | VERIFIED | Customer data at rest in Canada, ca-central-1. Application compute in the United States. AI requests to the United States. The provider list below is the full map. |
| AI handling | VERIFIED | No training or fine-tuning pipeline exists. Each AI result is stored with the workspace’s records, together with a short excerpt or label of the request that produced it. Grounding context is assembled server-side from your own records after the route has authorised you and resolved your tenant; only the request leaves. |
| Upload safety | LIMITED | Extension allowlist, blocked executable types, double-extension and magic-byte checks, size caps. This is validation, not antivirus: the hook for a malware-scanning service exists and is not switched on. |
| Secure development | OPERATING | Numbered migrations applied in order, an automated suite that includes tenant-isolation tests, fail-closed defaults, secrets in deployment configuration with a written rotation procedure, and error records kept in our own database rather than a third-party service. |
| Backups | LIMITED | Daily database backups by the managed database platform, about a week of them retained, and a written restore procedure whose final step re-runs the tenant-isolation test. Point-in-time recovery is not enabled, so a restore returns to the last daily backup. Uploaded files held in storage are not part of those database backups. No RPO or RTO is published because none is set. |
| Incident response | OPERATING | A written runbook: severity levels, a named incident commander, containment before root cause, evidence preserved, a blameless postmortem. A runbook, not a monitored service — nobody is watching a console overnight. |
| Breach notification window | LIMITED | No fixed number of hours is published. The Data Processing Addendum commits CyberWave to notify an affected customer without undue delay after confirming a security incident. |
| Subprocessors | VERIFIED | Six providers, each with its role and processing location. Three libraries present in the codebase but not configured in production are named as exclusions rather than left out. |
| Marketing website | VERIFIED | cyberwave.ca is hosted on Vercel and sets no analytics, advertising or tracking cookie. Its Content Security Policy allows scripts only from the site itself, with HSTS, X-Frame-Options DENY and nosniff on every response. |
| Domain, DNS and email | LIMITED | Domain registration and DNS at GoDaddy; the support mailbox on Microsoft 365. SPF is published for the domain and for the application’s sending subdomain; DKIM is published for the domain. No DMARC policy is published yet. |
| Responsible disclosure | OPERATING | A published route that reaches a person and does not require you to be a customer. No paid bug bounty. |
| SOC 2 report | NOT HELD | No Type I and no Type II audit has been performed. There is no report to send you. |
| ISO/IEC 27001 certification | NOT HELD | Sentinel maps your programme to ISO/IEC 27001:2022. CyberWave itself is not certified against it. Those are two different claims. |
| Penetration-test attestation | NOT HELD | No third-party test report or certificate to publish. |
| Legal package in force | OPERATING | The Terms of Service, Privacy Policy, Data Processing Addendum, subprocessor list and the policies they incorporate are in force. Each page shows its version and effective date, and Sentinel records which versions a customer accepted. |
Straight answers
What CyberWave does not have.
Most security pages in this category are technically defensible and practically misleading. Here is the list in plain words.
- A SOC 2 report. No Type I or Type II audit has been performed. What we can give you instead is this page, the Data Processing Addendum and the subprocessor list, and written answers to what they do not cover.
- ISO 27001 certification. Sentinel maps your programme to the standard; CyberWave is not certified against it.
- A penetration-test attestation. No third-party report to publish. Testing CyberWave needs our written agreement first — see the responsible disclosure page.
- A security operations centre. CyberWave does not monitor your systems or respond to your incidents. Sentinel is a readiness workspace, not detection and response.
Tenant isolation
Checked twice, in two systems, neither of them a convention.
Showing one customer another customer’s records is the failure this category does not recover from. So separation is enforced in the database, underneath the application, and again in the route above it — and asserted by tests, so a refactor cannot quietly remove a filter.
- RequestGET /api/controlsSession cookie only — no tenant in the URL
- Edge middlewareRate limit, session checkPer instance; sign-in limits also in the database
- Server routeResolve organisation and roleAuthorisation before any read
- Database policyRow-level securityRows filtered to that organisation in Postgres
- ResultRows for one organisationA query missing its tenant condition returns none
Two checks in two systems. The middleware limit is per instance, which is why that link is amber; sign-up and sign-in limits are also counted in the database, across every instance.
A trust page is only worth reading if it is capable of saying no.
Every state in the register was read from the live configuration or the source. The words OPERATING and LIMITED exist so that the word VERIFIED still means something when you find it on a row.
Data residency and providers
Where your data is, and everyone who can touch it.
Storage and processing are two different questions, and merging them is how a Canada-only claim gets made by a company that cannot support it. The primary datastore is in Canada; every request is processed in the United States in transit.
| Provider | What it does | Processing location | Can access customer data? |
|---|---|---|---|
| Supabase | Database, authentication, file storage | Canada — ca-central-1 | Yes — all of it |
| Vercel | Hosting and serverless execution for the application and the cyberwave.ca website | United States — iad1 | Yes — in transit |
| Anthropic | AI features | United States | Only what is in a prompt |
| Stripe | Payments, subscriptions, invoicing | United States / global | Billing data only |
| Resend | Transactional email delivery | United States — us-east-1 | Recipient address and message content |
| GoDaddy / Microsoft 365 | Domain registration and DNS; the support mailbox (Microsoft 365) | Not verified to be Canada | Support correspondence only |
Three libraries appear in our source and are not configured in production — an error tracker, a product-analytics client and a hosted cache. They are named as exclusions because a reader who finds them in the code deserves an explanation rather than a gap. Without the hosted cache, sign-up and sign-in limits are counted in the database, and other routes limit per instance.
AI handling
What we verified about our own conduct.
No training pipeline. AI results are stored with your workspace’s records, with a short excerpt or label of the request. Grounding for an AI request is built from your own records after the route has authorised the caller and resolved their tenant — never by instructions inside a prompt — and only the request leaves. What the provider may do with it is their commitment, in the AI Features Notice and the DPA.
Recovery and response
What happens when something goes wrong.
A written runbook: confirm scope and declare, contain before root cause, preserve the activity log, assess which organisations and rows were affected, then notify under the contractual obligation, fix, re-verify with the isolation tests and write it up. No RPO, RTO or notification window is printed, because none is set in a document that binds us.
Shared responsibility
Where the line falls.
Ours: keeping your data separate, authenticating members, recording who changed what, running the platform and the runbook. Yours, and it does not transfer: who has access and when it ends, what you upload, reviewing AI output before it reaches anyone external, and operating the controls themselves — Sentinel records that MFA is in place; it does not turn it on in your environment.
Questions
What buyers ask us about security.
Answered the way we would answer them on a call with your security team listening.
Do you have a SOC 2 report or ISO 27001 certification?
Can another customer see our data?
Each organisation is a separate tenant, enforced by row-level security in the database and by authorisation in the server route — a query that forgets its tenant condition returns nothing — and the automated suite has tests that assert exactly that. If you ever see something that is not yours, stop and tell us through responsible disclosure.
Can we enforce MFA or SSO on our Sentinel accounts?
Where is our data stored, and does any of it leave Canada?
Do you train AI models on our data?
CyberWave builds and trains no models, there is no job or export anywhere in the codebase that assembles customer data for model development. Each AI result is stored with your workspace’s records, together with a short excerpt or label of the request that produced it. What the AI provider may do with the content of a request is a contractual term in the AI Features Notice and the DPA.
Do you monitor our environment or respond to our incidents?
A question your form asks that is not answered here? Write to support@cyberwave.ca and you will get written answers. To report a vulnerability, use the responsible disclosure process.
Read the register, then look at the product.
Security detail is worth more when you can see what it is protecting. Bring the questionnaire your own customers send you and we will go through it against a real workspace.
No credit card required
- Published pricing on every standard plan
- No credit card required for the trial
- No automatic charge when a trial ends
- Tenant-isolated architecture, data stored in Canada
- Clear data-processing terms
- No compliance guarantee — human judgement still required