Security at RoadSnap

RoadSnap was designed around six principles from the first commit. Each is a fact you can check on this page.

• Nobody here can read your plans. Not as a policy we ask staff to follow — as a permission the database does not grant. Our own console is denied the table your roadmaps live in.
• No passwords, anywhere. A one-time code to your email, or your own identity provider on Team. There is no password database to steal. Your provider's second factor comes with it; the emailed code is itself possession-based.
• Your browser talks to nobody but us. The content-security policy forbids it from connecting to any other host. No trackers, session replay, third-party scripts or advertising pixels — none.
• Your data lives in Canada, encrypted in transit and at rest. Accounts are isolated from each other by the database itself, not by application code.
• Resilience is measured, not asserted. Encrypted daily backups, restore drills timed and published, and uptime checked every minute by an independent monitor whose record we cannot edit.
• When something goes wrong, you hear it from us first. A first word within 30 minutes on a critical incident, 72 hours on a personal-data breach, and published fix timelines for every reported vulnerability.

Authentication and sessions

• No passwords. You sign in with your email and a one-time code, so there is no password to be guessed, reused, or leaked.
• Hardened session cookies. Sessions use __Host--prefixed, HttpOnly, Secure, SameSite=Lax cookies. JavaScript cannot read the session token, and it is not sent cross-site.
• Short-lived access, silent refresh. Access tokens are short-lived and refreshed through a separate long-lived token. A returning user is not logged out, and a leaked access token has a small window.
• Cross-site request forgery. State-changing requests are checked against their origin.

Encryption, and what it does and does not protect

Your plans are encrypted in transit and at rest. The algorithms and keys are maintained by our infrastructure providers — Supabase for the database, Vercel for the application. They keep them current; we do not pin them.

We deliberately do not name a cipher suite here. We do not negotiate it and cannot verify it from where we sit. Quoting an algorithm we do not control would state somebody else's configuration as our commitment. What we stand behind is the property: encrypted going and encrypted sitting, by providers whose business depends on it.

What encryption at rest defends against, said plainly. Someone obtaining the physical storage: a stolen disk, a decommissioned drive, a copied backup volume. It does not protect against a compromise of RoadSnap itself. Our application holds a database credential that reads your data in the clear; without it there is no product. Anybody holding that credential could read plans, and at-rest encryption would not stop them.

What defends that credential is where it lives: server-side only, never in a browser, in the deployment platform's secret store. The access controls and isolation below do the rest.

Customer-managed keys are on our roadmap behind SOC 2, the order security reviews ask in. Single sign-on, once ahead of both, has shipped. If your organisation needs to hold the keys itself, tell us at security@roadsnap.app and it moves up the list.

Isolation between accounts

• Row-level security. Every account's data is isolated by row-level security policies in the database. One account cannot read or write another's roadmaps; the database enforces that, not only the application.
• Least privilege. The browser never receives a database key; all data access goes through our server functions. Administrative credentials are server-side only.
• Safe concurrency. Saves use an optimistic version check, so two devices editing the same roadmap cannot silently overwrite each other; a conflict is surfaced rather than lost. If you load the other copy, a snapshot of yours is taken first, so the choice is recoverable.
• One editor at a time, in team workspaces. A roadmap is a single document with a single editor. A lease passes the right to edit around rather than merging concurrent changes. It is a coordination mechanism, not an access control: it stops two colleagues editing at once. Membership, row-level security and the role checks above stop somebody reaching a roadmap they have no rights to, lease or no lease. The write path does not require a lease: somebody editing offline cannot hold one, and refusing their work on reconnect would lose it. The version check makes that safe.

What we can see, and what we cannot

• Nobody at RoadSnap can read your plans. Not as a policy we ask staff to follow — as a permission the database does not grant. Our internal console signs in to the database as its own limited user. That user can read a handful of usage summaries and the feedback people chose to send us. It can run one lookup, which records who asked and why before it answers. It is granted nothing on the table holding roadmaps, so the query fails rather than being declined. No setting, override or support tool changes this.
• What the console does show is the shape of usage, not the substance. How many workspaces exist, how many have built something, which weeks people came back. Those tables carry a workspace identifier and no way from it to a person. Somebody can see that a workspace has gone quiet and cannot learn whose it is. The support lookup goes the other way, from an address somebody wrote from to the shape of their account. It records the address, who asked and why.
• The one thing you write that we do read is feedback you send us on purpose, through the app or by email. Every time it is opened, that is recorded: which member of staff, when, and what they did. Our own console can add to that log but cannot read, edit or delete it.
• Every change to a roadmap is recorded too, in an append-only log kept by the database, not the application. It says which item changed, which version, and who. Nothing in RoadSnap can rewrite it. An owner reads their own workspace's log in the app, under Settings, and can export it as a spreadsheet. It holds node ids and counts, never a title, a note or a field value, and it is kept for 400 days.

