> 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/21.-privacy-security-and-compliance.md).
# 21. 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]).
***
### 21.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 most important takeaway of this chapter:** by default, FullSession **does not mask most input text** — it only protects a few built-in fields (section 21.2). If your pages contain other sensitive data, you must add masking rules. Read the next section carefully.
***
### 21.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 three **built-in, non-editable** masking rules that protect the most common sensitive fields automatically:
* `input[type=password]` — password fields
* `input[type=hidden]` — hidden inputs
* `[autocomplete*=cc-]` — credit-card fields
These can't be removed.
#### ⚠️ Everything else is captured by default
> **Inputs and on-page text are NOT masked by default** beyond the three built-in rules above. FullSession captures the text a visitor sees and types unless you add a rule. **If your pages show or collect other sensitive information** — names, emails, addresses, phone numbers, account numbers, health or financial data — **you must add masking or exclusion rules for those elements.** Don't assume sensitive data 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.
> **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].
***
### 21.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].
***
### 21.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.
***
### 21.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.
***
### 21.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.
***
### 21.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 21.6).
> **Your responsibility checklist** — mask sensitive elements (21.2), decide on IP/geolocation collection (21.3), exclude internal users (21.4), avoid sending sensitive data as attributes (21.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 only for password, hidden, and credit-card fields — *everything else is captured unless you mask it*), 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 22 — Admin Console] covers account-wide administration — the customer and usage views available to account administrators.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.fullsession.io/21.-privacy-security-and-compliance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.