What CannyList stores
- Your account: the email address you sign in with, a display name and, after a social sign-in, the profile picture URL the provider supplied. There are no passwords. Sign-in sessions are stored as hashes of a random token.
- Teams: which teams you belong to and your role in each (owner, member or viewer), plus pending invitations by email address.
- Workspaces: the imported rows exactly as uploaded, the mapped fields, triage decisions, pipeline stages, owners, notes, scores, the scoring profile and an activity log that names the teammate behind each change.
- Research results: accepted facts about organizations and people with their source URL, date, scope and confidence, and the research runs that produced them.
Who can see what
A team owns its workspaces. A request can list, read or change only the active team's workspaces; another team's workspace does not exist for it. Viewers read everything in their team and change nothing. The person who made a triage decision or a note is always the signed-in member, never a name typed into a request.
Organizations and their public evidence are shared across teams because they are public facts about companies and carry nothing team-private. Within a team, the same person appearing in two workspaces is one person record: each workspace's imported fields, notes and decisions stay in that workspace, and only accepted public research facts are shown across them.
What leaves the server
- People research sends a person's name together with their organization or title to a search service that CannyList runs itself, which forwards the query to public search engines. Result pages on public sites are then fetched. Imported email addresses and phone numbers are never sent anywhere, and LinkedIn pages are never requested. The hosted service has no paid language model configured, so no page text leaves it for a model provider.
- Organization research queries public registries and filings (SEC, GLEIF, Wikidata), official company websites and the same search service. Requests carry the organization's name or domain, nothing from your team's notes or decisions.
- Sign-in codes and invitations are emails, delivered through a transactional email provider. They contain the code or the invitation link and nothing about a workspace.
- Fonts are loaded by your browser from Google Fonts, which sees the request like any web font host.
- There are no analytics scripts, advertising pixels or third-party trackers on cannylist.com.
Where it runs and how it is protected
The hosted service runs on a single virtual machine at Oracle Cloud in the United States (Phoenix). Only HTTPS is exposed; the database is reachable from the application alone. Every response carries a strict Content Security Policy and the usual hardening headers, sign-in routes are rate-limited, and the server refuses state-changing requests that do not come from its own pages.
The database is dumped nightly to the machine's data disk and to a private object-storage bucket that is encrypted at rest and keeps 14 days of dumps. An archived workspace can be restored by its team; a deleted workspace is removed from the live database and remains only in those dated backups until they expire.
What you are responsible for
Import only lists you are authorized to use. Event attendee lists and meeting-program exports are the event organizer's proprietary data: keep them in the workspace they were authorized for, and treat a visible profile, a program role or a meeting match as information, not as consent to be contacted. CannyList drafts outreach but never sends it; what you send, and to whom, is your decision under your own obligations.
Questions
Ask the owner of the team that invited you, who can also remove your membership or delete a workspace, or contact the operator of cannylist.com. This page is updated whenever the service's behaviour changes; the date at the top of the page is the date of the last change.