Security & data handling
If you are trusting us with your operation's data, you should be able to read exactly how it is handled in two minutes. This page is that reading.
Your operational requests live in your Microsoft 365 tenant — SharePoint remains the system of record for request state. This is the standard model for every pilot: the SharePoint lists the pilot runs on are provisioned in your tenant, not ours. JFS OPS keeps separate, append-only audit and reliability records so there is a tamper-evident history of what happened and when. We do not build a second, competing copy of your data.
Sensitive stored values — notification channel webhook URLs and per-pilot SharePoint connection bundles — are encrypted with AES-256-GCM before they are written to the database. The encryption keys live in the hosting platform's environment configuration, separate from the data they protect. In transit, all calls to Microsoft's APIs use HTTPS, and the site itself is served over HTTPS.
Access is invite-only. There is no public signup and no self-service registration — accounts are created by invitation, and every account has one of three defined roles: admin, operator, or requester. Requesters do not get accounts at all: they check request status through token-gated links that are random and unguessable, bound to a single request, expire automatically in 7–30 days, can be revoked at any time, and only ever show requester-relevant fields. Every access attempt on those links is logged.
Two kinds of connection, both least-privilege. Users sign in with their own Microsoft accounts — JFS OPS never asks for or stores their passwords. The SharePoint service connection uses an app registration in your Entra ID with a client secret, granted the SharePoint Sites.Selected permission and scoped to the single site your IT admin approves — not tenant-wide access. Secrets live in the hosting platform's environment configuration — never in code, never in chat, never in files that ship with the product.
Every request lifecycle event — created, assigned, escalated, resolved, closed — is mirrored into a separate event record in Supabase. Each record stores an immutable snapshot of what changed, who did it, and when, so the history of a request cannot be quietly rewritten. Reporting exports (CSV and print-friendly) are built from these records, which is how audit history is handed over on request in standard formats.
We do not sell data, share it with third parties for marketing, or use one customer's operational data to benefit another. Requester email addresses are masked in the queue — full contact details appear only where the role genuinely needs them.
Your data stays yours. On off-boarding, your tenant data remains in your tenant, audit records are exported to you on request, and access is revoked. There is no lock-in mechanism and no hostage data.
Honest limits
Questions?
Security reviews, data-processing questions, tenant architecture — bring them to the first conversation, not the last. Found a security issue? Tell us directly at john@jfsops.com or through the contact page.
