Security at SprintBee

How SprintBee handles your data

SprintBee is hosted entirely on Amazon Web Services (AWS), running in a private network (VPC) with no direct public access to the database. The application runs behind a load balancer and CDN on managed AWS services, and data is stored in a managed PostgreSQL database (Amazon RDS) that is not publicly reachable from the internet. Live room state also passes through a managed in-memory cache, which is encrypted both in transit and at rest.

Our infrastructure and data storage are located in the United States. If you use SprintBee from elsewhere, your information is processed in the United States and in the other locations where our service providers operate.

We don't sell your data, and we don't run third-party analytics or advertising trackers on our website or in the product.

We are a small team, not a certified security vendor. We do not currently hold SOC 2, ISO 27001, or similar certifications, and we don't want to imply otherwise. What follows is a plain description of the controls we actually have in place today.

Encryption

All public traffic to SprintBee is served over HTTPS. Requests over plain HTTP are redirected to HTTPS, and our CDN and load balancer are both configured to accept only modern TLS versions (TLS 1.2 and 1.3), with certificates managed through AWS Certificate Manager.

Our primary database has storage encryption enabled at the infrastructure level. Room passwords, where a moderator sets one, are never stored in plain text — they're hashed with scrypt (a salted, computationally expensive hash) and compared using a timing-safe check. Personal Jira OAuth tokens, shared Jira Forge app credentials, Linear OAuth tokens, and any webhook URL you configure for Slack or Teams notifications are encrypted at the application layer with AES-256-GCM before they're written to the database, using a key that can be rotated independently of the credentials themselves. GitHub App access tokens are never written to the database at all — they're requested from GitHub when a task needs one and held only in memory until they expire.

Authentication

SprintBee doesn't store a password for your account. You can sign in either with a one-time code emailed to you through Amazon Cognito, or with an existing Google or Microsoft account. Either way there is no SprintBee password for an attacker to guess, reuse, or leak from another breach. If you sign in with Google or Microsoft, that sign-in is governed by your own identity provider's controls — including any multi-factor requirement your organization enforces there.

The tokens used for account requests are short-lived, signed by Cognito, and verified on every request against Cognito's published signing keys. For customer sign-ins, the longer-lived credential used to renew them is kept in a secure, HTTP-only cookie that page scripts cannot read. Our site-admin console is protected by a completely separate Cognito user pool that additionally requires TOTP multi-factor authentication — there is no path to admin access with a sign-in code alone.

If your team uses our Microsoft Teams app, SprintBee also accepts the identity Microsoft issues for you inside Teams, verified the same way against Microsoft's published signing keys. That identity establishes who you are in a ceremony; it does not grant access to anything beyond the Workspaces and Rooms you could already reach.

Payments

Billing is handled by Stripe. When you subscribe or update payment details, you're taken to a Stripe-hosted checkout or billing portal — SprintBee's servers never see, transmit, or store your card number, expiry date, or CVC. We only keep the identifiers Stripe gives us back (like a customer or subscription ID) so we know what plan an organization is on.

Workspace and room access controls

Every room has a shareable room code, and a moderator can regenerate that code at any time — useful if it was shared somewhere it shouldn't have been, without losing the room's history, queue, or settings.

On a paid Workspace, you can layer on additional access controls per room or as an organization-wide default: requiring a room password, requiring participants to be signed in, and restricting access to specific email domains (for example, limiting a room to people with an @yourcompany.com address). These controls are optional and off by default.

A Workspace itself can also be restricted. By default a Workspace is open to everyone in your organization; a paid Workspace can instead be set to Restricted, so only the people you assign to it can reach it or its history. Once a Workspace is restricted, that restriction keeps being enforced no matter what happens to your plan — a lapsed subscription never quietly reopens a confidential Workspace to the whole organization, and you can always remove someone's access without paying.

AI assistance

Some Sprint Retro features can use an AI model to suggest groupings for Notes and to draft narrative summaries. We've deliberately made that a disclosed, remembered decision rather than a quiet default, because retro content is often the most sensitive thing a team puts into SprintBee:

