Security
Your data stays yours, and stays separate.
We hold a record that work happened and who did it, not your code, messages or tickets. Here is how it is kept apart, how long we keep it, and who can see it.
Isolation
Every org's data is isolated at the database level
Separation is enforced by the database itself, on every table, rather than by application code somebody has to remember to write correctly. That matters because the other approach fails silently.
Separated at the source
Each record is tied to one organization and the database refuses to return it to anyone else. There is no query we could write, or forget to write, that returns another customer’s rows.
Encrypted, and tied to its owner
Connector credentials are encrypted with AES-256-GCM and bound to the organization that owns them, so a stored credential copied into another account simply fails to open.
Written down permanently
Settings changes, visibility changes and identity links go to a log the application can add to and cannot edit or delete. A log a bug could rewrite answers nothing.
What we hold
A record of work, not its contents.
That a pull request was merged, that a review was approved, or that a deploy finished, along with who did it and when. We do not clone your repositories, read your files, or store your code. We do not read the text of your tickets, and from Slack we read only the expression that gives someone credit.
- Names and work email addresses, from your own identity provider
- The accounts you link, so work reaches the right person
- The totals and cards those add up to
How long
Thirteen months, then it is gone.
The detailed records behind your boards are deleted after thirteen months. The totals survive, so a two-year-old leaderboard still works while we are not sitting on a record of everyone’s week for ever.
- Export everything we hold, whenever you want
- Delete the organization and it is removed, not flagged
- Error reports carry account identifiers and never names or email
- We never see a password, since sign-in is handled by your provider
Connections
What we will never do to your systems
The first three questions a reviewer asks about an integration, answered before they ask.
Never write to them
No comments on your issues, no labels, no status changes, and nothing appearing in your repositories in our name. We only read what happened.
Never accept a forged event
Everything sent to us is signed, checked against a secret only your organization holds, and rejected if it is more than five minutes old, so nobody else can add invented numbers to your boards.
Never slow you down
We answer in milliseconds and do the work afterwards, so nothing we do can make a deploy hang or a webhook time out somewhere else.
Subprocessors
Everyone else who touches your data
The complete list. If it changes, this page changes with it.
| Provider | What for | Where |
|---|---|---|
| Vercel | Application hosting and content delivery | United States |
| Neon | The database your events and boards live in | United States |
| PropelAuth | Sign-in, organizations, roles and invitations | United States |
| Stripe | Payments. Card details go to Stripe and never to us | United States |
| Sentry | Error reporting. Identifiers only, never names or email | United States |
| Resend | Email notifications, if you turn them on | United States |
Compliance
Where we are, plainly.
We are not SOC 2 or ISO 27001 certified. We will answer a security questionnaire, walk your team through any of the above, and put commitments in writing on your paper. If a certification is a condition of buying, tell us early so we can factor real demand into our roadmap.
Single sign-on and multi-factor authentication are available now and configured in the identity provider that owns your organization, so they follow whatever policy you already run.
Found something?
Tell us and we will fix it.
Email [email protected] with enough detail to reproduce it. We will confirm we got it, tell you what we find, and credit you if you would like to be credited. Please do not test against another customer’s organization.
Questions
The ones a reviewer asks
Do you read the contents of our repositories?
No. We receive notifications that something happened, such as a pull request merged, a review approved, or a deploy finished, along with the details attached to them. We never clone a repository, read a file, or store code. The 90-day history we import on install comes from the same notifications, not from your code.
How is our data kept separate from other customers?
By the database, on every table, rather than by application code. Each record belongs to one organization and the database will not return it to anyone else, so there is no query we could get wrong that leaks across customers. A test checks every table and fails if one is missing the rule.
Can an administrator see an individual’s numbers?
Only if your organization has chosen that. Visibility is a setting with three modes, and in the most private one no individual appears on a shared board at all. It is enforced where the data is, so it applies to exports and API access as well, not just to what the screen shows.
What happens if one of our secrets leaks?
Rotate it and the old one stops working immediately. Secrets are per organization, so the blast radius is one customer, and anything captured earlier is only usable for five minutes anyway.
Where is the data held?
In the United States, with the providers listed above. If residency in a particular region is a requirement, raise it before you start rather than after, since it is not something we can rearrange afterward.
Can we get everything back, and can you delete it?
Both, and both are built into the product rather than being a request you file with us. Deletion removes the organization rather than marking it deleted.
Send this to whoever has to approve it.
If something they need is missing from this page, tell us and it goes on it.