Loom Data Privacy Concerns Explained (2026)

A screen recording is dense with data. The pixels capture whatever is on screen — code, messages, customer information, financial figures, internal dashboards. The audio captures whatever is said, which often includes things that would not be written in an email. The metadata captures who recorded, when, where, on what device. When all of this lives on a third-party service, the privacy posture of that service becomes the privacy posture of the recording itself.

Loom's privacy practices are documented publicly in its privacy policy, sub-processor list, and SOC 2 attestation. This piece walks through what those documents actually say, how the Atlassian acquisition changes the data flows, where the genuine concerns sit, and what teams under HIPAA, GDPR, CMMC, or similar frameworks should consider. The framing is neutral — Loom is not unusual in its privacy posture for a SaaS product, but every team has to evaluate whether that posture matches their own data classification.

This is not legal advice. Compliance teams should review the actual policy documents and sub-processor list with counsel before making procurement decisions.

What data Loom collects

Loom's privacy policy enumerates several categories of data collection. The summary below is based on the public policy as of early 2026.

Recording content. Every screen recording, webcam track, and audio track uploaded to Loom is stored on Loom's infrastructure. Recordings are retained according to user-tier policies (free tier currently caps at 25 videos before older recordings are hidden; paid tiers have higher or unlimited caps). Deletion is user-initiated; videos remain in storage until explicitly deleted.

Transcription data. Audio tracks are processed to generate searchable transcripts and captions. The transcripts are stored alongside the video and are searchable in the user's library. AI-generated summaries (on AI-enabled tiers) are also stored.

Viewer analytics. When a viewer opens a Loom recording link, Loom captures the view event, viewer's IP address, approximate location, device type, browser, watch duration, where the viewer paused, where they commented, and whether they shared the link further. This data populates the sender's analytics dashboard.

Account and team data. User accounts include email, name, profile photo, team affiliation, billing details (for paid tiers), and authentication tokens. Team data includes member roles, library structure, folder permissions, and integration tokens for Slack, Jira, Confluence, and similar.

Usage telemetry. App and browser extension telemetry includes feature usage, recording attempts, errors, performance metrics, and session length. This data is used for product analytics and improvement.

Cookies and tracking pixels. The Loom website and viewer pages set cookies for session management, analytics (Loom uses analytics vendors disclosed in the policy), and marketing attribution.

The list is comprehensive but not unusual for a SaaS recording platform. Vidyard, Cap.so hosted, Tella, and similar platforms collect substantively similar categories. The differentiation is in retention policy, encryption, sub-processor relationships, and access controls — covered below.

Where the data is stored

Loom's infrastructure runs on AWS. The privacy policy and sub-processor disclosure list AWS regions in the US (us-east-1, us-west-2) and EU (eu-west-1, Ireland) as primary storage locations.

EU customers can request EU data residency on Enterprise tiers. The free, Starter, and Business tiers default to US residency. For teams with GDPR strict requirements, the residency configuration matters — US-stored data crosses the Schrems II line and requires Standard Contractual Clauses plus a Transfer Impact Assessment.

Recording media (the actual video files) are stored in S3 buckets with server-side encryption. Database content (account data, metadata, analytics) is stored in managed database services with encryption at rest. Transit is TLS 1.2+ end-to-end.

Backups are stored in geographically separate AWS regions for disaster recovery. The privacy policy notes that backup retention extends beyond active deletion windows, which means a user-initiated deletion of a video does not immediately purge all copies. The standard backup retention for Loom is on the order of weeks rather than months, but this is not the same as immediate purge.

For teams whose data residency requirements mandate that data physically remains in a specific jurisdiction, the disaster-recovery cross-region replication matters. EU-region recordings have backups that may live in adjacent EU regions; this is generally acceptable under GDPR but may not satisfy stricter regional rules in regulated industries.

Atlassian data sharing post-acquisition

The October 2023 Atlassian acquisition introduced a new dimension to Loom's data flows. As Loom integrates into Atlassian Cloud, the privacy posture changes in several ways.

Account integration. Loom workspaces are migrating to Atlassian-account-based authentication. Once migrated, account data (email, name, organizational affiliation, authentication state) is shared with Atlassian's identity layer.

