> For the complete documentation index, see [llms.txt](https://docs.fullsession.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fullsession.io/privacy-security-compliance.md).
# 22. Privacy, Security & Compliance
FullSession records real user sessions, so controlling **what** gets captured is essential. This chapter covers the privacy tools FullSession provides — masking and excluding content, IP and geolocation controls, excluding internal users, and managing the data you send — plus an honest account of FullSession's security posture and where your own responsibilities lie.
Most of these controls live under **Settings → Privacy Rules**, **Settings → Excluded Users**, and **Settings → Custom Attributes**, each gated by its own permissions (\[Chapter 16 — Team & Account Management]).
***
### 22.1 What FullSession Records — and the Privacy Toolkit
FullSession's tracker reconstructs what a visitor saw and did: the page's DOM and styles, mouse movement, clicks, scrolls, navigation, console and network activity, and any identity, events, or attributes you choose to send ([Chapters 3](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)–[7](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)).
Because that includes whatever text is on the page, FullSession gives you controls to keep sensitive content out:
| Control | What it does | Where |
| ------------------------------ | -------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Element recording rules** | Mask or exclude specific page elements | Settings → Privacy Rules |
| **IP Address Collection** | Stop collecting visitor IPs | Settings → Privacy Rules |
| **Lon/Lat recording** | Stop collecting precise geolocation | Settings → Element Tracking |
| **Total session length limit** | Cap how long a session records | Settings → Privacy Rules |
| **Page recording rules** | Stop recording certain URLs | Settings → Privacy Rules ([Chapter 7](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)) |
| **Excluded emails** | Stop recording specific people | Settings → Excluded Users |
| **Custom attributes** | Review/remove the data you send | Settings → Custom Attributes |
#### The Talk to User chat widget
If you use [Talk to User](/talk-to-user.md), the chat widget is recorded like any other element on the page. You'll see the chat panel replayed inside a session, and what a visitor types into it is captured by the recorder, subject to the masking rules in section 22.2. The conversation transcript is still kept separately with the conversation in the inbox. Two consequences worth knowing:
* Anything a visitor types into the chat — including personal details they volunteer — is captured in the session recording just like other page text, so make sure your masking rules (section 22.2) cover the widget if it collects sensitive fields. It's also kept in the conversation transcript, stored separately from the session.
* If you turn on **Ask for name and email before the first message**, you are collecting those details deliberately. Treat them as you would any other contact data you gather — and remember they may also appear in the recording since the widget isn't excluded.
> **The most important takeaway of this chapter:** by default, FullSession **masks all input fields** automatically — but it does **not** mask other on-page text. If your pages display sensitive data outside of input fields, you must add masking rules. Read the next section carefully.
***
### 22.2 Masking & Excluding Page Elements
**Element recording rules** are your primary privacy tool — *"Mask or fully exclude specific DOM elements so their content is never sent to FullSession."* You target an element by CSS selector and choose how it's treated.
#### The three actions
| Action | Effect | What's captured |
| ---------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------- |
| **Exclude element entirely** | The element is omitted completely from recording | Nothing — it isn't in the recording at all |
| **Mask element** | Text is hidden | Text is omitted, but interactions and change events are still captured |
| **Unmask element** | The element is fully captured | All text, interactions, and change events — an exception within a masked area |
**Exclude** is the strongest (the element doesn't exist in the replay); **Mask** preserves the layout and interaction signals while hiding the actual text; **Unmask** is used to *re-enable* a specific element inside a broader masked region.
#### What's protected out of the box
FullSession ships with four **built-in, non-editable** masking rules that protect the most common sensitive fields automatically:
* `input` — all input fields
* `input[type=password]` — password fields
* `input[type=hidden]` — hidden inputs
* `[autocomplete*=cc-]` — credit-card fields
These can't be removed.
#### ⚠️ Non-input on-page text is captured by default
> **Input fields are masked automatically**, but **other on-page text is NOT masked by default.** FullSession captures text that visitors see on the page unless you add a rule. **If your pages display other sensitive information outside of input fields** — names, emails, addresses, phone numbers, account numbers, health or financial data shown as plain text — **you must add masking or exclusion rules for those elements.** Don't assume sensitive data outside inputs is hidden automatically.
#### Adding a rule
1. Go to **Settings → Privacy Rules → Element recording rules**.
2. Add a rule with:
* **Selector** *(required)* — the CSS selector for the element(s), e.g. `.account-number` or `#ssn-field`.
* **Action** — Exclude, Mask, or Unmask.
* **Rule Exception Element Selectors** *(optional)* — selectors to *exclude from* this rule.
* **Note** *(optional)* — context for your team.
3. Save. New rules apply to sessions going forward.
#### Discovering elements to mask
If you're unsure which elements on your site may be exposing PII, the AI-powered **Suggest Rules** feature can scan a set of recorded sessions and propose selectors automatically — see \[Chapter 7, section 7.3] for how to start a scan and review suggestions.
> **Tip** — coordinate with engineering to add stable hooks (a class or `data-` attribute) to sensitive elements, and review masking after any site redesign so a markup change doesn't expose newly sensitive content. Masking is also covered from the configuration angle in \[Chapter 7, section 7.3].
#### AI Recommended Rules
If you're not sure which elements to target, the **Recommended Rules** tab (next to Element recording rules in Privacy Rules settings) can help. It scans a selection of already-recorded sessions with AI and proposes candidate selectors for elements containing likely PII — names, emails, payment data, government IDs, and more. Evidence previews are always redacted; no raw PII is shown. See \[Chapter 7, section 7.3] for how to review, accept, and dismiss recommendations.
***
### 22.3 IP, Geolocation & Recording Scope
#### IP Address Collection
A simple toggle controls whether IPs are stored: *"Choose whether visitor IP addresses are collected alongside session data."*
* **On** — IP and the geolocation derived from it are collected.
* **Off** — IP addresses are not collected. (Location detail that depends on IP is correspondingly reduced.)
#### Precise geolocation (Lon/Lat)
Separately, under **Settings → Element Tracking → Data Recording Rules**, the **Lon/Lat Recording** toggle controls whether precise longitude/latitude coordinates are recorded. With it **disabled**, FullSession falls back to coarser IP-based location only.
The same panel includes a toggle for recording **frustration signals on short text elements**, letting you tune how much per-session detail is captured.
#### Limiting recording length
The **Total Session Length Recording Rule** caps how long a single session records: *"Set a maximum recording duration — sessions that exceed it are automatically stopped."*
* Toggle it on, enter a value, and choose **Seconds** or **Minutes**.
* The maximum is **2 minutes (120 seconds)**; the default is **no limit**.
#### Limiting which pages record
To keep entire pages out of recording (e.g. an account or admin area), use **Page recording rules** — covered in \[Chapter 7, section 7.2].
***
### 22.4 Excluding Internal Users
To keep your own team's testing out of your data, use **Excluded Users** (**Settings → Excluded Users**) — *"Block specific email addresses from being recorded — useful for excluding internal team traffic."*
#### How it works
* Click **Add Email** and enter an address (e.g. `qa@yourcompany.com`).
* When a visitor is **identified** (\[Chapter 4 — Identifying Users]) with a matching email, their **entire session is excluded** from recording and processing — it's never sent, and doesn't count toward your quota.
* You can edit or remove entries at any time.
Exclusion is by **email**, so it relies on the user being identified with that email. For broader patterns, see how identification and exclusion work together in \[Chapter 4, section 4.4].
> **Exclusion happens at recording time and can't be undone.** An excluded session is never captured, so you can't retrieve it later. If you need to record your own sessions for debugging, remove yourself from the list temporarily.
***
### 22.5 Custom Attributes & Avoiding Sensitive Data
The **Custom Attributes** page (**Settings → Custom Attributes**) lets you *"View and manage custom properties passed via your JS snippet."* It lists every attribute you've sent through the tracker (\[Chapter 4, section 4.3]), with its name and type, and lets you **delete** ones you no longer want.
#### A privacy checkpoint
Because attributes are data **you** choose to send, this page is a useful audit point:
* **Review** what's being sent — make sure no attribute is carrying sensitive PII it shouldn't (e.g. don't send raw government IDs or full payment details as attributes).
* **Delete** attributes that are unnecessary or were sent by mistake.
* Remember attribute **values must be strings** (\[Chapter 4, section 4.3]), and that whatever you send becomes searchable across the app — so send only what you genuinely need.
> **Tip** — keep identity to what you need (the built-in `name`/`email` on `identify`, plus a stable user ID), and avoid putting sensitive personal data into custom attributes or custom-event properties in the first place.
***
### 22.6 Data Retention & Deletion
#### How long sessions are kept
Recorded sessions are retained for a period determined by your **plan** (see \[Chapter 5, section 5.7] and \[Chapter 17 — Billing & Subscriptions]). Retention isn't a per-site setting you configure — it follows your plan.
#### Automatic clean-up
FullSession automatically removes sessions that have little value or have aged out, for reasons such as **no recorded events**, **missing page data**, a **deletion rule**, an **expired** session, or **manual deletion**. This keeps your data focused on sessions worth reviewing.
#### Deleting a specific person's data
> **There is no self-service "delete this user's data" / right-to-erasure button in the app.** If you need to erase a specific individual's recorded data (for example, to fulfill a data-subject request), this isn't something you can do yourself in the settings — work with FullSession to action it. Plan your processes accordingly.
***
### 22.7 Compliance & Security — and What's Your Responsibility
It's important to be clear about what FullSession **provides** versus what **you** must handle.
#### What FullSession provides
* **Privacy controls** — masking/exclusion, IP-off, geolocation-off, excluded emails, session-length and page limits (this chapter and [Chapter 7](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)).
* **Access security** — role-based access control ([Chapter 16](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)), **SSO/SAML** ([Chapter 18](https://claude.ai/epitaxy/local_f5f6ba49-6bd2-4e30-b58d-b88360e08610)), and an **audit log** of administrative actions (\[Chapter 16, section 16.6]).
* **Encryption** — customer data is encrypted in transit and at rest.
#### What FullSession does *not* provide (you handle these)
Be explicit with your own privacy/legal teams — the following are **not** built-in product features:
* **No consent-management / cookie-consent UI** inside FullSession. If your jurisdiction requires consent before recording, **gate the tracker yourself** — for example, only load the snippet (or fire the GTM tag) after the visitor accepts analytics consent (\[Chapter 3, section 3.2]).
* **No data-residency / region-selection** options.
* **No in-app DPA, privacy-policy, or consent-record** management.
* **No "Do Not Track" honoring, visitor opt-out widget, or automatic anonymization** toggle.
* **No self-service data erasure** (section 22.6).
> **Your responsibility checklist** — mask sensitive elements (22.2), decide on IP/geolocation collection (22.3), exclude internal users (22.4), avoid sending sensitive data as attributes (22.5), gate recording behind consent if required, and route any data-subject/erasure requests to FullSession.
> **The big picture** — FullSession gives you concrete tools to control capture: **Exclude/Mask/Unmask** element rules (with built-in protection for all input fields as well as password, hidden, and credit-card fields specifically — *non-input on-page text is captured unless you mask it*), an AI-powered **Suggest Rules** scan to help identify what needs covering, an **IP toggle**, a **Lon/Lat toggle**, a **session-length cap**, **page rules**, and **excluded emails**, plus a **Custom Attributes** audit page. Access is secured with **RBAC, SSO, audit logs, and encryption**. But consent management, data residency, anonymization, DNT/opt-out, and self-service erasure are **not** product features — so handle consent and data-subject requests through your own processes and with FullSession directly.
***
> **Next up:** \[Chapter 17 — Billing & Subscriptions] covers plans, member-seat limits, and the subscription controls referenced throughout this chapter.
