Trust and security: SprintPoker for Jira
Where SprintPoker for Jira runs, what it stores and never stores, how it uses AI, and answers to common security questions.
Last updated
On this page
- At a glance
- Architecture and data flow
- In words
- What we store
- In your Atlassian site
- On our servers
- What we never store
- How AI is used
- Model training
- What the AI provider keeps
- Turning AI off
- Where data is held
- Connections outside Atlassian
- Sub-processors
- Retention and deletion
- Security practices
- Common security questions
- Contact
SprintPoker for Jira is a planning poker app for Jira Cloud, built on Atlassian Forge. Its sessions, votes and AI features run on our own servers: your data is stored in London (UK) and processed in Stockholm (Sweden), on Amazon Web Services. Its AI features use OpenAI, which processes the text it is sent in the United States.
Each Agile Pulse app is built differently, so each has its own trust page; this one covers SprintPoker for Jira. Compare all five apps.
At a glance
| Item | Detail |
|---|---|
| Made by | LayaNet LTD (company number 17430595), a company registered in England and Wales. On the Atlassian Marketplace it uses the vendor name Agile Pulse. |
| Marketplace listings | SprintPoker (paid), SprintPoker Free |
| Platform | An Atlassian Forge app that uses Forge Remote: its screens run in Jira, and its sessions are kept and run on our own servers. Both Marketplace listings are the same app. |
| Runs on Atlassian | The app is not Runs on Atlassian: it also uses our own servers. |
| Where data is held | Europe: stored in London (UK), processed in Stockholm (Sweden), on Amazon Web Services. Talk to us about United States hosting. |
| AI | OpenAI, called from our servers, outside Atlassian. |
| Turning AI off | A Jira admin setting (AI Settings, Enable AI), enforced by our servers. |
| Personal data | Atlassian account ids, display names and avatars, and session comments, on our servers. |
| Atlassian Marketplace programmes | In Atlassian’s Cloud Fortified and Marketplace Bug Bounty programmes. |
| Security contact | support@laya.net, with "Security report" in the subject line |
Architecture and data flow
How SprintPoker for Jira is connected, at a high level: where it runs, where your data goes and who keeps it. Each number matches an entry in the list under the diagram.
In words
- People use SprintPoker for Jira inside Jira, signed in with their Atlassian account.
- SprintPoker for Jira reads from Jira as it works. In Jira: the estimates people save, and what Ready or Not adds when someone asks it to: text added to a description or acceptance criteria field, comments, new split issues and the
ai-made-readylabel. - The app’s Forge functions call our servers to run sessions (votes, estimates and comments) and to make AI requests. Sent over HTTPS (TLS).
- Only when someone sends a message from the in-app Contact us form: the person types a subject and a message, and the app adds the Jira site, the app version and their email address from their Atlassian profile, so we can reply; it asks for an address only when Jira does not share one. The message goes through the app to our servers, which email it to our support team through Amazon Web Services’ email service in Stockholm (Sweden). Our servers do not keep the message. Sent over HTTPS (TLS).
- The browser keeps a secure WebSocket open to our servers for live updates during a session. Sent over Secure WebSocket (TLS).
- Our application servers keep your data in the database with MongoDB Atlas, on Amazon Web Services, in London (UK), and reach it over TLS. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
- Optional: only when someone uses an AI feature and AI is on for the site: our servers send OpenAI only the fields listed under How AI is used. Never sent to OpenAI: any person’s name or account details from Jira, Jira comments, attachments, votes, email addresses, or who is in a session. OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer. We never store the prompt. Sent over HTTPS (TLS).
- Only for sessions shared with laya.net, after a Jira admin links the site to laya.net: our servers share each shared session, and the issues in it, with laya.net, our own service in the United States, where laya.net’s Trust Centre applies. In shared sessions, AI hints and writing help come from laya.net, which uses Anthropic. Sent over HTTPS (TLS).
- The browser loads the app’s icons and images from our website.
- Only if someone opens the product demo: the browser shows it in a frame from the demo’s own service.
The SprintPoker for Jira Architecture Diagram and Data Flow has the diagram with a table of what is kept where and how it is protected, and prints as a document for your records.
What we store
Our servers keep the Atlassian account id of each person in a session, with the display name and avatar address Jira showed, their votes and the comments they write in sessions.
In your Atlassian site
- Forge storage on your site: the site’s guest and laya.net link settings, and each person’s saved session defaults, kept under their Atlassian account id.
- Jira itself: the estimates people save, and what Ready or Not adds when someone asks it to: text added to a description or acceptance criteria field, comments, new split issues and the
ai-made-readylabel.
On our servers
- Sessions: the name and settings, the ids and keys of the Jira issues in them, votes and final estimates, comments written in the session, and AI hints.
- People in a session, and people asking to join one: their Atlassian account id, and the display name and avatar address Jira showed.
- Ready or Not results: each scanned issue’s key, summary and type, the AI’s assessment and suggestions, and the account id of the person who ran the scan.
- Site settings: the estimation field and scale, Definition of Ready rules, the Enable AI setting, and a count of the site’s active users.
What we never store
- Issue descriptions, Jira comments and attachments: the app reads them live from Jira.
- The prompts sent to OpenAI: each is built for one request and deleted straight after.
- A copy of your Jira projects: our servers keep only the issue ids and keys a session uses and, for Ready or Not, each scanned issue’s summary.
How AI is used
AI runs on our servers, not on Atlassian. Our servers, on Amazon Web Services in Stockholm (Sweden), send each AI request to OpenAI’s API, using our own OpenAI account. In sessions shared with laya.net, AI hints and writing help come from laya.net instead, which uses Anthropic.
| Feature | When it runs | What is sent | What we keep |
|---|---|---|---|
| AI hint | When a session’s moderator asks, or for each issue if the session’s settings turn automatic hints on. | The issue’s key, its summary (up to 500 characters), its description as plain text (up to 3,000 characters) and the name of the estimation field. | The hint, saved with the session. |
| AI search helper (describe or fix a JQL query) | When someone using the advanced search asks it to write or fix a query. | The words typed (up to 500 characters), or the query to fix with its error messages; the site’s status, issue type and priority names; project keys; the current project. | Nothing: the answer goes back to the screen. |
| Ready or Not scan | When someone starts a scan. | For each issue: key, type, status, priority, estimate, labels, components, parent key and summary, linked issue keys and statuses, number of subtasks, whether it has an assignee (never a name), created and updated dates, summary (up to 600 characters) and description as plain text (up to 4,000 characters). | Each issue’s key, summary and type, the AI’s assessment and suggestions, and who ran the scan. |
| Ready or Not: similar issues, refine and split | When someone asks, for one issue. | Refine and split: the issue’s key, summary, description, type, linked issue keys and statuses, and estimate. Similar issues: the issue’s key, summary and description, and completed issues from the same project as key, estimate and summary. | Nothing: the answer goes back to the screen. |
| AI Ready-Up | When someone chooses issues, reviews the list and confirms. It only adds to each issue, marks what it adds as added by AI, and writes to Jira as that person. | The issue’s key, summary, description, type, linked issue keys and statuses, estimate and labels. | In Jira: the drafted text, marked as drafted by AI, and the ai-made-ready label. On our servers: the re-scan’s result. |
Never sent to OpenAI: any person’s name or account details from Jira, Jira comments, attachments, votes, email addresses, or who is in a session. Text people typed into the fields that are sent, such as a name written in a description, is sent as typed.
Model training
OpenAI’s API terms say it does not use data sent to its API to train or improve its models unless the customer opts in to share it. We do not train or fine-tune any AI model on your data.
What the AI provider keeps
Under OpenAI’s standard API terms, OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer, and then deletes it; the services our requests use keep nothing else. On our side, each prompt is built for one request and deleted straight after: we never store it. We keep only the AI’s answer: AI hints with their session, and Ready or Not results, in our database with no expiry (see "Retention and deletion").
Turning AI off
A Jira admin can turn AI off for the whole site: on the app’s admin page (in Jira settings, under Apps), switch off Enable AI under AI Settings. While it is off, our servers refuse every new AI request from that site, and laya.net’s AI is off in sessions shared with laya.net.
Each session’s creator chooses in the app whether it has AI hints, and only a session’s moderators can ask for one (our servers check that). Ready or Not and the AI search helper run only when someone uses them; nothing runs on a schedule.
Where data is held
| What | Provider | Location |
|---|---|---|
| Your data (database) | MongoDB Atlas, on Amazon Web Services | London (UK) |
| Application servers | Amazon Web Services | Stockholm (Sweden) |
| Sessions shared with laya.net | laya.net, on Amazon Web Services | United States |
Your data is held in Europe: stored in London (UK) and processed in Stockholm (Sweden). If your organisation needs United States hosting, talk to us at support@agilepulse.co. Sessions shared with laya.net are held by laya.net in the United States, its one hosting region today: see laya.net’s international data transfers. When someone uses an AI feature, the text sent is processed by OpenAI in the United States. Atlassian’s data residency settings do not cover data on our servers.
Connections outside Atlassian
| Address | From | What for |
|---|---|---|
sprintpoker.agilepulse.co | Your browser and the app’s Forge functions | Our servers: sessions, live updates over a secure WebSocket, and AI features. The in-app Contact us form: the person types a subject and a message, and the app adds the Jira site, the app version and their email address from their Atlassian profile, so we can reply; it asks for an address only when Jira does not share one. The message goes through the app to our servers, which email it to our support team through Amazon Web Services’ email service in Stockholm (Sweden). Our servers do not keep the message. |
api.openai.com | Our servers | AI features, only when someone uses one (see "How AI is used"). |
laya.net | Our servers | Only for sessions shared with laya.net, after a Jira admin links the site to laya.net. |
agilepulse.co | Your browser | The app’s icons and images. |
demo.arcade.software | Your browser | The product demo, shown in a frame only if someone opens it. |
Sub-processors
| Sub-processor | Purpose | Data | Location |
|---|---|---|---|
| Atlassian | Runs the app’s Forge functions and storage, and Jira. | What the app shows and keeps in your Atlassian site. | Where your Atlassian site is hosted |
| MongoDB Atlas | Our database service, on Amazon Web Services. | Everything listed under "On our servers". | London (UK) |
| Amazon Web Services | Hosts our application servers, and emails the messages sent from the in-app Contact us form to our support team. | Everything listed under "On our servers", while our servers work on it, and the messages sent from the in-app Contact us form. | Stockholm (Sweden) |
| OpenAI | AI features. | Only the fields listed under "How AI is used", when someone uses an AI feature. | United States |
| laya.net (run by LayaNet LTD, which also makes this app) | Only for sessions shared with laya.net. laya.net is our own service, not another company; the companies it uses, such as Amazon Web Services and, for AI hints and writing help, Anthropic, are in laya.net’s sub-processors. | The shared session and the issues in it. | United States |
We update this list at least 30 days before a new sub-processor starts processing your data.
Retention and deletion
- Uninstall: Nothing on our servers is deleted when the app is uninstalled: the app has no uninstall step.
- Deletion: Deleting a session in the app marks it deleted, and the record stays in our database. Nothing expires automatically.
- Atlassian’s personal data reporting: The app uses Atlassian’s personal data reporting every day. When Atlassian reports a closed account, we replace its id with a random one and remove its name and avatar; its votes and comments stay, anonymised.
- Logs: Our servers keep access logs, which hold IP addresses, for no more than 30 days.
- Deletion requests: to ask for your site’s data to be deleted, email privacy@laya.net.
Security practices
- Only encrypted connections: the app reaches our servers only over https and wss.
- Ready or Not’s changes to Jira are made as the person who asked for them, so Jira’s own permissions apply.
- Site settings save only for Jira admins.
- Encryption: All connections are encrypted: browsers and the app’s Forge functions reach our servers only over https and wss, and our servers reach the database over TLS, which MongoDB Atlas requires for every connection. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
- Atlassian Marketplace programmes: In Atlassian’s Cloud Fortified and Marketplace Bug Bounty programmes.
Common security questions
Does the AI run on Atlassian, or with an outside provider?
AI runs on our servers, not on Atlassian. Our servers, on Amazon Web Services in Stockholm (Sweden), send each AI request to OpenAI’s API, using our own OpenAI account. In sessions shared with laya.net, AI hints and writing help come from laya.net instead, which uses Anthropic.
Which data is sent to the AI?
AI hint: The issue’s key, its summary (up to 500 characters), its description as plain text (up to 3,000 characters) and the name of the estimation field. AI search helper (describe or fix a JQL query): The words typed (up to 500 characters), or the query to fix with its error messages; the site’s status, issue type and priority names; project keys; the current project. Ready or Not scan: For each issue: key, type, status, priority, estimate, labels, components, parent key and summary, linked issue keys and statuses, number of subtasks, whether it has an assignee (never a name), created and updated dates, summary (up to 600 characters) and description as plain text (up to 4,000 characters). Ready or Not: similar issues, refine and split: Refine and split: the issue’s key, summary, description, type, linked issue keys and statuses, and estimate. Similar issues: the issue’s key, summary and description, and completed issues from the same project as key, estimate and summary. AI Ready-Up: The issue’s key, summary, description, type, linked issue keys and statuses, estimate and labels. Never sent to OpenAI: any person’s name or account details from Jira, Jira comments, attachments, votes, email addresses, or who is in a session. Text people typed into the fields that are sent, such as a name written in a description, is sent as typed.
Is our data used to train AI models?
OpenAI’s API terms say it does not use data sent to its API to train or improve its models unless the customer opts in to share it. We do not train or fine-tune any AI model on your data.
Does the AI provider keep our data?
Under OpenAI’s standard API terms, OpenAI may keep a request for up to 30 days, solely to monitor for abuse, unless the law requires longer, and then deletes it; the services our requests use keep nothing else. On our side, each prompt is built for one request and deleted straight after: we never store it. We keep only the AI’s answer: AI hints with their session, and Ready or Not results, in our database with no expiry (see "Retention and deletion").
Can a Jira admin turn AI off for the whole site?
A Jira admin can turn AI off for the whole site: on the app’s admin page (in Jira settings, under Apps), switch off Enable AI under AI Settings. While it is off, our servers refuse every new AI request from that site, and laya.net’s AI is off in sessions shared with laya.net. Each session’s creator chooses in the app whether it has AI hints, and only a session’s moderators can ask for one (our servers check that). Ready or Not and the AI search helper run only when someone uses them; nothing runs on a schedule.
Is our data encrypted in transit and at rest?
All connections are encrypted: browsers and the app’s Forge functions reach our servers only over https and wss, and our servers reach the database over TLS, which MongoDB Atlas requires for every connection. At rest, MongoDB Atlas encrypts the database’s storage and its backup snapshots, as it does for every cluster.
Who in our Jira site can use the app and its data?
The app opens inside your Jira site, for people signed in to it. Only Jira admins can change the app’s site settings, including Enable AI. Only a session’s moderators can ask for AI hints. Ready or Not writes to Jira only when someone asks it to, as that person, so their Jira permissions apply.
Where is our data held, and can we choose the region?
Your data is held in Europe: stored in London (UK) and processed in Stockholm (Sweden). If your organisation needs United States hosting, talk to us at support@agilepulse.co. Sessions shared with laya.net are held by laya.net in the United States, its one hosting region today: see laya.net’s international data transfers. When someone uses an AI feature, the text sent is processed by OpenAI in the United States. Atlassian’s data residency settings do not cover data on our servers.
Which sub-processors does the app use?
The app uses Atlassian, MongoDB Atlas, Amazon Web Services, OpenAI, laya.net. The Sub-processors table above says what each does, with which data and where.
What happens to our data when we uninstall the app?
Nothing on our servers is deleted when the app is uninstalled: the app has no uninstall step. To ask for your site’s data to be deleted, email privacy@laya.net.
How do we report a security issue or an incident?
Email support@laya.net, with "Security report" in the subject line. Include the steps to reproduce it, and never passwords or tokens. If a security incident affects your data, we tell you without undue delay after we become aware of it, with what we know: what happened, which data was involved, the likely effects and what we have done. Where the full picture is not yet clear, we send what we have and follow up.
Do you hold SOC 2 or ISO 27001?
LayaNet LTD does not hold a SOC 2 report or an ISO 27001 certificate, for this app or any other. The cloud providers we use, such as Atlassian and Amazon Web Services, hold certifications for their own platforms; those cover their infrastructure, not this app or LayaNet LTD. On the Atlassian Marketplace, the app is in Atlassian’s Cloud Fortified and Marketplace Bug Bounty programmes.
Contact
- Security: support@laya.net, with "Security report" in the subject line. Please never include passwords or tokens.
- Privacy and deletion requests: privacy@laya.net.
- Support: the Agile Pulse support portal, or support@agilepulse.co.
Email support@laya.net and include what you expected, what happened, and a link to the affected board or item so we can help quickly.