top of page

What Are We Actually Storing - And Should It Be There At All?

Updated: Jul 24

Agile In Government Contexts
Practical Answers to Frequently Asked Questions in Agile Story Writing And Digital Delivery.

What Are We Actually Storing - And Should It Be There At All?


In a recent post, I shared my thoughts on why data residency and access control should be treated as core delivery concerns - not just IT decisions. We looked at where collaboration tools store our project data, who can access it, and how poor oversight can lead to governance risks, legal exposure or audit failure.


Knowing where our data is stored is only part of the story.


Trello, Miro, Jira, Confluence - these tools have become the digital backbone for many Agile teams. They help us organise, collaborate and make delivery work visible - but somewhere along the way, they also started absorbing a different kind of content: research notes, interview transcripts, evidence packs and even screenshots of users in action.


It is convenient. But is it safe?


Even when used by internal teams, these tools often involve third-party hosting and flexible permissions. A quick upload like dropping in a screenshot or document can unintentionally expose personal information. A participant’s name might appear in a tab, a photo might show identifying details, or digital whiteboard content might include quotes or observations linked to specific individuals. On their own, these fragments of information may seem harmless - but together, they can reveal far more than intended.


For public sector teams, the stakes are higher. You may be subject to Freedom of Information (FOI) requests which allow members of the public to request recorded information held by public bodies under the Freedom of Information Act 2000 as well as GDS assessments or internal audits.


Under the FOI Act, this can include research outputs such as discovery notes, interview summaries or design artefacts - if they inform public service delivery. Any personal data about individuals other than the requester must be redacted or withheld but when sensitive research material is stored in tools like Jira, Miro or Confluence - often outside formal records management processes there is a higher risk that they may be overlooked, incompletely redacted, or shared by mistake during an FOI response. These tools are not designed to act as secure evidence repositories and often lack the audit controls needed to manage that risk.


Separately, GDS assessors may ask where user research is stored, how access is controlled and whether any personal data is handled in line with your organisation’s policy. If your service includes vulnerable users or sensitive topics, this scrutiny will be stronger. Uploading research evidence to Jira, Miro or similar platforms - especially those hosted overseas or shared with suppliers can raise avoidable concerns. The safer option is to store personal or potentially sensitive information in a secure, approved system and link to it where needed.


Sensitive content such as raw research data, recordings, transcripts or anything personally identifiable should not be uploaded directly to collaboration tools. Instead, store them in your organisation’s approved system, such as SharePoint, Google Workspace (if permitted), AWS S3 or another controlled environment with audit logs, access controls and UK-based data residency.


If that material needs to be referenced in a story, task or epic, link to it - do not embed it. Ensure the link points to a protected location with restricted, time-limited access, and avoid public URLs or open folders. Clearly indicate what the document is, who can view it, and whether it has been redacted or anonymised.


Anonymising screenshots or recreating examples with dummy data is another effective approach. It allows you to share insights without compromising privacy or compliance.


Before uploading any research artefact into a collaborative space, pause consider:


  • Would I be comfortable showing this board to a governance lead, GDS assessor or audit team?

  • Could I explain where the data came from, who can see it, and why it is stored there?


If not, there is still time to fix it.



Thank you for reading this post. I hope you found it interesting and thought-provoking. I enjoy hearing how others approach these questions, so your perspective in the comments is always welcome.


UserResearch DataProtection AgileDelivery PublicSectorDigital InformationGovernance

© 2023 UK Scrum Academy Limited

Website by Random Analysis Design Studio

bottom of page