What this section does not claim. The people who run our infrastructure — Supabase, Vercel, Cloudflare — hold the access their platforms need, as for every company using them. They are named as sub-processors below, with what each holds. And if you ask for help with a specific problem, we may ask you to show us something. Your consent is a different thing from our access, and we will not blur them.

Application and transport hardening

• HTTPS everywhere, with HTTP Strict Transport Security.
• Strict Content-Security-Policy. Scripts load only from our own origin: no inline scripts, no third-party script hosts. Network connections are restricted to our origin, framing is denied, and form submissions to third parties are blocked. That prevents whole classes of injection and data exfiltration.
• Additional headers: X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer, a restrictive Permissions-Policy, and framing denied via X-Frame-Options and frame-ancestors.

Privacy by design

• No third-party trackers or advertising pixels. None, anywhere.
• No session replay. We do not use tools that record the screen — because the screen is your plan.
• De-identified analytics only, and they are ours. The little we measure is aggregate, lives in our own database in Canada, and cannot be tied to an individual. The events carry the hostname of the site somebody arrived from — and on public discussion and social sites the page as well — a two-letter country resolved at the network edge, any campaign tag we ourselves wrote into a link, and how many items the open plan has. Never an IP address in these events, never a query string, never a word of a plan. See the Privacy Policy for the list, and Settings → What RoadSnap records about you for the live list in the app.
• We declined a third-party analytics product to keep this true. Adding one is the ordinary answer to "where is our traffic coming from". Every option we looked at meant the browser calling a server we do not run, held by a company outside Canada. We widened our own measurement instead, which is why the sub-processor table below has not grown. It is also why the content-security policy still forbids the page from connecting to any third-party host. No scripts, no fonts, no network calls, no frames. Images are the one deliberate exception, and only images; the diagram below says what that means.
• Your data stays portable. You can export any roadmap at any time, so you are never locked in.

Infrastructure and sub-processors

Provider	Role	Notes
Vercel	Application and website hosting; serverless functions	Transport encrypted; standard managed platform hardening.
Supabase	Managed PostgreSQL database, authentication, sign-in code emails	Database hosted in Eastern Canada (Canada Central); encryption in transit and at rest; managed backups; row-level security enabled.
Resend	Delivery of every email we send. That is the sign-in code (through Supabase), the weekly summary, and share, invitation and mention notices. Also the “gone quiet” note, feedback copies, the support acknowledgement and billing-year notices	Receives the recipient address and that message's content only. Reports hard bounces and spam complaints back, so we stop sending to an address that has rejected us.
HetrixTools	Independent uptime monitoring of the public site	Requests the site from four cities and records whether it answered. It holds no customer data and never signs in — it sees what any visitor sees.
Stripe	Payments, subscriptions and invoices	Card details are entered on Stripe's own pages and never reach our servers or database. We hold a customer reference, plan state and billing email.
Anthropic	The AI Assistant — answering questions about a plan and proposing changes	Engaged 29 August 2026. It was named here in advance on 28 August, so the 30 days’ notice in our DPA ran before the feature existed, not after. When somebody uses it, we send Anthropic the question, and an outline of that roadmap: item ids, titles and field values. Notes are not sent with it. If answering needs the detail in a branch, the AI Assistant asks for that branch and its notes are sent then. It can also run a web search, in which case a search phrase it composes leaves too. It also runs once when a roadmap is opened, at most once a day and only on Pro and Team, to offer two short suggestions. Settings → Suggestions controls this per workspace. The call is made by our server, never by your browser. That is why the policy above still forbids the page from connecting to any third-party host. We do not permit your plans to be used to train models. We record one metering row per call — tokens, cost and counts — and not the question or the answer. For an unprompted suggestion we also keep the suggestion itself and what you made of it, so it is never repeated. Field values in the outline can include names in an Owner column and Jira account ids.

The database is hosted in Eastern Canada (Canada Central). Some application and hosting processing may take place elsewhere; see the Privacy Policy for how we handle cross-border processing.

Services you connect, and what they can do

Jira and Slack are connected by someone in your workspace, per workspace, never by us. Both are off until somebody turns them on. The detail matters more than the summary:

Whose access a connection carries. Atlassian grants access to a person, not a site. A Jira connection sees what the person who authorised it can see, and every editor in the workspace can use it. Connect it as somebody whose access you are content for that workspace to share. Viewers cannot use it to change anything in Jira.

