---
title: Data Handling
description: What 1Security reads, what it actually stores, where it runs, how long data is kept, and what happens when you disconnect - the answers a security review asks for.
icon: ShieldCheck
---

# Data Handling

1Security reads a lot about your tenant, which makes "what happens to it?" a fair question - and usually the first one a security review asks. This page answers it in the order those reviews tend to go.

## What is read, and what is stored

The distinction matters more than the volume. Most of what 1Security touches is read, evaluated and discarded; what persists is the map, not the material.

| Data | Read | Stored |
| :--- | :--- | :--- |
| Identities, groups, roles, devices, apps, agents | Yes | Yes - metadata only (names, IDs, membership, timestamps, licence assignment) |
| Sites, files, folders, links | Yes | Yes - **metadata and permissions**: path, owner, sharing state, who can reach it |
| **File content** | Yes, during a sensitivity scan | **No.** Content is streamed into the analysis process and discarded when it finishes |
| **Email content** | Yes, when the Email module is enabled | **No.** Bodies and attachments are analysed in the same transient way |
| Sensitivity findings | - | The detection **type**, the match count and a confidence bucket, linked to the file. The matched values themselves are not written to the database |
| Activity (unified audit log) | Yes | Yes - actor, action, resource, app, device, location, timestamp |

<Callout type="info">
  The practical summary customers care about: 1Security never becomes a second
  copy of your documents or your mailboxes. It becomes a copy of who can reach
  them and what was done with them.
</Callout>

## How sensitivity scanning analyses content

The [sensitivity engine](/en/docs/sensitivity) runs **in your deployment's own process**:

- **Detectors are deterministic** - over 300 regular-expression and keyword detectors, plus validation rules such as checksum tests on card and identifier formats.
- **OCR runs locally** - images and scanned documents are processed offline inside the same process, not sent anywhere.
- **No third-party AI service sees file content** in the default configuration. Optional LLM-assisted analysis exists for harder cases, is gated per tenant, and falls back to the deterministic detectors whenever AI is disabled for the tenant.

## Where the data lives

| Model | Where processing and storage happen | Fits when |
| :--- | :--- | :--- |
| **Cloud (SaaS)** | 1Security's managed environment | You want zero infrastructure. Setup is minutes. |
| **BYOC (Azure)** | Your own Azure subscription, using our container images | Data residency rules require the data to stay in your cloud |
| **On-Premise** | Your own hardware, air-gapped if needed | Full control of location and network boundaries |

Deployment specifics, sizing and cost estimates are in [Installation](/en/docs/installation).

### Tenant isolation

Every connected tenant gets its **own dedicated database** by default, not a shared table with a tenant column. A query issued for one tenant physically cannot reach another tenant's rows. On top of that, every tenant-scoped table carries the tenant identifier and every query filters on it - the isolation is enforced twice, at the infrastructure layer and in the query layer.

