Trust and security: SprintRetro
Where SprintRetro 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
SprintRetro is a retrospective app for Jira Cloud, built on Atlassian Forge, sold as SprintRetro (free) and SprintRetro Pro. Its retros 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. This page covers the Jira apps.
Each Agile Pulse app is built differently, so each has its own trust page; this one covers SprintRetro. 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 | SprintRetro (free), SprintRetro Pro (paid) |
| Platform | An Atlassian Forge app that uses Forge Remote: its screens run in Jira, and its retros are kept and run on our own servers. SprintRetro and SprintRetro Pro 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 (SprintRetro Dashboard, AI settings), enforced by our servers. |
| Personal data | Atlassian account ids, and comment authors’ display names, 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 SprintRetro 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 SprintRetro inside Jira, signed in with their Atlassian account.
- SprintRetro reads from Jira as it works. In Jira: the issues people create from action items, when they choose to.
- The app’s Forge functions call our servers to run retros (cards, comments, votes, polls and action items) 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 retro. 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.
- Our application servers keep uploaded files and whiteboard images with Amazon S3, on Amazon Web Services, in London (UK). Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.
- 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: who wrote or voted for anything (no account ids, names, avatars or email addresses; anonymous cards are treated the same), and no Jira issue descriptions or Jira comments. 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 when someone connects Miro or Mural to import a board: our servers reach that service with the connection the person made.
- Only when someone searches for a GIF: the browser sends the search words, and a random id kept in the browser, to KLIPY. Not your Atlassian identity. Sent over HTTPS (TLS).
- The browser loads public files from file delivery networks, an emoji service and Google’s web services. Our code sends no retro content to them.
- Only if someone opens the product demo: the browser shows it in a frame from the demo’s own service.
The SprintRetro 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 the people in a retro and of whoever adds a card, comment, vote, poll or action item, and comments keep their author’s display name. Anonymous cards and comments show no author in the app, but our servers still store the author’s account id with them, and comments also keep the author’s display name.
In your Atlassian site
- Retro content is kept on our servers, not in your Atlassian site.
- Jira itself: the issues people create from action items, when they choose to.
On our servers
- Retros: name, board and sprint, settings, and who took part (Atlassian account ids and roles).
- Cards, comments, votes, polls, action items, ice breakers, sprint goals, health checks and whiteboard notes, with the account id of whoever added them. Comments also keep the author’s display name.
- Sprint Replay snapshots: Jira issue ids, keys and titles, status and story point changes, the sprint’s name and dates.
- AI results: sprint reports, replay stories, action quality scores and rewrites, Facilitator themes and suggestions (which can repeat a card’s text), and theme labels with their embeddings.
- Miro or Mural connections, only for people who connect one to import a board.
What we never store
- Jira issue descriptions, Jira comments and attachments.
- Email addresses.
- The prompts sent to OpenAI: each is built for one request and deleted straight after.
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.
| Feature | When it runs | What is sent | What we keep |
|---|---|---|---|
| Generate Sprint Report (SprintRetro Pro) | When someone in the retro clicks to generate it. | The key and title of each completed issue in the sprint, and the sprint’s numbers: velocity, predictability, committed and delivered points, scope change, carryover and median cycle time. | The report, saved with the retro. |
| Sprint Replay story | When someone in the retro clicks Generate narrative. | The sprint’s events (up to 120): date, event type, issue key and title, story point changes and status changes, and the point totals. | The story, saved with the sprint’s replay. |
| Action quality score | When someone who can edit an action item clicks Score. | Only the action item’s text. | The score, grade and suggested rewrite, saved on the action item. |
| Facilitator panel and theme memory | When a retro’s moderator runs the panel. | Each card’s title and description (up to 400 characters each), up to 5 comments per card (up to 200 characters each), vote counts, and poll questions, options and votes; on a whiteboard, the notes’ text. Theme matching sends only the AI’s own theme labels. | Themes, suggested rewordings (which repeat the card’s text) and suggested actions, saved with the retro. Theme labels and their embeddings, saved per board to spot recurring themes. |
Never sent to OpenAI: who wrote or voted for anything (no account ids, names, avatars or email addresses; anonymous cards are treated the same), and no Jira issue descriptions or Jira comments. Text people typed into cards, comments and action items is sent as typed, including any names in it.
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, with its retro, 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 SprintRetro Dashboard, choose AI settings and switch AI off. Our servers then refuse every new AI request from that site.
The Sprint Report needs SprintRetro Pro, and the Facilitator panel is for a retro’s moderators. Each feature runs only when someone uses it; 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) |
| Uploaded files and whiteboard images | Amazon S3, on Amazon Web Services | London (UK) |
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. 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 |
|---|---|---|
retrospectapi.agilepulse.co | Your browser and the app’s Forge functions | Our servers: retros, 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"). |
api.klipy.com | Your browser | GIF search: the search words and a random id kept in the browser, not your Atlassian identity. |
cdn.jsdelivr.net, unpkg.com, emoji-api.com, www.googleapis.com, www.gstatic.com | Your browser | Public web services the app’s Forge permissions let the browser reach: file delivery networks (cdn.jsdelivr.net, unpkg.com), an emoji service (emoji-api.com) and Google’s web services (www.googleapis.com, www.gstatic.com). Our code sends no retro content to them. |
miro.com and app.mural.co | Our servers | Only when someone connects Miro or Mural to import a board. |
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 Jira. | What the app shows 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 |
| KLIPY | GIF search in the browser. | Search words and a random browser id. | 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 retro or a card marks it deleted, and the record stays in our database. Nothing expires automatically.
- Atlassian’s personal data reporting: The app does not use Atlassian’s personal data reporting yet, so a closed Atlassian account’s id, and the display name on its comments, stay in past retros.
- Logs: Our servers keep their application log files for 3 days and their error log files for 14 days. Each request is also written, with its IP address, to the server’s console log, which is kept until it reaches a size limit rather than for a set number of 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.
- AI requests are checked before they run: the retro must belong to your Jira site, and, for the Sprint Report and the Facilitator, the person must take part in it.
- 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. Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.
- 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.
Which data is sent to the AI?
Generate Sprint Report (SprintRetro Pro): The key and title of each completed issue in the sprint, and the sprint’s numbers: velocity, predictability, committed and delivered points, scope change, carryover and median cycle time. Sprint Replay story: The sprint’s events (up to 120): date, event type, issue key and title, story point changes and status changes, and the point totals. Action quality score: Only the action item’s text. Facilitator panel and theme memory: Each card’s title and description (up to 400 characters each), up to 5 comments per card (up to 200 characters each), vote counts, and poll questions, options and votes; on a whiteboard, the notes’ text. Theme matching sends only the AI’s own theme labels. Never sent to OpenAI: who wrote or voted for anything (no account ids, names, avatars or email addresses; anonymous cards are treated the same), and no Jira issue descriptions or Jira comments. Text people typed into cards, comments and action items is sent as typed, including any names in it.
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, with its retro, 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 SprintRetro Dashboard, choose AI settings and switch AI off. Our servers then refuse every new AI request from that site. The Sprint Report needs SprintRetro Pro, and the Facilitator panel is for a retro’s moderators. Each feature runs only when someone uses it; 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. Uploaded files and whiteboard images are kept in Amazon S3 in London (UK), encrypted at rest, with public access blocked.
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. Before an AI feature runs, our servers check that the retro belongs to your Jira site, and, for the Sprint Report and the Facilitator, that the person takes part in it. Scoring an action item needs the right to edit it. The Facilitator panel is for a retro’s moderators.
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. 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, KLIPY. 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.