← Back to home

Trust and data handling

Security reviews start with one question: does the platform hold our personal data? It does, and this page says exactly which fields, why each one is needed, how long it is kept, and what you can switch off.

Last reviewed: August 31, 2026

Yes, and only the directory metadata the findings are built from

Unsave is an identity and posture product. A finding like “this account holds Owner at subscription scope” is worthless without the name of the account, so we store display names, user principal names and object IDs for the principals that appear in your Azure, Entra, Windows 365 and GitHub estate. We do not store what those people produce.

Never read, never stored

  • Blob, file and disk contents
  • Database records inside your resources
  • Key Vault secrets, keys and certificates
  • Document and email bodies. The SharePoint scan reads sharing settings and site URLs only
  • Application code and configuration values
  • Passwords, MFA secrets and payment card data

Stored, per the map below

  • Principal display names and object IDs on role assignments
  • User principal names on Windows 365 Cloud PCs
  • Group names and membership lists
  • GitHub logins, verified emails and SSO identities
  • The sign-in identity of your own Unsave users
  • Credential expiry dates and key fingerprints

Data map, field level, by source

This is the complete set of personal fields the platform persists. Anything not listed is either derived state, resource configuration with no person attached, or not collected.

SourcePersonal fields storedWhy it is neededRetention
Your Unsave sign-inname, email, alternate emails, Entra object ID, last loginAuthentication, matching invites across UPN and mail aliases, and role assignment inside your organization.Life of account
Azure RBACprincipal ID, display name, principal type, scope, roleNaming who holds privileged roles. A finding that says an unnamed object holds Owner cannot be acted on.Your policy
Entra directorygroup ID, group name, member lists, effective access pathsResolving inherited access. Group nesting is where standing privilege usually hides.Your policy
Windows 365user principal name, display name, device name, last login resultAttributing a Cloud PC to its assigned user for provisioning, grace period and licence waste views.Your policy
App registrationsowner IDs, credential expiry dates, assigned permissionsExpiring secret alerts, routed to the person who owns the registration.Your policy
GitHub EnterpriseOptionallogin, name, verified emails, SAML name ID, SSH and GPG fingerprints, credential authorizationsSeat waste, two-factor coverage, and which credentials are SSO authorized against your orgs.Your policy
SharePoint sharingOptionalsite name, site URL, sharing stateCopilot readiness. Finds anonymous and org-wide links before Copilot surfaces them. No file contents, no file names.Your policy
Platform activityactor ID, action, target, timestamp, IPYour audit trail of what was viewed and changed inside Unsave.90 days
Administrator actionsactor ID, action, target, timestampA separate, longer trail covering support and platform administrator access.365 days

What holds it in place

Access

Read-only by default

The core connection consents to read scopes only, such as Directory.Read.All and the Azure Reader role. The only write permissions in the product belong to the optional Cloud PC operations module and require their own separate consent.

Access

Consent per capability

Scopes are grouped by module. Declining Copilot readiness or Cloud PC operations means those permissions are never requested, and the rest of the platform reports as healthy rather than broken.

Collection

Field allowlists, not raw dumps

Collectors request a named list of fields from Microsoft Graph rather than whole objects. The Cloud PC collector, for example, selects 24 named fields. A property we do not ask for never reaches our network.

Storage

Canadian residency

Account data and tenant metadata live in Azure Canada Central: PostgreSQL flexible server, container apps, and a Key Vault scoped to each environment.

Storage

Encryption

Encrypted at rest by the platform, and TLS 1.2 or higher in transit with HSTS enforced. Connection secrets and integration tokens carry a second layer: AES-256-GCM with a unique initialization vector per value, keyed from Key Vault.

Isolation

Row-level tenancy

Every stored row carries its organization, customer and tenant ID, and every query is scoped through them. Inside your organization, role-based access applies, plus a separate per-user gate on the GitHub section.

Lifecycle

Retention you set

Your organization carries a retention window. A nightly job deletes history past it across posture, compliance, cost, scan and Cloud PC tables, backed by scheduled database jobs that hold fixed ceilings on logs regardless of configuration.

Lifecycle

Revocable in one step

Consent is yours. Removing the enterprise application in your tenant severs collection immediately. There is no agent to uninstall and no inbound network path into your estate.

What you decide before signing

Retention window
Name the number of days. We set it on your organization and the nightly purge enforces it. Common choices are 30, 90 or 365.
Scope of estate
Connect a single subscription or a non-production tenant first. Nothing outside the subscriptions you select is read.
Optional modules off
GitHub, SharePoint sharing and Cloud PC operations are separately consented. Left off, their permissions are never requested and their tables stay empty.
Breach notice
Notification within 72 hours of becoming aware, naming the data affected and the steps taken.
Named subprocessors
Microsoft Azure for hosting, Stripe for billing, PostHog for product analytics, Sentry for error monitoring. Analytics and error monitoring can be disabled for your organization on request.

Things a security review should hear from us first

Stated as current limitations, not roadmap.

  • No SOC 2 or ISO 27001 certification yet. We hold no third-party attestation today. What we can share instead is our internal security audit and its remediation log, our infrastructure definitions, and this data map.
  • Encryption keys are ours, not yours. Secrets are encrypted with a platform key held in Key Vault. Customer-managed keys are not available today.
  • Product analytics run on the front end. PostHog and Sentry see page views, browser details and error traces tied to a user ID. Neither receives Azure tenant metadata, and both can be disabled for your organization.
  • Names are stored, not pseudonymized. Display names and user principal names sit in the database as read. If you need identifiers only, with names resolved live from your tenant at render time, ask and we will scope it as a dated commitment rather than claim it now.

A reasonable way to start

One subscription, a 30 day retention window, and every optional module off. Run it for two weeks, ask us at any point in that window for an export of what we hold, and widen the scope only once your team is satisfied with what the data map turned out to contain.

Questions from a security or privacy review go to privacy@unsave.io. See also our Privacy Policy and Terms of Service.