Data Handling
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.
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 |
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.
How sensitivity scanning analyses content
The sensitivity engine 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.
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: 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.
Write access
The base installation cannot change anything in your tenant. Write permission exists in exactly two opt-in modules - 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.
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; 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.
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.
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
Integrations & Modules
One connection to Microsoft 365, every surface in one map - Entra, SharePoint, OneDrive, Teams, Exchange, Intune, Azure, Copilot and the audit log - plus the opt-in modules that extend it.
Permission Graph
One interactive map of every identity, resource, and permission in your tenant - so "why does this user have access to this file?" becomes a path you can see, not a project.