Only an owner can connect one, because only an owner can disconnect one. Binding a Jira grant or a Slack webhook to a workspace is an owner's act, and so is removing it. A credential a workspace cannot revoke without an owner should not be creatable without one. Editors can change how a connection behaves, such as which channel the digest goes to or whether the nightly Jira push is on. They can also post to Slack. Viewers can do neither.

What a viewer can and cannot do here. A viewer sees every roadmap in the workspace and cannot edit one. Three layers enforce that: the app opens read-only, the server refuses their edits, and database policy grants write only to owners and editors. Each is sufficient alone.

• Jira is read-only by default. On Pro we request read access and the personal-data reporting permission, and nothing that can change an issue. Write access is a separate, deliberate reconnection available on Team.
• The assignee is held by its account id, and reported. Since 10 September 2026 a Jira sync brings in who an issue is assigned to. The roadmap stores the Atlassian account id only; the display name sits in a small table of ours, keyed by workspace. It is reported to Atlassian on their seven-day cycle and deleted when they say the account was closed or changed. So an erasure never touches a customer’s document. Disconnecting Jira deletes the names too. Names are shown to anyone the roadmap is shared with, by link or membership, and appear in exports like any other column.
• Five scopes, and what each is for. On every tier, three. read:jira-work reads issues, including who they are assigned to. offline_access is a refresh token, so the connection outlives an hour. report:personal-data reports the account ids we hold back to Atlassian. On Team, two more. write:jira-work updates the issues you link; Atlassian’s classic write scope also permits deleting issues, which RoadSnap never does. write:issue:jira-software reorders the backlog, only when a workspace switches ranking on. You will see all of them on the consent screen, so we would rather say them here first. Connections made before 10 September 2026 reconnect once to gain the new ones; the reconnect keeps the workspace’s settings.
• The tokens themselves — Jira’s access and refresh tokens and Slack’s webhook — sit in a table no browser session can read. Row-level security and the provider’s encryption at rest protect it. We add no application-level layer, for the reason given under encryption above.
• Automatic write-back is off until somebody switches it on, and only an owner or editor can. When on, RoadSnap updates the status and target of linked issues once a night. If the workspace has switched it on separately, it also sends the order of linked issues as Jira’s backlog rank. It stops if the workspace leaves Team. It never sends titles automatically. Only columns RoadSnap owns are sent; a column Jira owns is never written back.
• Slack can post to one channel and nothing else. The channel you pick while installing is the whole permission. RoadSnap cannot read messages, list members, or post elsewhere.
• Disconnecting deletes our copy of the credentials immediately. For Slack that ends its ability to post. An Atlassian authorisation belongs to the account that granted it, so we tell you where to revoke it there rather than implying we have.

Data storage and resilience

• Your roadmaps are stored in our managed database when you are signed in. They are held in your own browser too, so the app stays responsive and works without a connection. The browser copy is written first and the account copy follows, so a crash, a closed laptop or a flat battery loses nothing. Work done offline is only ever late to your account, never lost.
• Each roadmap's history (daily trend readings and snapshots) is kept with the roadmap in your account. It is not tied to the browser that made it, and it is deleted with the roadmap.
• Backups run daily and are kept for seven days, taken and encrypted by our infrastructure provider. A backup nobody has restored is a hope, so we restore one and time it.
• You can export a full copy of any roadmap at any time, a safeguard within your control.

What happens if something breaks — measured, not estimated

We drill this rather than assert it. A backup is restored into a separate, isolated environment and compared with production row by row. The expected figures are written down before the comparison runs, and the result is kept so each drill can be compared with the last.

Most recent drill: 25 August 2026.

• Time to recover: under five minutes from starting a restore to a working, queryable database.
• Recovery point: up to 24 hours. Backups are daily, so a total loss could cost the work since the last one. On the day we drilled, that window was 19 hours and 37 minutes.
• Verified faithful. Every table that had not changed since the backup matched production exactly; every table that had changed was correctly behind. Nothing from after the backup point appeared.

For your own work it is better than those numbers suggest. Your roadmaps are written to your browser before they reach us. A database restored to yesterday does not take your work away: your device still holds it, and it syncs back. What a restore costs is server-side state: shares, membership, subscription records and history.

You do not have to take our word for whether RoadSnap is up. An independent third party checks it every minute from New York, San Francisco, London and Frankfurt. Their record is public and unedited: live uptime report, running since 6 August 2026. It is their measurement, not ours. When RoadSnap is down, that page says so, whether or not we would have mentioned it.