• AI assistance is opt-in per Workspace. Nothing is sent to a model unless someone has turned it on for that Workspace, and grouping Notes by hand always remains available.
• Organization Owners and Admins can switch AI assistance off across every Workspace at once. Doing so takes effect immediately and cancels any run already in flight.
• The model receives only the Note text from the retro session in front of you. It does not receive participant identity, or content from unrelated sessions, rooms, or Workspaces.
• Models run through Amazon Bedrock inside our own AWS environment, in the United States. Under AWS's terms, content sent to Bedrock is not stored by the service, is not used to train the underlying models, and is not shared with the model provider.

Data retention & deletion

We keep organization, Workspace, and room data for as long as needed to provide SprintBee, maintain security, and meet legal obligations, consistent with our Privacy Policy. You can request access to, correction of, or deletion of your personal information at any time.

Our primary database is backed up automatically with a 14-day point-in-time recovery window, and in production it runs with automatic failover to a standby in a separate availability zone. One consequence worth being explicit about: deleted data can persist in those backups until they age out of that window.

Security-relevant administrative actions — changes to members and roles, room security policies, room codes, and plan changes — are recorded to an activity log we retain for investigation. We don't yet expose that log to customers directly; if you need a record of a specific change in your organization, ask us and we'll pull it.

To request deletion or ask a retention question, contact privacy@sprintbee.net. We may need to verify a request before acting on it, and some information may be retained where required for security, fraud prevention, or legal compliance.

Subprocessors

We rely on a small set of vendors to run SprintBee. We don't sell your data, and we only share it with providers who need it to deliver the service:

• Amazon Web Services (AWS): hosting, database, application infrastructure, email delivery (Amazon SES) for sign-in codes and transactional messages, and the AI models behind Retro assistance (Amazon Bedrock).
• Amazon Cognito (part of AWS): authentication, issuing and verifying sign-in codes and session tokens.
• Stripe: payment processing and subscription billing. Stripe handles and stores all card data directly.
• Google: only if you choose to sign in with a Google account. We receive your email address and name to identify you; we don't request access to anything else in your Google account.
• Microsoft: if you choose to sign in with a Microsoft account, or if your team uses SprintBee inside Microsoft Teams. We receive your email address and name to identify you, plus the meeting or channel context needed to run a ceremony where you started one.
• Sentry: error and performance monitoring for our web application, configured not to collect personal information by default.
• Better Stack: hosts our public status page at status.sprintbee.net.

Beyond that list, the only other companies that see your data are the ones you connect yourself — your issue tracker or your chat tool. Those are covered in the next section, and none of them receive anything until someone on your team connects them.

Connecting your own tools

Connecting an issue tracker is always a deliberate act, and it happens in two steps. First a connection is authorized once — either by you personally, or, for the Jira Forge app and the GitHub App, installed for your whole organization by an owner or admin. Then each individual room chooses which connected project, board, or site it pulls work items from. A connection existing does not put anything into a room; someone has to point a room at it.

Writing anything back is a separate, per-room decision. Unless a room has been configured to write estimates or edits back, SprintBee only ever reads.

• Atlassian: only if you connect a Jira site. SprintBee reads the specific Jira issues you import into a room, and writes back only where that room is configured to. We don't access any other part of your Jira site.
• Linear: only if you connect a Linear workspace. SprintBee reads the specific Linear issues you import into a room, and writes estimates back only where that room is configured to. We don't access any other part of your workspace.
• GitHub: only if an owner or admin installs our GitHub App. SprintBee reads the items on the specific GitHub Projects a room is pointed at, and writes estimates back only where that room is configured to.
• Slack: only if you connect Slack to receive notifications. SprintBee posts voting-window messages to the channel you choose and reads nothing from your workspace.

Reporting a vulnerability

If you believe you've found a security issue in SprintBee, we want to hear about it. Email security@sprintbee.net with as much detail as you can (steps to reproduce, affected URLs, and why you think it's a security issue), and we'll follow up with you directly.

Please avoid accessing or modifying data that isn't yours while investigating, and give us a reasonable chance to fix an issue before disclosing it publicly.