The one deliberate exception is a [tenant group](/en/docs/connecting-tenants#one-dashboard-for-several-tenants-combining): tenants an admin explicitly **combines** into one dashboard share one database. That is a choice your own admin makes at connect time, it can only join tenants of your own organization, and the query-layer tenant scoping still applies to every read and write. Two different customers never share a database.

This is also what makes multi-tenant scenarios safe for MSPs and holding companies: connecting a second tenant adds a database (unless you combine it on purpose), it does not widen the blast radius of the first.

## Access inside 1Security

Reading your tenant is one permission question; who inside your organisation can read it in 1Security is another. Three access levels are available when inviting a user:

- **Sync with Microsoft 365** - admin status follows the person's existing Entra roles.
- **Admin** - full access to all resources, settings and connected tenants.
- **User (limited access)** - sees only their own resources: files, emails, groups and sites they own or interact with, plus trends explicitly shared with them.

Before inviting a limited user you can preview exactly what they will see. Details in [Getting Started](/en/docs/getting-started#managing-accounts-and-access).

## Write access

The base installation cannot change anything in your tenant. Write permission exists in exactly two opt-in modules - [Automations](/en/docs/screens/automations) and Mailbox Management - and even once enabled:

- Actions are **staged behind a review queue** with a grace period before anything executes.
- Every action is recorded in a ledger you can replay - what was proposed, who approved it, what actually changed.
- Mailbox actions quarantine or flag; they do not permanently delete.

The exact permission each module requests is listed in [Requirements](/en/docs/requirements#permissions-module-by-module).

## Retention

- **Activity history** is retained for as long as your subscription is active, up to **three years**. Three years of continuous subscription means three years of history available for investigation - far past Microsoft's default audit retention.
- **Sensitivity findings and the permission graph** reflect the current state of the tenant and are refreshed by [scans](/en/docs/scans); historical trend points are kept so you can see direction of travel.

## Disconnecting and deletion

Disconnect a tenant from **Settings → Tenants → Disconnect**. All data associated with that tenant is removed from 1Security **within 7 days**.

Disconnection removes the tenant's data entirely: a standalone tenant's dedicated database is removed as a whole, and a combined tenant's data is deleted from the database its own group shares. Either way there is no residue in another customer's dataset - a database is only ever shared inside one organization, by that organization's own choice.

Revoking consent in Microsoft Entra also cuts access immediately, independently of anything done in 1Security: the application's tokens stop working the moment consent is withdrawn.

<Callout type="warn">
  Disconnecting is not the same as pausing. Once the deletion completes, the
  activity history built up under that tenant is gone - reconnecting starts the
  three-year window again from the data Microsoft still holds, which is usually
  90 days.
</Callout>

## AI catalog feedback

1Security classifies your apps by AI capability (Copilot-powered, running the
vendor's own model, hybrid) and lets admins correct or enrich that
classification. Those admin-submitted reports can be shared back to the
1Security AI catalog so every customer's classification improves - a
crowd-sourced knowledge base no single tenant could build alone.

What this channel does, precisely:

- **What is sent**: global app identifiers (the Microsoft application ID, app
  name, publisher), the proposed classification, an optional admin note, and
  a pseudonymous deployment ID. One batch per day.
- **What is never sent**: tenant or user identities, file names or contents,
  agent instructions, activity data, or any report the admin marked *"do not
  share outside my organization"*.
- **Control**: sharing is on by default and can be turned off per tenant in
  **Settings → Integrations**, where a *view sample payload* control shows the
  exact JSON the next send would transmit. Self-hosted operators can disable
  the channel entirely with `AI_TELEMETRY_ENDPOINT=''`; air-gapped
  installations are unaffected (the sender silently no-ops).
- **Audit**: every consent change and every transmission is recorded in the
  audit trail, and each send appears in the tenant's activity log as a
  **1Security** entry ("Agentic feedback has been sent").

## Geolocation feedback

1Security classifies the networks behind sign-ins and activity (datacenter,
VPN, Tor, ordinary ISP) and geolocates them. Cloud providers reshuffle IP
ranges faster than any public dataset tracks, so admins can report
corrections ("this range is an Azure datacenter", "wrong country") - and
those network-fact reports can be shared back so geolocation improves for
every customer. Vetted corrections ship to all deployments as a curated
overlay file; raw reports are never applied to other customers directly.

What this channel does, precisely:

- **What is sent**: public network identifiers (ASN, network operator name),
  the observed and proposed classification, an optional admin note, dataset
  version markers, and the same pseudonymous deployment ID the AI channel
  uses. One batch per day.
- **What is never sent**: tenant or user identities, IP addresses, activity
  data or event counts, company locations, trusted/suspicious judgments,
  reports marked as describing your own infrastructure ("this is our
  corporate VPN"), or any report the admin marked *"do not share outside my
  organization"*. These exclusions are enforced server-side, not just in the
  form.
- **Control**: a separate consent from the AI channel - on by default,
  toggled per tenant in **Settings → Integrations** on the same
  classification-feedback card, with its own *view sample payload* control.
  Self-hosted operators disable it entirely with `GEO_TELEMETRY_ENDPOINT=''`;
  air-gapped installations are unaffected (the sender silently no-ops).
- **Audit**: consent changes and transmissions are provenance-recorded, and
  each send appears in the tenant's activity log as a **1Security** entry
  ("Geolocation feedback has been sent").

The AI catalog and geolocation feedback channels are the only traffic a
self-hosted deployment's *server* sends to 1Security - there is no license
phone-home, version ping, or usage telemetry. (The geo *dataset downloads* -
public IP databases, cloud provider range files, the Tor exit list, and
1Security's curated overlay - are inbound fetches of public data and carry
nothing outbound.)

## Error and crash reports

Two browser-side channels also carry data out of the page a user is on, and
belong in the same transparency list:

- **The in-product error dialog** ("Report this problem") sends whatever the
  user types, an optional contact email, and - only while the checkbox stays
  ticked - technical diagnostics (route, browser, error digest). The report
  goes to the platform's own error log: 1Security's environment on Cloud
  (SaaS), your own deployment's database on BYOC/On-Premise.
- **Crash telemetry** (Sentry) reports client-side errors with stack traces
  and page context - never file contents or message bodies. Self-hosted
  environments that must not emit any browser telemetry can block the Sentry
  host at the network layer; the application is unaffected.

## Frequently asked in security reviews

<Accordions>
  <Accordion title="Do you store our files?">
    No. File and email content is read during analysis and discarded when the
    analysis finishes. What persists is metadata, permissions, and the type and
    count of any sensitive information detected.
  </Accordion>
  <Accordion title="Is our content sent to an AI provider?">
    Not in the default configuration. Detection is deterministic - regular
    expressions, keyword rules and validation checks - and OCR runs locally.
    Optional LLM-assisted analysis is gated per tenant and falls back to the
    deterministic detectors when AI is disabled.
  </Accordion>
  <Accordion title="Can 1Security change anything in our tenant?">
    Not unless you enable Automations or Mailbox Management. The base
    installation holds read permissions, with the one documented exception of
    SharePoint's `Sites.FullControl.All` scope, which SharePoint's own API
    requires to expose sharing configuration - see
    [Requirements](/en/docs/requirements#core-visibility---read-only-granted-at-install).
  </Accordion>
  <Accordion title="Can we keep all data inside our own cloud?">
    Yes - the BYOC model runs the whole platform in your Azure subscription, and
    the On-Premise model runs it on your own hardware, air-gapped if required.
    The optional exceptions are the [AI catalog feedback](#ai-catalog-feedback)
    and [geolocation feedback](#geolocation-feedback) channels - global app and
    network identifiers only, each off per tenant with one toggle, off entirely
    with one environment variable, and a no-op when air-gapped.
  </Accordion>
  <Accordion title="What happens to our data if we stop being a customer?">
    Disconnect the tenant and everything associated with it is deleted within 7
    days. Revoking application consent in Entra cuts access immediately in the
    meantime.
  </Accordion>
</Accordions>