RoadSnap is built and run to be available around the clock. We print no percentage: a number on a page is right the day it is written, and the link above is always current. As is usual for self-serve plans, our terms carry no service-level agreement. Availability commitments with service credits are available under an enterprise agreement — write to hello@roadsnap.app.

Drills run at least quarterly, and after any change to where or how backups are taken.

When something goes wrong

Every product has incidents. What sets vendors apart is whether they decided in advance what to do, and whether they tell you.

We keep a written incident response runbook. It covers detection, severity, who is told and when, procedures for the likeliest failures here, and a post-mortem for every one. Like most companies, we keep the operational half internal: it names our detection sources and response times and, by omission, our gaps. What we commit to publicly is this:

Severity	What it means	What we do
SEV‑1	Nobody can sign in or reach their data — or data may have been lost, altered or disclosed	Everything stops. We say something within 30 minutes, even with the cause unknown, and again at every time we promise.
SEV‑2	A major feature broken for everyone, or any feature for one identifiable customer. Anything involving money.	Same day, and we contact the affected people directly rather than waiting to be asked.
SEV‑3	Degraded or ugly, with a workaround	Next working session, tracked on the roadmap.

“May have been” is treated as SEV‑1 until evidence narrows it. The severity is set by the worst plausible reading, not the most comfortable.

If personal information is involved, the commitment is specific and is on the Privacy Policy. We tell you by email within 72 hours of establishing that a breach occurred, not 72 hours from finishing the investigation. The email says what we know and which parts are still unknown.

Every incident gets a written post-mortem, blameless about people and merciless about mechanisms. It says what happened and what it cost, in specifics. It says why, at the level of the mechanism rather than the mistake, what would have caught it, and the change we made.

Responsible disclosure

If you believe you have found a vulnerability, we want to hear from you. Email security@roadsnap.app with the details and steps to reproduce, and give us a reasonable chance to fix it before public disclosure. We will not pursue good-faith research that respects our users' privacy and does not degrade the service.

What happens after you report one. An automatic note confirms it arrived within minutes. A human acknowledges every report within two working days, and tells you what we concluded, even when it is not a vulnerability. Once an issue is confirmed and rated, these are the times we work to:

Severity	Fixed or mitigated within
Critical — customer data reachable across accounts, authentication bypass, remote code execution	7 days
High — privilege escalation within an account, or a serious flaw needing unusual conditions	30 days
Medium and below	90 days, or the next release that touches the area

The clock starts when we confirm and rate the issue, not when the mail arrives. A report unread in a spam folder should not consume a deadline. Mitigating counts as meeting the target. Taking a feature down, revoking a token or blocking a path protects you today; the permanent fix follows. If we are going to miss one, we say so before the date, to you and any affected customer.

These are targets we hold ourselves to and publish so they can be checked. They state how we work; they are not a contractual service level, and not part of the Terms of Service or the Data Processing Agreement. Where a fix depends on a sub-processor, our obligation is to escalate it promptly and tell you what we are told.

What a security review can have today

• An accessibility conformance report (VPAT 2.5) — published in full, against WCAG 2.2 A and AA, Section 508 and EN 301 549. It says how it was evaluated, what was found, and what is next.
• A completed CAIQ-Lite questionnaire (Cloud Security Alliance) — written and available now, from security@roadsnap.app. Where a control does not exist it says so and says what we do instead.
• Our Data Processing Agreement is published in full, at roadsnap.app/dpa.html. It covers the sub-processors and the breach commitment above, retention and deletion, and the assistance we owe you on a data-subject request. It includes standard contractual clauses for transfers out of the EEA and out of Québec. Read it before you ask for it; print it or save it as a PDF from the page. To sign it or propose a change, write to privacy@roadsnap.app.

Single sign-on (SAML 2.0) is included in the Team plan at no surcharge, with any provider that speaks SAML. Setup goes through a person, because one step cannot responsibly be automated. That step is confirming you control the domain before a provider may vouch for everyone with an address at it. You send us your provider’s metadata and the domains to enrol. We send back what your provider needs and test it with you before it goes live. See Support for what it changes and what it does not, including that we do not support SCIM today.

What is next, and in what order

Everything above is in place today. What follows is on our public roadmap, in the order security reviews ask for it:

1. An independent penetration test, with the findings and their fixes published here.
2. SOC 2 Type I, then Type II. The controls are written down and practised now; the audit puts a third party's name on them.
3. SCIM provisioning, so the identity provider that already signs your people in also adds and removes them.
4. Additional data regions. Eastern Canada today.
5. Customer-managed encryption keys.

If one of these decides a review for you, say so at security@roadsnap.app; that is how the order gets set.