Security and data handling
This page is written for your security review. It lists the exact Microsoft Graph permissions, what the registry stores and where, and what leaves your environment, which is Microsoft Graph and nothing else.
At a glance
- All registry and audit data stays in your own PostgreSQL database, wherever you run it.
- Outbound connections go only to Microsoft Graph and Microsoft Entra sign-in. No telemetry, no licence server, no call to IDE Solutions.
- Read-only access to the directory. The only non-read permission is
Mail.Send, used to email owners. - Administrators sign in with Microsoft Entra ID. There are no local accounts.
- The audit log is append-only, enforced by a database trigger.
Microsoft Graph permissions
The scanning service uses its own app registration with application permissions and client-credentials sign-in. These are all of them:
| Permission | Type | Used for |
|---|---|---|
User.Read.All | Application | Validating owners against Entra ID and reading sign-in activity, so a departed owner is noticed on the next scan |
Group.Read.All | Application | Microsoft 365 groups, Teams and security groups, and their current owners |
Directory.Read.All | Application | Directory objects the narrower scopes do not cover |
Sites.Read.All | Application | SharePoint site inventory (optional scan type) |
Application.Read.All | Application | Service principals and app registrations (optional scan type) |
AuditLog.Read.All | Application | Last sign-in data, which separates "unused" from "in use but ownerless" |
Mail.Send | Application | Sending attestation emails and reminders to owners |
There is no permission and no code path for modifying or deleting anything in your tenant. Declined or unanswered objects are escalated by email to your service desk for a human to decide, never removed automatically.
One point to handle during onboarding: an application-level Mail.Send grant can send as any mailbox by default. The registry only ever sends from the one sender address you configure, and we recommend scoping the grant to that mailbox with an Exchange Online application access policy (or RBAC for Applications), so the tenant enforces it too.
Sign-in and access
- The admin interface signs in with Microsoft Entra ID using the authorization-code flow with PKCE. The API validates every token against your tenant’s signing keys.
- Two app roles:
Registry.Admincan change data,Registry.ServiceDeskcan read. Every non-read API call requires the admin role. - Owners answering an attestation email need no account: each link carries a single-use random token, and it records one answer.
- The development mode without sign-in is refused against a connected tenant unless someone overrides it explicitly in configuration.
What is stored, and where
The registry stores the objects it inventories (name, type, identifiers, last activity), their assigned primary and backup owners, attestation requests and answers, and the audit log. It does not read mailbox content, files or messages.
Everything lives in a PostgreSQL 17 database that you run: in a Docker volume on your host, or in Azure Database for PostgreSQL in your subscription. Nothing is stored outside your environment, including in the managed option, where we operate the deployment against your tenant rather than copying data out of it.
Audit trail
Every scan result, email, reminder, answer and escalation is written to an append-only log. A database trigger rejects any update or delete on that table, so no code path, including a future bug, can rewrite history. Entries are kept indefinitely, and each object’s page shows its complete trail, which is the history you need for an ISO 27001 A.5.18 or NIS2 review.
Hosting and network
- Runs as Docker containers: the application (Node.js 22, TypeScript, Fastify) and PostgreSQL 17.
- Needs no inbound connection from Microsoft. It only calls out to Graph.
- Put it behind your existing reverse proxy or ingress for TLS, the same way you expose any internal web app.
Who builds it
Ownership Registry is built and operated by IDE Solutions UG (haftungsbeschränkt), Breitfeldweg 21, 63829 Krombach, Germany, registered at Amtsgericht Aschaffenburg under HRB 17253. Full company details are in the Impressum.
If we operate the registry for you, the contract includes a data processing agreement under Art. 28 GDPR. If you run it yourself, we have no access to your data at all.
Security review questions
Can Ownership Registry delete or change anything in our tenant?
No. Its permissions are read permissions plus Mail.Send, and the code has no write path. The most it can do about a stale object is email your service desk.
Does any of our data leave our environment?
No. The registry talks to Microsoft Graph and Entra sign-in and nothing else. There is no telemetry and no connection to IDE Solutions.
Can we restrict which mailbox it sends email from?
Yes, and we recommend it. Scope the Mail.Send grant to the sender mailbox with an Exchange Online application access policy or RBAC for Applications during onboarding.
How long is audit data kept?
Indefinitely. The audit table accepts inserts only, and a database trigger blocks updates and deletes, so the full history stays available for audits.
Take this into your security review
We walk your security team through the permissions and the architecture during the demo, against your own tenant. Book a demo