Security & trust
Built to be reviewed, not just trusted
TRACER365 is self-hosted: it runs on infrastructure you control, reads your Microsoft 365 sharing metadata read-only, and stores everything it finds locally — the vendor never receives your findings. This page is the detail a security reviewer needs — including an explicit list of what the product deliberately does not do.
Where it runs
Your infrastructure, your data
TRACER365 runs entirely on infrastructure you control — your server, your network, your local database. Self-hosted isn't a licensing footnote; it's the architecture. There is no vendor cloud in the request path.
The application authenticates directly to your Microsoft 365 tenant with credentials you generate and hold, reads sharing and permissions metadata over Microsoft's own APIs, and stores the results locally. Storrex — the vendor — never receives your findings, your tenant data, or your credentials. Your audit data never leaves your environment.
Precisely what that means, and what it does not. Nothing is uploaded, synced, or reported to a Storrex endpoint. It does not mean the product sits still. Left alone it reaches outside the machine in exactly three ways. A scheduled scan wakes on its own timer and connects to your tenant over Microsoft's APIs; that is the job. Mail goes out through the relay you configure, to the recipients you name: the post-scan findings digest, plus operational notices that carry no findings at all, among them an alert when a scheduled scan fails, an advisory when one is repeatedly skipped, and a warning as a connector's certificate nears or passes expiry — none of it carrying an attachment, and none of it sent at all if you configure no relay. And the optional update check, which ships turned off, fetches a version file on its own timer once you switch it on, carrying nothing about your tenant or your findings. Everything else is you taking data out deliberately: an operator can export findings to a file, and the management console serves them over your network; which machines can reach it is your own network configuration, not something the product enforces. Every path that carries your findings stays inside your own environment and under your own controls, which is exactly what the sentence above claims. It is also the part your reviewers can test for themselves rather than take on trust.
No vendor cloud in the path
The interface loads nothing external
Credentials stay with you
Permissions
Read-only, and verifiable in your own tenant
TRACER365 authenticates to Microsoft Graph and the SharePoint REST API using certificate-based, app-only authentication — the current Microsoft-recommended pattern for this class of integration. App-only means there is no signed-in user and no delegated permissions at all: there is no end-user sign-in path into your tenant.
Your tenant administrator grants the read-only application permissions below with admin consent. Because the app registration lives in your tenant, your security team can open it at any time and verify every line of this list — and that nothing on it can write.
Application permissions requested (all read-only)
| Permission | Used for |
|---|---|
Files.Read.All (Graph) | Read drive items and their permissions for the sharing analysis |
Sites.Read.All (Graph) | Enumerate SharePoint sites and read site-level metadata |
User.Read.All (Graph) | Resolve display names and sign-in names (UPNs) for the principals on a sharing grant |
Group.Read.All (Graph) | Enumerate Microsoft 365 groups and map sites to their backing group |
Sites.Read.All (SharePoint REST) | Identify a site's default groups, so default-group membership isn't mis-classified as external exposure |
Deliberately not requested
Sites.FullControl.Allon either API;Directory.ReadWrite.AllorUser.ReadWrite.All;- any
Mail.*,Calendar.*orContacts.*permission; - any delegated permission of any kind — the application is app-only.
A deliberate trade-off worth naming
Microsoft Graph offers a delta-query mode that makes change-detection scans more efficient — but the permission it requires is tenant-wide Sites.FullControl.All: full control over every SharePoint site in your tenant. TRACER365 declines that mode by design. A read-only tool that asked for full control in order to do its job would undercut the very posture it exists to demonstrate — so the product forgoes the optimisation and stays within read-only scope. We will not request write-capable access to your tenant in order to audit it.
Credentials at rest
How stored secrets are protected
The credentials the application stores locally — the connector certificate, its private-key password, and any SMTP relay password you configure — are held under authenticated symmetric encryption: AES-128 in CBC mode for confidentiality, HMAC-SHA256 for integrity, with a fresh random initialisation vector on every write, so identical secrets never produce identical ciphertext. Tampering with a stored value — even a single byte — is detected and rejected on read, not silently accepted.
The encryption key is generated fresh, locally, on each installation. It is never shared, never embedded in the application, and never the same across customers; on Windows the key file should be restricted at the OS level to the service account and the local Administrators group — standard file-ACL practice, not a special mechanism.
One honest limit, stated here because a reviewer will ask: the application does not encrypt the full local database. Findings, scan history and the audit trail are ordinary database records, not secrets. If you need those protected at rest as well, apply host-level disk encryption such as BitLocker — it is in the non-goals list below.
Operator roles
Who inside your organisation can do what
TRACER365 has its own operator-role model, separate from the Microsoft 365 permissions above — those govern what the product may read from your tenant, not who inside your organisation may use the product.
Admin — configuration
Viewer — the auditor persona
Two design decisions we want a security reviewer to read as deliberate, not oversights:
- The DSAR person-lookup and its export are reachable by the Viewer role on purpose. The Viewer is the auditor persona whose job is to answer "what is this person shared on" — gating that behind the Admin (configuration) role would put privacy-response work in the wrong hands, not the right ones.
- The Viewer retains the ability to mark findings as reviewed. That is a state-changing action, which makes the role functionally a reviewer, not a read-only viewer — we describe it by its actual rights, not its current label.
Enforcement is a single, fail-closed authorization mechanism applied consistently across the application: every route is explicitly assigned to a role, a route added without a role decision fails closed rather than defaulting to open, and every denial it issues is written to the audit trail.
Audit trail
A local record of what happened
The application keeps a local audit log of security-relevant events in three categories: security events (sign-in success and failure, account lockout, password changes, authorization denials), administrative actions (connectors created, updated or deleted; users created or disabled; settings changed; certificates uploaded or rotated), and system events (scheduled scans starting and completing, credential-decryption failures). Every row carries a UTC timestamp, the acting user where applicable, the action, and enough detail to reconstruct what changed.
One event a reviewer should note is the authorization denial: when the fail-closed mechanism refuses a privileged request because the signed-in user's role isn't permitted to make it, that refusal is recorded. In this version of the application, audit-log rows are not deleted — the trail is retained in full for the life of the installation's database.
What it does not do
The non-goals, stated plainly
An explicit list of what TRACER365 does not do is more useful to a security reviewer than a feature list — it tells you exactly where your own controls need to pick up the slack. None of these are oversights; each is a deliberate boundary with a clear owner.
| Not provided | What covers it instead |
|---|---|
| Full-disk or full-database encryption | Host-level disk encryption (e.g. BitLocker) on the machine running the application |
| Multi-factor authentication for the application's own login | Host-level identity controls — Windows Hello, an MFA-protected jump host, or RDP-level MFA in front of the machine |
| Hardware Security Module (HSM) key storage | The per-installation key is a file protected by standard OS access-control lists; for HSM-grade protection, run on a dedicated host with TPM-bound disk encryption |
| Integration with a centralised secret manager (e.g. a cloud key vault) | Not currently offered; the application manages its own local credential store, described above |
| Judging intent, or comparing findings against your internal policy | The product surfaces exposures; deciding whether a given share is "a violation" is the customer's call |
When a scan can't see everything
TRACER365 fails toward showing you more, not less.
The product is deliberately conservative about clearing a finding. A previously-flagged exposure is marked resolved only after the product positively re-confirms it is gone — a share it re-checked and found removed, or an item it confirmed deleted.
When a scan fails, is cancelled, is throttled by Microsoft, or can't reach a resource, the findings under that resource stay open rather than being cleared — and the same is true for any part of your tenant a scan doesn't cover, such as a site or drive you have excluded from it. When coverage is uncertain, a gap surfaces as a finding still on your list, not one that has quietly dropped off it.
Licensing
No licensing server, no usage reporting
TRACER365 ships with no licensing server. A licence is a self-contained, cryptographically signed string you paste into the application's settings; verification happens entirely on your own machine, with no network call of any kind. The key that can create a valid licence exists only on infrastructure Storrex controls and is never in the shipped application — the shipped app holds only the public key, which can check a signature but cannot forge one. A missing, malformed or tampered licence is always treated conservatively: the application falls back to its unlicensed trial state rather than silently granting access.
Two honest limits. A licence key is not technically locked to a machine — because verification is fully offline, the scope is held by contract and intent, not by a machine-lock mechanism; treat a key with the same care as any other credential. And the licensed scope itself — one Installation auditing up to two Microsoft 365 tenants — is a contractual bound, not something the software counts, meters or reports: TRACER365 performs no licence-usage reporting of any kind.
Compliance frameworks
Two senses of "complies", kept separate
Does the product help you meet a requirement?
Yes — for one specific, recurring requirement that appears across nearly every relevant framework: knowing who can access what, especially externally, on a recurring schedule, with results a reviewer can act on. TRACER365 provides evidence toward the access-control requirement in GDPR Article 32, ISO/IEC 27001 controls A.5.15 (access control) and A.8.12 (data-leakage prevention), and SOC 2 Trust Services Criteria CC6 (logical access).
That is evidence for your own access-control review — an input to your compliance programme, not a substitute for it. Using TRACER365 does not, on its own, make your organisation compliant with any framework.
Is the vendor itself certified?
For a self-hosted product with no vendor-side data processing, this is largely not applicable — there is no vendor-side handling of your data to certify.
We treat that architectural fact as a meaningful answer to the question rather than a gap: the data a certification would cover never reaches us in the first place.
Request the full security overview
The document your security team would receive
The full security overview covers the threat model, the at-rest crypto detail, and the complete non-goals and out-of-scope tables. Ask us for it and we'll send it over.
It is also the right channel for a security-review conversation — we're glad to walk your team through the read-only app-registration scopes before you install anything.
The form couldn't submit just now — please reload the page and try again shortly.