Cross-product analytics. Atlassian's broader product suite (Jira, Confluence, Bitbucket) operates on a unified analytics infrastructure. As Loom integrates, usage telemetry may flow into the same infrastructure. Atlassian's privacy policy governs this — the relevant sections are about cross-product feature analytics and personalization.

Sub-processor changes. Loom's pre-acquisition sub-processor list was specific to Loom (AWS, transcription vendors, analytics vendors, support tools). The post-integration list expands to include Atlassian's standard sub-processors. The total surface area of third parties with potential access to Loom data is larger.

AI training questions. Atlassian's AI products (Atlassian Intelligence) operate under broad terms that historically have not used customer content for model training without opt-in. Loom-specific terms reiterate this: recordings are not used to train general-purpose AI models. However, Loom's own AI features (transcription, summarization, viewer questions) do process recordings on Loom-controlled infrastructure to generate user-facing AI outputs.

Data export and portability. Atlassian's account model affects export procedures. Pre-acquisition, individual Loom workspaces could export independently. Post-migration, exports flow through Atlassian's account management. For teams considering migration off Loom, the migration guide covers the export procedure step-by-step.

The integration is not complete as of early 2026 — it is rolling out across the customer base over multiple quarters. Different workspaces are at different points in the migration. The privacy posture of an individual workspace depends partly on which side of the migration it sits on.

GDPR compliance status

Loom's GDPR posture rests on four pillars:

EU data residency option. Enterprise tier supports EU-only residency. Lower tiers do not.

Data Processing Addendum (DPA). Loom offers a standard DPA that covers Article 28 processor obligations. Enterprise customers can negotiate amendments.

Standard Contractual Clauses (SCCs). For US-region data flows from EU customers, SCCs are in place. Schrems II additional safeguards (Transfer Impact Assessment) are documented.

Subject access rights. GDPR Articles 15-22 (access, rectification, erasure, portability, objection) are supported through user account controls and a privacy request submission process.

For most GDPR-compliant uses, Loom's documentation is sufficient. The areas where teams under stricter interpretations push back:

• The free, Starter, and Business tiers default to US residency. Many EU teams discover this after-the-fact when reviewing data flows.
• The cross-product analytics integration with Atlassian creates a documentation gap that some compliance teams find under-specified.
• Backup retention beyond user-initiated deletion creates a tension with the right to erasure, though this is a common SaaS pattern and is documented.
• Sub-processor changes post-Atlassian require explicit notification to DPA signatories. The notification cadence has been sufficient but adds review overhead.

For teams in EU public sector, German Mittelstand operating under stricter privacy regimes, or any organization where DSGVO compliance is audited externally, the friction is enough that some teams move to self-hosted alternatives. The self-hosted alternatives breakdown covers options that eliminate the third-party processor question entirely.

Who has access to the data

Access controls inside Loom segment by role and necessity. The categories:

Loom employees. Loom engineering, security, support, and infrastructure teams have role-based access to systems that store recordings. Access is logged. The privacy policy and SOC 2 audit confirm that access requires business justification and is reviewed.

Atlassian employees. Post-integration, Atlassian's identity, security, and infrastructure teams have access to overlapping systems. Atlassian operates under similar access-control regimes per its SOC 2 Type II.

Sub-processors. AWS infrastructure teams have access to encrypted storage but not encryption keys (server-side encryption with Loom-managed keys). Transcription vendors process audio tracks and have time-bounded access to recording audio. Analytics and support vendors have access to telemetry and account metadata but generally not to recording content.

Law enforcement. Loom's privacy policy includes the standard provision for legal process (subpoenas, warrants, court orders). Loom commits to the standard transparency-report cadence and notice-where-permitted policy.

For teams whose threat model includes insider risk at the SaaS provider, this access map matters. A recording uploaded to Loom is accessible to Loom employees with business need, Atlassian employees with business need, and any sub-processor in the data flow. None of these are unusual for SaaS — but for highly sensitive content, the access surface is wider than for self-hosted or local-only architectures.

Specific concerns by industry

Different regulated industries have different points of friction with Loom's privacy posture.

Healthcare (HIPAA). Loom offers a Business Associate Agreement (BAA) on Enterprise tier only. Free, Starter, and Business tiers are not HIPAA-eligible. Healthcare organizations using Loom on lower tiers and recording PHI are operating outside the BAA boundary. The BAA on Enterprise covers AWS as a sub-processor (AWS has its own BAA with Loom). Teams handling PHI should either upgrade to Enterprise with explicit BAA execution or move to alternatives that handle PHI more transparently.

Financial services (GLBA, SOX). SOX-relevant recordings (financial data, audit trails) typically require records-management policies that may not align with Loom's deletion-and-backup model. Recording retention for SOX is typically 7 years with immutable storage; Loom's storage is mutable by design. Some financial firms use Loom for non-SOX content (training, internal communication) and explicitly avoid Loom for SOX-relevant content.

Legal services. Attorney-client privilege concerns arise when recordings could capture privileged content. Loom's terms do not waive privilege, but the practical concern is that recordings on third-party infrastructure create discovery obligations and chain-of-custody questions. Some firms restrict Loom usage to non-privileged communications.

Government and defense (FedRAMP, CMMC). Loom is not currently FedRAMP authorized. Federal agencies and defense subcontractors generally cannot use Loom for any recording that could include controlled unclassified information (CUI). CMMC Level 2 contractors handling CUI need FedRAMP-authorized or equivalent infrastructure; Loom does not qualify.

EU public sector (DSGVO strict). Public-sector procurement in Germany, France, and several other EU jurisdictions requires data-residency commitments that exceed what Loom's standard tiers offer. Enterprise EU residency may satisfy procurement; lower tiers typically do not. Several public-sector buyers have moved to self-hosted alternatives for this reason.

Education (FERPA). US schools recording teaching content with student data in frame need FERPA-compliant data handling. Loom's K-12 EDU tier addresses some of this with explicit FERPA contractual commitments. General Loom tiers do not include FERPA-specific provisions.

For teams crossing these regulatory boundaries, the practical answer is often a two-tool approach: Loom or similar for non-regulated content, and a local-only or self-hosted recorder for regulated content. The Mac-native alternatives roundup covers Mac options that satisfy local-only constraints.

What changes after the Atlassian integration completes

The Atlassian integration is rolling out incrementally. The full state, projected for 2026-2027, will include:

Unified Atlassian account. All Loom workspaces will authenticate through Atlassian's identity stack. The current dual-state (some workspaces on legacy auth, some on Atlassian auth) will resolve toward Atlassian-only.

Cross-product feature integration. Loom recordings embedded in Jira issues and Confluence pages will become a primary distribution path. The data flow between products tightens.

Shared analytics. Atlassian's product analytics infrastructure will absorb Loom's. User behavior across Loom, Jira, Confluence, and Bitbucket will be analyzable in unified dashboards (with the associated privacy implications).

Bundled pricing. Loom may become a feature of Atlassian Cloud bundles rather than a standalone product for some customer segments. The standalone tiers remain for now.

Expanded sub-processor list. As features integrate, the sub-processors backing Atlassian Cloud become Loom sub-processors. The list grows.

For privacy-conscious teams, the trajectory is unambiguously toward more integration and broader data flows. Teams that want to lock in their current privacy posture before further integration may consider migrating sooner rather than later. Teams that prefer the integrated Atlassian experience may consider the integration a benefit. The procurement decision depends on which side of that line the team sits.

The Loom pricing breakdown post-Atlassian covers the cost dimension of the integration; this piece covers the privacy dimension. Both interact in the procurement decision.

What enterprises should consider before procurement

For teams evaluating Loom in 2026, a privacy review should cover at minimum:

1. Data classification mapping. Catalog what types of data your team would record. PHI, financial data, customer PII, internal-only material, public-facing demos. Different classifications drive different requirements.

2. Tier selection. The free, Starter, and Business tiers do not include BAAs, do not default to EU residency, and do not include enterprise-grade DPA terms. Many teams discover this after deploying Loom widely; doing the homework first saves a re-procurement.

3. Sub-processor review. Loom's sub-processor list (and Atlassian's, post-integration) should be reviewed against your own approved-vendor list. Sub-processor disclosures change; subscribe to the notification feed.

4. Retention and deletion policy. Loom's default retention is "indefinite until user deletes." Teams with retention obligations (delete after X days for compliance) need to either build their own deletion automation or evaluate alternatives with configurable retention.

5. Backup retention windows. Confirm with Loom Enterprise contract that backup retention aligns with your right-to-erasure obligations. The standard retention may extend beyond what your DPA requires.

6. Incident response. Confirm Loom's breach notification timeline (currently 72 hours per GDPR). Confirm that your team's incident response plan integrates with Loom's reporting.

7. Migration exit plan. Procurement decisions should include an exit plan. Loom's export functionality covers most of the workflow, but full migration of large libraries with metadata preserved takes weeks. The migration guide covers the steps.

8. Sensitivity-based tooling split. For teams whose recordings span multiple data classifications, a tooling split (Loom or similar for non-regulated, local-only or self-hosted for regulated) is often the cleanest answer. This adds operational complexity but isolates risk.

For teams that conclude Loom does not fit their privacy requirements, the self-hosted alternatives breakdown covers options where the privacy posture is fundamentally different. For Mac-first teams with privacy requirements, the Mac-native alternatives covers local-only options.

Privacy-focused alternatives

For teams where Loom's privacy posture does not fit, the following alternatives present different trade-offs.

Cap.so self-hosted. Open-source AGPL-3.0 codebase. Deploy on infrastructure you control. Recordings never touch a third-party cloud. Includes Loom-style share links. Trade-off: operational overhead.

Screenify Studio in offline mode. Mac-native recorder. Records to local disk. Optional cloud share that the user controls per-recording. Free tier without watermark. Trade-off: Mac-only.

OBS Studio. Open-source GPL-2.0. Local-only by design. No cloud component. Trade-off: no built-in sharing platform; no automatic share links.

Kap. Open-source MIT. Local-only Mac recorder. Simple interface. Trade-off: no sharing platform; no advanced editing.

PeerTube. Open-source AGPL-3.0 federated video platform. Pair with a local recorder for a self-hosted async-video stack. Trade-off: server operations; not a single-tool solution.

Nextcloud Talk + local recorder. For teams already on Nextcloud, async video can flow through Nextcloud Files with a local recorder. Trade-off: not Loom-style; requires existing Nextcloud deployment.

MediaRecorder API custom build. For teams with development capacity, building a Loom-equivalent on the browser's MediaRecorder API and self-hosted infrastructure is a 2-4 week project that delivers complete control. Trade-off: ongoing maintenance.

The right alternative depends on the team's data classification, infrastructure capacity, and workflow requirements. For most regulated teams, the practical answer combines local-only recording with the team's existing internal sharing infrastructure (SharePoint, Nextcloud, internal CDN) — eliminating the third-party processor question entirely.

FAQ

Is Loom GDPR compliant? Loom offers a DPA, supports SCCs for US data flows, and maintains EU residency on Enterprise. For most GDPR uses, the documentation is sufficient. For stricter interpretations or public-sector procurement, the gaps in lower tiers and post-Atlassian sub-processor expansion may require closer review.

Does Loom train AI on my recordings? Loom's stated policy is that recordings are not used to train general-purpose AI models. AI features (transcription, summarization, viewer questions) process recordings on Loom-controlled infrastructure to generate user-facing outputs. Specific terms are documented in the privacy policy and AI features documentation.

Where exactly is my data stored? AWS US regions by default for free, Starter, and Business tiers. AWS EU (Ireland) on Enterprise with EU residency selection. Backups in adjacent regions for disaster recovery.

Who at Atlassian can see my Loom recordings? Atlassian employees with role-based access for support, security, and infrastructure operations. Access is logged and audited. Atlassian does not generally view recording content; access is for system operation rather than content review.

Can I delete my recordings completely? User-initiated deletion removes recordings from active systems. Backups retain copies for the standard backup window before complete purge. For immediate-purge requirements, a deletion-confirmation request to Loom support documents the timeline.

Is Loom HIPAA compliant? Only on Enterprise tier with explicit BAA execution. Lower tiers do not include BAAs and are not HIPAA-eligible for PHI.

What happens to my data if I cancel Loom? Recordings remain accessible in read-only mode for the cancellation window (typically 30-90 days depending on tier). After that, deletion proceeds per the retention policy. Export should happen during the cancellation window — see the migration guide for the procedure.